[Feedback] AD core features are not ready for professional use

[fernandolins86]

Hello Serif team,

I want to thank you for the effort of taking such a big project on, for both AP and AD (and other upcoming software) and getting so far in a short period of time.

Designer has great ideas and a great future ahead of it, and has reached far into the pool of features in other software from larger and more experienced companies. For that, congratulations!

 

However, plenty of the core, basic features for any graphic design software are broken:

- Moving objects so that they snap to pixels works most of the time

- Pixel preview is completely broken, with the pixel grid moving around documents and artboards when you change zoom level

- Line alignment follows an unorthodox system that turns simple tasks like making a 1-pixel high line into chores

- Color pickers around the UI don't show the same values for a single object

 

There are many other issues unfortunately, but I'm keeping this list to what I believe is basic to any design software.

If one can't even get proper pixel alignment going, why work on new features and a complex roadmap?

These should be top priority concerns, as it feels like the very core of the graphic engine is broken.

If there is a proper time to get the basics right, this is it. Please don't wait any longer.

 

Unfortunately for me (and I believe for many other professional UI designers) these are breaking issues.

I hope the team will be able to sort these soon, but I need to get my work done and I'll have to jump back to Photoshop.

 

I will not be asking for a refund and in fact I'd love to be able to donate to the project, even if I have already paid for the software, because I want to be set free from Adobe. At this time Designer is not ready for my kind of professional activity.

Best of luck to the team,

Fernando

[MattP]

Hi Fernando,

 

Thanks for your feedback - it's always welcomed :)  I haven't got time at the moment to give a thorough response (sorry) but I thought I'd reply to your main points so you have more information:

 

- With snap to pixels turned on, it should always generate a pixel snap - unless you've also got some object, guide or grid snapping turned on that is snapping the data to an already-off-pixel object or centre?

- The issue is that the artboards are created not on a whole pixel - and this is causing the artefact. I should just force artboards onto a pixel boundary and all the problems would go away... :/

- To get a one pixel high line, just choose a 1px line in the stroke panel and draw a horizontal line - but remember that it needs to have a y value that is on a half-pixel so your 1 pixel high line covers only that pixel. This is exactly the same as how Apple tells designers to draw lines too - nothing terribly unorthodox?

- If your colour picker is picking different values for the same object, then something is wrong - we don't ask the screen what the value is, we ask the document and if the document returns two different numbers for the same object in different places then it's seriously broken! Let us know an example and we can fix it... :)

 

Thanks again,

Matt

[AshTeriyaki]

Strangely I was about to start a thread on this, but someone already did it!

 

The art board alignment thing is a pain in the butt, I think forcing artboards to full pixels is definitely the way to go, I've had my guy working on dozens of banners in one doc, with the export being what it is, is killer. BUUUUuuuut, then having to go back through and nudge all of the boards to export files at the expected size is a bit rubbish.

 

I'd love you all forever if you'd fix this :D

[R C-R]

- With snap to pixels turned on, it should always generate a pixel snap - unless you've also got some object, guide or grid snapping turned on that is snapping the data to an already-off-pixel object or centre?

Fernando, also note that if Move By Whole Pixels is enabled & the item you are moving is currently at an off-pixel position, this option will do exactly what it says it does to maintain that off-pixel relationship. So for example, if a node's x position is at 20.5 px & you move it, even with Force Pixel Alignment enabled, it will snap to some 0.5 pixel position because it must move by whole pixel increments.

 

- If your colour picker is picking different values for the same object, then something is wrong - we don't ask the screen what the value is, we ask the document ...

 

Matt, if I drag the eyedropper in the Color panel (not the Color Picker tool) out of the document to pick a color from somewhere else on the screen, for example the desktop's background image or some window open in the background belonging to another app, what does Affinity "ask" for the value?

[R C-R]

The art board alignment thing is a pain in the butt, I think forcing artboards to full pixels is definitely the way to go...

Maybe I am missing something but if I want to create a new artboard in an existing document by dragging with the Artboard tool & make sure it is pixel-aligned, I just turn on Force Pixel Alignment. Does this not work for your people?

 

If I create a new document using the "Create artboard" option, the top left corner is always pixel-aligned in the workspace, as are the other corners unless I deliberately enter a custom document dimension that has a fractional pixel value. I would not be happy if for some reason I did want the artboard to have a fractional pixel width or height & could not get that because it was automatically forced to whole pixel alignment.

 

Using the preset sizes in the Artboard tool's Context toolbar to insert a new artboard always creates pixel aligned ones, which leaves the  "Selection" insert option as the only one that won't, & only if the selection is not pixel-aligned. Again, if for some reason I did want the artboard to have a fractional dimension (like for a 'tightest fit' one for a rotated object), I would not be happy if it was arbitrarily automatically forced to whole pixel alignment.

 

I realize that fractional pixel alignments, particularly for odd whole number stroke widths or object dimension values, can be a pain to work with but I do not see any way around that, other than avoiding using those dimensional values to begin with. I have seen suggestions to force one or odd numbered stoke widths to align offset horizontally or vertically to whole pixel boundaries, but that seems arbitrary & it won't do any good if the line segment is not exactly horizontal or vertical anyway.

[Bento]

I do agree too, AD is not UI/UX frendly at the moment.

 

It has been spoken a couple of time.

 

If you search for pixel alignement issues , it is revelant of what's a major issue.

 

Last answer that goes in our way was given by Ben on this thread :

 

https://forum.affinity.serif.com/index.php?/topic/36949-layer-pixel-alignment-issues/?page=3

 

Quote

Ben said :

To mitigate for the range of options, there are the presets, which have been carefully selected based on the requirements of said users.  I'll add another preset which only has "Force pixel snapping" turned on, and everything else turned off.  You also have the ability to create your own snapping presets - so if you find a configuration you can work with, make a preset of it.

 

 

Not sure that it will be enough but that's a start.

 

As i said before, we need, when we create a new document for UI/UX (it is in your presets options when creating a new document), a real pixel based document, even when we resize an object from the corner (it should force the object to resize with no digits ! Even if it deforms it by 0.3 for example)

 

Cheers we count on you guys.

 

Ben

[R C-R]

... even when we resize an object from the corner (it should force the object to resize with no digits ! Even if it deforms it by 0.3 for example)

 

From the Affinity Designer "Force Pixel Alignment" help topic:

If you deactivate Move By Whole Pixels but have Force Pixel Alignment active, moving an object which occupies partial pixels will also transform it marginally.

 

Does this not do what you want?

 

At least for me, it works for everything: artboards, shapes, pixel layers, etc. The only exception is for items that can't be completely pixel-aligned, like for strokes set to an odd whole number width using the Align Stroke To Center option.

[MattP]

Matt, if I drag the eyedropper in the Color panel (not the Color Picker tool) out of the document to pick a color from somewhere else on the screen, for example the desktop's background image or some window open in the background belonging to another app, what does Affinity "ask" for the value?

 

If you sample from outside the document view itself then we obviously just ask the screen for the colour under the mouse :)

[R C-R]

If you sample from outside the document view itself then we obviously just ask the screen for the colour under the mouse :)

Thanks for that info but I am still wondering if (or how) it is color managed. The eyedropper in the Apple Color Picker (in Color Slider mode) has a bunch of options for selecting different color depth, color profile, & color space contexts, most of which result in different values being picked up.

 

At least for Mac Affinity app users, this may be part of the confusion about why different color pickers do not always show the same values. When i use the Apple Color Picker, I have to make sure it is using the same color profile & color space as the Affinity document; otherwise it won't agree with the Affinity pickers. I assume this is the correct way to use it....

[Alfred]

The eyedropper in the Apple Color Picker (in Color Slider mode) has a bunch of options for selecting different color depth, color profile, & color space contexts, most of which result in different values being picked up.

 

"Pick a colour: any colour!" :P

[fernandolins86]

On ‎19‎/‎05‎/‎2017 at 7:57 AM, MattP said:

Hi Fernando,

 

Thanks for your feedback - it's always welcomed  I haven't got time at the moment to give a thorough response (sorry) but I thought I'd reply to your main points so you have more information:

 

- With snap to pixels turned on, it should always generate a pixel snap - unless you've also got some object, guide or grid snapping turned on that is snapping the data to an already-off-pixel object or centre?

- The issue is that the artboards are created not on a whole pixel - and this is causing the artefact. I should just force artboards onto a pixel boundary and all the problems would go away...

- To get a one pixel high line, just choose a 1px line in the stroke panel and draw a horizontal line - but remember that it needs to have a y value that is on a half-pixel so your 1 pixel high line covers only that pixel. This is exactly the same as how Apple tells designers to draw lines too - nothing terribly unorthodox?

- If your colour picker is picking different values for the same object, then something is wrong - we don't ask the screen what the value is, we ask the document and if the document returns two different numbers for the same object in different places then it's seriously broken! Let us know an example and we can fix it...

 

Thanks again,

Matt

 

• The snapping issue is described here, and it's been a long discussion - https://forum.affinity.serif.com/index.php?/topic/36949-layer-pixel-alignment-issues/?hl=snap
• The pixel grid issue is described here: https://forum.affinity.serif.com/index.php?/topic/32370-bug-grid-offset-in-pixel-view/?p=194359- I even suggested that Artboards should not be placed on anything but interger pixel values as you do.
• Related to the pixels issue, paste in place also doesn't work - https://forum.affinity.serif.com/index.php?/topic/35710-designer-paste-in-place/
• The 1-pixel line issue is described here: https://forum.affinity.serif.com/index.php?/topic/34785-too-hard-to-scale-wide-thin-rectangles/?p=170687- Notice that having to move a line by 0,5px so that it matches the pixel grid completely breaks moving objects around as now you have to keep that 0,5px offset.
• The color value issue is described here (there are other threads about it with CMYK too) - https://forum.affinity.serif.com/index.php?/topic/39287-ad-wrong-hex-value/

Just wanted to add that I'm using Windows 10, so I'm not considering any fixes made for Mac or other issues that might be attached to those.

[R C-R]

"Pick a colour: any colour!" :P

Well, not exactly any color, but there really is little that is obvious or straightforward about picking colors.

 

To begin with, we have to consider two basic types of color models (additive/transmissive & subtractive/reflective), various color matching systems like Pantone that are not based on any abstract mathematical color model, & systems that try to model human color vision as closely as possible vs. those that do not.

 

Colors can be specified mathematically by their positions in various three dimensional color spaces like RGB, HSL, & HSV; but that doesn't work very well for reflective models like CMYK where considerably more than three values may be needed to fully specify a color, & there is no way to convert values from one space to the other except approximately.

 

There is also the problem that we perceive color based on our eyes' sensitivity to different wavelengths in visible light, which varies with the light's intensity & spectral composition. That sensitivity is different for different people & even for the same person, depending on physiological & psychological factors, so the best we can do is some sort of averaging process for carefully controlled viewing conditions.

 

So with all that in mind, I think the "same value" quest is pointless if taken to extremes. The best we can do is pick color values that most people will agree closely match some reference like the Pantone system provides.

[R C-R]

On ‎19‎/‎05‎/‎2017 at 2:48 PM, fernandolins86 said:

• The 1-pixel line issue is described here: https://forum.affinity.serif.com/index.php?/topic/34785-too-hard-to-scale-wide-thin-rectangles/?p=170687- Notice that having to move a line by 0,5px so that it matches the pixel grid completely breaks moving objects around as now you have to keep that 0,5px offset

That is what the Move By Whole Pixels option is for. Also note that unless the line is exactly horizontal or vertical the issue is moot because for any other orientation the line will never fill a pixel completely unless it is not antialiased, resulting in the stair-stepped appearance sometimes known as the "jaggies."

[fernandolins86]

That is what the Move By Whole Pixels option is for. Also note that unless the line is exactly horizontal or vertical the issue is moot because for any other orientation the line will never fill a pixel completely unless it is not antialiased, resulting in the stair-stepped appearance sometimes known as the "jaggies."

 

Thanks R C-R, I understand how pixel banding works and would like a solution (maybe a proper Line tool?) that allowed me to create 1 pixel high or 1 pixel wide lines that fit perfectly in the grid without having to offset them.

Currently a 1 px vector stroke sits between two solid pixels and renders as 2 pixels with 50% opacity in exported images (or Pixel Preview).

[R C-R]

Thanks R C-R, I understand how pixel banding works and would like a solution (maybe a proper Line tool?) that allowed me to create 1 pixel high or 1 pixel wide lines that fit perfectly in the grid without having to offset them.

That still would not change how any line (of any width) would be rasterized that was not absolutely vertical or horizontal anywhere along its path.

[fernandolins86]

That still would not change how any line (of any width) would be rasterized that was not absolutely vertical or horizontal anywhere along its path.

 

Mr. R C-R, you have already stated that in the original thread about the issue. Do we really need to go over Graphic Design-101 at this stage? 

The very capable Serif developers understand the issue, they know how graphics work inside out and they're aware of that case.