multi-line text formatting browser incompatibilities

[David Mathog]

The method inkscape is currently using for line spacing in multi-line text is incompatible with all tested
browsers and LibreOffice Draw. A test svg follows, and then some screen dumps. Basically the line height specification is being ignored by the other programs. Are they all defective, or is this an SVG problem with Inkscape?

[David Mathog (mathog)]

Inkscape r11707 screen shot.

[David Mathog (mathog)]

Libre Office 3.6 Draw screen shot

[David Mathog (mathog)]

Firefox 15.01 screen shot

[David Mathog (mathog)]

Opera 12.02 screen shot

[David Mathog (mathog)]

Internet Explorer 9 (on W7) screen shot.

[su_v (suv-lp)]

How exactly was the text created in the sample file?

1) Not reproduced with newly created text using exactly the same formatting (r11914, OS X 10.7.4)
2) After nudging the two text objects in the provided SVG sample file with the arrow keys (in Inkscape), both text objects render as expected in other SVG viewers (e.g. Firefox and Opera) - i.e. the same as in Inkscape.

[David Mathog (mathog)]

The "line-height" property is described here:

http://www.w3.org/TR/SVG/text.html

in part with:

  The ‘line-height’ property has no effect on text layout in SVG.

That seems to be the case for all of the tested browsers and LO Draw. However line-height definitely has an effect on text layout in inkscape, as demonstrated in the attached svg file. Dump.svg was made to be read into inkscape and be editable once inside - which works as desired. (Load it into inkscape and then edit one of the paragraphs. The red text under the black shows the positions of the separate text elements from which the black text was reassembled.) But it looks absolutely horrible in browsers. It isn't obvious here, but the the line-height property between two successive lines of inkscape text (in <tspan>'s within the same <text> is

  (baseline[i+1] - baseline[i])/ font_size * (descender[i]/max_font_size_in_line(i) + ascender[i+1]/max_font_size_in_line(i+1))

When the largest font in each line is the same the denominator simplifies to just "font_size". In the attached example line-height controls line spacing, in inkscape, but that works not at all elsewhere.

This all came up in the context of text reassembly from EMF files. The text reassembly part is working well, but the SVG that Inkscape wants to see isn't what anything else wants to see, apparently. I really need to know an SVG syntax that inkscape will be able to edit properly, which other programs can also display as intended!

[David Mathog (mathog)]

They were made on Windows. Remaking them from scratch on Linux. Hmm, the new one seems to work OK in browsers. The Windows and Linux versions of inkscape are only slightly out of sync, and older windows versions (0.48.2) are doing the same thing. Could be a platform issue. I wonder if the windows one will break the linux one if I edit it. No, it stays ok. Very strange. The key difference seems to be that the broken one has:

         sodipodi:linespacing="200%"><tspan
         sodipodi:role="line"
         id="tspan12-0"
         x="56.487522"
         y="368.96161">This is some wrapped</tspan><tspan
         sodipodi:role="line"
         x="56.487522"
         y="393.96161"

where the working one has:

       sodipodi:linespacing="200%"><tspan
         sodipodi:role="line"
         id="tspan3283-2"
         x="355.0014"
         y="452.84192"
         style="font-size:20px;line-height:200%">This is some wrapped</tspan><tspan
         sodipodi:role="line"
         x="355.0014"
         y="492.84192"
         id="tspan3285-7"
         style="font-size:20px;line-height:200%">test with multiple lines</tspan><tspan
         sodipodi:role="line"
         x="355.0014"
         y="532.84192"
         id="tspan3287-1"

Will update the windows version to match linux exactly and repeat.

[su_v (suv-lp)]

> The key difference seems to be that the broken one has:

AFAICT no, that difference does not necessarily matter (it's just reflecting whether you had portions of the text highlighted when applying the formatting: without haveing highlighted text, the style is only applied to the parent <text> object, if you highlight all content and then change the line-height/style, the <tspan> get the style attribute and overwrite the parent style instead of inheriting it).

In my tests, it worked (rendered the same in Inkscape and browser) without applying the style to the <tspan>'s.

[su_v (suv-lp)]

s/overwrite/override/

[David Mathog (mathog)]

Here is one with the same problem made on linux. In order to do it I did exactly these steps.

1. start inkscape
2. set to A4 portrait.
3. Click on "A" to start typing.
4. Set font to Arial 16, left justified. Line spacing still at default 1.25
5. Enter text "First line^ of several^ at 2.0^ line spacing" with returns indicated by ^
6. With the cursor still in the text, ^A to select all, and change line spacing to 2.0.
7. Draw the surrounding rectangle.
8. Save

I was also able to get a "bad" one by

6 (alternate). Change to arrow icon, click on empty spot, click on text, click on "A" (to enter typing mode), change
line spacing to 2.0.

As you noted the difference with the line spacing on each line is a red herring, it just shows if the text was selected when
the line spacing was changed. In the attached one you can see that the line-spacing value is still 125%, even though if this
is opened in inkscape it shows up as 2.0.

in the alternate one the line spacing did change to 200%, yet it still looks wrong in a browser. Will attach that next.

Was able to "fix" these in windows version by editing the text and then saving. Similar to what you did earlier. So the problem seems to be something picky about exactly how the drawing is created, not a platform issue as I thought earlier.

[David Mathog (mathog)]

This is the other bad one made on linux.

I left out a step in the description - add text to describe the method. That does not seem to have changed anything.

Next up is one where I set the text specification FULLY before starting to type: arial 16, left justified, 2.0 line spacing. This was
done on Windows. Linux worked the same. It shows up correctly in web browsers.

So it looks like there is some issue, in some instances, where conversion from 1.25 to 2.0 line spacing doesn't work correctly. Maybe it needs some change to the text contents other than just to line spacing to fully take effect?

[David Mathog (mathog)]

This one was made on Windows with the line spacing set to 2.0 _before_ any text was entered. It looks OK in browsers.

[David Mathog (mathog)]

Opened windows_method3.svg, added an extra line of text showing what was done. Edited the original text 2.0 to 3.0. THEN changed the line spacing 2.0 to 3.0. Adjusted rectangle. Saved. It is now bad.

Conclusion: changing the line spacing by entering a value into that field (I type it in), and hitting return changes the line
spacing on the screen but not fully in the SVG. Maybe up/down arrows on line spacing do both?

[David Mathog (mathog)]

Like 3b, but adjusted the line spacing with the arrows, rather than entering the value into the field and hitting return. This
one is also broken.

So both modes of changing the line size do not fully take effect until the text contents are modified in some way AFTER the line line spacing change is entered.