Please force integers on Artboard pixel dimensions

[Frank Jonen]

Sometimes (like 98% of the time) moving Artboards around creates floating point pixel values in their position and dimensions.

This always results in rendering errors (white gaps, wrong export sizes, distortions). The problem has not been addressed since Artboards got introduced.

There's no benefit to having sub-pixel accuracy when moving Artboards around on an infinite canvas. It only creates problems.

[Gabe]

Hi @Frank Jonen,

This is a feature request/improvement, and not a bug. If you turn "Force pixel alignment" on, you won't have this issue

[Fixx]

On 4/16/2020 at 12:18 PM, Gabe said:

f you turn "Force pixel alignment" on, you won't have this issue

Maybe it should be on by default.

[ashf]

On 4/16/2020 at 2:18 AM, Gabe said:

Hi @Frank Jonen,

This is a feature request/improvement, and not a bug. If you turn "Force pixel alignment" on, you won't have this issue

Artboards often snap to objects that have floating point pixel so in that case it won't work as expected.(hard to notice it)
Artboards should be aligned to the pixel grid regardless of snapping.

[GarryP]

Why should users be forced to have pixel alignment when creating/moving artboards?
Why not let them choose by simply using (or not using) the existing “Force Pixel Alignment” functionality as mentioned above?
While I can see that a lot of people would want pixel alignment by default I can imagine that other people might not want it, so why force it onto the people who don’t want it when the functionality exists to allow users to say whether they want it or not?
Can you give an example of an artboard snapping to objects that are not aligned to integer pixel values when “Force Pixel Alignment” is switched on?

[Alfred]

1 hour ago, GarryP said:

Why should users be forced to have pixel alignment when creating/moving artboards?

We shouldn’t, but there probably wouldn’t be nearly so many support queries if ‘Force pixel alignment’ were switched on by default as @Fixx suggested.

[GarryP]

I agree with both of your comments above.
Personally I would prefer if it was switched on by default as I can’t think of a time where I have wanted it to be switched off. Also, as you say, there would be fewer issues reported if it was switched on by default.
But, I don’t think it should always be forced on (i.e. the only available option) when creating/moving artboards (which is, I think, the issue in this case), just in case someone has a good reason to not want it on.
However, ashf seems to say that even if it is switched on there may be instances where it is not enforced, which is why I asked for an example. If it is not enforced when it is switched on then that might be something that needs looking into.

[VolkerMB]

I know it is my fault, however, every time I use artboards I run into this issue. And it takes some extra steps to correct it (I always exort it first before I realize something is wrong...).

One example: Create two artboards of size A4 with "force pixel alignment" and "move by whole pixels" switched on. The initial position of the artboards is fine, but the size is not: 2480,3 x 3507,9 px. If you move one of the artboards for any reason and let it snap to the other one you are in trouble afterwards. When moving the artboards now, the position is never an intereger value again but a floating one.

The solution is to swich off "move by whole pixels" so that the artboard position can fall back to full interger values. However, it is a bit counter-intuitive... Maybe a different default setting could help.

[Alfred]

2 minutes ago, VolkerMB said:

The solution is to swich off "move by whole pixels" so that the artboard position can fall back to full interger values. However, it is a bit counter-intuitive... Maybe a different default setting could help.

What’s counterintuitive for me is that ‘Force pixel alignment’ doesn’t take precedence, even though ‘Move by whole pixels’ is presented as a child option.

[SnapArtboardsToPixels]

This is such a bad implementation.
A) Snap to pixel alignment isn't working for me, I don't know why, I assume something else in the snapping is overriding it. I have spent the day rounding off numbers, and then accidentally one board that was imperceptibly an extra pixel wide.
B) Even if it was working, all we really want it to not have to think about this and the sheer volume of people talking about this issue shows that it just doesn't work.

I have just moved over and used designer all week so it's crazy that of the hundreds of features I have used this is the thing that is making me want to move back. I guarantee you that most people working in the software want a grid of artboards and not to have to think about if they will export at 1081px or 1921px. They don't want to toggle a (finicky) setting on and off just to duplicate boards, I have literally never wanted to have one artboard placed 0.1px below the other in 20 years of doing this, just make artboards snap to pixel by default.

[kilimanjaro]

Even the current implementation is broken.

If I have a board that is placed on, say y: 2080.5 and I switch on force pixel alignment and move by whole pixels it will only move the dartboard by whole pixels i.e. 2081.5 or 2082.5. So, if I have to uncheck move by whole pixels to actually force the coordinates of the artboard to always be on a whole pixel. Great.

So, now please pray tell me what is the point of having the option to move by whole pixels if it's a subitem of force pixel alignment and kinda disables that when checked?

[GarryP]

3 hours ago, kilimanjaro said:

what is the point of having the option to move by whole pixels if it's a subitem of force pixel alignment and kinda disables that when checked?

This is an old ‘argument’ which will probably never be 'resolved'.
The software is working as it is designed to work but it is confusing until you know what’s happening.
Force Pixel Alignment, when Move by Whole Pixels is also activated, only applies to new layers, not existing layers.
If you have an existing layer which has a non-integer pixel location then Move by Whole Pixels will keep the fraction of a pixel when you move that layer.
Force Pixel Alignment is like saying “Only allow integers”, but Move by Whole Pixels is the equivalent of “But also allow fractions for the stuff that already exists”.
It’s the naming that is confusing but “Move by Whole Pixels only for new layers but keep the fractional parts of values for existing layers” is a bit too long for a button name.
You just get used to it eventually.

[Alfred]

52 minutes ago, GarryP said:

It’s the naming that is confusing but “Move by Whole Pixels only for new layers but keep the fractional parts of values for existing layers” is a bit too long for a button name.

The problem isn’t the naming, it’s the layout of the options and the behaviour that results.

As @kilimanjaro points out, Move by Whole Pixels (MWP) is presented as a sub-item of Force Pixel Alignment (FPA). This means that you have to enable FPA in order to toggle the MWP state, but when MWP is toggled on it overrides its FPA parent.

When an object is aligned to the pixel grid, it doesn’t matter whether FPA or MWP is enabled. As long as one of them is enabled (or both are!) the object will end up aligned to the pixel grid when you move it. When an object isn’t aligned to the pixel grid, FPA and MWP are mutually exclusive, since the former forces alignment to the grid and the latter maintains the existing non-alignment. FPA and MWP should therefore be presented either as radio buttons, along with a third ‘Do Not Constrain’ option, or as checkboxes which can’t both be checked at the same time.

[Pšenda]

 

[kilimanjaro]

On 3/31/2022 at 4:40 PM, GarryP said:

This is an old ‘argument’ which will probably never be 'resolved'.
The software is working as it is designed to work but it is confusing until you know what’s happening.
Force Pixel Alignment, when Move by Whole Pixels is also activated, only applies to new layers, not existing layers.
If you have an existing layer which has a non-integer pixel location then Move by Whole Pixels will keep the fraction of a pixel when you move that layer.
Force Pixel Alignment is like saying “Only allow integers”, but Move by Whole Pixels is the equivalent of “But also allow fractions for the stuff that already exists”.
It’s the naming that is confusing but “Move by Whole Pixels only for new layers but keep the fractional parts of values for existing layers” is a bit too long for a button name.
You just get used to it eventually.

This is typical programmer logic forced on end users that only makes sense if you explain it and end user will have forgotten the explanation by the time they use it, and be confused every single time.

In short: it's a shitty user experience, it's bad usability, it's not predictable just by looking at the info you can get from the UI and it should be fixed to a behavior that can easily be understood and predicted by normal end users, not programmers.

[Frank Jonen]

On 3/31/2022 at 9:40 AM, GarryP said:

You just get used to it eventually.

AKA “the prime reason why people abandon apps”. Developer arrogance. 

[Old Bruce]

Forcing integer pixel dimensions means a lot of cases (if not most cases) where artboards will be off by fractions of an inch/cm / etc. depending on the dpi/ppi.

[Alfred]

13 minutes ago, Old Bruce said:

Forcing integer pixel dimensions means a lot of cases (if not most cases) where artboards will be off by fractions of an inch/cm / etc. depending on the dpi/ppi.

Those fractions of a physical unit are tiny fractions. Even for a resolution as low as 72 ppi, half a pixel is only 1/144 inch.

[fde101]

On 4/5/2022 at 11:35 AM, Alfred said:

Those fractions of a physical unit are tiny fractions. Even for a resolution as low as 72 ppi, half a pixel is only 1/144 inch.

Even so, having both options available means that you can be precise in terms of pixels, or precise in terms of real-world units (where the pixels may or may not map precisely).

There are valid applications for both, so no reason to force all users to one or the other when different users have different needs.

[Frozen Death Knight]

When I was doing UI design work with Artboards for school, the problem of pixel misalignment became a very, very big problem. I had to constantly change the placements of Artboards just to fix things like export slices having the wrong dimensions (every texture needed to use power of two, so a ton of errors), text and frames being misaligned so active and inactive versions of the same button did not match, etc., etc.

The thing is that this problem can reappear depending on how you place Artboards. If you move an Artboard the misalignment problems can start appearing on Artboards that you previously fixed. This to me is the most annoying aspect of doing this type of work in Affinity. I was able to learn how to use the various snapping options to fix stuff (Pixel View Mode was a life saver as well), but it would be much appreciated if this kind of workflow was a lot more streamlined so very little tinkering was needed to get pixel accurate results.

[RedMattis]

Yes. Please max snapping for artboards separate to everything else. It is an absolute pain to constantly go back and find that random artboard exports are 512x513 

[Pšenda]

5 hours ago, RedMattis said:

It is an absolute pain to constantly go back and find that random artboard exports are 512x513 

If you use the many times recommended settings for Pixel perfect, i.e. Force Pixel Alignment = on, Move by Whole Pixels = off, then the position and size of the artboards is always in integer pixels.

[walt.farrell]

8 minutes ago, Pšenda said:

If you use the many times recommended settings for Pixel perfect, i.e. Force Pixel Alignment = on, Move by Whole Pixels = off, then the position and size of the artboards is always in integer pixels.

As long as one doesn't move them while holding the Alt (Windows) or Opt (macOS) key, which overrides Snapping, that's a good approach.

[Pšenda]

1 minute ago, walt.farrell said:

As long as one doesn't move them while holding the Alt (Windows) or Opt (macOS) key, which overrides Snapping, that's a good approach.

If someone actively disabled snapping, then perhaps it is not surprising that the result is no snapping.

[walt.farrell]

4 minutes ago, Pšenda said:

If someone actively disabled snapping, then perhaps it is not surprising that the result is no snapping.

It is often unintentional.