Working pixel perfect with Designer 2 still does not work which is super frustrating for GUI work

[pixelworker]

Affinity works more precise as a given pixel grid in the document. That means you often get non integer value (12.4px) even with "Force pixel alignment". The result is a unsharp result, you can't show 1.4px as a sharp line.

The lock to grid option"Force pixel alignment" and also View Mode as Pixel doesn't help much, it still happens. 

It's an absolutely fundamental need to quantise all data to a given pixel grid without any possibility do have results that are not fitting.

Example are all transforms operations which results often in non integer values.

Affinity, do you understand this problem and how much problem it creates for any pixel perfect design like GUI design?

[Tia Lapis]

Hmm isn't Photo the tool if you want pixel perfect?

[debraspicher]

Is there a way you could produce video to illustrate what you mean? I've often felt pixel hinting does not produce the results that I'd come to expect in AI even when moving points to whole number positions. I've been looking forward to it being improved, but I don't know how to provide feedback because I don't really understand what is causing it.

Re: Pixel Mode I would expect this to display a 1:1 result as in other programs but on my machine, anyway, it gives a fudged example, whereas correct pixel preview looks more like the Retena option than PM. It cannot be compared to the actual output so represents nothing valuable for me.

Edit: Also related/unrelated, when pasting screenshots into Affinity Photo from clipboard, there is a weird Gaussian blur added. I have a program for viewing clipboard data and it's not changed in Windows. So no idea why but it makes text blurrier and harder to read, so I have to use Clip Studio to save screenshots. It's bizarre. I might start another thread.

Here are the PNGs, but if you want to see actual result without possible browser scaling, I included PSDs:

"Pixel Mode" (notice it says zoom 100%)

vs Retena

221119_AffinityDesignerV2_retena-mode.psd 221119_AffinityDesignerV2_pixel-mode-not-1-to-1.psd

[debraspicher]

22 minutes ago, Tia Lapis said:

Hmm isn't Photo the tool if you want pixel perfect?

Vectors are specifically preferred for their crispiness. Pixel-hinting is the process/time it takes to move points to whole pixels (sometimes half points if warranted) in document set to pixel in units to reduce anti-aliasing. Especially for straight lines, edges, etc, it's the difference between unpolished and polished output. It's essential for icon design, UI, logos for websites to increase clarity and generally not look crummy.

Pixel preview is meant to show us what this anti-aliasing is doing in real time so we can move points to clean up output.

[loukash]

10 hours ago, pixelworker said:

The lock to grid option"Force pixel alignment" and also View Mode as Pixel doesn't help much, it still happens. 

As counterintuitive as it may seem, make sure that in Snapping Options, "Move by whole pixels" is disabled.
Because when it's enabled and your object is already misaligned, it would then still continue to move by whole pixels, i.e. actually retaining its non-integer value. For some reason (which doesn't really make sense to me) this option overrides its parent option "Force pixel alignment".

Whereas when the option is disabled, moving/resizing a misaligned object will immediately snap it to an integer pixel value.

Also, generally I'm working with 6 decimal places for all my frequently used units, including pixels: Preferences > User Interface > Decimal Places. Like that I'm always in control even with the tiniest misalignments.
The problem here being that if you set e.g. 1 decimal place, Affinity will only round up or down the display of the value in the Transform panel, but not the actual value itself. So a misalignment of 0.04 px would still display as an integer, not as 0.1 px. But even such a small misalignment is already enough to introduce slight antialiasing. 

Also to keep in mind:
You can control antialiasing on object level individually via Blend Options in the Layers panel. You can either fine tune via the Coverage Map curve, or you can select "Force Off" in the Antialiasing popup menu.

[ashf]

I think one of the problems in Affinity regarding this matter is transformation tasks that always create sub pixels.
I want Serif to improve it.
 

 

[pixelworker]

Yes, "Move by whole pixels" is disabled.

But after years of having problems with it and a couple of posts here in the forum without any real solution I thought it's a flaw in Affinity. But you might have given the solution.  At least it looks like it after a short test. I will keep testing next week.

Preferences > User Interface > Decimal Places

This is pretty hidden and you have to think twice about what it does. I've seen this option but I never thought that this is the reason. Especially because when you have "Force pixel alignment" active, you think it's the option for that. A pixel is an atomic unit physically.

It should be more prominent in the snapping options, with this connection it would be easy to understand. And default of 1 decimal place for pixel is not a good default.

When you set it to 0 I get no non integer even at transformations.  @ashf you should try if it solved your issue too?

[tudor]

8 minutes ago, pixelworker said:

When you set it to 0 I get no non integer even at transformations.

If you're resizing freely by dragging with the mouse, check your graphics. I think the app might simply hide the fractional values instead of actually constraining the transform operations.

[pixelworker]

25 minutes ago, tudor said:

If you're resizing freely by dragging with the mouse, check your graphics. I think the app might simply hide the fractional values instead of actually constraining the transform operations.

Unfortunately you're right. It's still a total mess. 😬

I think for newly created items via mouse it works quite ok with 0 decimal places. Also for transformations. Great that some problems can be fixed by this setting.

1. But existing items do not snap to the grid after changing the option, which is somewhat understandable. But the big issue is that items that still have non integer coordinates are shown without decimal places but are clearly not rendered that way.
2. And you can still type non integer values, which are rendered like that, but the gui shows integer dimensions (a shape with a 1.4px line is rendered with 1.4px but the transform panel says 1px).

I had strong hopes to use Affinity for my gui work and kept using it out of idealistic reasons, but after years of problems which are still in Version 2 I'm currently strongly evaluating to change to Figma or Sketch again.

It's just too expensive to run in these kind of issues.

[pixelworker]

12 hours ago, Tia Lapis said:

Hmm isn't Photo the tool if you want pixel perfect?

No, I create assets that needs to work perfect on a pixel grid. And you have all the pixel snap features, they just don't work right.

Photo has the same issues by the way. It's not just a Designer problem.

[tudor]

Well then 0 decimal places is definitely not a good idea. It's actually worse because it hides the issue.

I don't have problems with integer values. Enabling the "Pixel work" preset from the Snapping menu does the job for anything I create in that file. I only have to double check whatever I import or paste from other files.

[pixelworker]

I'm sorry to say, but you can't work pixel perfect with the "Pixel work" preset without 0 decimal places. Just do a transformation like changing a shape size via mouse and you get non integer values quite quickly.

To summarize:

• Option 0 decimal places for px seems to fix all actions for newly created items with the mouse.

But the inspector still has fundamental issues. Like you said, it hides the problem. But it looks like a bug to me.

• Previously created items do not change to 0 decimal points after changing the option, which is somewhat understandable. A button to quantize all items would be helpful for old and external document.
• But items with decimal points (line with 1.3px) are rendered with decimal points as a shape (so not in the pixel grid), but in the inspector value display them without decimal points. The value does not show correctly what's rendered on screen.
• You can still type decimal places with option 0 decimal places. That's unexpected but not a big problem as you have good control about what you type, but then again, the value in the inspector say they have no decimal places. Same as issue above.

 

@Affinity Team. It would be super nice if you could join this discussion. Dealing with basic issues like that is super expensive as you waste hours checking and correcting these things manually, which should work out of the box. Without any feedback or acknowledgment of the problem I think I can't justify keep using Affinity products in my day job.

[pixelworker]

Two ideas to fix this. Not sure if that will fix everything.

- "Force pixel alignment" should automatically use zero decimal places internally to avoid any placement outside the pixel grid. Or the setting for decimal points should be accessible in the snapping panel.

- Non integer values coordinates should always be shown, maybe in a different color when "zero decimal places" is active to show that they are not on the grid.

[loukash]

1 hour ago, pixelworker said:

you can't work pixel perfect with the "Pixel work" preset without 0 decimal places.

And you don't have to.
As already noted, the "Preferences > User Interface > Decimal Places" affects only the display of the values, not the actual values. That's why this preference is in the "User Interface" section, not e.g. in "Tools".

1 hour ago, pixelworker said:

Option 0 decimal places for px seems to fix all actions for newly created items with the mouse.

Nope, it doesn't.
It's the "Force pixel alignment" snapping option that does. Snapping must be active, of course.

1 hour ago, pixelworker said:

But the inspector still has fundamental issues. Like you said, it hides the problem. But it looks like a bug to me.

I don't know if it's a bug or "by design". We would have to search deep in the forum history to find staff posts that would confirm either possibility. I, for one, vaguely remember reporting it a few times, requesting improvement.
It's annoying for sure though.

1 hour ago, pixelworker said:

A button to quantize all items would be helpful for old and external document.

That's a good idea. As a Logic Pro user of over 20 years, I'm very familiar with the concept of quantizing to a grid.

1 hour ago, pixelworker said:

but in the inspector value display them without decimal points. The value does not show correctly what's rendered on screen.

The Tranform panel only reflects your "Preferences > User Interface > Decimal Places" setting. Don't use "0" under any circumstances! You want to know if your object is misaligned, don't you?

1 hour ago, pixelworker said:

You can still type decimal places with option 0 decimal places.

Yes, and that's definitely "by design". You may want to manually override what ever value is in there. Or which ever unit is in there. This is supposed to work this way.
https://affinity.help/designer2/en-US.lproj/pages/Workspace/expressions.html

[loukash]

By the way, fixing non-integer values of an object in the Transform panel works relatively quickly like this:

1. click into one of the fields
2. press the arrow-up or arrow-down key, depending whether you want to round up or down
3. press tab
4. repeat #2
5. press tab
6. repeat #2
7. etc.

[debraspicher]

The other thing to watch out for is artboard size. If it gets changed by accident and if it's an odd number across one dimension and then someone goes to center an element, it produces more anti-aliasing across the whole workpiece.

[pixelworker]

6 hours ago, loukash said:

And you don't have to.
As already noted, the "Preferences > User Interface > Decimal Places" affects only the display of the values, not the actual values. That's why this preference is in the "User Interface" section, not e.g. in "Tools".

Nope, it doesn't.
It's the "Force pixel alignment" snapping option that does. Snapping must be active, of course.

Thanks for the hint. I have to check it carfully and comparing it to actual pixel rendering. I did only a quick check and thought that might be the missing option. At first glance it looked like that. Could be a mistake.

But "Force pixel alignment" is not enough to work pixel perfect. One example. Just resize a shape (dragging on the edge of the selection) and you will quickly get non integer values.

[pixelworker]

5 hours ago, loukash said:

By the way, fixing non-integer values of an object in the Transform panel works relatively quickly like this:

1. click into one of the fields
2. press the arrow-up or arrow-down key, depending whether you want to round up or down
3. press tab
4. repeat #2
5. press tab
6. repeat #2
7. etc.

I'm sorry to say this but it's not a solution for an operation that you have to do hundrets of times like resizing via mouse. This have to work out of the box like in other programs. Too many sources for human error otherwise and too time consuming.

[pixelworker]

• So far I can trace back many of these issues to scaling an item with locked aspect ration. Scale a shape 100 x 50 will scale down to 99 px x 49,5px. That keeps the perfect ratio, but it's moving of the grid and overrides the "Force pixel alignment" option.
• Another source is setting "Width" of a Stroke. It's non integer when dragging on the slider even with the "Force pixel alignment" option. You have to use arrow keys to set it in px, which reduce working speed a lot and you have to be very careful to not to drag on the "Width" slider in any situation.
• Another source is placing items. I can place a text easily at X 1583,9 px and Y 96,3 px when clicking on the canvas. The same is true for many other tools like the pencil tool. It's not forcing things to the grid.

It's the same in Photo by the way.

[loukash]

1 hour ago, pixelworker said:

I can trace back many of these issues to scaling an item with locked aspect ration. Scale a shape 100 x 50 will scale down to 99 px x 49,5px. 

Yes, that's how it's designed to work. That's why I use other methods to scale.

1 hour ago, pixelworker said:

Another source is setting "Width" of a Stroke. It's non integer when dragging on the slider even with the "Force pixel alignment" option

Same here. That's how it's designed to work. Pixel alignment of vector objects affects bounding boxes. If you want alignment of strokes, you must set them to "Align stroke to inside". If you align them to center of the bounding box, then you must always use even numbers for stroke width. 

The math is actually quite simple here.
Oh, and you'd better avoid prime numbers…  

1 hour ago, pixelworker said:

I can place a text easily at X 1583,9 px and Y 96,3 px when clicking on the canvas

Artistic text, yes. I guess that's by design because its bouding box is not really relevant. You will always have to align individual characters manually. (Been there done that many times when designing banners or logotypes for Teh Interwebz…)

Text frames, however, align to pixel grid.

1 hour ago, pixelworker said:

The same is true for many other tools like the pencil tool. It's not forcing things to the grid.

Frankly, I never expected the Pencil to align to anything. It's designed to be a free drawing tool, after all. It never occured to me to use it for pixel-precise work.

The Pen tool, on the other hand, will align to pixels.

[debraspicher]

I misunderstood the initial post it seems. It doesn't appear to be criticism of the clarity itself, it is a criticism of the tools. Even rereading, I'm still unclear exactly where the general complaint actually lies. The way I do it, I get everything scaled to about where I need it. If I'm using a grid system, I get everything flush within the span. So text I get it about where I need it, convert to curves and then scale to whole pixel width. The tools get you within distance, then it's up to the designer to move key points to final placement...

It seems like their goal is to pixel-hint (basically), but it's my understanding we can't really get fully pixel-hinted rasters without taking the time to move these points once everything is placed about where it should be.

[pixelworker]

2 hours ago, loukash said:

3 hours ago, pixelworker said:

I can trace back many of these issues to scaling an item with locked aspect ration. Scale a shape 100 x 50 will scale down to 99 px x 49,5px. 

Yes, that's how it's designed to work. That's why I use other methods to scale.

But that's basic operation in almost every software. Dragging on a shape with the mouse to scale it. I can't imagine an alternative for daily work. How do you deal with it exactly?

 

2 hours ago, loukash said:

3 hours ago, pixelworker said:

Another source is setting "Width" of a Stroke. It's non integer when dragging on the slider even with the "Force pixel alignment" option

Same here. That's how it's designed to work. Pixel alignment of vector objects affects bounding boxes. If you want alignment of strokes, you must set them to "Align stroke to inside". If you align them to center of the bounding box, then you must always use even numbers for stroke width. 

The math is actually quite simple here.
Oh, and you'd better avoid prime numbers…  

It's about the method to change the "width" value. You have a slider for that too. You need to use arrow keys to set integer values. With the mouse you get non integer values quickly. "Force pixel alignment" should restrict to pixels as well.

It's the issue in Photo which should be about pixels.

 

2 hours ago, loukash said:

3 hours ago, pixelworker said:

I can place a text easily at X 1583,9 px and Y 96,3 px when clicking on the canvas

Artistic text, yes. I guess that's by design because its bouding box is not really relevant. You will always have to align individual characters manually. (Been there done that many times when designing banners or logotypes for Teh Interwebz…)

It's relevant. Consider this. Starting at non integer values means the resulting text is moved off the pixel grid. You will get aliasing and a different text rendering.

Test this. Write a text. Copy it and start at x, y 10; 10. Now copy the text and start at 40,4; 40. The text is rendered differently.

[pixelworker]

1 hour ago, debraspicher said:

I misunderstood the initial post it seems. It doesn't appear to be criticism of the clarity itself, it is a criticism of the tools. Even rereading, I'm still unclear exactly where the general complaint actually lies. The way I do it, I get everything scaled to about where I need it. If I'm using a grid system, I get everything flush within the span. So text I get it about where I need it, convert to curves and then scale to whole pixel width. The tools get you within distance, then it's up to the designer to move key points to final placement...

It seems like their goal is to pixel-hint (basically), but it's my understanding we can't really get fully pixel-hinted rasters without taking the time to move these points once everything is placed about where it should be.

Right. It's about the tools not about the inner rendering. Affinity has many places that can mess up pixel perfect work, resulting in aliased rendering because pixels are between physical pixels.

Sorry , but Affinity is the only application I know that require so much care to work pixel perfect. It's no solution to tripple check everything and correct many values manually in a second step. I can't justify this overhead and correct it manually in a productive environment.

[debraspicher]

38 minutes ago, pixelworker said:

Right. It's about the tools not about the inner rendering. Affinity has many places that can mess up pixel perfect work, resulting in aliased rendering because pixels are between physical pixels.

Sorry , but Affinity is the only application I know that require so much care to work pixel perfect. It's no solution to tripple check everything and correct many values manually in a second step. I can't justify this overhead and correct it manually in a productive environment.

That's still vague. I'm not sure how you work, so that can't make clear what your actual needs are.

"Correct manually" doesn't make it clearer either because that is part of the final process. That's your words. Expecting a tool to do all the hinting work will produce flawed work. For example, scaling a logotype that was produced at higher pixel res (hinted) down to a really reduced resolution for say other usages, it would not look good without manual hinting each character individually.

[loukash]

3 minutes ago, pixelworker said:

Starting at non integer values means the resulting text is moved off the pixel grid. You will get aliasing and a different text redering.

You'll have to pixel align and hint any text manually anyway, no matter where its bounding box aligns to. That's how the Affinity text engine currently operates. It also still lacks a couple of nifty typographic features that InDesign has. Yep, I miss them, too. But there you go.

That aside, the Artistic Text bounding box dynamically adapts to the text within. It's kinda pointless attempting to align the box. If you type just something like "num", the bounding box will be just the x-height. Type "numi" and the bounding box will automatically extend to accent height of the "i". Type "numig" and the bounding box will additionally extend to the descender.
For Artistic Text, only the baseline position remains fixed. Not the bounding box.
The bad news is that unlike e.g. in Illustrator, there is no visible baseline with nodes in artistic text frames that we could grab with the Move tool and align to pixels. Sad but true. That definitely needs improvement. A workaround would be switching to Publisher and use its Baseline Grid in pixel steps to align text by baselines. It should work, but you don't have the Pixel Preview in APu, so you'd need to switch back and forth in APu's personae.

In other words, just by setting the initial click with the Artistic Text tool to align to the pixel grid won't fix the problem. Way more changes how Affinity handles text are needed. (Desperately!)

So if you need a text engine that aligns text to pixel grid now, I'm afraid you'll have to use e.g. Illustrator. From what I recall from CS5, there was such an option in the Save For Web module.

34 minutes ago, pixelworker said:

Affinity is the only application I know that require so much care to work pixel perfect. It's no solution to tripple check everything and correct many values manually in a second step. I can't justify this overhead and correct it manually in a productive environment.

Fair enough. I don't think that anybody here denies that dealing with pixels in Affinity apps can be quite a p.i.t.a. sometimes. So I'm offering facts about the current state, how to work with it and around it.  
If that's a serious issue, then you may want to use a different tool until Serif gets all this improved.
I, for one, have bought ADe in 2014 and APh in 2015, but I couldn't do any serious work with them until about two years ago after I took the time to intensively dive into the Affinity universe and tried to comprehend how it's supposed to work (yep, pandemic lockdowns can have their positive sides).