Swatches and overprinting

[mac_heibu]

What I did:

I defined 2 global colors:

1. black knock out: C=0, M=0, Y=0, K=100 and
2. black overprint: C=0, M=0, Y=0, K=100, overprint

Look, what happens, when these colors are assigned:

 

[Old Bruce]

I have noticed something similar on occasion, I will pay more attention and report back.

[MikeW]

I suppose it should work as you have done.

But there is no reason to make a Black overprint swatch as that is the default behavior for a 100% black swatch. Unless one turns that off when creating a PDF or other export file type that supports the overprint attribute.

[mac_heibu]

@MikeW, that is an examülde!

First I want and need two different blacks (overprint and knock out) at one place one under the other to control at one short glance, if the correct black is applied (is "text black“ defined correctly as overprinting?)

Second, this is true not only for black for every other colour too. There must be a way to define two colours with the same values but different overprint states. For example: To counteract printing  inaccuracies is may make sense for critical elements, to define a small outline with an overprinting colour to avoid colour shifting.

[MikeW]

I understand.

I can (more or less) have what you desire and I do not get the weird swatch thing here using Windows. But there is a caveat:

APub (all the apps as far as I can remember) does not properly create a PDF with overprint. I think the swatch issue you show in the video is something else entirely.

Trapping has been largely removed from anything creating PDFs (my main focus). There are no reasonably current RIPs that either do not support in-RIP trapping or, simply remove the attribute from a PDF that does specify trapping and use its in-built trapping routine. Most all (likely all) desktop PS printers trap automatically (and/or kiss fit properly). Inkjets do not need trapping. That doesn't mean that APub (Affinity applications) should not allow manual trapping. They should--but first Serif needs to fix how they create proper PDFs using overprint.

Mike

[mac_heibu]

The main reason of course is having 2 black swatches side by side to assign and easily control overprinting/knock out. And this actually isn‘t given.

Overprinting is working — sometimes at least. Look at my sample documents in this thread: https://forum.affinity.serif.com/index.php?/topic/70509-overprint-issue/

[fde101]

This seems to be a bug in which item is selected in the palette.

If I mimic this by creating a document swatch palette with two swatches both having the same color, create three objects and pick one of the palette entries for two of them and the other entry for the third, then just like the above demo, all three objects result in the first entry being selected in the swatch palette...

However, if I edit the color that I had assigned to two objects, only those two change, and with the colors being different, the correct entry is then selected.

Based on that, the objects are retaining the separate choices, but selecting an object is causing the incorrect palette entry to be highlighted in this case.

[MikeW]

9 hours ago, mac_heibu said:

The main reason of course is having 2 black swatches side by side to assign and easily control overprinting/knock out. And this actually isn‘t given.

Overprinting is working — sometimes at least. Look at my sample documents in this thread: https://forum.affinity.serif.com/index.php?/topic/70509-overprint-issue/

Do black rectangles on top of a color rectangle. Have the swatches 100%k, one set to over print and one not set to over print.

Does this work out for you?

[mac_heibu]

No.

[Chris_K]

Thanks for this. It also affects our current apps so i shall get it reported

Cheers