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

Publisher color export problem: 100% Black is turning into a mix of CMYK colors when exporting to PDF


Recommended Posts

Hi,

I am preparing a book to be printed and I cannot figure out one issue for days already! 🥵

The text is in 100% Black, but every time I export the file into PDF, it turns into a mix of CMYK. I tried various color profile setups, every export possible and nothing changes...

Also when I place an image as Designer/PDF/EPS file (yes, I tried all of them!), it is 100% Black + one spot color, but it turns into a mix of CMYK after saving.

I am desperate... the data for the printer needs to be 1 color + 1 spot color and I do not know how to achieve that. The only qick fix is to convert colors in Adobat Acrobat.
But I am afraid that could mess the illustrations.

Thanks for your prompt help, the deadline is soon...

1855132157_Snimekobrazovky2022-01-19v9_16_56.thumb.png.dba31e65e3e4bf33aaa99ffe9480195c.png1421851359_Snimekobrazovky2022-01-19v9_17_28.thumb.png.78bb1142b23f642f9acd6b656910ca4e.png

 

Snímek obrazovky 2022-01-19 v 9.16.45.png

Link to comment
Share on other sites

This could be the "illustory" problem of having a device-CMYK PDF that is produced if you used "PDF (press-ready)" and either had the images already in CMYK mode, or checked "Convert image color spaces" export option under the "More" PDF export option page. Affinity apps by default include the target ICC in the PDF, which is basically not needed since everything is already in target color space. If this target is different than what you have in Adobe Acrobat Pro (which shows the default Adobe CMYK target Coated Fogra 39), the Output Preview will show ad-hoc converted CMYK values, where e.g. K100 values show as four-color black.

In such situation, simply changing the simulation color profile (in Output Preview of Adobe Acrobat Pro) to match your Publisher working CMYK color space should correct the problem, but I would rather unceck the "Embed ICC  Profile" option, and re-export as then it does not matter which simulation profile you use. Another option is to use any of the PDF/X-based export methods, as these presets embed the required profiles, but additionaly include the output profile intent so that Adobe Acrobat Pro automatically picks the correct simulation profile. 

EDIT: It is not completely clear to me whether this confusion could actually result (by itself) in erroneous print-out, but I am certain that it can confuse (inexperienced) press personnel, and might actually lead in a situation where colors get mixed. This problem does not happen when you use e.g. Packzview as prefilight tool so it might be Adobe-specific, so in that sense "illusory". But this problem does not happen when you produce PDFs from e.g. InDesign (or QuarkXPress) because the defaults are such that ICC profiles are not eimbedded if not needed, and when included, the target intent is included, as well.

EDIT2: The way to avoid most of the printing issues that exist in Affinity apps when producing for commercial press is to choose "PDF (for press)", and then changing the following two options as shown:

devicecmyk.jpg.52824d98e48274ec2c01ab5f280c9e4e.jpg

PDF/X-based methods would otherwise to fine, but they do not work well if you have placed PDFs that are meant to be passed through (these files might get rasterized if there is PDF version "incompatibility", as Serif puts it).

Link to comment
Share on other sites

3 hours ago, Lagarto said:

This could be the "illustory" problem of having a device-CMYK PDF that is produced if you used "PDF (press-ready)" and either had the images already in CMYK mode, or checked "Convert image color spaces" export option under the "More" PDF export option page. Affinity apps by default include the target ICC in the PDF, which is basically not needed since everything is already in target color space. If this target is different than what you have in Adobe Acrobat Pro (which shows the default Adobe CMYK target Coated Fogra 39), the Output Preview will show ad-hoc converted CMYK values, where e.g. K100 values show as four-color black.

In such situation, simply changing the simulation color profile (in Output Preview of Adobe Acrobat Pro) to match your Publisher working CMYK color space should correct the problem, but I would rather unceck the "Embed ICC  Profile" option, and re-export as then it does not matter which simulation profile you use. Another option is to use any of the PDF/X-based export methods, as these presets embed the required profiles, but additionaly include the output profile intent so that Adobe Acrobat Pro automatically picks the correct simulation profile. 

EDIT: It is not completely clear to me whether this confusion could actually result (by itself) in erroneous print-out, but I am certain that it can confuse (inexperienced) press personnel, and might actually lead in a situation where colors get mixed. This problem does not happen when you use e.g. Packzview as prefilight tool so it might be Adobe-specific, so in that sense "illusory". But this problem does not happen when you produce PDFs from e.g. InDesign (or QuarkXPress) because the defaults are such that ICC profiles are not eimbedded if not needed, and when included, the target intent is included, as well.

EDIT2: The way to avoid most of the printing issues that exist in Affinity apps when producing for commercial press is to choose "PDF (for press)", and then changing the following two options as shown:

happyprinting.jpg.cea43b162dc34893272c3088c6a8548b.jpg

PDF/X-based methods would otherwise to fine, but they do not work well if you have placed PDFs that are meant to be passed through (these files might get rasterized if there is PDF version "incompatibility", as Serif puts it).

first of all: THANK YOU SO MUCH!!!

EDIT2 seems to be working – now I can see only K from CMYK values in Acrobat preflight preview :)

P. S. I tried all PDF export files, but none of them worked well with the combination of a spot color + vector illustration, as far as I remember.

Link to comment
Share on other sites

  • 7 months later...
On 1/19/2022 at 2:54 AM, lacerto said:

This could be the "illustory" problem of having a device-CMYK PDF that is produced if you used "PDF (press-ready)" and either had the images already in CMYK mode, or checked "Convert image color spaces" export option under the "More" PDF export option page.

... ...

 

EDIT2: The way to avoid most of the printing issues that exist in Affinity apps when producing for commercial press is to choose "PDF (for press)", and then changing the following two options as shown:

happyprinting.jpg.cea43b162dc34893272c3088c6a8548b.jpg

No picture!  What are the settings?

I'm currently facing this issue with a printer who is flagging black color issues using Adobe Acrobat Pro.

Link to comment
Share on other sites

2 hours ago, wendylou said:

No picture!  What are the settings?

There is a picture now, but notice that these settings basically just guarantee correct readings in Adobe Acrobat Pro, and that the resulting PDF is in "Device-CMYK" mode (all colors in CMYK color mode and not needing interpretation at print time).

There are many reasons why black, intended to be printed just with black ink, can be converted to four-color black at export time, also when the document is in Gray/8 color mode, so it would be necessary to know more about the job, and have an example of a PDF that has the issue (even just one page where intended black has become four-color black).

Link to comment
Share on other sites

Thank you so very much!  That worked!  The printer just reported back that my new PDF passed Adobe Preflight.  FYI, I just heard that Adobe updated Acrobat a week or so ago, and even someone at the printer was experiencing similar flagging during Acrobat Preflight, so very good to know what to set things to for PDF export from Publisher to make Acrobat "happy"!  This made my day! Thanks again.

Link to comment
Share on other sites

  • 1 month later...

@lacerto I'm confused about this issue too. I don't do this stuff regularly enough anymore to come across this often, but I just had to output a couple of jobs and could not work out why the black was being converted to a CMYK mix. I checked the seps in your 'PDF Output Preview' app, as well as the PDFTRON WebViewer Demo, and both show the same thing, so I don't think it's an 'illustory' Acrobat issue as you described it earlier.

My document colour settings are:

  • Colour format: CMYK/8
  • Colour profile: Coated FOGRA39 (ISO 12647-2:2004)

The text colour is K:100 as shown by selecting the text and double clicking on the fill colour well:

image.png.57bb2acb25ded77b11abe6fcc110ebdd.png

With the default 'PDF (press ready)' preset, the profile is set to 'Use document profile'. After PDF export, the black is changed to a CMYK mix every time:

image.png.4e13e3fdd489f5a7ed0032634a977680.png

 

I was scratching my head because I don't remember this being a problem in the past. But when I found your advice to uncheck the 'Embed profiles' option, problem fixed!

This makes absolutely no sense to me. Firstly, I want colour profiles embedded, because RGB images need to be converted correctly to CMYK at prepress. Secondly, there should be no conversion of CMYK values to new CMYK values when the output profile matches the document profile.

Is there something I'm missing here? A publishing program that turns black text to C:71, M:66, Y:66, K:76 with the default prepress settings?? What the #$^&*@??

 

Link to comment
Share on other sites

3 hours ago, Kal said:

This makes absolutely no sense to me. Firstly, I want colour profiles embedded, because RGB images need to be converted correctly to CMYK at prepress. Secondly, there should be no conversion of CMYK values to new CMYK values when the output profile matches the document profile.

This is basically an "illusory" problem, caused by making color references ICC-dependent. The ideal (IMO) is to create a device specific (and accordingly ICC independent) PDFs where all CMYK values are fully resolved and will simply be passed through without further interpretation. This basically happens if you use any of the PDF/X-based export methods or if you choose the default "PDF (press-ready)" preset without inclusion of ICC profile. I am not sure why Serif has chosen to include the ICC profile as a default since it just confuses everyone, and leaving it unchecked does not seem to have any negative effect (e.g., RGB objects still include references to their source profiles so e.g. AdobeRGB and sRGB objects are differentiated).

So to explain the reason for confused display values in Acrobat Pro, here is a situation where the document CMYK profile (here ISO Coated v2) is different from the simulation profile used in Acrobat (Adobe used to have Coated Fogra 39 as the default CMYK profile in whole Adobe suite and this is still true for many users using Adobe apps; the default used by Acrobat Pro can be defined separately in the preferences of the app):

press_ready_default_01.jpg.adda9ff3dea6746f0adf00e42c2b0b76.jpg

...so the K100 values are shown using ad-hoc conversion of color values based on chosen simulation profile, and appear to be four-color CMYK.

But when the preview is switched to Object inspector, you can show object-wise the actual ICC profiles the objects use, and true internal color values for the object:

press_ready_default_02.jpg.fdbe8cd4dbb96fbd967a6a48769bcc5f.jpg

If you use PACKZVIEW, it shows true color values so this conflict does not show there. If you change the Simulation Profile in Acrobat Pro to ISO Coated, the illusory conflict is resolved and true color values are shown for CMYK objects:

press_ready_default_03.jpg.0b8a3de5bef5a6a0ac571d0746df5c9c.jpg

If "Embed ICC Profile" is unchecked, you would get all color definitions of native objects (including RGB definitions) converted to ICC-independent CMYK, and Adobe Acrobat Pro would show true CMYK values no matter which simulation profile is selected, as all CMYK objects are now "DeviceCMYK":

image.jpeg.20e2123aa270f8cf04959ca3af018048.jpeg

If you additionally force conversion of image color spaces to the defined color space, you would get pure device CMYK color space (spot colors excluded), and basically a similar plain vanilla PDF export that you get in InDesign when choosing the Press Quality export (at least in ID CS6): the PDF version is by default 1.4 in InDesign (not 1.7), but using PDF 1.7 is wise to get maximum "compatibility" to avoid PDF conflicts within Affinity apps. As the PDF version is always 1.4 or later in Affinity apps, you would still retain transparencies (the only way to flatten them in Affinity apps is to use PDF/X-1 or PDF/X-3):

image.jpeg.374895c41836ad33a3a40dfaac62cd49.jpeg

press_ready_iccoff_03.jpg.51f337e122b4c65fd16e097d5afe9acc.jpg

Using PDF/X-based methods would basically be problem-free because then the output intent is included, which would cause simulation profile to be chosen automatically in Acrobat Pro Output Preview, while image color spaces would by default stay in RGB :

image.jpeg.2ee989106cd5e5d9b206354742235a36.jpeg

But in Affinity apps using PDF/X based export methods has some serious limitations so they cannot be used without precaution.

BTW, what you mentioned about PDF Output Preview (POP) -- interesting, I had not noticed this! So it seems that embedding ICC does fool Ghostscript, since I am just using the default functionality in Ghostscript to get the separations. Ghostscript does support in some degree color profiles but I have thought that it would by default ignore all ICC based stuff and just read the "native" color values (similarly as PACKZVIEW, or Adobe Acrobat Pro when using the object inspector).

This is good information, as it could then be possible that this "illusory" problem would actually cause the RIP to produce incorrect color values, or would require a skillful enough prepress personnel at print shop to get the job separated "as intended". Basically this is of course something where the blame is on the guy who created the PDF, or software that was used to create it ;-)

Here are the test files I used:

press_ready_default_iccdependent.pdf

press_ready_default_devicecmyk.pdf

press_ready_default_devicecmyk_all.pdf

pdfx3_default.pdf

Link to comment
Share on other sites

1 hour ago, ashf said:

Actually Adobe Illustrator does the same thing.

Which version? At least in CS6 there is no conversion or profile inclusion by default:

ai_default.jpg.3ee6679382020565c2b0f31cc6a3c123.jpg

...and when choosing Press Quality, the settings are basically the same as in InDesign (CS6):

ai_pressready.jpg.02bc67cf96564f381e081f4a2619e8bd.jpg

In Illustrator it is of course a bit different than in InDesign since native color definitions are converted to document color mode (while InDesign supports multiple color definitions for native objects). But basically colors are converted to CMYK, but not between the native CMYK (so numbers are kept). InDesign also by default discards all embedded CMYK ICC profiles and just passes through the original CMYK values (while e.g. Affinity apps retain embedded CMYK profiles of placed AI files).

Link to comment
Share on other sites

14 minutes ago, lacerto said:

Which version? At least in CS6 there is no conversion or profile inclusion by default:

I mean if I choose to embed the profile(with Profile Inclusion Policy), the black will be the rich black in the PDF.
Mine is CC 2022.

Link to comment
Share on other sites

24 minutes ago, ashf said:

I mean if I choose to embed the profile(with Profile Inclusion Policy), the black will be the rich black in the PDF.

Yes, it will (also CS6). But isn't it a user-choice then that deviates from the default, also in CC2022?

It is of course fine to allow any choice the user prefers to have but IMO it would be good if the defaults would produce as generic and problem-free output as possible (and at least provide the kinds of descriptions for each option that Adobe apps do). It is also common that print shops provide step-by-step instructions for users of Adobe apps. Hopefully they some day do this also for Affinity apps.

Link to comment
Share on other sites

2 hours ago, lacerto said:

The ideal (IMO) is to create a device specific (and accordingly ICC independent) PDFs where all CMYK values are fully resolved and will simply be passed through without further interpretation.

Agreed. (For colours defined in Publisher anyway—I still prefer to let the printer convert RGB photos to CMYK.)

 

2 hours ago, lacerto said:

This basically happens if you use any of the PDF/X-based export methods or if you choose the default "PDF (press-ready)" preset without inclusion of ICC profile. I am not sure why Serif has chosen to include the ICC profile as a default since it just confuses everyone, and leaving it unchecked does not seem to have any negative effect (e.g., RGB objects still include references to their source profiles so e.g. AdobeRGB and sRGB objects are differentiated).

Ah okay, that's a relief about RGB profiles. I always assumed they were included when I chose a 'press-ready' export, but manually deselecting that 'Embed profiles' option had me worried!

 

2 hours ago, lacerto said:

This is good information, as it could then be possible that this "illusory" problem would actually cause the RIP to produce incorrect color values, or would require a skillful enough prepress personnel at print shop to get the job separated "as intended". Basically this is of course something where the blame is on the guy who created the PDF, or software that was used to create it ;-)

I guess we'd need to talk to someone who works in pre-press for a living. I've never delved into the PostScript or PDF code the way you have, so I have no idea what it all looks like under the hood—I just assumed that when I preview separations in software designed for that task (I used Acrobat Pro for many years, but switched to those other options as per our discussion about Acrobat Pro alternatives) I'm seeing how it will separate at the other end. I've never used PACKZVIEW, but if all the other software is showing the same thing, that black text has been converted to a CMYK mix, that's reason enough for me to want to fix it before it goes to the printer. Imagine a whole book being printed that way! What a disaster that would be.

TL;DR: Choose the 'PDF (press-ready)' export preset and uncheck 'Embed profiles'. 🙂

BTW, has anyone submitted a feature request to make this behaviour the default?

 

Link to comment
Share on other sites

13 hours ago, Kal said:

Ah okay, that's a relief about RGB profiles. I always assumed they were included when I chose a 'press-ready' export, but manually deselecting that 'Embed profiles' option had me worried!

Yes, this is something that worries me, too, so don't count on me. This would be something to discuss with some prepress guy. This is why I personally like to turn everything to CMYK at export time even if it makes the file size bigger.

Based on the following two clips, it does seem that ICC info is carried in the PDF produced without ICC embedding. The RGB full values of AdobeRGB and sRGB files with embedded profiles show clearly in PDF output, including information about the associated profile (even if the profiles themselves are not included):

 But I cannot say if it is enough that the files are just tagged with an ICC profile without actually embedding the profiles (which the option does, as can be seen from the file sizes). In case the referred profiles are common, like sRGB and AdobeRGB, I suppose everything is OK (meaning that 100% Red in AdobeRGB and 100% Red in sRGB really end up producing different colors when printed). But what would happen if the profiles are not common (like when using some high-end scanner profile embedded in images)? 

For these reasons, for me it is CMYK, please (or at least digital proofs of ripped content).

pdfxpress_devicecmyk_iccrgb.pdf

EDIT: I suppose it is related to this, whenever conversions are not performed:

whattoinclude.jpg.354130f08552cfa7f5047b534c418f59.jpg

...meaning that if "Include All Profiles" (which is what the "Embed ICC Profile" of Affinity apps supposedly means), then the embedded destination profile marks everything ICC Profile dependent, and would cause conversion of all colors including "conflicting" CMYK values, to be converted to "correct" destination (even if just simulation-determined). The screenshot above shows the other available options that do not include the target profile but just source profiles, and this would not cause conversion of CMYK values, unless specifically tagged and involving conflicting profiles.

But this seems to become very complex: I just noticed that InDesign (CS6) discards embedded profiles from PNG files, so it assigns them whatever document RGB profile the publication uses, even if the general policy dictates keeping of embedded RGB profiles (and discarding only CMYK ones). But for TIFF files the general policy is honored! In InDesign it is possible to assign per image based profiles and this way have control on what will be done, but having a prepress tool seems to be useful no matter what tools and workflows one is used to! (I am still to some extent old-school so I basically import TIFF bitmaps and if any other format in RGB, they are always in sRGB, so I had not noticed this PNG thing before!)

Link to comment
Share on other sites

From the discussion here, I learn: I buy Adobe Acrobat and "find" problems with it that I wouldn't have without the software? Right? ;-)

I have never had any printing problem. I export a PDF with my own - few - presets, open it in Designer or Publisher and check all the important details. Yes, I find errors from time to time, but they are my own mistakes and easily corrected.

Thanks to DeepL.

Link to comment
Share on other sites

17 minutes ago, Palatino said:

From the discussion here, I learn: I buy Adobe Acrobat and "find" problems with it that I wouldn't have without the software? Right? ;-)

If the tasks are similar and routines are good, there is certainly no point in changing them just to seek a failure. But this forum shows that for many the routines are wrong, or the workflows so different that you simply just cannot give universal instructions based on your own standard workflow. 

Link to comment
Share on other sites

2 hours ago, Palatino said:

I buy Adobe Acrobat and "find" problems with it that I wouldn't have without the software? Right?

@Palatino, not really right. The problems start in Affinity, caused by its lack of an export option to maintain colour definitions on export, in particular to maintain 100 K for text (see topic title). Acrobat is 'just' used to detect this issue (– regardless of possible issues within Acrobat).

2 hours ago, Palatino said:

I export a PDF with my own - few - presets,

This "my own" is what @lacerto doesn't mention or state only but illustrates, demonstrates and describes in details (repeatedly in various threads).

2 hours ago, Palatino said:

Yes, I find errors from time to time, but they are my own mistakes and easily corrected.

Well, this is you and your solution with your own presets. Imagine that every user may run into this same problem because the default Affinity presets not only cause unexpected results (e.g. not 100 K) but also the solution appears confusing strange: not to use the default preset option "Embed profiles" on export, although profiles are developed & used to maintain correct colours and default presets to set them with one-click.

The absence of the "Preserve colour definitions on export" option and the Affinity solution can demand the additional need to set the document profile to the export profile before exporting to avoid the problems that occur when using only the offered option to select the required export profile.

It gets more complicated when users need to respect certain expectations of various print services without knowing their detailed handling while different services have different expectations … and, another lack of Affinity, we can't use possibly available .joboption files which possibly get created & delivered by print services exactly to avoid issues & reduce the necessity of discussions like this.

If your few own presets include any that appear to work bullet-proof I am sure you would make many users happy (possibly developers, too) and stop discussions like this if you would share them, ideally as importable files … if Affinity would not lack in a preset export / import option, too (… for Serif's sort of proprietary use of the .dat file type for this user presets). :234_unicorn:

512008146_exportmanagepreset.jpg.9122d711d546d07c0ceee2a25d2d8660.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

13 hours ago, lacerto said:

Yes, it will (also CS6). But isn't it a user-choice then that deviates from the default, also in CC2022?

It is of course fine to allow any choice the user prefers to have but IMO it would be good if the defaults would produce as generic and problem-free output as possible (and at least provide the kinds of descriptions for each option that Adobe apps do). It is also common that print shops provide step-by-step instructions for users of Adobe apps. Hopefully they some day do this also for Affinity apps.

"Don't include profiles" is the default for the Press Quality & PDF/X profile in 2022 also.
 

Link to comment
Share on other sites

11 hours ago, lacerto said:

Yes, this is something that worries me, too, so don't count on me. This would be something to discuss with some prepress guy. This is why I personally like to turn everything to CMYK at export time even if it makes the file size bigger.

Ah, okay. I went full CMYK for years, before seeing the benefits of a tagged RGB workflow for photos. The problem with converting photos to CMYK at our end is that the 'prepress guy' can't then do anything to correct colours, even if he wants to (aside from minor ink coverage fudges on the press).

 

11 hours ago, lacerto said:

The screenshot above shows the other available options that do not include the target profile but just source profiles, and this would not cause conversion of CMYK values, unless specifically tagged and involving conflicting profiles.

Right. Adobe, for all its faults, was very explicit about this kind of thing, so you knew where you stood. With Affinity's one-setting-fits-all approach, we can really only guess at what's happening.

Link to comment
Share on other sites

It's this kind of stuff that makes me feel some regret at jumping all in with Affinity. Aside from the endless frustrations I feel with the UI (particularly with colour swatches), there are some essential features for professionals (like support for 1-bit images and turning off anti-aliasing) that are simply missing. Years go by, with users requesting the same features over and over, and there seems to be little evidence that these features are even on the roadmap.

It makes me wonder if Affinity just doesn't have any print professionals on their team, if they think these things aren't essential.

Link to comment
Share on other sites

On 11/2/2022 at 8:47 AM, lacerto said:

Affinity apps using PDF/X based export methods has some serious limitations so they cannot be used without precaution.

PDF/X-3 for sure. After my last year's frustration with that format, I switched my output to PDF/X-4. No complaints here so far. But that's print shops in Switzerland or Germany, so elsewhere your mileage may vary.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

On 11/8/2022 at 2:46 AM, loukash said:

PDF/X-3 for sure. After my last year's frustration with that format, I switched my output to PDF/X-4. No complaints here so far. But that's print shops in Switzerland or Germany, so elsewhere your mileage may vary.

My concerns are primarily related to incompatibility of PDF/X-based export methods with non-PDF/X based placed PDF content: it will all be rasterized no matter which PDF/X-based method will be used for export. This is a pure Affinity-limitation, this does not exist elsewhere. In addition, Affinity apps cannot produce RGB-based PDF/X-4, they always force conversion of RGB-based native content to target CMYK. In addition, there have been recent posts on this forum where PDF/X-4 has failed to handle complex transparencies, while transparency flattening methods (both PDF/X-1a and PDF/X-3) have exported such jobs without problems.

But this does not mean that any other method would be foolproof, either. The following example is pretty complex, but should not be impossible task to handle:

pdf14rgb.pdf

 pdf14cmyk.pdf

It is PDF 1.4 export from ISO Coated V2 CMYK mode document in RGB (sRGB) and CMYK format (no embedded profile), and both work fine as they are as independent files. I tried to create a test document using PSO Coated v3 in a CMYK/8 document to show how you would be able to create PDF 1.7 based PDF exports from these files, in RGB mode from the former and CMYK from the latter, without any issues, but noticed that colors of the CMYK export showed oddly distorted in Adobe Acrobat Pro Output Preview, yet show perfectly correct separations in Object Inspector mode (and when the Output Preview windows is closed).

pdf17rgb.pdf

pdf17cmyk.pdf

When exported to PDF/X-4, both files are rasterized.

pdfx4_fromrgb_apub.pdf

pdfx4_fromcmyk_apub.pdf

When produced from InDesign, both behave (more or less) as expected (nothing rasterized, objects showing correct colors when examined using Object Inspector), the RGB one is ICC-based RGB, and the CMYK is DeviceCMYK:

pdfx4_fromrgb_id.pdf

pdfx4_fromcmyk_id.pdf

Because of these kinds of problems, the best general purpose choice seems to be using the default PDF 1.7 (PDF (press ready)) and unchecking the ICC Profile Embedding option. It seems to produce most robust CMYK PDF outputs without rasterizing placed PDF content (because of Affinity "incompatibility rule"), while still tagging RGB content with their source profiles, and it would also allow producing pure RGB PDF content. All non-PDF/X-based methods keep transparencies, which might be a problem in some situations, and if transparencies need to be flattened (without full rasterization), there are no other options than using PDF/X-1a:2003 or PDF/X-3. Both methods unfortunately use rasterization for transparency flattening, and both methods force conversion of native color definitions to CMYK.

EDIT: I later re-created the test with pure InDesign created PDF 1.4 files (another all CMYK, another all RGB), which could subsequently be produced without problems as placed PDFs  both from Publisher (PDF/X-4 always rasterized, but PDF 1.7 without problems) and InDesign (all exports without problems). The confusing color values in Acrobat Pro Output Preview were related to PDF 1.4 files attached above containing transparencies and Publisher using RGB blending color space (not allowing the user to define the blending color space; sRGB blending color space causes display of confused color values when combined with CMYK objects).

Link to comment
Share on other sites

The only way I can get 100% solid black when printing from Publisher (v1) and I dare say it will be the same with V2 (not yet printed from them as yet), is to set the colour profgile to Grey and print that way. This now prints black as a solid, if left as a colour profile then it prints single black with a screen or as a 4 colour black.

It's been a nightmare when sending to press, so I let the printer do their thing with the PDF. Even though it prints incorrectly for me (on a Xerox VersaLink C7000), the printer alters the PDF with their own tools.

Interestingly if I export a Pub doc to PDF andf print teh PDF, black prints correctly.
The whole handling of colour in Affinity apps has always confused me with regard to CMYK and printing.
I hope V2 has solkved this . . .

Link to comment
Share on other sites

  • 2 weeks later...

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.