Inkscape shows text with ridiculously wide line spacing (regression)

Bug #1642133 reported by Nutchanon Wetchasit on 2016-11-16
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

This is a spin-off from bug #759154 comment 35.

I have been testing my schematic.svg sample originally posted in bug #1580042
using the bleeding-edge Inkscape 0.92pre2 (and most recently,
Inkscape 0.92pre3).

While I found that the original problem of Cairo PDF export (bug #759154)
is fixed, there is a new issue on the bottom-left text. This text's
line height was originally set to 1.25 times of normal; which looked
reasonably good.

But when the file is viewed under the bleeding-edge Inkscape 0.92pre2 or
Inkscape 0.92pre3, said text seems to be rendered as if the line spacing
was set to ~2 times (or around 1.25 x 1.25 x 1.25 times) of normal,
which is incorrect.

Raster renderings of the diagram are attached as follows:

schematic-batik1.8.png: Reference rendering from Apache Batik 1.8
schematic-inkscape0.48.png: Correct rendering from Inkscape 0.48
schematic-inkscape0.91.png: Correct rendering from Inkscape 0.91
schematic-inkscape0.92pre2.png: Ridiculous rendering from Inkscape 0.92pre2
schematic-inkscape0.92pre3.png: Ridiculous rendering from Inkscape 0.92pre3

This problem does not exist in stable Inkscape 0.91 or older
Inkscape 0.48.2 r9819, thus could be considered recent regression.

Note: The original diagram is drawn using Inkscape 0.48.2 r9819.

Inkscape: 0.92pre3 r15195 (binary 7-Zip release)
Inkscape: 0.92pre2 r15127 (binary 7-Zip release)
Inkscape: 0.91 r13725 (portable)
Inkscape: 0.48.2 r9819
Apache Batik: 1.8
System: Microsoft Windows XP SP3

Alvin Penner (apenner) wrote :

confirmed on Windows 10, Inkscape 0.92pre3 15195
attached is a comparison of the Inkscape display with IE11, where I have attempted to make the vertical scaling roughly the same in both cases. The line spacing is different.

Changed in inkscape:
status: New → Confirmed
Martin Owens (doctormo) wrote :

The error is likely related to a mishandling of the line spacing units (added since) and the settings. When I create a new next field, it always has a line spacing of 10, with no unit. Even though I'm pretty sure it's remembering a 10px spacing by accident from another document.

jazzynico (jazzynico) wrote :

Also reproduced on Windows XP (32-bit), lp:inkscape/0.92.x rev. 15205.

Changed in inkscape:
importance: Undecided → Medium
milestone: none → 0.93
status: Confirmed → Triaged
su_v (suv-lp) wrote :

Can be "fixed" with extension from bug #1652340, output attached.

Andreas Schwarz (unifire) wrote :

I reproduced this with legacy documents and I was able to reproduce this with a fresh installed version. To check if there is any relation to my Linux settings and or documents in use, I have created a windows 7 virtual image and installed the windows version r15299. I created a new text field with 2 columns. The default was 30 size and 6.61mm line distance. I changed that to 1 with no unit. It look right. But when I changed the size to 6 the distance is way to much. In this virtual box image I have never opened a legacy file.

Andreas Schwarz (unifire) wrote :

I am using now the extension described in bug #1652340. This fix does work well for standard font sizes (16). I use fonts with the size of 6 and 8. There the problem is not at all solved with this fix / extension.

However, what I do not understand at all is, when I create a new document a two column text has always a pixel value in the XML (line-height:23.4375px). Regardless of what I am selecting the stored value unit inside the XML is in pixel. When I change this with a text editor to 125% it is shown in Inkscape correct. But as soon as I play around, the value is again stored in pixel.

Problem 1) a line-height value of 125% is correct displayed as long as the font size is not too small (< 10 does scale incorrect).

Problem 2) a new document (not legacy) stores the line-height value as pixel unit. And a pixel does not scale.

su_v (suv-lp) wrote :

The file based on the original report opens as expected with Inkscape 0.92.1 (see attached).

Issues with baseline spacing of text in legacy files (last edited with <= 0.91) which persist in Inkscape 0.92.1 should be filed separately (for new reports, please provide the original files which have not yet been resaved with Inkscape 0.92.x).

Carwyn Edwards (carwyn) wrote :

I seem to be seeing this in 0.92.2 with brand new files after deleting ~/.config/inkscape and ~/.cache/inkscape

(Fedora version inkscape-0.92.2-1.fc27.x86_64).

As per one of the comments above it seems rather arbitrary. What I have noticed is that if you create a text box and use a larger font size, then select all and reduce the font size it can sometimes leave spacing that looks like the original font size. Ramping up the baseline figure to ridiculous levels also seems to overflow and bring back the desired spacing. If you then reduce it again it's sometimes back to the expected value.

From a fresh start of Inkscape:

1. Start Inkscape.
2. Create a textbox (font size defaults to 30)
3. Type a few words per line, three lines then a blank line then another few words.
4. Select all.
5. Resize text using toolbar to 12.
6. Spacing is huge similar to 30pt baseline value reporting as 1.25
7. Try reducing it with arrows or text input into toolbar - no effect.
8. Increase it to 5.0 or more, text expands.
9. Reduce it again and now goes lower than it was, including to 0 but still not correct.

Is the baseline spacing somehow stuck at a value that relates to the original font used for the textbox? Maybe I'm doing something wrong here?

This seems distinct to bug #1655483

Carwyn Edwards (carwyn) wrote :

Hmm, opening up the XML Editor I can see what's happening in my case above.

When I select all and change the font size it's only effecting the svg:flowPara font-sizes not the svg:flowRoot font-size. Technically this makes sense although caught me out.

The line-height adjustments on select all are effecting the svg:flowPara line-height, when nothing is selected but the cursor is in the text box it's effecting the svg:flowRoot line-height.

The line height adjustments seem to be working as intended. To change the flowRoot font-size selecting the text box with no cursor active allows adjusting of the flowRoot font-size.

Bug is behind the keyboard. May be that others have been caught out by this.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers