The slice dimension in the export persona is different (1px higher) from the artboard dimension in the designer persona in Affinity Deisgner

[Pon Siva]

When I design for 1080x1080 px artboards dimensions in the designer persona and then move to export persona to export the files, I have to manually adjust the slices to 1080x1080 px because some slices are 1081x1080 px (as shown in the attached picture). This makes it hard to export multiple artboards. Anybody else facing this issue?

[NotMyFault]

The artboard has fractional digits in x and y position. This causes the issue.

 

[Alfred]

3 hours ago, NotMyFault said:

The artboard has fractional digits in x and y position. This causes the issue.

I have never understood why the position of the artboard should affect the dimensions of the exported images.

[Pšenda]

59 minutes ago, Alfred said:

I have never understood why the position of the artboard should affect the dimensions of the exported images.

Because it defines the starting position in the pixel grid/raster into which the resulting image is rendered. This is a symmetrical property to the ability to define (and thus export) the image/canvas/artboard size in partial pixels.

[Alfred]

3 minutes ago, Pšenda said:

Because it defines the starting position in the pixel grid/raster into which the resulting image is rendered. This is a symmetrical property to the ability to define (and thus export) the image/canvas/artboard size in partial pixels.

I don’t understand why the exported image doesn’t simply have a starting position of (0, 0) every time.

[GarryP]

As I understand it, the exported bitmap image is always ‘aligned’ with the document pixel grid, rather than the Artboard or layer.

Because of this, when the image is exported, any sub-pixels that are needed, because of non-integer position/sizes, will be created as full pixels to cover the ‘short-fall’ so that nothing is omitted.

[Alfred]

2 minutes ago, GarryP said:

Because of this, when the image is exported, any sub-pixels that are needed, because of non-integer position/sizes, will be created as full pixels to cover the ‘short-fall’ so that nothing is omitted.

Surely sub-pixels should only be needed for non-integer sizes? I don’t understand how the position on the artboard is relevant when you’re only exporting an object on the artboard, not the artboard itself.

[GarryP]

I don’t know if I can explain it any better than I did above.

All I need to know is that I need to use integer pixel positions and sizes to make sure I get what I want when exporting to bitmap file types.

That’s just pretty-much ‘second-nature’ to me now so it’s difficult for me to know why I didn’t understand it before I did, or to explain it better.

[Alfred]

2 hours ago, GarryP said:

All I need to know is that I need to use integer pixel positions and sizes to make sure I get what I want when exporting to bitmap file types.

That’s all I need to know too, Garry. The necessity of integer pixel dimensions is self-explanatory, but what has eluded me all along is the logic behind the requirement for integer pixel coordinates. When you export an image, you’re discarding its connection with the canvas or artboard that it came from, so its position there should be irrelevant.

[NotMyFault]

The 1px larger export size is actually the smaller issue. 
 

In case you have pixel aligned fine details (1px strokes, pixel art etc) on the artboard everything becomes a blurry mess at export.
If you use 0.5 offset for the artboard, a 1px black/white alternating pattern becomes 50% gray.

 

 

[GarryP]

17 hours ago, Alfred said:

what has eluded me all along is the logic behind the requirement for integer pixel coordinates

My (complete) guess is that it’s much easier to create and maintain the code when the pixels are ‘fixed’.

If the various Effects and Live Filters (etc.) work with the pixel grid of the document then I imagine it might be difficult to replicate their effects upon export in such a way that the output exactly matches the on-screen document when the thing being exported isn’t aligned to the pixel grid of the document, which itself could create ‘sub-pixels’ which would then have to be ‘dealt with’.

[Alfred]

3 minutes ago, GarryP said:

My (complete) guess is that it’s much easier to create and maintain the code when the pixels are ‘fixed’.

Thanks, Garry. That sounds plausible. I must confess that I haven’t taken the time to think it through, but it seems that you have.

[GarryP]

There wasn’t much thinking involved, and I might be completely wrong, but I think it sounds plausible to me.

I vaguely remember that a member of staff explained it a good while back but I can’t remember who that was or what the explanation was (or even if it actually happened).

Whatever the reason, I think it should be documented so that (the few?) people who read the Help can find the information and know what to do about it, even if it’s not what they might expect.

[Pšenda]

On 3/9/2025 at 9:54 AM, GarryP said:

I think it should be documented

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

[GarryP]

I said that I thought it should be in the Help, rather than in some Spotlight article.

[Pšenda]

2 hours ago, GarryP said:

I said that I thought it should be in the Help, rather than in some Spotlight article.

In my opinion, Help is about basic instructions on how to use the application's tools. Something like a car's user manual - how to shift gears, how to turn on the turn signals. On the other hand, just like the "skill" of taking a curve at maximum/racing speed, Pixel perfect design is already a specific knowledge and skill (which not all users/drivers need) that should be described in a more specialized document on procedures and skills, not in a basic/general help manual. This is exactly why I bought Affinity Workbooks, because in them I can find procedures and skills that I can't find in Help - and I wouldn't even look for them there.

But personally, I think the biggest problem with Pixel perfect design is that users don't expect it - other apps behave differently. If the user understands it and accepts this logic, then there is no problem at all.

[NotMyFault]

Thanks for the insightful link to spotlight. This explains some unknown background to me, but more in the way of highlighting issues than solutions.

Affinity seems to think pixel perfect workflows are only used for UI design in Apple universe, and relies on a dirty trick to use 144dpi to get 1pt = 2px.

Most users requiring pixel perfect results are not designing UI, and not working as developers targeting Apple platform.

They need pixel perfect design for uncountable other reasons, coming from Windows, Linux or other apps. Requiring them to know these crude constraints is just ridiculous.

It seems Affinity developers are totally blindfolded by their own usage and experience as UI developers, on Mac devices and cannot imagine that there are different demands in the outside world.
So I can only agree and emphasis on your last sentence - Affinity must explain the Affinity specific constraints and assumptions, in online help. Or better provide an app in line to what allmost all competing apps do and users rightfully expect.

 

 

[GarryP]

I don’t think there is a ‘one-size-fits-all’ solution for this sort of thing but I’m not a big fan of this sort of important information – which, as has been said, most users won’t be aware of initially – being outside of the main documentation (Help).

It comes up so many times in the forums that I think there should be at least a mention of it in the documentation somewhere but I don’t know where would be best to put it. (And I realise that many users don't read the Help.)

Personally I would like to see a page in the Help which gave people a good set of basic do’s and don’ts for pixel-aligned work – maybe utilising some of the Spotlight article – but I realise that might never happen.

Basically, if the software does something that ‘most’ users would not expect then that should probably be properly documented – including the reasons for it doing so – but I don’t know where or how.

[Pšenda]

55 minutes ago, GarryP said:

It comes up so many times in the forums that I think there should be at least a mention of it in the documentation somewhere but I don’t know where would be best to put it. (And I realise that many users don't read the Help.)

The very fact that it is discussed so often and repeatedly on the forum only points to the fact that users are not looking for this information. In fact, all you need to do is write a simple query to the search service (https://www.google.com/search?q=1px+higher+site:https://forum.affinity.serif.com), which contains part of the topic title "1px higher", i.e. no secret and specific term, and dozens of relevant posts are available. So, including this information in Help (perhaps in the form of a link to a more detailed article/video) would probably not find its reader anyway, because the user with this problem would come across it. By the way, where and in which chapter should this information be included? Some new chapter about frequently discussed problems and differences? Or a link to a specific part of the forum (something like FAQ) with a description of procedures and problems (tutorials)?
But the truth is that this is such a frequently discussed problem that Serif should try to do something about it.

[GarryP]

25 minutes ago, Pšenda said:

In fact, all you need to do is write a simple query to the search service (https://www.google.com/search?q=1px+higher+site:https://forum.affinity.serif.com), which contains part of the topic title "1px higher", i.e. no secret and specific term, and dozens of relevant posts are available.

What if the person doesn’t look at the problem as it being “1px higher”? What if they think it’s “1px larger”, or “1 pixel wider”, or “one pixel too big”, or just “bigger than expected”, or even “too big”, or anything else which isn’t as specific as “1px higher”?

I know the OP used that in their title but not everyone does, and because of that they won’t use the same keywords even if they do try to search.

25 minutes ago, Pšenda said:

But the truth is that this is such a frequently discussed problem that Serif should try to do something about it.

That’s something which I think we can both agree on, but I think we can leave that to someone who’s getting paid to decide how to do it.

[Pšenda]

2 minutes ago, GarryP said:

What if the person doesn’t look at the problem as it being “1px higher”? What if they think it’s “1px larger”, or “1 pixel wider”, or “one pixel too big”, or just “bigger than expected”, or even “too big”, or anything else which isn’t as specific as “1px higher”?

Any variant of the query/problem description will bring relevant results:

https://www.google.com/search?q=1px+larger+site:https://forum.affinity.serif.com
https://www.google.com/search?q=1+pixel+wider+site:https://forum.affinity.serif.com
https://www.google.com/search?q=one+pixel+too+big+site:https://forum.affinity.serif.com

Although the relevance of some "creative" queries will of course decrease, but the results provided can help refine the query (but I suppose these are the basics of effective internet searching). This is, after all, the advantage of external searches in forum posts or online Help - they will always bring more relevant results even if you don't know the exact term and formulation of the problem.

[GarryP]

I think some people might balk at having to do an external search (or having to search at all in some cases) but I can certainly see where you’re coming from.

Since Serif are very much aware of the issue I guess we can just wait and see if anything happens.