Jump to content
You must now use your email address to sign in [click for more info] ×

Printing black - Correct settings for commercial printers


Recommended Posts

I want to check that the black text in my press-ready PDF is actually black.

The document profile is set as CMYK

image.png.bef87afb3fcb09359843cc5d093de6f2.png

Text colour is showing in the document as CMYK  0-0-0-100

I'm using the following export profile: 

image.png.6dd94e59cd891c9ab16d301d34c907d2.png

Text colour in the PDF produced shows RGB 20-29-27 CMYK 69-66-67-77

A previous profile showed RGB 30-27-27 which my commercial printer flagged as an issue and I want to find out which setting I set actually corrected the issue.

I've read the following threads but I am none the wiser:

 

 

Link to comment
Share on other sites

Hi @Catshill,

Are you able to upload your pdf so we can check for you?

Affinity Designer 2.3.1.2217 | Affinity Photo 2.3.1.2217 | Affinity Publisher 2.3.1.2217
Affinity Designer Beta 2.4.0.2294 | Affinity Photo Beta 2.4.0.2294 | Affinity Publisher Beta 2.4.0.2294

Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8

Link to comment
Share on other sites

1 hour ago, Catshill said:

Check what? I already know what the output is. I want to identify the factor in the export profile that changes the text colour. 

I don’t understand why your commercial printer is quoting the text colour for a CMYK exported PDF in terms of RGB values. If the item is being printed in CMYK and they have requested you use the FOGRA39 ICC profile then if you’ve set the text to K100 using Coated Fogra39 and exported using the settings shown in your screengrabs then I would expect the RGB values to be RGB 29-27-27 but I’m unsure why that is relevant.

What specs has your printer requested?

image.thumb.png.f5d0b49456624422fcfb3343ce404561.png

Affinity Designer 2.3.1.2217 | Affinity Photo 2.3.1.2217 | Affinity Publisher 2.3.1.2217
Affinity Designer Beta 2.4.0.2294 | Affinity Photo Beta 2.4.0.2294 | Affinity Publisher Beta 2.4.0.2294

Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8

Link to comment
Share on other sites

As Affinity apps basically always convert native elements (text, shapes, etc.) to CMYK whenever a CMYK PDF is created (even when this is not necessary), it is strange that RGB output is created. Therefore delivering a sample page (preferably of both an Affinity document and the created PDF) would save time, simply to double-check the readings, and see that there is just not some confusion. There are multiple reasons why production of a press PDF might fail and why original color values change, as proven by countless posts on the forum trying to explain why expected output is not achieved (or why native object color values get incorrectly interpreted or read).  

Link to comment
Share on other sites

7 hours ago, Catshill said:

I want to check that the black text in my press-ready PDF is actually black.

 

Are you using a Swatch that is defined as CMYK 0, 0, 0, 100. I usually make a Document Palette and define CMYK 0, 0, 0, 100 as a global colour named Black for Text and I use that Black for Text colour for the text colour in the definitions for my Text Styles.

Mac Pro (Late 2013) Mac OS 12.7.2 
Affinity Designer 2.3.1 | Affinity Photo 2.3.1 | Affinity Publisher 2.3.1 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

Thanks for the replies and apologies if I was not being clear. I've corrected my OP when I referenced the RGB rather than the CMYK value.

First of all the text style is set to CMYK 0-0-0-100K

image.png.39ee445e53d346ff9174ea679982a7db.png

As I said earlier my printers are now happy with the PDF I am sending them as text is 0-0-0-K100. 

However, I still do not know what factor(s) in the PDF export profile affect the conversion of CMYK 0.0.0.100K set text to other CMYK values as shown below.

These screenshots show the original PDF showing incorrect CMYK value and the current PDF showing the correct CMYK value. 

Note that the only difference in the source APu file were the export settings used - I just can't work out what setting(s) are making the change. 

Link to comment
Share on other sites

38 minutes ago, Catshill said:

However, I still do not know what factor(s) in the PDF export profile affect the conversion of CMYK 0.0.0.100K set text to other CMYK values as shown below.

This is usually caused when the Export ICC Profile differs from the Document ICC Profile resulting in a conversion between how black is defined between the two profiles...

When your source document uses FOGRA39 but is exported using an embeded U.S. Web Coated (SWOP) v2 ICC profile, K100 is converted to C:69 M:66 Y:67 K:77 as you are seeing in your screen recording...

Affinity Designer 2.3.1.2217 | Affinity Photo 2.3.1.2217 | Affinity Publisher 2.3.1.2217
Affinity Designer Beta 2.4.0.2294 | Affinity Photo Beta 2.4.0.2294 | Affinity Publisher Beta 2.4.0.2294

Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.6.8

Link to comment
Share on other sites

An alternative option being of course a confused reading (especially when using Adobe Acrobat Pro), caused by embedding an ICC profile in a job where CMYK values are already resolved (DeviceCMYK).

Your screenshot implies that you have (correctly) used the document color profile (and NOT an export time profile deviating from the document profile, which always results in recalculated CMYK values of native objects defined in CMYK, e.g. a K100 black being converted to four-color black). BUT, the same screenshot also shows that you have not disabled the default option "Embed ICC Profiles", which makes the export PDF ICC-dependent, even if there is no need for print-time calculations. This means that anyone using Adobe Acrobat Pro using an incorrect simulation profile to review the color values of the job, would get ad-hoc translated values, instead of native color values of inspected objects. 

I have no clear understanding on whether this kind of confusion might actually result in having recalculated color values printed on paper, but it might, either by causing confusion in print personnel (as might have happened in your case), or resulting in wrong interpretation in RIP software (confused by mixed color spaces included, without explicit output intent profile). 

Therefore I would recommend checking the "Convert image color spaces" option, and unchecking the "Embed ICC Profiles" option, as this would produce pure DeviceCMYK output (similar as InDesign and QuarkXPress do when using standard press exports), not needing any embedded ICC profiles. If it is important to leave placed images in RGB color space, it would be a good idea to use PDF/X-3 or PDF/X-4 export methods, instead (which would embed all relevant ICC profiles, and intent profile, as required, for print-time resolution). 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.