Measurement anomaly in the decoration

[Pyanepsion]

Hello everyone,

The + or - sign of the value indicating the distance does not make much sense to me, as it does not depend on the origin or the deviation from the limit. What about it?

 

 

[MikeTO]

Hi, paragraph decoration is relative to the paragraph, not to the text frame.

When you make the left indent relative to the column, it is relative to where the text would normally start and end in the column and ignores other paragraph formatting such as the normal left and right indent. When you make it relative to "indents", it takes that other formatting into account. These settings have nothing to do with the text frame or its origin which is why top and bottom don't have a column option. Perhaps they could be named more clearly and it would be helpful if they were described in the Help system.

Cheers

[Pyanepsion]

I wanted to talk about the positive or negative value of decoration. Distance is usually used in two ways:

1. Either as a distance outwards with a positive value and inwards as a negative value (example margin in CSS with Firefox);
   
2. Or as a distance from a vertical line and respectively vertical with a negative value to the left of the vertical, and above the horizontal, and respectively with a positive value to the right of the vertical, and below the horizontal.
   

This is not the case here with Affinity Pubmlisher, which leads to some misunderstanding. It looks like a bug to me.

Comparison in CSS and recently in Affinity Publisher

Null value: This seems consistent.

Positive value: This is the opposite of the usual logic about left, right and up. The bottom, curiously, follows a different logic, the one that is in fact usually used.

Negative value: This is the opposite of the usual logic about left, right and up. The bottom, curiously, follows a different logic, the one that is in fact usually used.

More information on CCS logic on Firefox Developer.

[MikeTO]

I think you're looking at this differently than it's designed. The fields are labeled "indent" (retrait) so positive values indent from the left and right column edges or whatever option you chose while negative values outdent. This exactly mirrors Paragraph > Spacing's Left and Right Indent options where positive and negative values do the identical thing.

[Pyanepsion]

The new behaviour of version 2 is really not ergonomic.

The vocabulary has been adapted accordingly for the spacing. The vocabulary and behaviour should also be adapted to the management of decorations so that it does not become a real headache.

The easiest way to see this is to perform some manipulations in the attached AFPUB file. If, for example, you want to add a decoration around the text, you must now write :
-0,14
-0,14
-0,14
+0,14 (not -0,14)

decoration.afpub

The paragraphs before and after use the Normal style. The middle paragraph uses variations of the decoration. At the start, we start from scratch.

The horizontal axes increase in value not when they move towards the centre between the two edges, but when they both move downwards.

The vertical axes of the decoration both increase in value as they approach the centre between the two edges.

The vertical and horizontal behaviour changes.

This behaviour differs from the margin management, and it differs from version 1. This is a headache as it goes against the grain.

[MikeTO]

Ah, I didn't notice the bottom issue.

Serif, the Decorations > Bottom field's value is inverted in meaning in v2, positive is treated as negative, so opening a v1 document in v2 will change its formatting.

Here is a simple v1 test document that will appear differently when opened in v2.

Decoration test.afpub

This document has decoration values of 0.25" for all four fields which in v1 (centre screenshot) correctly indents the decoration from all four edges, but in v2 (right screenshot), the bottom value outdents the decoration.

  

[Patrick Connor]

Thanks @Pyanepsion for your detailed investigations. This is a know issue (the same one you reported here) 

[Patrick Connor]

Sorry that you have experienced this problem with the 2.0.3 release of the Affinity Suite. 

We have now released 2.0.4 on all platforms, and using those builds this problem no longer occurs.

Unfortunately while the Text Frame "Bottom" decoration UI was broken in 2.0.3. If you actually used that field to adjust your frame decoration, then when loaded into 2.0.4 your document will look different to the way it drew in the (incorrect) 2.0.3 version. Please tweak your decoration bottom value in 2.0.4 and it should look correct again (as it did in 1.10.x or 2.0.0)