fde101

I think one of the limitations is the fact that the Affinity products only seem to allow global spot color entries; creating them as a non-global swatch seems to convert them to process colors. If non-global swatch entries could be legitimate spot colors then I believe that might solve your "problem" as those do inherit the name of the color when created.

if you are using C1, try the PSD format and enable the "Enable Save over imported PSD files" in Preferences. I haven't tried it with the beta yet, but with the release version the back and forth between C1 and APh is nearly seamless.

Multiple feature requests in one thread is frowned on. Each request should have its own thread. Otherwise the discussion of the requests tends to get interwoven and can be difficult (and time consuming) to follow. If the developers need to spend a significant amount of time trying to decipher which parts of a thread represent which feature while reading through them I would expect they would be more likely to give up and move on...

My take on it is that global swatches should really be named for what they are being used for, not for the color they represent. Rather than "orange" and "purple" should have names like "sidebar", "chapter title", etc. Since the program obviously can't guess that for you it is providing a placeholder name until you change it to something meaningful.

Not even close...

In most cases, documents created in the beta can be opened in the subsequent release, but my understanding is that this is not guaranteed to always be the case.

i am seeing the same. It kind of makes sense that Photo would default to RGB across the board, but I'm not so sure about Designer. I would have thought too that the print presets in Designer would have defaulted to CMYK...

The pixels are present in the document even if there are no layers to provide them with any content other than the background (either solid white or transparent), so yes they can be selected. Sure there is... the "empty" document is like a blank sheet of paper. Even if you haven't applied any ink to it the "paper" is still there and can be either transparent or opaque. That one also works for me even when there are no layers. If the document is transparent it is selecting the background as a solid black color (that one might be a bug?), while if it is opaque it is selecting the white of the "paper".

The pixel selection is largely independent of the existence of content. No, it just means that anything which is there is transparent/invisible. Creating a pixel layer in a document with a transparent background does not suddenly make the background opaque, so it really doesn't tell you anything about the state of the layers/objects within the document: the layers can have transparent content at that point and there is "something there" but you still can't see it. The opaque or transparent background exists behind the layers, independently of them. The one on the Color panel? That works quite well with no content in the document as it can pick from anywhere on the screen, including other applications. This is because the layer that exists is most likely completely transparent so you are seeing the "paper" through the layer. If you don't want them to look the same, then simply paint something onto the layer.

No such feature exists in Affinity Publisher at this time, though many have requested it. Is there some practical reason why you would need such a feature?

Affinity Photo is a single-image-at-a-time editor with some very basic batch processing capabilities (though perhaps not for RAW development?). It is not a DAM solution. See other threads for the discussion on a possibly-upcoming Affinity DAM solution which would be more in line with what you are requesting for this.

I think these all sound like reasonable requests, except that I don't think object slices should be changed to include all layers - I think the whole point of those slices is that they don't do that, thus allowing individual objects to be exported in isolation. Being able to create an area slice from an object slice should neatly solve your problem though and that seems quite reasonable to me. It seems too that it should be possible to create a slice from the raster selection, but that doesn't seem to be an option either...

Just a hunch, but I suspect that the brush presets (which have the names) are never actually selected. "Selecting" one may actually copy its settings into the active brush, after which the preset itself becomes irrelevant and thus forgotten - this would make the entire concept of a "selected" brush invalid and explain why this is not being done. A "most recently used brush preset" list should certainly still be possible, however, even if my guess as to how this works does turn out to be correct...

I would be curious as to what you are bumping into... I have a project in-flight where I am using PSD format to round-trip between Capture One 20 and Affinity Photo (I am on the Mac) and having zero issues doing so based on the requirements of this particular project.

Make sure "Show Lines in points" and "Show Text in points" are turned off in preferences (see the post by @walt.farrell above) and those will display in the document units. Set the document units to mm and you should be good. Note that the document units are synced with the rulers, so if you have the rulers showing, you can right-click on the corner where the vertical and horizontal rulers meet and select the units from there without needing to open the Document Setup window.

Grids are generally regular in their spacing; you might be better served by guides instead.

I don't think that was ever a Serif product? The link you gave is to a PDF of a PagePlus manual... Many, many companies in today's world of digital distribution have stopped doing that.

It is not image editing at all, it is digital painting, and that is far from "child-stuff". It is simply a different type of application with a different set of requirements from the one being discussed here - more in line with the purpose of Corel Painter than with Photoshop.

Ho @Jeannette, welcome to the forums! This is actually the only way to run the beta as it will not open unless it sees the released version installed. They can be run side-by-side and do not share settings, but be warned that if you open a document in the beta version, you might not be able to open it again in the released version after that as it could be updated to the newer file format that the released version doesn't understand.

Interesting... yes, I hadn't noticed yet either that this was missing, possibly due to the lack of global swatches, but it is indeed. Definitely something that should be addressed.

and interpret that relative to the shape, or to the gradient? They might not even be centered at the same place. Good catch, yes I meant the origin point, thanks... Yes, and I think that is largely why this missing set of parameters on the panels hasn't bothered me up to now - I find it much more direct and just as convenient to use the tool in any case. Yes, obviously they would need to use some default mappings if creating a gradient parametrically rather than using the tool.

well... The challenge here is that the "rotation" of the gradient as provided in the Affinity products is a natural consequence of the position of the dots that form its endpoints (even if we are just talking about linear gradients - other gradient types may have more than two points involved...) since these points can be inside or outside of any particular shape at arbitrary places and it is not just the angle of the line they form but also their spacing that dictates the look of the gradient, when considering rotation of the gradient, you need to consider the spacing of those two points and their vertical and horizontal offsets relative to whatever axis of rotation is being considered (yet another factor involved in this request). So I don't think the request is really quite that simple. Even if a control were added to rotate and the rest was left to the tool, how would the control determine the axis of rotation? Would it be the center of the selected shape(s), the midpoint of the line...

PNG files do not support layers. Neither does TIFF for that matter. After embedding the entire document structure into the PNG file which does not natively support it, the PNG image data itself would basically need to be ignored when the Affinity products read the file back in, as I am sure they are doing with the TIFF files. I suspect a more optimal end solution for this will be for Serif to release a scripting or plugin API powerful enough to automate setting up the export persona to maintain the PNG export next to the native Affinity document when one is saved, for those who want this capability.

This has been requested numerous times for the desktop version also. The response has been that while Serif has had this technology for their prior product line they are not happy with how it performs. They want to do this for the Affinity products but when they do, they want it to be right. There was talk of this functionality introducing an entire new persona, so they are clearly thinking of something major with it. As a result, it is going to take time, and it may still be a few versions out. I definitely believe it will be coming, and I expect it will be excellent when it does, but it is not clear just how soon.

Indeed it does, but only when there is a document open.