trunk: text tool spinboxes not behaving as expected (rev >= 13298)

[Liam P. White]

When I am in the text editing context, and have no text selected, I tried to make the line spacing 0 to determine if it was the cause of bug #1334662 — it was, but as soon as I entered 0, the spinbox value jumped back to 1.25 (despite the line spacing actually being 0).

I then attempted to use the buttons on the side of the spinbox — similarly, I had no luck attempting to change the value.

This doesn't happen in stable — spinboxes work as expected in the text toolbar.

No relevant console messages appear.

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 13441.
Not reproduced with revision 13293.

[jazzynico (jazzynico)]

Affects the Text & Fonts dialog and the control bar.

What I see is a bit different. I can change the box value as expected while there's no text in the text box, but it jumps back to 1.25 as soon as I type some text (or try to edit existing text).

[su_v (suv-lp)]

Possibly related to bug #1248120 (viewBox not handled well by text tool controls on the toolbar)?

On 2014-06-28 11:40 +0100, jazzynico wrote:
> What I see is a bit different. I can change the box value as expected
> while there's no text in the text box, but it jumps back to 1.25 as soon
> as I type some text …

Possibly related to bug #1227232? (adjusting options without a selected text object is supposed to adjust the default style, but does not work in current trunk).

[Liam P. White (liampwhite)]

Tests with archived revisions determine this to be related to the style cleanup and refactoring in r13298/9:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/13299

[Tavmjong Bah (tavmjong-free)]

OK, this is a bit complicated. As SVG is moving to CSS based text layout we need to follow CSS rules for multi-line text. Inskcape always creates text in <tspan>s inside a <text> element. The <tspan>s act as inline elements while the <text> acts as a block element. (The SVG WG still needs to explicitly define this.)

The value of 'line-height' on a block element gives the minimum height of the contained "line boxes".

The value of 'line-height' on an inline element gives the value that should be used to calculate the "line box height".

The "line box height" is the distance between the uppermost box top and the lowermost box bottom, taking into account vertical alignment properties, where the boxes are determined by the 'font-size'.

The default value of 'line-height' is 'normal' which means take a reasonable value. The CSS 2.1 spec suggests a value between 1.1 and 1.2 (multiplied by the 'font-size'); Inkscape uses a value of 1.25.

In trunk, setting 'line-height' in the Text Tool-bar sets the value only on the <text> element, leaving the <tspan>s with their default values ('normal'), while the number displayed in the spinner is the average value of the <tspan>s (ignoring the <text> 'line-height' value).

So there are actually multiple bugs here:

1. Changing the value of the spinner should be setting the value of 'line-height' on all the descendant <tspan>s as well as <text>, if the entire <text> element is selected. (How to set just the <text> 'line-height' value needs to be considered.)

2. Changing the value of the spinner when only part of the text is selected, should set 'line-height' for the selected text, creating a new <tspan> if necessary.

3. The spinner should be set to the value of the selected text, taking into account the <text> element and the <tspan> elements (it's now just using the <tspan> elements).

4. The rendering of the text is ignoring the values of 'line-height' in the <tspan>s.

The first bug is the most important at the moment.

See:
http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
http://www.w3.org/TR/CSS2/visudet.html#line-height
https://developer.mozilla.org/en-US/docs/Web/CSS/line-height

[Tavmjong Bah (tavmjong-free)]

The first bug in the previous comment is wrong. The 'line-height' property should not be set on all descendants as the value is inherited (over-riding the 'normal' value). The actual bug is that 'line-height' values were not properly being inherited. The other "bugs" still exist but are out-of-scope for this bug report.

Fixed in 'experimental' branch (r13558) and trunk (r13564).