Inkscape 0.92 line space problem with text of Inkscape 0.91

Bug #1655483 reported by Guillaume on 2017-01-10
This bug affects 19 people
Affects Status Importance Assigned to Milestone

Bug Description

I update my version of inkscape 0.91 to the new version 0.92 but when I open a finished document done on 0.91 with the new version. Some texts are "over-spacing" without apparent reason. I tried to changed the line-space parameter but even with 0 pt, the text stay "over-spacing".

The strangest, the rest of texts of the document don't change layout.

Operating System : Windows 8.1
Inkscape : Version 0.92 r15299 64-bit

su_v (suv-lp) wrote :

Please attach a test case (Inkscape SVG file) to the bug report to allow further investigation, thank you.

Changed in inkscape:
status: New → Incomplete
Guillaume (guillaume007) wrote :
Guillaume (guillaume007) wrote :

Sorry for that, I attach a SVG file "Test case of bug"

Guillaume (guillaume007) wrote :

I re-upload the image.

su_v (suv-lp) on 2017-01-11
Changed in inkscape:
status: Incomplete → New
su_v (suv-lp) wrote :

See also:
Changes wrt line spacing in Inkscape 0.92 are described here:

Earlier related reports:
Bug #1655483 “Inkscape 0.92 line space problem with text of Inkscape 0.91”
Bug #1655412 “Space between base lines misbehavior”
Bug #1652006 “Line spacing differs between 0.91 an 0.92b4”
Bug #1644299 “text and image not displaying in 0.92pre3”
Bug #1642133 “Inkscape shows text with ridiculously wide line spacing”
Bug #1617692 “Spacing Between Baselines Messed Up 0.92 15081”
Bug #1556400 “line height all equal in development version”

Bug #1652340 “Extension for 0.92.x to fix line spacing in legacy documents”
The proposed extension (for 0.92.1) can help with many basic cases where multi-line text in legacy documents renders differently in Inkscape 0.92. In your test case, the outer style of the two text objects differs, and thus the result for the re-adjusted text on the left will still show a slight difference in the baseline spacing compared to the text on the right (the extension does not copy style properties from random other text objects; it only shuffles the style properties per text object).

Internally, the extension basically applies the same steps you likely read about based on the bug description (setting line height explicitly for all inner text elements, and setting it to 0 for the outer text, which defines the CSS "strut" value). These steps also work for your test case when done manually (using the options on the text tool controls bar).

su_v (suv-lp) wrote :

Nevermind the prior attachment - I retested applying the extension to both text objects, and the bitmap export of the result then matches the rendering in Inkscape 0.91 ok.

Guillaume (guillaume007) wrote :

Thank you much for your help, your explanation and your extension. It's works. Howerver, if write multi-line text in Inkscape 0.92., it don't have 1,25 for default in line space like inkscape 0.91. So each time you create this type of text, you have to change spacing parameter to 1,25 em. It is normal and / or wanted ?

su_v (suv-lp) wrote :

@Guillaume - setting a default line-height based on relative units (%, em, ex) or unit-less (if line-height definitions are unset) does currently not seem to stick as new default: AFAICT a relative line-height stored as default in the preferences file is converted to absolute units (displayed in document units) when applied to newly created text, as reported in
* Bug #1645016 “0.92 Stored default line height auto-change unit to document unit”

Guillaume (guillaume007) wrote :

Thank you very much for your help.

Deevad (deevad) wrote :

Hi, I have a webcomic called Pepper&Carrot. This webcomic is open-source and I use Inkscape for the speechbubbles, the translation system and the renderfarm. I have the responsability of 10804 SVG files created with Inkscape, prior or with 0.91, spread over 20 repositories, contributed by 40 translators. I'm rendering this 10K of SVGs with command-line.

Problem: Inkscape 0.92 can't read them without affecting them visually. All my SVG can't be rendered properly. If a client tries to open my sources with 0.92 ; he'll be prompted with dialog proposing obscure choices, and will get rendering issue with texts anyway and will blame my competences as a designer, not the software. Should I be blamed as an artist for the tools I'm using? For using FLOSS? Should my artworks be not interpreted correctly after an update?...

No. This is highly unprofessional for a major release, and it put my project , Pepper&Carrot, in an unsecure area. I can't rely my professional tools with this type of choices. As I can't use 0.92 -for sure- on my production now, I'm forced to downgrade to 0.91 and I'll force all my collaborator to not use 0.92.

The dialog poping at startup in 0.92 and proposal of an external extension to fix SVG text file by file is not a solution. I can't spend the next week to convert over 10000 files manually. Inkscape 0.92 is able detect old legacy files, why not 'not prompting' user and just apply the smartest converting solution to preserve the rendering accross 0.91 to 0.92 ? If the extension does it, why not doing it auto-magically by default?

Mistakes and error in design can be done. No problem if quick fix follows; Now I need to know if it is something planned for 0.92.1 or 0.92.2?

Tavmjong Bah (tavmjong-free) wrote :


I downloaded one of your files. The source of the problem you are having is that in 0.91 the 'line-height' property is set to a % value:

  <flowRoot style="font-size:12px;line-height:125%;...">

According to CSS, the line spacing for a % line-height value is calculated once and then applied to all inner elements (which don't have their own 'line-height' value). So in this case, the line spacing should be 16px (12px * 1.25). Inkscape 0.91 is incorrectly recalculating the line spacing for each 'flowPara' element inside the 'flowRoot'. In the file the flowPara has a font size of 48px:

  <flowPara style="font-size:48px;...">

thus 0.91 is applying a line spacing of 60px (48px * 1.25). 0.92 is following the CSS spec and not recalculating the line spacing for each flowPara where the 'line-height' property is not given in the flowPara style attribute.

There are a number of ways to fix this depending on how consistent your files are and how backwards compatible you wish to be:


1. One can change the 'line-height' from a percent value to a unitless value. I've attached a perl script that will do that. Changing the line spacing in 0.91 will break the fix.

2. One can look at the font-size in the first flowPara and apply it to the flowRoot element. This is backwards compatible with 0.91 but is a bit more difficult to do in perl.

3. One can add a 'line-height' property to the style attribute of each flowPara element so the line spacing is recalculated for each flowPara. This is also backwards compatible with 0.91. This might be the best solution.

It is possible that a fix could be automated in 0.92.2 (probably too late for 0.92.1) but it would require quite a bit of testing.

Deevad (deevad) wrote :

Thank you for your time and propositions. All in all, I favor the last solution: "It is possible that a fix could be automated in 0.92.2 (probably too late for 0.92.1) but it would require quite a bit of testing." and I agree to help testing and spend my time on helping to give feedback for this.

I released an article here; with more informations. I'll keep receiving SVG files from 'old' Inkscape from 0.48 to 0.91. I render them via command-line. The ideal scenario for me is not 'converting' them, but having a Inkscape 0.92.x able to read them, with keeping the same aspect as when they were created.

I understand, in case of editing and modification, and I accept Inkscape to move the SVG markup to 0.92 way to write it. But keeping able to read previous SVG without be prompted for a choice, or a manual conversion would be the best fix.

Jack Underwood (ocean-wolf) wrote :

I think I should point out that while inkscape does contain an XML editor, in terms of the user, it should get treated as a WYSIWYG editor, so using XML/CSS terminology should get avoided as part of the main part which gets handed down to the user.

In terms of the bug fix that created this bug, the end user should not have to know anything about CSS propagation rules, that job should get buried beneath the surface of the WYSIWYG blackbox, thus the blackbox should auto-correct any parts of the CSS that were assumed there before under the bad implementation.

su_v (suv-lp) wrote :

The file based on the original report opens as expected with Inkscape 0.92.1 (if detected as legacy file, i.e. not resaved with 0.92 already).

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).

su_v (suv-lp) wrote :

In latest release Inkscape 0.92.1 the baseline spacing of text in legacy files is adjusted on load. The behavior is enabled by default and can be disabled with a command line option (--no-convert-text-baseline-spacing) if needed.

Relevant commits in the stable release branch <lp:inkscape/0.92.x>:

The changes have been forward-ported to trunk <lp:inkscape> in

Fixes for locale-related regression:

@jazzynico - could you please add a bug task for 0.92.x, with milestone 0.92.1 and bug status 'Fix Committed' (for now)?

jazzynico (jazzynico) on 2017-02-16
Changed in inkscape:
milestone: none → 0.93
status: New → Fix Committed
importance: Undecided → Medium
jazzynico (jazzynico) on 2017-02-16
Changed in inkscape:
assignee: nobody → Mc (mc...)
Radek Svoboda (svobora) wrote :

This also break the Czech documentation bundled with Inkscape. It really surprise me that nobody noticed the docs were screwed up, I suppose they were also in English but someone took time to fix these.

To replicate, set Interface Language to Czech (cs), then open Inkscape Basics documentation (in czech "Inkscape Zaklady") in Help->Tutorials.


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

Other bug subscribers