[Publisher 2.6.0][BUG][Horizontal rule (Paragraph>Decoration) ending spaces do not get underlying rule]

[Franz Rogar]

ISSUE

I want to create an underlying rule that it's 2 em spaces wider (left and right) of a field text.

The issue is that the ending em spaces do NOT get the underlying rule.

WHY I CONSIDER THIS A BUG?

Even though "ignoring" spaces at the end of a sentence might be thought of being useful to the lazy editor, I don't think they should be ignored because they are, after all, part of the text.

WORKAROUND

As "workaround", I've added a "transparent" character at the end with a tracking of "-500%" (thus reducing its horizontal space to none).

It'd be a nice to add "horizontal rule" support to APub, via "Paragraph > Decorations" + "length modifiers".

[MikeTO]

There's an easier way to do what you want.

1. Don't add any spaces to your heading
2. Format the running header field's bottom decoration with negative left and right indents. Try -10 mm as a starting point.

[Franz Rogar]

9 hours ago, MikeTO said:

There's an easier way to do what you want.

Thank you very much for the "easier" and cleaner way, but that suffers from a side issue: if you change the font size, the hanging is no longer "visually proportional", forcing you to manually resize the indents. Thanks why I used "em spaces" for that, so all rules hang the same width (which your workaround does) and keeps been visually pleasant (which will be lost as you change the font size farther from the original one, forcing you to manually tweak).

It'd be nice if the "indent" field would allow for "em/en/thin/..." spaces as measurement unit, not just the document one (in this case, mm).

As a real example, Inkscape "number" fields (everywhere they are) take the "document" unit by default (for example, "mm") so if you write: "32" it recognizes "32 mm". But if you write "32 px", the object is resized to "32 px", not "32 mm"; if you write "32 pt"... et cetera.

Inkscape "converts" the unit (as far as I know) to the "document" one (to avoid bugs with future calculations) automatically, but in this case it'd be great if they were "kept" (em/en...) instead of "converting" them to the document one (mm).