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 126.96.36.199 (Linux) the word "Definition" in the image is correctly shown
However, in LO 188.8.131.52 (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.
Created attachment 130949 [details]
Screenshot - lefft LO 184.108.40.206, right MS PowerPoint 2007 - note in-word spacing of "Definition" and dented right edge cell-border line
Regression introduced by:
author Khaled Hosny <email@example.com> 2016-11-02 21:52:06 (GMT)
committer Khaled Hosny <firstname.lastname@example.org> 2016-11-03 00:17:06 (GMT)
commit 8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533 (patch)
parent c8be45889217c555e4bec92af838d0524ceba4e0 (diff)
Revert "Revert "Enable the new text layout engine by default""
This reverts commit 3950166877bf1308f9e449992e20b558342af825.
Adding Cc: to Khaled Hosny
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!
(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.
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.]
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.
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.
@Bartosz, any thoughts on how Kahled can unwind the EMF+ spacing and use the glyph widths to arrive at correct spacing for ligatures.
*** This bug has been marked as a duplicate of bug 105913 ***