Need true grayscale output for commercial printer from Affinity Publisher 2

[TypeNerd]

I'm on mac running OS Sonoma 14.3.1.

My document is set up color: grayscale/8 profile: generic grayscale.

My images are all grayscale tiffs. My text styles have all been specified as 100% K with no other colors.

My printer needs a PDF/X pdf. I have tried every combination in the pdf settings I can think of, but the pdf always exports in cmyk color. What am I missing?

[Joansz]

I'm on a PC running Windows 10 and I'm getting a preflight error "Document color profile not suitable for PDF/X. Yet it does export gray scale and I started with color images. I got the error selecting either gray/8 or gray/16 in document setup. The document does export grayscale for both doc setups. When I export, I do have to select convert color spaces, otherwise it doesn't convert to grayscale. So here's my suggestion, if you haven't selected that option because you started with gray gifs, select it anyway | or if you do have it selected, unselect.

Edited February 12 by Joansz
typo

[lacerto]

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 

Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).

You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).

If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

[TypeNerd]

This is making me insane.

You are right. If I choose a CMYK/8 color profile, I can then get a true K-only pdf with press-ready option and choose gray. But if I choose PDF/X, it outputs in color.

I can do an ink correction in Acrobat Professional and get back to a true black output, and will do that. But I just couldn't believe it wasn't possible.

Adobe is never getting any more of my money than what I have to pay for Acrobat, (because of this problem!) but I sure hope Affinity fixes this one day. I love Affinity otherwise.

[loukash]

24 minutes ago, TypeNerd said:

I sure hope Affinity fixes this one day

I'm not sure if Serif can even fix or work around all the issues that PDFlib is having  

[TypeNerd]

Thanks to all for your informed and timely response on this! You all rock!

[Joansz]

1 hour ago, TypeNerd said:

If I choose a CMYK/8 color profile, I can then get a true K-only pdf with press-ready option and choose gray. But if I choose PDF/X, it outputs in color.

I can do an ink correction in Acrobat Professional and get back to a true black output, and will do that. But I just couldn't believe it wasn't possible.

Adobe is never getting any more of my money than what I have to pay for Acrobat, (because of this problem!) but I sure hope Affinity fixes this one day. I love Affinity otherwise.

[Is the reason your printer wants PDF/X is because they have an ink printer? If so, the printer would need to be told how much of each ink is required to get black. Since your images and I assume text is gray scale, could you make your document color profile CMYK and then export it to gray/8 or 16?] Oops, you did try that. Never mind.

Edited February 13 by Joansz
Misread the post I'm replying to, so have to retract

[lacerto]

5 hours ago, TypeNerd said:

You are right. If I choose a CMYK/8 color profile, I can then get a true K-only pdf with press-ready option and choose gray.

Note that you could export PDF/X-3 or PDF/X-4 based Grayscale PDF also from Affinity apps, but you need to have a true grayscale print profile installed on the system (I am not sure but on macOS you might have Generic Gray inherently available [UPDATE: Checked, and Generic Gray Profile is inherent on macOS, but is not available whenever using PDF/X-based method]; on Windows [UPDATE: and on macOS, too] you would need to fetch one from the Internet, or have one that comes with QuarkXP or Adobe available), since the only grayscale profile that comes with Affinity apps (Greyscale D50) is basically a display (Gamma) color profile and not selectable when you have a CMYK or Gray/8 document color mode and convert to Grayscale, and use PDF/X-based export method:

 

If you leave the profile empty (or do not have anything available), all the blacks defined above would be converted to four-color black and have Affinity app default U.S. Web Coated v2 marked as the output intent profile. If you do define a true grayscale color profile as output intent, RGB 0,0,0 and B:0 (Grayscale 0) will be output in ICC-dependent 100% Gray (CalGray/ICCBasedGray), but K100 will have something like a 92% value.

See below a PDF/X-3 with no explicit press-specific grayscale output intent (U.S. Web Coated v2 auto-assigned):

pdfx3_gray_from_cmyk_noexplicit_output_intent.pdf

...and a version where a true grayscale output intent is defined:

pdfx3_gray_from_cmyk_quark_genericgray_output_intent.pdf

UPDATE: The same applies to PDF/X-4 production (and in PDF/X-1a only CMYK color mode is available).

If you do not have to use PDF/X-based export method, but force the Grey color space, the default Greyscale D50 would be available, but then, too, K100 values would have non-100% gray values. So whenever forcing grayscale output, you need to have native color values (text and shapes) defined either in RGB or Grayscale, not CMYK.

There might be point in checking whether the printer truly needs PDF/X-based output in grayscale, or whether they just meant K-only output (but accept any regular non-PDF/X based CMYK-based output, as long as CMY plates are empty).

UPDATE: And if they just meant K-only, then the correct method to produce such PDFs is to choose CMYK document color mode and export to CMYK, and make sure that all native objects have K-only color definitions. There are plenty of other considerations that need to be checked when producing press PDFs from within Affinity apps, so the issues related to grayscale are only one of the concerns (but one of the most frequently experienced, and confusing, probably much because the very different K/Grayscale approach/policy used in Adobe apps within CMYK/press-related production).

In this context, paying Adobe for Acrobat Pro -- still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs -- is not money wasted. pdfToolbox by callas software would be an alternative (still more expensive than Acrobat Pro). Free Packzview is not a prepress tool but is useful for decent preflight (it appears to be generally available only for professional use, though).

[loukash]

10 hours ago, lacerto said:

[Acrobat Pro] still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs

Not possible.  
I still keep my various old Intel and PPC Macs alive for a reason… Particularly both my Intel MBPs running El Capitan with Adobe CS5.5 and Acrobat Pro X. The workflow is not even all that complex, since I can easily exchange files via drang & drop and run the old apps via Screen Sharing.

The best workaround on Catalina and newer likely would be running a Win version of Acrobat X in an emulator. I'm not sure if a free Wine based emulator would suffice though. (I was able to make the Win version of Expression Media 2 work in a Wine based emulator on my MBA running Ventura, but it's not very stable.)

[lacerto]

1 hour ago, loukash said:

Not possible.  

Have you tested, or is this just based on assumptions? I ask because Adobe still sells Adobe Acrobat Pro 2020 stating that it is compatible with macOS post-Mojave, including Sonoma.

https://helpx.adobe.com/acrobat/system-requirements-acrobat-2020.html

This is so clearly stated in system requirements for macOS that I suppose it is true (but I can understand if they do not advertise this). This of course means that the macOS version must at least have some kind of a 64-bit front end that is capable of running a 32-bit Intel module, since I do not believe that they have created a 64-bit Intel build just for macOS (but this is of course possible, considering that 64-bit Safari browser plug-in is mentioned) -- which would kind of suck considering Windows users; needing to run a 32-bit module is sometimes an annoyance when opening large files that break the 2GB RAM barrier. 

But this forum is probably not the best place to find out how Adobe Acrobat Pro 2020 runs on modern macs and M3 processors on latest Sonoma 🙂 

[loukash]

2 minutes ago, lacerto said:

Have you tested, or is this just based on assumptions?

Tested up to Acrobat X.

2 minutes ago, lacerto said:

Adobe still sells Adobe Acrobat Pro 2020 stating that it is compatible with macOS post-Mojave, including Sonoma.

Oh, I see! 
I forgot about that, thanks.  

Still, it's over my budget for what I'd need it. Every now and then launching Acrobat X still does it for me.

[loukash]

8 minutes ago, lacerto said:

https://helpx.adobe.com/acrobat/system-requirements-acrobat-2020.html

Quote

Acrobat Pro 2020 (Acrobat Standard 2020 is not available on macOS)

• Intel processor
• macOS v10.14, macOS v10.15, macOS v11^‡, macOS v12, macOS v13, or macOS v14 (Sonoma)

Then it should run on M# processors in Rosetta mode. Usually this shouldn't be an issue; e.g. I'm launching APh in Rosetta mode whenever I want to use the old Google Nik plugins, and I can't tell any difference.

[loukash]

11 minutes ago, lacerto said:

1 hour ago, loukash said:

Not possible.  

Have you tested, or is this just based on assumptions?

Now I see why there was a misunderstanding. You wrote:

12 hours ago, lacerto said:

Acrobat Pro -- still also available as a 32-bit app on a perpetual license

Acrobat X was 32-bit, hence I assumed this is what you meant.

[lacerto]

55 minutes ago, loukash said:

Acrobat X was 32-bit, hence I assumed this is what you meant.

Adobe Acrobat Pro 2020 on Windows is still a 32-bit-only app -- it is clearly a kind of a deliberate annoyance in order to urge Windows users to go for the subscription based DC version. That's why I was interested in knowing what kind of solution Adobe has to be able to sell the app for 64-bit macOS, including Sonoma. It definitely requires Rosetta, as it is Intel only, but whether they have a genuine 64-bit build for macOS for the actual app, or just some kind of a front end, was my main interest (as that would avoid 2GB RAM barrier and errors that I sometimes experience when opening huge PDFs on Windows).

EDIT: Just checked, and happily it seems I am wrong, since I just found a download link for a 64-bit Windows version of Adobe Acrobat Pro 2020 -- it was that on my logged in Adobe downloads site, for some odd reason only 32-bit version was offered...

[loukash]

9 minutes ago, lacerto said:

whether they have a genuine 64-bit build for macOS for the actual app

I don't know. Acrobat X apparently still has some crucial elements that are 32-bit, hence the Mojave end of line. But some parts are likely 64-bit because Get Info on El Capitan has the "Open in 32-mode" checkbox.

[lacerto]

I am about to install the 64-bit version, so I soon see.

But I already found the following:

Acrobat 2020 is originally a 32-bit app. However, it includes OS compatibility features that enable it to run on 64-bit operating systems. For more information, see System Requirements for Acrobat Pro 2020, Acrobat Standard 2020. So what this probably means is that the core of the app is still 32-bit (on both platforms), but it has those "compatibility features" (whatever they are) that let it run on 64-bit OSs...

https://helpx.adobe.com/acrobat/faq-acrobat-2020.html#:~:text=Acrobat 2020 is originally a,Pro 2020%2C Acrobat Standard 2020.

[Joansz]

I'm on Windows 10 64 bit and have been using Acrobat Pro 2020 since 2020 and have had no problems. Hopefully it will work that way on a Mac.

[TypeNerd]

Yes, sadly, it appears my only solution at this time is to use cmyk color profile in Affinity Publisher 2, export PDFX1a which the publisher needs, and then use Acrobat Pro to make it grayscale again. Pretty ridiculous, but it does work. (Sigh)

Longing for the day I can ditch my last subscription to Adobe and let them greedy guys make their money elsewhere.

Just FYI, Adobe Acrobat Pro works fine on mac OS, and has for years.

[lacerto]

15 hours ago, TypeNerd said:

Yes, sadly, it appears my only solution at this time is to use cmyk color profile in Affinity Publisher 2, export PDFX1a which the publisher needs, and then use Acrobat Pro to make it grayscale again.

That is odd. I cannot produce such a file in any layout app [other than Affinity based], since PDF/X-1a basically only supports CMYK (+ spot) color mode. So if grayscale is truly required, you need to force conversion of grayscale as a post-production operation anyway. I just did it for a check (post-processed PDF/X-1a to DeviceGray), and then ran the PDF/X-1a compliance check on the file, and it was passed. So obviously it does not cause problems. But it is an odd requirement, and possibly stems from RGB production environment [e.g., something like Word] not supporting CMYK, but capable of presenting RGB in grayscale (to guarantee one ink only) and tag it as PDF/X-1a [creating a non-ICC-dependent file, possibly even flattening transparencies]. 

[lacerto]

15 hours ago, TypeNerd said:

to make it grayscale again

You could try using the following setting to create a DeviceGray PDF. You need to define your black elements using Grayscale color model (in Colors panel). The point is to leave "Embed ICC profiles" unchecked. That messes up a job because it makes it ICC-dependent, and if your printer asks for grayscale PDF/X-1a, they basically want a job with 1 ink and no color profiles. (They additionally want it without live transparencies so if you have such things, just go on with PDF/X-1a and then optionally convert to grayscale (if you do not have grayscale print profile to be used); but you should also understand that if your design contains any PDFs placed for passthrough, they will all be rasterized if you use PDF/X-1a whether containing transparencies or not, even if the rasterized image will stay DeviceGray; using PDF 1.7 does not rasterize any of your placed PDFs, nor does it flatten transparencies).

[TypeNerd]

Thank you. Yes, the frustrating thing is that I have done the work already, all images are 8-bit grayscale tiffs, all my text is specified at 100%K with no other color. And then my pdf turns it all to color at the end with PDFX1a. But I did check with the printer, and the reason they specify that pdf setting is that USUALLY that is the only way to get true grayscale output (from Adobe InDesign). They are content with any pdf output that is grayscale, so I will go ahead without the PDFX1a setting. Thanks, everyone for sharing my pain and helping to work on the problem.

[thomaso]

6 hours ago, lacerto said:

You could try using the following setting to create a DeviceGray PDF. You need to define your black elements using Grayscale color model (in Colors panel). The point is to leave "Embed ICC profiles" unchecked. That messes up a job because it makes it ICC-dependent, and if your printer asks for grayscale PDF/X-1a, they basically want a job with 1 ink and no color profiles.

1 hour ago, TypeNerd said:

Yes, the frustrating thing is that I have done the work already, all images are 8-bit grayscale tiffs, all my text is specified at 100%K with no other color. And then my pdf turns it all to color at the end with PDFX1a.

What am I misunderstanding when I export successfully as PDF/X-1a with 1 ink channel only with the profile "Schwarze Druckfarbe - PSO Coated v3" (see attached)? Can't a printer not simply ignore this profile, especially if the images are placed in the layout as grayscale already without CMY conversion, like in the OP's case? – The .afpub is setup with the "Generic Gray Profile", for text the default black swatch in the Swatches Panel was used – unexpectedly this gets displayed in the Colours Panel as RGB, not Grayscale or K only.

Schwarze Druckfarbe - PSO Coated v3.icm

 ->

[lacerto]

1 hour ago, thomaso said:

What am I misunderstanding when I export successfully as PDF/X-1a with 1 ink channel only with the profile "Schwarze Druckfarbe - PSO Coated v3" (see attached)?

I am not sure what you ask... This scenario was already explained and demonstrated above: having a Gray/8 document color mode, defining colors in grayscale or RGB (virtually same) and exporting using PDF/X-1a method to produce DeviceGray output (no ICC-dependencies, but just output intent description, so nothing to be resolved), the crucial thing being ability to choose a press-specific grayscale profile (which has to be fetched and installed separately).

Obviously OP did not have such a profile installed so they were not able to produce such a file, so in lack of an appropriate profile, the ICC profile field is left blank, and Affinity app will use the app default US Web Coated v2 as the target profile, resulting in all black definition becoming converted to four-color black. So OP ends up using a workaround, producing PDFX-1a in CMYK document color mode with K-only definitions, producing DeviceCMYK file on mere K plate, and converting the file afterwards to Grayscale 1-ink file.

As mentioned, the printer's requirement appears to be unreasonable, but it is possible that they have been offered grayscale exports with 4-color black, and PDF/X-1a CMYK exports with 4-color black, either as a result of profile conflict (document vs. export time), or because of PDF compatibility violation (and resulting rasterization), etc. Or, because of having been offered an ICC-dependent file (even if otherwise meeting the specs). Some printshops have automated preflight checks that may discard a job for practically irrelevant reasons. So the advise given for "Grayscale" might have been a reference to need of having one ink (grayscale job), whether DeviceGray or DeviceCMYK with K plate only, and with no ICC-dependencies. PDX-1a is probably referred as for requirement of needing to have transparencies flattened. 

As explained in many posts on this forum, this primordial requirement is probably made in sincere belief that it is easy to achieve, and that it is a fool-proof method of guaranteeing expected results on paper (as basically what the client sees is what they get, since nothing will be left to be resolved at RIP-time). But within Affinity ecosystem, depending on complexity of publication, producing PDFs meeting these kinds of primitive specs, can become a challenging job that takes lots of knowledge and experience, or long trial-and-error workflow -- especially if a proper preflight tool is not available.

 

[lacerto]

15 hours ago, TypeNerd said:

Thank you. Yes, the frustrating thing is that I have done the work already, all images are 8-bit grayscale tiffs, all my text is specified at 100%K with no other color. And then my pdf turns it all to color at the end with PDFX1a. But I did check with the printer, and the reason they specify that pdf setting is that USUALLY that is the only way to get true grayscale output (from Adobe InDesign). They are content with any pdf output that is grayscale, so I will go ahead without the PDFX1a setting. Thanks, everyone for sharing my pain and helping to work on the problem.

Thanks for the update. This was an instructive thread, because the job at hand appeared to be very simple, and what was confusing, was basically the very different way Adobe InDesign and Affinity apps handle "grayscale" (or basically, press-oriented black). InDesign does not basically offer "grayscale" color model at all, but uses instead Lab for specifically light intensity oriented color definitions, and for print intent documents always handles "gray" as K ink. So it is very straight forward. Whatever is defined in print intent document and using the factory default {Black] swatch (including tints) will end up on K plate when exporting to press, and stay "grayscale" in that sense. Similarly, imported grayscale images will aways stay on K plate, there is no need to explicitly tell that gray is not a composite RGB but needs to be treated as black ink.

What however was particularly confusing was bringing in PDF/X-1a and combining it with concept of grayscale, and specifically in context of InDesign, since when using this standard, conversion to grayscale proper is not available at all in InDesign (at least up to CS6), so to be able to produce specifically grayscale PDFs, anything else than PDF/X-1a needs to be chosen! PDF/X-1a is often asked for the purpose of guaranteeing that the job will be in CMYK-only color space and will not contain live transparencies, and is therefore a kind of fool-proof export method. 

So, to wrap up, what seemed to have happened was that as you had a pure b/w press-oriented job, you initially chose the Gray/8 document color mode and assumed that text and native art is safest to specify in  CMYK, using K ink only (as you would do in InDesign or Quark, where gray is not even available). Which in Affinity apps is wrong, since K would be handled as an RGB value in a grayscale document and would end up being either a four-color black or a diluted black (dark gray) depending on whether exporting to Grayscale or CMYK. So: in a Gray/8 color mode document, you need to define blacks (text and native art) that are intended to end up on K plate, as Grayscale or RGB color values, and make sure that you also export using Grayscale color mode (using CMYK at export time would convert grays to four-color black).  Placed grayscale images would also be converted to rich black. Using PDF/X-1a in context of a grayscale document, would work if you had press-oriented grayscale profile available (which Generic Gray Profile or D50 are not), so in this sense the color preflight warning that you would get trying to export using PDF/X-1a in context of a grayscale document, is correct. You will end up having four-color blacks if you use PDF/X-1-a:2003.

The next step you tried was probably switching the document color mode to CMYK/8. You already had your text and possible native art defined in K100 so it would seem obvious that you will have correct output having K-only color definitions and placed 8-bit TIFF grayscales. But no, your placed TIFFs would now be exported using four-color-black, as they would be treated as RGB images within Affinity apps whenever placed in Gray/8 or RGB color mode document, but handled in CMYK context, and would be exported as rich black when exporting to CMYK. Using PDF/X-1a would not change anything here.

At this stage, at latest, you might have heard an instruction from the printer to produce in true "grayscale", in the meaning: everything on one/black plate. The trick, in Affinity apps, is to apply the "K-Only" button on all placed grayscale images. This would not be done when placing these images in other than CMYK document color mode, and it won't be done automatically if switching the document color mode to CMYK. The button is also visible on the context toolbar only when using CMYK document color mode, and unfortunately you cannot apply "K-Only" for all document images at once, but need to go through images one by one and make the change. Note that when you have a document color mode in CMYK, placed grayscale images do have K-Only button automatically applied (and the mode will be retained also if you subsequently switch document color mode even if the button itself is hidden, which would also change the way these images are treated in these alternative document color modes when exporting to different color spaces).

After this, you would finally get what you need: "a simple grayscale" job where what you have defined in K-ink only and with imported TIFF grayscales, will be delivered as expected on one (K-plate) only (whether exported using PDF/X-1a or not). You should additionally be careful not to change color profile at export time, since that would, again, convert K-only colors to four-color values. [ALSO: It is good to remember that letting Affinity apps embed ICC profile in the document (= default), will produce an ICC-dependent PDF where using wrong simulation profile will show incorrect CMYK values in Adobe Acrobat Pro so there is still this additional confusion related to complexity of defining black ink values within Affinity apps.]

Part of this is related to clash of different technologies and underlying color engines, and terminology (some say "cultures", but I personally disagree), and the fact that you are not likely to get proper instructions from printers / print shops. The Affinity apps are also under development, and there seem to be recent changes e.g. in the way placed CMYK images are treated when they contain embedded profiles (nowadays they are discarded similarly as by default in InDesign). How could anyone expect to get step-by-step instructions from a third-party when they are not provided even by the first-party, practically ever?