fde101

If Serif does choose to provide preset presets for the preflight panel, I think it would be best if they would stick with presets that fit well-defined standards in the print industry rather than cater to all of the oddball requirements that individual users are likely to come up with. If the presets can be imported/exported, then print shops could provide presets matching their requirements so their users could download them and add them to Publisher if they want to. Agreed 100%.

Tossing this one out there for discussion: poor contrast (luma or chroma) between overlapping vector objects, optionally accounting for various forms of colorblindness?

Suggest providing a crash log to help the developers figure out where it is crashing... preferably as an attachment rather than as text pasted into the forum...

Add to that: Document contains non-spot colors

Why would that be?

What is the rationale behind this design? It obviously is not a bug if it was designed this way but it is a rather questionable design choice...

They generally do not respond to feature requests, but they actually did respond to this one a few times: etc.

Yeah, scaling the glyphs definitely sounds like a misfeature to me also.

The problem is that this is a lie as soon as it is printed on the page.

I don't think I agree with this one at all. And do what specifically? This is the wrong type of application for these behaviors. You are asking for DAM-like software, and that doesn't exist in the Affinity lineup yet. Serif has indicated they are planning one, but it may be a while until we have any real details on what it will offer. In the meantime consider software such as Capture One, DXO PhotoLab, On1 Photo RAW, etc. Those are DAM/RAW processing applications. Affinity Photo is an editor, optimized for working on one image at a time when you need to focus in on it. Different tools entirely. If this doesn't work for you, make sure there is a thread reporting this in the bug section for your platform. It does work for me (Mac).

To a point... the catch is that this would need to be set up for each file rather than something integrated into the document format itself. Maybe a "save documents with large previews" option in preferences wouldn't be too bad of a thing to offer, but I definitely wouldn't want a "full size" preview of large documents saved in every file... Meanwhile, this at least does exist.

You can also use the export persona to configure a png (or other format) and set up a "live" export as you modify the native file, and keep that next to the main file if desired.

If you haven't already, you might want to post about this on the Windows bug forum and not just here. You could link back to this one. It should get attention from the right people a bit faster that way.

A full-size preview will also require full-size disk space, will take the full-size export time whenever saving the document, and this is in addition to the space already occupied by the file. The Affinity team has already indicated that they designed the file format to optimize the speed of file operations, and this would not only contradict that purpose, but would also waste even more disk space where there are already people complaining that the files are sometimes too large. I for one specifically do NOT want this. Larger than 500 x 500 I could possibly live with, but the full resolution of my 20+ MPix camera? No. The size of the file is not constant either, and neither is the size of the suggested png "wrapper" - as a png file's size can vary even with the resolution being fixed, each time the file was saved there is the potential that the Affinity data might need to move within the file to accommodate changes to the size of the wrapper. The files are not likely being rewritten in their entirety each time the document is saved, so this is potentially a much bigger change to the file format than you seem to realize.

Based on some of the hints I've seen from reading between the lines of some of the various issues and the like that have been identified related to the Affinity document file format, I don't think this would be as simple as you seem to think. The Affinity document format seems to be structured more like a database file than a traditional document structure, and that might not play nicely with a tagged format like the ones you suggest, as the files might be updated constantly while they are open, not just when you explicitly save the document.