Inconsistent handling of parent transforms or 'viewBox' attribute in text tool controls

Bug #772057 reported by Ð.Sp!dér
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Alvin Penner

Bug Description

Letter spacing for text drives me absolutely insane. The text is inside a polygon frame:

 ____
/    |
"""""'
(sorry for the poor ASCII representation)

Line spacing and word spacing seems to work ok, but the character spacing, man oh man...

If I set it to -0.3 it switches to -0.24 !
If I set it to 3 it switches to 2.40 !
If I set it to -0.7 it switches to -0.56 !
-1 turns into -0.80 and so on, so forth....

Using the mouse scroll above the input box is even worse ! What the hell ??

I'm running Arch Linux i686, up to date, but the exact same thing happens on Windows XP as well.

Is there anything I can do ? For instance draw the polygon clockwise or something... Should the beginning point be top left corner ?

Ð.Sp!dér (zdspider)
description: updated
Revision history for this message
su_v (suv-lp) wrote :

> (sorry for the poor ASCII representation)

Please attach a sample SVG file which exposes unexpected results when editing the character spacing.

tags: added: text
Changed in inkscape:
status: New → Incomplete
Revision history for this message
Ð.Sp!dér (zdspider) wrote :

Try setting the text letter spacing to 1 or any from the above examples.

Weird, huh ? I have personally tested it on both operating systems. I realise I'm a newbie with Inkscape, but what is going on ?? I thought maybe it was the font because it was custom made (just early this morning) but it shows up fine in any other text editor. So I tried with other fonts and it's the exact same thing !

I've attached the sample with Arial set.

Apparently to "fix" it, I had to copy-paste objects one by one into a new .svg file. I may have done something extra but I don't remember... I tried *SO* many things.

su_v (suv-lp)
tags: added: viewbox
Revision history for this message
su_v (suv-lp) wrote :

Do you remember how the original SVG file was created? It defines a 'viewBox' attribute [1] for the top-level <svg> node which scales the whole drawing content by the factor 0.8 - possibly to scale the SVG user unit (px) to the 'pt' unit. Inkscape itself does not write this attribute into the SVG source, but respects it if present. If you change the values of the viewBox to match the width and height attribute, the px values entered into e.g. the spacing entry box of the text tool will match your expectations.

<svg
   (…)
   width="1253.75"
   height="1513.75"
   viewBox="0 0 1003 1211"
   (…)

Proposing to close as 'Invalid' because AFAIU it is a correct interpretation of the information in the SVG source file. The 'viewBox' setting had to be intentionally added to the SVG source by manually editing it or the file was originally created by a third-party application which makes use of the 'viewBox' attribute.

> Apparently to "fix" it, I had to copy-paste objects one by one into a new .svg file.

That's because Inkscape doesn't add this attribute in its default template.

[1] <http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute>

Revision history for this message
Ð.Sp!dér (zdspider) wrote :

Well, yes, the original file was created with a vector tracing application (available commercially). If you think it's the initial program's fault I'm not going to pursue this matter further.

One question, though. Why does the line spacing and word spacing work, but not the letter spacing ? Is that supposed to happen ?

PS:

<path
     style="fill:none;stroke:#000000;stroke-width:0.80000001px...

I opened the .svg file with Leafpad and I searched for "0.80". Then I set "stroke-width" to 1.0px and now the line spacing works again. Hmph.

Revision history for this message
su_v (suv-lp) wrote :

> Why does the line spacing and word spacing work (…)?

1) line spacing is a relative size (in %, or "times font size") and thus not affected
2) editing the word spacing value shows the same effect as editing letter spacing (1px -> 0.8px)

> If you think it's the initial program's fault

It's no fault per se - the 'viewBox' attribute is valid SVG code (which is partially supported in Inkscape). After further tests, Inkscape's GUI does indeed have some inconsistencies with regard to units if the attribute is present compared to how the scaling is compensated in other widgets, e.g.
- Fill & Stroke > Stroke style > Width
- Text tool controls bar -> Font size
do compensate the scaling and read/store the scaled value to the SVG source (enter 1px in the GUI, write 0.8px in the SVG source; read 0.8px from the source -> represent as 1px in the GUI). The code for the extended formatting options on the text tool controls bar is rather recent (new in 0.48), and apparently doesn't use the same concept how to handle parent transforms or scaling via viewBox attribute. [1]

With regard to usage of the 'viewBox' attribute in Inkscape: The problem how to best handle the need for absolute, real units based on the SVG file format (which doesn't really define them as absolute values) is a recurring discussion on the developers' mailing list - the viewBox method (use SVG user units (px) for all elements in the drawing and scale the drawing contents via viewBox attribute) is known and (AFAIU) recommended by the standard, but not (yet?) used by Inkscape for setting the drawing units/scale of its own drawings.

[1] see next comment

Revision history for this message
su_v (suv-lp) wrote :

More generic, underlying issue (GUI controls for text formatting don't handle parent transform transparently):

Steps to reproduce
1) open a new drawing,
2) create a text object with default font size (40px)
3) duplicate the text, group the duplicate
3) scale the group to 200% ('Ctrl+>')
4) edit the text inside the group

Results:
- the text size stays unchanged in the source (40px), but is presented in the text tool controls bar with 80px
- changing the text size will show/keep the value with the parent transform applied (visual result), but store the unscaled value in the SVG source
- the letter and word spacing widgets show the value as stored in the SVG source
- changing the letter/word spacing will compensate the parent transform on-the-fly: enter 10px (visual result with transformation applied), get 5px (actual spacing value without the parent transformation as stored in the source)

Changed in inkscape:
status: Incomplete → Confirmed
summary: - Letter spacing nightmare when used with "Flow into Frame"
+ Inconsistent handling of parent transforms or 'viewBox' attribute in
+ text tool controls
tags: added: transformations ui
Revision history for this message
su_v (suv-lp) wrote :

Test file with text object inside a scaled group.

Revision history for this message
Ð.Sp!dér (zdspider) wrote :

Exactly! The text was scaled. I just figure it out.

If you SCALE the text (as on object) it will mess with the character spacing and the word spacing.

If you group two text areas then spacing will also be affected.

Revision history for this message
ScislaC (scislac) wrote :

This inconsistency is incredibly frustrating and confusing as a user.

1) Create text
2) Change document units
3) Change letter spacing in the text tool to 10 and hit enter.
4) Now try adjusting it using the spinbox arrows.

Changed in inkscape:
importance: Undecided → Low
tags: added: blocker
ScislaC (scislac)
tags: removed: blocker
Changed in inkscape:
milestone: none → 0.92
Revision history for this message
Alvin Penner (apenner) wrote :

similar problem reported at Bug 1421842

Revision history for this message
Alvin Penner (apenner) wrote :

fix committed to rev 13937

Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → Alvin Penner (apenner)
su_v (suv-lp)
tags: added: backport-proposed
Revision history for this message
ScislaC (scislac) wrote :

trunk r13937 backported in 0.91.x r13749

Changed in inkscape:
milestone: 0.92 → 0.91.1
su_v (suv-lp)
tags: removed: backport-proposed
jazzynico (jazzynico)
Changed in inkscape:
milestone: 0.91.1 → 0.92
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers