DarkClown

This is indeed pretty strange ...

Hmm, took me a while to understand ... Of course the document could have been designed differently with larger document dimensions and equal (smaller) bleed. Considering the hazard is based on a mirrored bleed zone the behaviour and reason for the warning is understandable. Thx

Affinity Publisher 2.6.2 - Windows 11 It seems the preflight has a bug showing a preflight hazard without reason when the document has a asymetrical bleed. See pictures. Document with asymetric bleed and 3 rectangles Preflight: I attached the document. Cheers, Timo Preflight Bug.afpub

True, that's why I wrote that in this case the copy needs to be added left of the last marker

Is there any valid reason, why you can't copy the last marker in the Color Gradient Dialog (yes, of course, unlike the others it needs to be inserted BEFORE the last one)? This leads to the situation that the same color as the last can not be copied but needs to be edited manually by inserting another marker before the last and changing values by hand. I don't cosider this as a bug, but it seems inconsistent and unconvienient ...

Windows PC, RGB/8 and Wacom Tablet - But I would presume it's unlikely connected with the input device.

I guess I did not make it a feature request

Hmm, that might be a good solution under certain circumstances. My problem here is that the templates get updated frequently (and versioned - so they get a different name). So each time I update a template the link needs to be renewed as well 😞

When I add a folder to the template folders the subfolders as always shown as well. Is there a way to NOT show subfolders? They mess up the window and make it really hard to find the folder that contains the template itself. I'm aware that I could just dedicate a folder without subfolders to all existing templates but I want to keep the templates with the according project files. Cheers, Timo

That's true - but I could not find a feature request for it. And it seems just mentioning a missing feature does not make it a feature request. On the other hand a feature request - no matter how simple it is- does not make it a feature either as we all know by now

Embedded elements can't be direcly edited - they open up in a seperate window and can be edited as a seperate file. I'd like to convert theses elements to be included (and not embedded any more) in the original file.

It would be great to have a single command to convert an embedded layer into an standard element of the file (not embedded). I'm aware there a workarounds but this would significantly save time. Result could be a group with all previously embedded elements included. Cheers, Timo

Thx, David. Both of you are right, there are workarounds to externally automate the process. It does not change my initial point: why not simply fix this over years?

Sorry (not) to say I fully disagree and can't follow your point of view! Affinity Designers key vector format is SVG! Not getting an import done properly for such an essential format IS CRUCIAL! I'm very much aware that Affinity users come from totally different areas and have different needs. Not everyone works with vector files or needs to import them - but assuming this does not affect many useres seems a very uninformed and personal interest driven statement. Just search the forum for discussions on this topic. And given that you feel there's an "easy" workaround proofs your complet lack of knowldge for some designer needs (I'll happily send you 200 svg files to manually change the encoding format). And considering it would be a piece of cake to fix it (I assume) - it is quite brazen to state there is no need to correct bugs just because it does not affect you. And implementing features without fixing their bugs for the sake of new gimmicks, does not seem a reliable business concept. I wonder if you supply your products to your customers with bugs and when they complain tell them that they should be quiet since at least they got "something". Astonishing point of view!

LOL ... Don't kill the translator 🙂