Inconsistence with stroke width

[transitdiagrams]

Hello guys,

just wanna report this inconsistency in AD. The correct width is applied to the stroke but the number in the appearance panel is wrong...

All the best,
Chris

[Dan C]

Hi @transitdiagrams/Chris,

Thanks for your report!

I suspect this is due to your Decimal Places for Unit Types setting in Preferences, if you navigate to Affinity Designer > Preferences > User Interface you can set the number of decimals for each unit type.

However I believe the Appearance Studio should also be using the User Interface setting and is expected to report with 1 decimal place (when 1 is used in User Interface), and that's the behaviour I'm seeing currently on macOS and Windows -

This continued to work as expected, even when setting my macOS & Affinity app to German, so that commas were used as the decimal separator, therefore I'm unable to replicate this currently.

I can also see in your screenshot that neither 'Draw stroke behind' or 'Draw stroke in front' is selected in the stroke panel, which is also unexpected and something I've not seen before.

Are you able to provide a sample .afdesign file which shows this issue please?

Many thanks in advance  

[transitdiagrams]

On 8/11/2022 at 2:20 PM, Dan C said:

Hi @transitdiagrams/Chris,

Thanks for your report!

I suspect this is due to your Decimal Places for Unit Types setting in Preferences, if you navigate to Affinity Designer > Preferences > User Interface you can set the number of decimals for each unit type.

However I believe the Appearance Studio should also be using the User Interface setting and is expected to report with 1 decimal place (when 1 is used in User Interface), and that's the behaviour I'm seeing currently on macOS and Windows -

This continued to work as expected, even when setting my macOS & Affinity app to German, so that commas were used as the decimal separator, therefore I'm unable to replicate this currently.

I can also see in your screenshot that neither 'Draw stroke behind' or 'Draw stroke in front' is selected in the stroke panel, which is also unexpected and something I've not seen before.

Are you able to provide a sample .afdesign file which shows this issue please?

Many thanks in advance  

Okay, hope this will be corrected with the next update... which is hopefully coming this year...

Attached a random file. Having more than one stroke not all strokes have draw behind/in front selected. I thought this is normal behaviour as only the most top or most bottom stroke can be in front/at the bottom. In between it wouldn't make sense to have the option selected, would it?

All the best,
Chris

stroke.afdesign

[Old Bruce]

5 hours ago, transitdiagrams said:

Attached a random file. Having more than one stroke not all strokes have draw behind/in front selected. I thought this is normal behaviour as only the most top or most bottom stroke can be in front/at the bottom. In between it wouldn't make sense to have the option selected, would it?

Drawing in front or drawing behind refers to in front of or behind the Fill, not the other strokes.

[Dan C]

23 hours ago, transitdiagrams said:

Attached a random file. Having more than one stroke not all strokes have draw behind/in front selected. I thought this is normal behaviour as only the most top or most bottom stroke can be in front/at the bottom. In between it wouldn't make sense to have the option selected, would it?

Thanks for providing that for me! My apologies as your understanding is correct, for strokes in the 'middle' of the appearance stack, neither behind/in front options are required, therefore neither are selected and this is expected behaviour.

Just to confirm, the file you have provided, does this show the same Stroke/Appearance error for you? As opening this file here shows the same values for me in both locations.

[transitdiagrams]

1 hour ago, Dan C said:

Thanks for providing that for me! My apologies as your understanding is correct, for strokes in the 'middle' of the appearance stack, neither behind/in front options are required, therefore neither are selected and this is expected behaviour.

Just to confirm, the file you have provided, does this show the same Stroke/Appearance error for you? As opening this file here shows the same values for me in both locations.

That's how I see it: