ronnyb Posted January 11 Share Posted January 11 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. Quote 2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1 2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17 Link to comment Share on other sites More sharing options...
loukash Posted January 11 Share Posted January 11 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… debraspicher and ronnyb 2 Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
Staff Sean P Posted January 12 Staff Share Posted January 12 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 1 Quote Link to comment Share on other sites More sharing options...
ronnyb Posted January 12 Author Share Posted January 12 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! 🙏 Quote 2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1 2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17 Link to comment Share on other sites More sharing options...
walt.farrell Posted January 12 Share Posted January 12 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 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
walt.farrell Posted January 12 Share Posted January 12 @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: Designer on Windows New document Select Vector Brush Tool, with default brush size of 16 px. Paint a stroke (16px). Press ] which gives 18.4 px. Paint a stroke. Press ] which gives 21.16 px. Paint a stroke. Type 16 px into Width field on Context Toolbar. Paint a stroke (16 px). 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. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
debraspicher Posted January 12 Share Posted January 12 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 1 Quote Link to comment Share on other sites More sharing options...
ronnyb Posted January 12 Author Share Posted January 12 Agreed! I'm suggesting the default behavior be changed so that: Increment based on whole integers using the current document's selected Unit type, not based on percentages It ignores the Decimal Places setting in apps' Settings. 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. Quote 2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1 2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17 Link to comment Share on other sites More sharing options...
ronnyb Posted January 12 Author Share Posted January 12 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: Designer on Windows New document Select Vector Brush Tool, with default brush size of 16 px. Paint a stroke (16px). Press ] which gives 18.4 px. Paint a stroke. Press ] which gives 21.16 px. Paint a stroke. Type 16 px into Width field on Context Toolbar. Paint a stroke (16 px). 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 1 Quote 2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1 2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17 Link to comment Share on other sites More sharing options...
walt.farrell Posted January 12 Share Posted January 12 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. ronnyb 1 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
debraspicher Posted January 13 Share Posted January 13 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.