Bug 105798 - FILEOPEN: PPTX - EMF image with contained text - text spacing wrong [Regression]
Summary: FILEOPEN: PPTX - EMF image with contained text - text spacing wrong [Regression]
Status: RESOLVED DUPLICATE of bug 105913
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.3.0.2 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:emf, filter:pptx, regression
Depends on:
Blocks: HarfBuzz-regressions EMF-WMF PPTX
  Show dependency treegraph
 
Reported: 2017-02-06 14:25 UTC by Tobias Burnus
Modified: 2018-04-27 04:17 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
PPTX file (PowerPoint 2007) with EMF table image word "Definition" in the image (54.05 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2017-02-06 14:25 UTC, Tobias Burnus
Details
Screenshot - lefft LO 5.3.0.3, right MS PowerPoint 2007 - note in-word spacing of "Definition" and dented right edge cell-border line (18.77 KB, image/png)
2017-02-06 14:27 UTC, Tobias Burnus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2017-02-06 14:25:25 UTC
Created attachment 130948 [details]
PPTX file (PowerPoint 2007) with EMF table image word "Definition" in the image

The attached PPTX file contains a table which is an EMF image. Using MS PowerPoint 2007 (Win 7) or LO 5.2.0.1 (Linux) the word "Definition" in the image is correctly shown

However, in LO 5.3.0.3 (Win 7) and today's MASTER (Linux), the "in" and "io" of "Definition" run into each other (see screenshot).

Additionally, in LO (all versions) but not in PowerPoint the right edge and bottom edge is a bit dented where the horizontal and vertical cell-border lines meet.
Comment 1 Tobias Burnus 2017-02-06 14:27:17 UTC
Created attachment 130949 [details]
Screenshot - lefft LO 5.3.0.3, right MS PowerPoint 2007 - note in-word spacing of "Definition" and dented right edge cell-border line
Comment 2 Xisco Faulí 2017-02-06 15:19:07 UTC
Regression introduced by:

author	Khaled Hosny <khaledhosny@eglug.org>	2016-11-02 21:52:06 (GMT)
committer	Khaled Hosny <khaledhosny@eglug.org>	2016-11-03 00:17:06 (GMT)
commit	8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533 (patch)
tree	db496889434c484a87b13ffcc4650d65e6672129
parent	c8be45889217c555e4bec92af838d0524ceba4e0 (diff)
Revert "Revert "Enable the new text layout engine by default""
This reverts commit 3950166877bf1308f9e449992e20b558342af825.

Adding Cc: to Khaled Hosny
Comment 3 Khaled Hosny (inactive) 2017-02-06 21:20:27 UTC
Something is wrong with the ligatures, they seem to take half their actual width. No idea why the new layout engine would cause this though, clicking on the chart renders it fine in Calc!
Comment 4 Tobias Burnus 2017-02-09 09:09:32 UTC
(In reply to Khaled Hosny from comment #3)
> Something is wrong with the ligatures, they seem to take half their actual
> width. No idea why the new layout engine would cause this though, clicking
> on the chart renders it fine in Calc!

Well, that's two different things. Clicking on the chart loads the embedded .xls file, which is then rendered in Calc. - While in Impress, the embedded .emf file (as rendered created by Excel) is shown. That Excel's EMF and Calc itself render differently, is less surprising.

Looking at the rendering in Paint & Microsoft Office, I have the feeling that the EMF does not contain the "fi" and "ti" ligatures but that LO detects them - and replaces the f + i by fi and t + i by ti. Thus, it looks as if it first calculates the widths (or uses the placements from the EMF) but then replaces the glyphs. That way, it would not be surprising that the result does not fit.

Actually, I believe: if a EMF file does not contain ligatures, LO also shouldn't insert them.
Comment 5 Tobias Burnus 2017-02-09 09:45:27 UTC
Another observation - probably unrelated to this bug:

If I right click and choose "Break", the rendering looks much nicer [both with LO 5.3.0/Win 7 and with LO 4.3.7/Linux]. Result:

The glyph width problem is gone (there are still ligatures), the fonts render much smoother and also the cell-frame lines are thinner and, hence, the right frame is no longer dented.

The result is then the same as loading the EMF in Paint or Microsoft Office (except for the ligatures, which only are in LO).

[As the rendered font is much smoother, I wonder whether that uses the system installed font instead of the embedded glyph. In any case, both systems have the used font installed.]
Comment 6 Khaled Hosny (inactive) 2017-02-09 09:52:58 UTC
We do now enable the ligatures on all platforms, but that is not likely the only reason since we had the ligatures enabled on Linux in 5.2 as well and the width of the ligatures is fine there.
Comment 7 Khaled Hosny (inactive) 2017-02-09 15:59:23 UTC
After some debugging, it turns out EMF+ files not only store the text but the individual glyph width (the dreaded DX array), so after we layout the text and try to apply the DX array we end up giving the ligature the width of its first unligated glyph (e.g. fi gets the width of f). Previously on Linux we would sum the widths and apply them (e.g. fi gets the width of f + the with of i) which is still wrong, but less visibly.

Now I’m not sure what is the way forward. We need to replicate the exact layout settings EMF+ (and thus GDI) uses for any given piece of text if we want to apply the DX array, but it is not clear if EMF+ files carry such information. Or ignore the DX array and risk breaking legitimate uses of it.
Comment 8 V Stuart Foote 2017-04-14 04:48:24 UTC
@Bartosz, any thoughts on how Kahled can unwind the EMF+ spacing and use the glyph widths to arrive at correct spacing for ligatures.
Comment 9 Khaled Hosny (inactive) 2018-04-27 04:17:45 UTC

*** This bug has been marked as a duplicate of bug 105913 ***