Text tool: new unit selector for line spacing is erratic in not px-based documents

[su_v]

The newly introduced unit selector to specify line height in absolute units (apart from % of font size) seems partially broken in documents with SVG user units not corresponding to CSS Pixels (e.g. in new documents based on the default mm-based template). Some of the experienced behavior is similar to an earlier one with the other text tool GUI controls as tracked e.g. in bug #772057 and bug #1248120 (both fixed).

Some steps to reproduce unexpected behavior:
1) launch current trunk with default (i.e. new) prefs and default new document ('mm'-based)
2) switch to the text tool
3) click once on the canvas, write a two-line text
4) drag a flowed-text frame, write a two-line text

Expected result:
Both types of text are rendered with identical (default) line heights on-canvas.

Actual result:
Line height for regular and flowed text with default (new) prefs differs.
This difference is no longer exposed if setting a new default line height in '%' (by adjusting the line height with no or an empty text object selected on-canvas).

5) select the regular text object
6) change the unit for the line height

Expected result:
Only the numerical value in the controls bar changes to represent the same amount in the newly chosen units, the actual (absolute) line height as rendered on canvas remains the same (unchanged).

Actual result:
The absolute line height as rendered on-canvas decreases each time a different unit is chosen.

7) create another regular text object with two lines
8) select 'mm' as units for line height
9) try to adjust the line height using the GUI controls (type number, or click on the spinbutton arrows)

Expected result:
The line height in-/decreases based on the entered or adjusted numerical value in the chosen unit.

Actual result:
Rather erratic reset of the line height to a lower value.
- Scrolling quickly in the entry field of the spinbutton may succeeds to override the reset, but does not allow actual fine-grained control over the line height in the chosen unit.
- Over-typing the numerical value twice with the new one (e.g. 20.0 mm) sticks in the toolbar, but is not reflected correctly on-canvas. Re-selecting the text object on-canvas with the text tool again resets the numeric value shown in the toolbar.

Common aspect to all observed symptoms:
The resulting line height on-canvas (distance between two baselines of multi-line regular text) based on a selected absolute unit identifier (i.e. apart from '%'; em and ex not tested) for the line height in the text tool controls bar seems not correct when used in documents which have a different document scale (i.e. SVG user unit ≠ CSS Pixel) than 'px'-based documents (i.e. SVG user unit = CSS Pixel) - compared e.g. to a rectangle with the height defined in the same units as used for the line height.

Reproduced with Inkscape 0.91+devel r14701, r14735, r14745 on OS X 10.7.5.

Notes:
* Similar symptoms had been observed with both recent implementations of the newly added unit selector for the line spacing:
Revision 14701: Add a units box to line height and wire in the style units, plus some cleanup
Revision 14735: More complete handling of units for 'line-height' in text toolbar.
* This report is based on the GUI experience to control the line spacing of multi-line text - the resulting values as stored in the SVG source have not been investigated nor compared.

[jazzynico (jazzynico)]

Confirmed on Windows 7, Inkscape trunk rev. 14747.

[Tavmjong Bah (tavmjong-free)]

Partial fix in r14752.

There is still a bug when 'Store transforms: Optimized' preference selected and the unit is 'em' and 'ex'.

[Tavmjong Bah (tavmjong-free)]

Final part of the fix in r14753.

Note: I still need to restore the ability to set 'line-height' without a unit. I forgot that a value of '1em' or 100% has very different behavior from a value of '1' when inherited. See section "Prefer unitless numbers for line-height values" at:

      https://developer.mozilla.org/en-US/docs/Web/CSS/line-height

[su_v (suv-lp)]

Testing with Inkscape 0.91+devel r14758, in new document based on default template (user unit = mm):

a) Default line spacing with new prefs, for newly created text, is shown as 6.61mm, which corresponds to 62.5%. Expected would be a size corresponding to 125% (former default line spacing).

b) Changing the unit for line spacing in flowed text from '%' to absolute unit (and back) changes scale by factor 2:
1) launch trunk with new prefs, default
   switch to the text tool, keep it active for remaining steps:
2) create two-line regular text --> line spacing: 6.61 mm
3) create two-line flowed text --> line spacing: 6.61 mm
4) select regular text --> line spacing: 6.61 mm
5) change line spacing unit to '%' --> 62.50
7) select flowed text --> line spacing unexpectedly changes units: 25px
8) change line spacing unit to '%' --> 125
   line spacing on-canvas increases unexpectedly
9) change line spacing unit back to 'px' --> 25
   line spacing on-canvas decreases unexpectedly

[su_v (suv-lp)]

Retesting with Inkscape 0.92pre1 r14955:
1) The 3 symptoms as originally reported are fixed.
2) The 2 symptoms described in comment #4 are still present.

Note: all tests have been done with default (new) preferences in a new document based on the default template (en_US).

[su_v (suv-lp)]

On 2016-06-07 19:11 (+0200), su_v wrote:
> Retesting with Inkscape 0.92pre1 r14955:
> (...)
> 2) The 2 symptoms described in comment #4 are still present.
>
> Note: all tests have been done with default (new) preferences in a new
> document based on the default template (en_US).

Since both last described symptoms (comment #4) also reproduce in a new
'px'-based document (e.g. template 'default px'), they should be tracked
separately and the original report closed (the original report was
focused on symptoms only seen in documents with a different scale).

[Tavmjong Bah (tavmjong-free)]

Bug 4b should have been fixed by r15319 in trunk and r15254 in 0.92.x.

[Tavmjong Bah (tavmjong-free)]

Bug 4a is due to code in desktop-widget.cpp (SPDesktopWidget::namedviewModified()) which sets the active unit on any "tracker" to the display unit. This is done after the text toolbar is setup.

[Tavmjong Bah (tavmjong-free)]

Bug 4a fixed in trunk r15462.

[su_v (suv-lp)]

Tavmjong Bah wrote:
> Bug 4b should have been fixed by r15319 in trunk and r15254 in 0.92.x.
and
> Bug 4a fixed in trunk r15462.

Issue 4a in the meantime was filed separately as
* Bug #1645016 “0.92 Stored default line height auto-change unit to document unit”
  https://bugs.launchpad.net/inkscape/+bug/1645016

Proposing to close this report as 'Fix Released' with milestone 0.92 (the fixes for the originally reported issues are part of the stable release, as is the fix for 4b), and to track backporting the fix of 4a for 0.92.1 or 0.92.2 in bug #1645016.