Designer 2: the age old integer transform for artboards +1px export problem.

[daffyflyer]

Just had the most frustrating experience with Affinity.. Have designed a UI with a total of 1250 artboards, only to realize that all along they've been creating at non integer locations

And this means for like a month now my supposedly 96 pixel elements for example have been exporting at 97 pixels... 

Looking on the forums I'm finding nearly a decade of people complaining about this issue, and how unintuative it is that by default, if you're not paying attention to placement, artboards will end up in non integer positions and just sneakily change size on export. 


Best I can understand the solution is to use force pixel alignment *from the start* but that if you've already got it wrong, it seems like you can't fix it? 

I tried using force pixel alignment and moving every artboard at once, but that doesn't work.   It seems the only solution is individually moving each of my 1250 artboards, all because I didn't realize that the exact placement of my artboards would cause the size I specified to be ignored/incorrect. 


I'm really liking Affinity Designer 2 in most other respects, but right now I'm so frustrated with it, and I don't know how I'm going to even fix my project besides manually moving thousands of objects to correct a really sneaky and silent behaviour that I had no way to anticipate...


Can we at least have some kind of "I'm an idiot and placed my artboards at fractional transforms, please fix it" button?   And maybe a warning on export that artboards are exporting a different size to what we've actually specified?

[daffyflyer]

Just to point out I'm not the only one.. 


And I understand the reason it happens, I just don't understand how we're supposed to fix it.

To be clear, not how we avoid it, I get that, how do we fix it *once we've done it* to thousands of objects? 

And why despite complaints dating back to like 2017 does the constant reply to this seem to be versions of "Well of course it does that if you don't position things right, what did you expect?  Sorry nothing we can do"

I'm so exhausted
 

 

[kaffeeundsalz]

1 hour ago, daffyflyer said:

And why despite complaints dating back to like 2017 does the constant reply to this seem to be versions of "Well of course it does that if you don't position things right, what did you expect? 

You'll find an approximately equal number of replies that acknowledge the issue. The thing is that the kind of reply you posted really does contain the solution as long as the software itself doesn't offer an easier way to fix this. I guess you could rephrase this to something less reproachful, e.g. "Take extra care that objects are positioned correctly from the very beginning, otherwise you'll need to do a lot of extra work later". But both of these tones boil down to the same thing.

Something you could do and which works if (and only if) all your objects are offset by exactly the same decimal amount: do some basic arithmetics in the transform panel to slightly nudge your entire composition (including the artboards) to the next whole pixel. You'll need to set the document units to pixels and you may need to increase the number of decimal places visible in order for this to work. But as soon as you need to move/scale different objects by different amounts to make them align to whole pixel values, you need to do it manually. For thousands of layers, this is of course not a viable solution. But it's the only one for now.

[carl123]

1 hour ago, daffyflyer said:

To be clear, not how we avoid it, I get that, how do we fix it *once we've done it* to thousands of objects? 

Is it just the x/y values of your Artboards that contain non-integer values or do some or your Artboards also have non-integer w/h values (width and height)?

 

[daffyflyer]

Bizzarely the nudge trick fails in a new and exciting way I've never seen before. 

If I calculate the exact amount it needs to move, and do it to one artboard (they're almost all off by 0.513, so that's easy enough to do) then it fixes that artboard.  Selecting one artboard and dragging it with force pixel alignment on also fixes that one artboard. 

If I select more than one artboard and nudge them however, regardless of the size of the nudge or the snapping settings it will appear to move, but when it's deselected again it'll snap to a position thats [INTEGER].513     Even if I nudged it to like 100.253, as soon as I deselect the multiple artboards it pops back to that same 0.513.   Typing in a transform also doesn't work, at it'll just slap 0.513 on the end too.   

That might make sense to me if I had force pixel alignment/move by whole pixels on, but it does it regardless of if it's off or on, so that's even more baffling. 



The only thing I've found that fixes it, is specifically click and drag moving each individual art board, one by one, with force pixel alignment on.


Basically it seems I've "tainted" the art board transforms somehow and force pixel alignment doesn't work when moving multiple artboards at once....

I dunno.  I guess it should only take me a couple of hours to manually drag each artboard.  It was just overwhelmingly frustrating finding out that this has been an issue that has tripped up so many people since day one without any way of fixing it or even warnings that it's happening.  It seems to be just assumed knowledge that "well of course sometimes things don't export the size you set them to"   

 Possibly I'm just confused given I mostly work on textures in packages like Substance Designer, where if textures *sometimes* exported a different size to what was specified it'd be considered completely acceptable, given the whole powers of two thing... 



 

[daffyflyer]

Nah, the heights and widths are perfect, I typed them in because I knew it was important they be correct.  I just had no idea that the exact position of the artboard actually mattered, and got over 1000 deep before noticing. 😓 

Weirdly basically every artboard that is wrong, is at like 25969.513 px in Y (or any INTEGER.513) always .513

 

 

[carl123]

3 minutes ago, daffyflyer said:

Nah, the heights and widths are perfect

Good

I don't know the exact layout of your Artboards but...

Assume you have 5 Artboards in a row and each has a non-integer x value

1. Fix the first Artboard (e.g. x=0)
2. Select the row of all 5 Artboards
3. Use the alignment option "Space Horizontally" and set the value to (say) 50px
 

All Artboard x values should now be Integer values
 

[daffyflyer]

14 minutes ago, carl123 said:

Is it just the x/y values of your Artboards that contain non-integer values or do some or your Artboards also have non-integer w/h values (width and height)?

 

Ah that is probably the most sanity preserving approach, I'll give that a crack.  At the very least it's a lot better than doing them one by one, thanks  

Still would absolutely kill for a "just snap every artboard to the nearest integer" option.   Or a "please actually export the size I asked for" option though! 

[kaffeeundsalz]

26 minutes ago, daffyflyer said:

Still would absolutely kill for a "just snap every artboard to the nearest integer" option.   Or a "please actually export the size I asked for" option though! 

Yes, these are the two solutions that are already being discussed at length, and I completely agree with you. "Force pixel alignment" should get an option for an extra emphasize on "force" so the introduction of decimal places gets avoided at all costs even for things like proportional scaling, adding effects or certain snapping operations. Alternatively or even additionally, there should be an option to ignore the absolute pixel grid of the whole canvas when exporting assets from artboards. Alas, it's entirely up to Serif to implement any of this.

[daffyflyer]

Yeah, not holding my breath on anything getting implimented there given how long its been talked about, but thought I should at least add my feelings on the matter to the pile of feedback! 

[Pšenda]

2 hours ago, daffyflyer said:

individually moving each of my 1250 artboards

The position of the Artboards is based on the position of the "first" artboard, i.e. the one on the top and left. So just adjust its position, and the positions of all the others will be broken or fixed by the same amount.

P.S. Is it really necessary to use so many artboards? - is this really the most appropriate design and working method?
Considering the "96 pixel elements", I assume that this is probably a design for equally sized images/icons, for which it is more appropriate to use Grid, see https://affinityspotlight.com/article/designing-a-travel-icon-set-with-isabel-sousa/

Another interesting article: https://affinityspotlight.com/article/hi-res-iconui-design-can-be-pixel-perfect/

Edited January 14 by Pšenda

[bures]

Is it really necessary for the Affinity developers to insist on this autistic vision of the world? I assume that most users don't default to requiring apps to work with decimals when specifying image dimensions. The problems with rounding values, when unwanted white lines are created, or when images change dimensions "by themselves", etc. are repeated over and over in this forum. This is just not right.

[kaffeeundsalz]

18 minutes ago, bures said:

Is it really necessary for the Affinity developers to insist on this autistic vision of the world?

Please tell me where they said that. The Affinity developers don't "insist" on anything here. The whole time the problem has existed, I have not seen any one developer claim that the current behavior is how it's supposed to be. This is a question of priorities and developer resources, not one of developers disavowing the existence of the problem.

[Pšenda]

12 minutes ago, kaffeeundsalz said:

The whole time the problem has existed

In my opinion, this is not a real/application "problem". As is clear from the linked article "Hi-res icon/UI design can be pixel perfect!", just follow a few principles, and no "problem" will ever occur. The problem is that some users assume some behavior of the application, which is not and has never been declared as such - so in my opinion there is nothing to fix.

[daffyflyer]

Just to be clear, you're suggesting:


If I create 4 art boards, and place them at different locations, all of them set to 100px x 100px

And when I export them they export as 100 x 101, 101 x 100, 100 x 100 and 101 x 101

That's just a case of "Well you shouldn't assume that just because something is 100px it's going to be 100px?

I don't really understand that take, but maybe I'm being an idiot and it's normal for things like that to happen, and I should have.... just known that setting a size doesn't actually mean setting a size?   

Personally if software I designed did that, and if there was such a history of people being confused by it, I'd consider it needs fixing and not that the user should expect it to happen...  and every thread about this seems to be a whole lot of people confused by it followed by 1 or two people being like "well it's your fault for not expecting this odd behaviour that isn't well telegraphed by the software"

[kaffeeundsalz]

On 1/14/2025 at 3:16 PM, Pšenda said:

The problem is that some users assume some behavior of the application, which is not and has never been declared as such - so in my opinion there is nothing to fix.

That's a valid position, yet it's clearly on the "Well of course it does that if you don't position things right, what did you expect?  Sorry nothing we can do" side that @daffyflyer mentioned above. We can probably agree that it's not a bug – that's why I didn't write "bug" in my reply. It might be an oversight by the developers, but we don't know since we have no insight into Serif's internal processes. It could even be a deliberate design choice because it gives you more control over antialiasing behavior (at the cost of export size precision).

My point is: There are many forum topics dealing with this effect. So for a lot of people, this application behavior has caused unexpected or unuseable results. In many cases, fixing was not easily possible, but required hours of extra work. When all of this comes together, I think it's time to evaluate whether it's really all the users' fault – or whether the application could be optimized so that a) the consequences of the intended behavior are communicated more clearly and earlier in the design process; b) the default behavior is changed in a way that fewer people get unexpected or unuseable results; and/or c) extra features allow for faster and easier design modifications that lead to the desired result.

Again, you are free to take a different view.