v_kyr Posted December 27, 2019 Share Posted December 27, 2019 38 minutes ago, GarryP said: where I use “x+10” and “w/2 px” Though for "x+10 px" or "w/2 px" etc. it won't with an applied UOM here, thus the whole parsing is usage oriented, pretty inconsequent and confusing implemented for certain aspects. Quote ☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan ☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2 Link to comment Share on other sites More sharing options...
GarryP Posted December 27, 2019 Share Posted December 27, 2019 Yeah, confusing. I’m not sure what “w/2 px” would do – e.g. divide the width by 2 pixels? - but “x+10 px” (or any other UOM) should definitely be allowed, especially if you want to temporarily override the document’s UOM. For example, a document might be measured in inches but some elements might be measured in millimetres for convenience. Does anyone have any objections to me reporting this as a bug? Quote Link to comment Share on other sites More sharing options...
v_kyr Posted December 27, 2019 Share Posted December 27, 2019 53 minutes ago, GarryP said: I’m not sure what “w/2 px” would do – e.g. divide the width by 2 pixels? Since the document used units are shown there as defaults in that fields, in this initial case probably a document size setup in pixels is used as default. So for “w/2 px” I would here expect then, the half doc width sized in pixels. - For other expressions with units, then the math related operation dependent on the given unit measures. Thus for "x * 10 px" I wouldn't expect that to be the same x position as "x * 10 mm". Here then also a corresponding unit size conversion from one to the other then would be internally needed for given units. However, that's how I would usually expect and interpret expr entries for those fields. But as we already noted, some things work others do not dependent on an UOM usage or not then, thus I think parsing is not consequent equally used here and thus maybe sometimes undetermined in behavior. Quote ☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan ☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2 Link to comment Share on other sites More sharing options...
walt.farrell Posted December 27, 2019 Share Posted December 27, 2019 For another example, given an artboard that is 2000px in width, in a document setup as 300DPI, w+(2 in) gives you an artboard that is 2600px in width. 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...
Gear maker Posted December 27, 2019 Share Posted December 27, 2019 6 hours ago, GarryP said: FYI my mac gives the same results. I had been suspicious when you show column C didn't work, but I couldn't get it to work either. Yes I think a bug report needs to be done due to the inconsistency of operation. Quote iMac (27-inch, Late 2009) with macOS Sierra Link to comment Share on other sites More sharing options...
GarryP Posted December 28, 2019 Share Posted December 28, 2019 A bug report has been created: I put it in the Windows section but have noted that it's on OS X too. Gear maker and firstdefence 1 1 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.