Bug 160702 - Wrong and unstable positioning of text parts in SVG
Summary: Wrong and unstable positioning of text parts in SVG
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:24.8.0 target:24.2.4
Keywords:
Depends on:
Blocks: SVG-Import
  Show dependency treegraph
 
Reported: 2024-04-17 04:00 UTC by Mike Kaganski
Modified: 2024-05-03 11:32 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
A sample with colon after a tspan (263 bytes, image/svg+xml)
2024-04-17 04:00 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2024-04-17 04:00:11 UTC
Created attachment 193717 [details]
A sample with colon after a tspan

The attached SVG has this markup:

 <text x="2" y="1em" style="font-family:Liberation Sans;font-size:0.77em;font-weight:bold"><tspan>Tititititititititit</tspan>:</text>

Note that the colon is outside of the tspan containing the most of the text, not separated by anu spaces. It is expected that the colon is drawn as a natural continuation of the text, as if there weren't a tspan element around the preceding "Tititititititititit".

Opening it in different versions of LibreOffice gives different, but consistently poor, result. In versions prior to 7.5 (e.g., in 7.0), the colon is "merged" to the preceding "t" in most of zoom levels (e.g., 200%, 250%); but sometimes, it is separated by a large space (in 180% and 280%); and sometimes, it "jumps" somewhere between i and t (160%).

In fact, this is not the colon that jumps; zooming between 250, 280, and 310 percent zoom using the mouse wheel allows to see that it's the size of "Tititititititititit" that changes inconsistently, becoming relatively larger or smaller compared to the whole page size in different zoom levels.

Starting with version 7.5 (and in current master), the size of the "Tititititititititit" and the position of the ":" is different, but still wrong; the picture similar to older versions' 250-280-310% jumping is now visible in 140-160-180% zoom. Two commits resulted in this change: 1fa731d03ba0f22cb9392a578124ea977eaab2e9 and a42f5faac7c6d4590e632cf40e3ba9eb618e6f56. Note how this seems to answer the "I don't know in which context such blank is needed" in bug 103888 - the blank between different pieces was likely added as a hack to increase chances that the pieces won't overlap (at the cost of adding unexpected gaps).

Note that the effect depends on display DPI; all the abovementioned zoom levels were tested using 100% display scale on Windows; and when using 150% scaling, the 140-160-180% looks different, but 90% zoom shows the jump. The essence of the problem is generally inconsistent scaling of the text, which makes the absolutely positioned pieces of text to look bad. That same issue may result in a bad absolute positioning of the colon here, when its position is calculated using some screen font size, with unclear correctness of the calculation.
Comment 1 Xisco Faulí 2024-04-17 07:20:10 UTC
(In reply to Mike Kaganski from comment #0)
> Starting with version 7.5 (and in current master), the size of the
> "Tititititititititit" and the position of the ":" is different, but still
> wrong; the picture similar to older versions' 250-280-310% jumping is now
> visible in 140-160-180% zoom. Two commits resulted in this change:
> 1fa731d03ba0f22cb9392a578124ea977eaab2e9 and
> a42f5faac7c6d4590e632cf40e3ba9eb618e6f56. Note how this seems to answer the
> "I don't know in which context such blank is needed" in bug 103888 - the
> blank between different pieces was likely added as a hack to increase
> chances that the pieces won't overlap (at the cost of adding unexpected
> gaps).

Later, a42f5faac7c6d4590e632cf40e3ba9eb618e6f56 was partially reverted in 5079e7937ef471a44dcf119dc6ae0a334d9c6adc in order to fix tdf#156251
Comment 2 Commit Notification 2024-04-20 09:29:18 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/cc3663bbaed4f65d64154e5f9abb51a5f622f710

tdf#160702: improve text positioning

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 Mike Kaganski 2024-04-20 09:32:12 UTC
Let me call this fixed. It is not ideal, but somewhat more stable.
Comment 4 Xisco Faulí 2024-04-22 09:05:46 UTC
Verified in

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e902fe1b8bf03f9c3747685314f4d443bcea9333
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

@Mike, thanks for fixing this issue!!
Comment 5 Commit Notification 2024-05-03 11:32:43 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/5a25899a9c5c0c4e6fb92ca355ea1e24cec3a747

tdf#160702: improve text positioning

It will be available in 24.2.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.