Description: Display of subscripts and italic characters are not correctly displayed into libreoffice writer. See attached files Steps to Reproduce: 1. Draw a .svg graphic (in Inkscape) and use subscript and italic 2. drag and drop the .svg into libreoffice writer 3. see non-correct display of .svg-file inside libreofficwriter Actual Results: See attached screenshot Expected Results: file looks same as in inkscape Reproducible: Always User Profile Reset: Yes Additional Info: libreoffice writer should display .svg-files including subscripts and italic characters correctly
Created attachment 183679 [details] output example of italic and subcripted text. See results in inkscape and libreoffice writer
Created attachment 183680 [details] inkscape .svg file to reproduce the bug
Created attachment 183683 [details] Partial reproduction on sample document I can only partially reproduce the bug: * Italicization is ok. * Getting regular size instead of subscript * Subscript horizontal placement is a little off: Too much space before the `t` on the middle line of the example. Build info: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bcf333309f9a9bde21aac1302cbead2b23822458 CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded (build is from earlier today)
I tested recent versions, and I see the issue in spacing (although not as jumbled as the OP shows), which is an issue that has been around for a while. I also see a more recent issue, that Eyal shows, in 7.5: the characters that are supposed to be subscripts are at the same level as the rest. In my opinion, we have a long-standing problem with kerning, and a recent regression in vertical position. (Imported SVG looks the same in other components, like Draw)
Created attachment 183723 [details] imported SVG in LO 7.3, 7.4, 7.5 and GNOME image viewer Note that Firefox 107.0 has the same vertical issue as LO 7.5. Versions: Version: 7.3.6.2 / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb7bc82de19ea8e20c767fdf21f9ba4feb5e9f0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded The issue in 7.5 should probably be reported separately.
*** Bug 155265 has been marked as a duplicate of this bug. ***
Issue was already present in: Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) Noting that how much jumbling of character there is depends on zoom level, like in bug 114941.
Noting that the SVG file uses "baseline-shift:sub" for the subscripts. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/baseline-shift As of 2023-11-07, the developers.mozilla.org documentation notes: "This property is going to be deprecated and authors are advised to use vertical-align instead." Xisco, with the recent fixes in bug 157113, bug 156837 and bug 86938, can you have a look at this one? Testing with a recent trunk build: - Vertical placement: Chromium displays the subscript lower than LO, while Firefox displays them on the same baseline. - Horizontal movement: placing a line next to the second line's subscript "t" shows that zoom does not affect it's position, contrary to the rest of the line. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Created attachment 190932 [details] minimized reproducer
Created attachment 190934 [details] minimized reproducer
I see two problems here, one with the subscript and the other with the horizontal position, which I'll report in a follow up ticket
(In reply to Xisco Faulí from comment #11) > I see two problems here, one with the subscript and the other with the > horizontal position, which I'll report in a follow up ticket Reported in bug 158295