jstask Posted March 5, 2019 Posted March 5, 2019 With the default settings i experience some problems with black colors. First i would suggest to add a default document-swatch with a overprinting black, (and probably a non overprinting one). I need these colors in every print-design. In the default PDF export-settings (except the web-preset) the checkbox is marked to embed profiles. For CMYK documents i don't want this behaviour. In most situations i would prefer to export untagged CMYK colors (Device CMYK, instead of ICC-based CYMK) and tagged (ICC-based) RGB but with a output intent set to the documents cmyk profile. I did not manage to do that with Affinity Publisher (and Designer) With the current PDF export presets a black color is always tagged causing acrobat and printers to separate k into cmyk due to the color-profile. Nathan Shirley and AlexNo 2 Quote
mac_heibu Posted March 5, 2019 Posted March 5, 2019 This is an issue, I reported some time ago: Normally I don’t rely on „colours out of the box“, but define my own ones. Affinity allows to set up global colours including (or excluding) the „overprint“ attribute. But when I define two different blacks (K = 100) one with „overprint“, one without, the problem becomes visible: When these colours are assigned to objects, „Publisher“ seems only to check the color values, not the attributes or – what in my opinion should be the case – the name of the color. So a different k100 black isn’t honoured at all. Just look at this small screencast: And – to top this – the handling of K100 (and any other color) is only controllable generally by the output switch „overprint black“ under the „More“ button of the PDF export dialog. AlexNo and Nathan Shirley 2 Quote
jstask Posted March 5, 2019 Author Posted March 5, 2019 While this is not the same problem i described, this issue is also color related an should be fixed. Did you get an response on that? Quote
fde101 Posted March 5, 2019 Posted March 5, 2019 10 hours ago, mac_heibu said: Just look at this small screencast: I reported that a long time ago. The correct color is actually attached to the object, which you can verify by changing the definition of one of them. It is only that the wrong entry gets highlighted in the palette... but even that is still problematic and annoying. Quote
mac_heibu Posted March 5, 2019 Posted March 5, 2019 @fde101: I think, it is not. There is no way to keep these two kinds of black in the exported PDF. Either they both knock out, or they both overprint. Just try! Quote
fde101 Posted March 6, 2019 Posted March 6, 2019 1 hour ago, mac_heibu said: There is no way to keep these two kinds of black in the exported PDF. If that is the case, then producing the PDFs is also being handled badly, but internally (as the above video demonstrates) they are being retained separately. Quote
mac_heibu Posted March 6, 2019 Posted March 6, 2019 … and perhaps it makes a — buggy — difference, if not the colour values are changing, but „ only“ an attribute (overprint yes/no). fde101 1 Quote
jstask Posted June 15, 2019 Author Posted June 15, 2019 Thank you Affnity, you did not mention it, but the lastest version features some PDF-export options wich allows to preserve images in their original color-space. You did this just in time so that i can verify it before my super old acrobat stopes woking with the next macOS. Keep up the good Work! Quote
fde101 Posted June 17, 2019 Posted June 17, 2019 On 3/5/2019 at 3:14 PM, fde101 said: The correct color is actually attached to the object, which you can verify by changing the definition of one of them. It is only that the wrong entry gets highlighted in the palette... but even that is still problematic and annoying. This issue still exists in the GM. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.