Inkscape 0.92 line space problem with text of Inkscape 0.91

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

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

I re-upload the image.

See also:
Changes wrt line spacing in Inkscape 0.92 are described here:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92#Line_Spacing
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92#Known_Issues

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”

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

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.

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 ?

@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”
  https://bugs.launchpad.net/inkscape/+bug/1645016

Thank you very much for your help.

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?

@deevad

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:

Options:

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.

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; http://www.peppercarrot.com/en/article396/new-inkscape-0-92-breaks-your-previous-works-done-with-inkscape 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.

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.

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

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>:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15338
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15339
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15350
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15351

The changes have been forward-ported to trunk <lp:inkscape> in
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15481

Fixes for locale-related regression:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15368
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15503

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

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.

r

For what it's worth, I just resolved the issue as follows:

Opened preferences.xml
Found <eventcontext id="text" …>…</eventcontext>
Removed the style parameter -- something in there (couldn't determine what) was retaining the bad line spacing within the tool itself, which is why it persisted with new documents.

This is why, after upgrading to 0.92.1 and then .2, the bad line spacing was still stuck regardless of what the UI showed (zeroing line spacing in the UI did nothing -- the line spacing control was not working). (It's still strange in the default " " mode though, but I'll let someone who knows what it does worry about that; pt mode works.)

Thank you so much, Daniel Beardsmore. I was totally lost why I have it broken in 0.92 and your post helped me fix that :).

I'm using Inkscape 0.91 on Ubuntu and can confirm the fix above. I deleted:

   style="fill:black;fill-opacity:1;stroke:none;font-family:Arial;font-style:normal;font-weight:normal;font-size:20px;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:start;text-align:start;writing-mode:lr;-inkscape-font-specification:'Arial, Normal';font-stretch:normal;font-variant:normal"

from preferences.xml: <eventcontext id="text" ... /> and the bug is gone.

The bug is still here at least on Windows.

Steps to reproduce:

1) download Inkscape for Windows

2) open a blank document

3) type anything using text tool

4) press Enter key

Result : - the text line height is huge and in tool controls the value is 1000%

Observations:
1) 100% or 125% (125% for the most cases)would be much better.

2) selecting text then trying to reduce line height from controls produce no result even if you go to 0% or 0px to 1000px

3) I solved this bug by importing some text from an old Inkscape file (with the right line height) and setting the text tool using my imported text. This 'solution' worked but it will not work for new users because they don't know how to set the text tool from Preferences.

Conclusion: - the bug is still active on the 0.9x line (including the last Windows unreleased yet pre 0.92.3)

I have (what appears to be) the same problem on Ubuntu 18.04 with Inkscape 0.92.3 (2405546, 2018-03-11).

Pretty sure I have this same bug in 0.92.3 on Kubuntu 18.04.1.

I can use the xml-editor in Inkscape to set the line-height to 1em and things are fine. Pasted in text is getting a line-height of 200px and losing line breaks.