Description: When importing an SVG image that has text that has been scaled horizontally (in other words, text with horizontal scaling that differs from its vertical scaling), the text is rendered with the wrong horizontal scale. This bug first appeared in LO 24.2.4.1 (LO 24.2.3.2 works properly). The bug still exists in the current LO 24.8.2.1 version. The bug affects Windows platforms, but not Linux. My guess is that the bug might have been introduced with this commit, but that's just a guess (more about that below): https://git.libreoffice.org/core/+/cc3663bbaed4f65d64154e5f9abb51a5f622f710 Steps to Reproduce: Open the attached ODG file in a version of LO >= 24.2.4.1 on Windows. The file contains an embedded SVG image with 3 lines of monospaced text (Liberation Mono font). All lines use the same font size (height). The top line has 10 characters without any horizontal scaling applied. The middle line has 5 characters with a horizontal:vertical scaling of 2:1 applied. The bottom line has 20 characters with a horizontal:vertical scaling of 0.5:1 applied. The original SVG image file is also attached for reference. Actual Results: All 10 characters of the top line of text are rendered properly. The middle line renders only 3 of the 5 characters, but is the same total length as the top line, implying a horizontal scaling of 10/3=3.333, not 2 (a scaling error factor of 1.67). The bottom line renders only 12 of the 20 characters, but is the same total length as the top line, implying a horizontal scaling of 10/12=.833, not 0.5 (a scaling error factor of 1.67). A PDF is attached which illustrates the incorrect rendering generated by LO 24.2.4.1 on Windows. The same result is obtained when using LO 24.8.2.1. Interestingly, using FontForge to inspect the font metrics of the font used (Liberation Mono Regular) reveals that the font has a design height of 2048 and a width of 1229. That works out to a ratio of 1.666, which is the same as the scaling error factor, so that may be a clue as to what is going wrong. Based on the above observations, these lines of code in the above referenced commit seem like possible candidates for causing the error: https://github.com/LibreOffice/core/blame/cc3663bbaed4f65d64154e5f9abb51a5f622f710/drawinglayer/source/primitive2d/textlayoutdevice.cxx#L183 https://github.com/LibreOffice/core/blame/cc3663bbaed4f65d64154e5f9abb51a5f622f710/drawinglayer/source/processor2d/vclprocessor2d.cxx#L417 Expected Results: Properly rendered, all characters of each line should be displayed, and all three lines should appear to be the same total length. A PDF is attached which illustrates the proper rendering generated by LO 24.2.3.2. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.2.4.1 (X86_64) / LibreOffice Community Build ID: bd07154d43e1c17c8045539e3a56d206798fe486 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 196963 [details] svg horizontal text scaling test ODG file
Created attachment 196964 [details] svg horizontal text scaling test SVG file
Created attachment 196965 [details] svg horizontal text scaling test results using LO 24.2.4.1
Created attachment 196966 [details] svg horizontal text scaling test results using LO 24.2.3.2
It is *possibly* a duplicate of bug 162259. I see the problem in 24.8.2, but not in master.
Confirmed on 24.2.6.2 and 24.8.2.1 release builds. But also => WFM on recent master builds against 25.2 @Mike, backports of https://gerrit.libreoffice.org/c/core/+/171382 appropriate?
I, too, confirm that the bug is fixed on the latest daily master build. Bibisected with bibisect-win64-24.8, confirming the bug originates with cc3663bbaed4f65d64154e5f9abb51a5f622f710 "tdf#160702: improve text positioning" Bibisected with bibisect-win64-25.2, confirming the bug was fixed with f29d94c7b1bf9bee3e3598d90ba6e9dfd684ecfc "tdf#162259: correctly handle font width on Windows" Those are the same 2 commits associated with creating and then fixing bug #162259. I'm therefore marking this bug as a duplicate. *** This bug has been marked as a duplicate of bug 162259 ***
Just wanted to mention, that I rarely see such a detailed and well-formed report, with the nice minimal reproducer. If it wasn't fixed already, it would be a pleasure to work on it. And it was a pleasure to read, too.
(In reply to V Stuart Foote from comment #6) > @Mike, backports of https://gerrit.libreoffice.org/c/core/+/171382 > appropriate? I recall a longish trail of follow-ups because of a havoc created on buildbots - there was some incompatibility with Windows 7/8 (and respective Windows Server SKUs). I don't remember what specifically was done there, but it could be a8d677035a6565ebc051375206786dab3a353578 and a1b18eba354dc773c214fc3b7ee92c3473ec4a5e, among others. I am not sure if we can backport the fix here without rather massive, ~risky and ~unrelated those commits, because unit testing is essential. It could be backported without the unit test, maybe? Xisco?
(In reply to Mike Kaganski from comment #9) > (In reply to V Stuart Foote from comment #6) > > @Mike, backports of https://gerrit.libreoffice.org/c/core/+/171382 > > appropriate? > > I recall a longish trail of follow-ups because of a havoc created on > buildbots - there was some incompatibility with Windows 7/8 (and respective > Windows Server SKUs). I don't remember what specifically was done there, but > it could be a8d677035a6565ebc051375206786dab3a353578 and > a1b18eba354dc773c214fc3b7ee92c3473ec4a5e, among others. > > I am not sure if we can backport the fix here without rather massive, ~risky > and ~unrelated those commits, because unit testing is essential. It could be > backported without the unit test, maybe? Xisco? My take at it: https://gerrit.libreoffice.org/c/core/+/174978