"Merging Down" Pixel Layers leads to undesired Anti-Aliasing for Illustration work

[fde101]

4 hours ago, debraspicher said:

offering Merge options that are in the context of the actual behavior of Merge, would seem to be in order. "Merge Against Document Grid"

Yes, that is a better name for that command.

 

4 hours ago, debraspicher said:

And to be fair here, all graphic programs have their UX issues/bugs. It's like a badge of honor to have to learn some weird workflow.

This will probably always be true in any program of non-trivial complexity, in any major field, but minimizing this characteristic is an important goal for anyone developing software.

More important, in my opinion, than matching the features and UX of an application to other similar applications, is matching it to itself.  If a program's behavior is inconsistent across its own features, then users may need to learn multiple conflicting ways of working in order to get anything done with that one program.  If a program is consistent with itself, then at least once a user learns how to interact with that program, it can be applied throughout the program.

Because of that, I would argue that some of the biggest failings in the Affinity suite right now come down to things like the Typography panel which cannot be docked as a studio panel, but otherwise serves a similar purpose and has content which functions similarly.  I get it that things like Snapping and Guides are distinct in nature from things that go into studio panels - but then so is Metadata, so why is Metadata a dockable studio panel when Snapping and Guides are floating windows?

Combine that with the radically different way that the Channels panel behaves compared to the Layers panel (yes there will be some differences, but these are rather extreme), and those are the kinds of loose ends that bother me the most about the Affinity UX - the internal inconsistencies within the design of the program.

The fact that a command like Merge behaves unexpectedly differently from the way it does in other software which is marketed in a similar manner is certainly not ideal, and I definitely agree that some improvement is in order here, but to me that isn't nearly the UX issue that some of these other things are.  It is at least consistent with other behaviors of the program when you realize that it is actually a vector application at heart and not a raster one; the document DPI is really used as something of a fallback or default to support features which wouldn't otherwise have anything to work with, or which are applied across the entire document as opposed to being used for individual layers.

[NotMyFault]

19 hours ago, fde101 said:

and erroneously refers to the current option as not rasterizing

This is a misinterpretation of my statements. Not rasterizing is used in the sense of „does not includes the rasterize function from the regular menu“. It does not intend to say that „no rasterization happens at all“. 

[debraspicher]

I added my own request for another better option for Merge...

 

[fde101]

One thing that might help with this a bit, if nothing else, is scripting support, whenever that shows up.

Presumably you would be able to write a script to automate the necessary steps, and assign a meaningful keyboard shortcut to it.

Bonus points to the Serif developers if you can also add your scripts to relevant context menus...

[RandallCC]

Illustrator here, doing a lot of black and white line illustrations & graphic novel work, just dropped in to say that I was one of the users preplexed by the merging feature blurring my crisp linework. Thank you @NotMyFault for enlightening me.