Bug 157390 - Converting PowerPoint PPTX to PDF causes overlap in artistic text characters
Summary: Converting PowerPoint PPTX to PDF causes overlap in artistic text characters
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2023-09-23 09:27 UTC by wei
Modified: 2023-10-18 06:50 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug Show (339.64 KB, application/pdf)
2023-09-23 09:27 UTC, wei
Details
this is the origin ppt file. (2.45 MB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2023-10-11 00:45 UTC, wei
Details
this is the target PDF file (1.96 MB, application/pdf)
2023-10-11 00:47 UTC, wei
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wei 2023-09-23 09:27:04 UTC
Created attachment 189769 [details]
Bug Show

Converting powerpoint to PDF causes overlap in artistic text.
PPT is ok, but PPTX is problematic.
Please get more information from attachment.
Comment 1 ⁨خالد حسني⁩ 2023-09-24 17:23:09 UTC
Please attach the document where this issue happens.
Comment 2 wei 2023-10-11 00:45:59 UTC
Created attachment 190131 [details]
this is the origin ppt file.

The file "powerpoint.pptx" is origin file. Thanks.
Comment 3 wei 2023-10-11 00:47:55 UTC
Created attachment 190132 [details]
this is the target  PDF file

this is the target  PDF file. Thanks.
Comment 4 Stéphane Guillou (stragu) 2023-10-17 16:10:08 UTC
Reproduced in 7.5:

Version: 7.5.7.1 (X86_64) / LibreOffice Community
Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

And recent trunk build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e9374f74385d7dfe77d1902d3d82af20143bc775
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Not reproduced in 7.4:

Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 5 Stéphane Guillou (stragu) 2023-10-18 06:44:03 UTC
Re-saving as PPTX with LO before exporting fixes the issue.

Using the impress_pdf_Export filter, I bibisected with linux-64-7.5 repo to first bad commit caee3eee4bab84fb7e7f438ea1ff43496414f096 which points to core commit:

commit 60fd694ac362e9314f54fa992e31e8baa5bdf80f
author	Khaled Hosny 	Tue Sep 06 00:56:37 2022 +0200
committer	خالد حسني 	Tue Sep 06 15:05:39 2022 +0200
vcl: Add LogicalFontInstance::GetGlyphWidth()
To be used it in PDF export where we need the unshaped glyph width to
calculate PDF glyph adjustments.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139462

At this point, only two characters out of five are visible on the export.

Later on, at build commit e02e4eac04b0750cdd4e82ee0d7962033ca96786, which points to the core commit below, they are in the wrong order, and two of them overlap.

commit e5a797a9beb03b9d9759a94b98107f509a0d5488
author	Khaled Hosny 	Sun Sep 18 13:04:05 2022 +0200
committer	خالد حسني 	Mon Sep 19 13:38:52 2022 +0200
vcl: Fix Type 3 glyph widths
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140126

Khaled, can you please have a look?
Comment 6 Stéphane Guillou (stragu) 2023-10-18 06:50:08 UTC
(In reply to Stéphane Guillou (stragu) from comment #5)
> Re-saving as PPTX with LO before exporting fixes the issue.

(for some reason, this is only true after _deleting_ some other slides and then saving, but not if e.g. moving a picture or editing some other text and then saving...)