macOS - Changing Stroke Width with Brackets seems off...

[ronnyb]

New Beta adds increments with 4 decimal places — seems to be based on the Decimal Places for Unit Types preference?
 

For changing stroke width via keyboard, I think it would be good to just use 0.5pt increments fixed, instead of based on this preference setting.

[loukash]

1 hour ago, ronnyb said:

seems to be based on the Decimal Places for Unit Types preference?

This kind of bug already persists since v1. Always affected were e.g. input fields in the Text Frame and Paragraph panels. Especially annoying if you keep Decimal Places for Unit Types at value 6…  

[Sean P]

Hi Ronny,

What do you mean by New Beta adds increments with 4 decimal places?

This shortcut behaviour for [ and ] is intentional. By default [ and ] will change the value relative to what it currently is. This means that the larger the stroke is, the more it will increase. Meaning you can easily just hold the keys down to change it by a large amount relatively quickly if you just want to eyeball things.

You can use Shift+[ or ] and it will scale by an absolute amount of 1px for every key press. Arguably this isn't the most useful value for if your line or document is set to something else. This behaviour is not new to 2.4 and hasn't changed from what I can see.

[ronnyb]

3 hours ago, Sean P said:

Hi Ronny,

What do you mean by New Beta adds increments with 4 decimal places?

This shortcut behaviour for [ and ] is intentional. By default [ and ] will change the value relative to what it currently is. This means that the larger the stroke is, the more it will increase. Meaning you can easily just hold the keys down to change it by a large amount relatively quickly if you just want to eyeball things.

You can use Shift+[ or ] and it will scale by an absolute amount of 1px for every key press. Arguably this isn't the most useful value for if your line or document is set to something else. This behaviour is not new to 2.4 and hasn't changed from what I can see.

thanks for the explanation @Sean P Although it may not be new bug or behavior, let me explain why I think this isn’t working still.

Usually when designing we maintain levels of consistency throughout a design’s elements. Stroke weights are one of those elements that need to be consistent. Having the keyboard shortcut for stroke weight add 4 decimal places is not useful nor best practice, that level of precision is best saved for numeric input.

i was not aware of the Shift modifier to increment in absolute number of pixels. However the pixel unit is useless for print work.? How about making.the increment in whole POINTS, not Pixels? Furthermore, I wud suggest swapping the modifier to increase in POINT increments with the brackets, and to increase stroke weight  variably when pressing the Shift modifier. This will prevent introducing uneven increments by default. 

Thanks for your consideration and everything you do! 🙏 
 

[walt.farrell]

22 hours ago, ronnyb said:

For changing stroke width via keyboard, I think it would be good to just use 0.5pt increments fixed

That's not going to be very useful to users working in px or other unit of measurement, though.

In any case, the [ and ] shortcuts are already rather imprecise as they decrease/increase the brush size by a percentage. And the absolute sizes will differ when you increase using ] and then decrease again using [. 

E.g., 16  ]  18.4  [  17.996

[walt.farrell]

@Sean P: Has it been reported that [ and ] remember and work from the last value they generated? This is not new to the beta, or even to V2 as V1 behaves the same way. It's just something I noticed while reviewing this topic and playing around.

Scenario:

1. Designer on Windows
2. New document
3. Select Vector Brush Tool, with default brush size of 16 px.
4. Paint a stroke (16px).
5. Press ] which gives 18.4 px. Paint a stroke.
6. Press ] which gives 21.16 px. Paint a stroke.
7. Type 16 px into Width field on Context Toolbar. Paint a stroke (16 px).
8. Press ] which gives 24.334 px, which continued incrementing from step 6 (last value set by ]) not from the manually set value in step 7.

[debraspicher]

9 hours ago, Sean P said:

Hi Ronny,

What do you mean by New Beta adds increments with 4 decimal places?

This shortcut behaviour for [ and ] is intentional. By default [ and ] will change the value relative to what it currently is. This means that the larger the stroke is, the more it will increase. Meaning you can easily just hold the keys down to change it by a large amount relatively quickly if you just want to eyeball things.

You can use Shift+[ or ] and it will scale by an absolute amount of 1px for every key press. Arguably this isn't the most useful value for if your line or document is set to something else. This behaviour is not new to 2.4 and hasn't changed from what I can see.

It would be fantastic if we could have a Snapping criterion that allowed users to override how [, ] handles increments. Even allowing us to use Shift + [,] to strictly follow pixel-precise convention (regardless of document units) would also be infinitely creatively useful. I get there's some calculations going on there to achieve a desired visual increment which results to increments such as 1.593255pt, and I'm not against that behavior as a different way of doing things and I think it has its place in Affinity, as long as there's a way to achieve the desired outcome without data entry.

[ronnyb]

Agreed! I'm suggesting the default behavior be changed so that:

1. Increment based on whole integers using the current document's selected Unit type, not based on percentages
2. It ignores the Decimal Places setting in apps' Settings.
3. Relegate the current behavior to the shortcut using the +Shift modifier

 

45 minutes ago, debraspicher said:

It would be fantastic if we could have a Snapping criterion that allowed users to override how [, ] handles increments. Even allowing us to use Shift + [,] to strictly follow pixel-precise convention (regardless of document units) would also be infinitely creatively useful. I get there's some calculations going on there to achieve a desired visual increment which results to increments such as 1.593255pt, and I'm not against that behavior as a different way of doing things and I think it has its place in Affinity, as long as there's a way to achieve the desired outcome without data entry.

 

[ronnyb]

I don't think the current behavior is an issue as much with vector/raster brushes than with stroke weights, as that use case is more aesthetic. But when dealing with vector objects in a design / information context —as opposed to an illustrative/artistic context— consistency of stroke weights is critical for the document's coherency in visual hierarchy.

 

6 hours ago, walt.farrell said:

@Sean P: Has it been reported that [ and ] remember and work from the last value they generated? This is not new to the beta, or even to V2 as V1 behaves the same way. It's just something I noticed while reviewing this topic and playing around.

Scenario:

1. Designer on Windows
2. New document
3. Select Vector Brush Tool, with default brush size of 16 px.
4. Paint a stroke (16px).
5. Press ] which gives 18.4 px. Paint a stroke.
6. Press ] which gives 21.16 px. Paint a stroke.
7. Type 16 px into Width field on Context Toolbar. Paint a stroke (16 px).
8. Press ] which gives 24.334 px, which continued incrementing from step 6 (last value set by ]) not from the manually set value in step 7.

 

[walt.farrell]

35 minutes ago, ronnyb said:

I don't think the current behavior is an issue as much with vector/raster brushes than with stroke weights, as that use case is more aesthetic.

Good point, and I see that for stroke widths (Pen Tool, etc.) the [ and ] keys do not have the problem I described above. That seems to only affect brush widths.

[debraspicher]

5 hours ago, ronnyb said:

I don't think the current behavior is an issue as much with vector/raster brushes than with stroke weights, as that use case is more aesthetic. But when dealing with vector objects in a design / information context —as opposed to an illustrative/artistic context— consistency of stroke weights is critical for the document's coherency in visual hierarchy.

I don't like it so much for the raster brushes either. But again, I'm not looking to change the default, but rather to be able to do a full override when needed, using Snapping settings (subjectively it is not semantic, but I think it could be an appropriate area for overrides?). For example, I use whole pixels to fill in with ink with rounds, etc, similar to a vector stroke, but hand drawn with raster. Vector brushes of an organic type (non-round) don't matter as much as I tend to view them as a painterly stroke, so when they finally make those brushes full vector and we can expand it... then we can adjust as we need after. That's labor we would expect would be necessary if we needed to hint a logo or something with a vector brush stroke in it for output.