4

I have been struggling with this for a few days, so I thought I'd ask for help here...

Basically, I'm trying to use ps2pdf (version 9.10) to create correct PDF/X-1 and PDF/X-3 documents. Yes, I know that ps2pdf is said to only support PDF/X-3 (see this thread and this thread and this thread). However, as PDF/X-1 is basically a subset of PDF/X-3, I guess such a conversion should be possible. Also, using the command...

gs -sDEVICE=pdfwrite -dPDFX -dBATCH -dNOPAUSE -dNOOUTERSAVE -sProcessColorModel=DeviceCMYK -sOutputFile=out.pdf PDFX_def.ps in.pdf

I noticed that the colors of the PDF/X-3 files that I'm creating are converted to CMYK, instead of leaving them in RGB (which should be the case with PDF/X-3). So, technically, the files are now PDF/X-1: Which I can confirm by adding "/GTS_PDFXVersion (PDF/X-1a:2003)" to PDFX_def.ps and running the file through Adobe's Preflight.

Which brings me to the first part of the question: How can I prevent the RGB colors that are defined in the original PDF document to be converted to CMYK? The switch "-dColorConversionStrategy=/LeaveColorUnchanged" doesn't seem to have any effect. (Actually, I read here that such a conversion isn't even possible. So, why is it happening? Or is this outdated information?)

Secondly, why does the documentation say that "RGB is not allowed" in combination with "-dPDFX"? Isn't this what PDF/X-3 is all about?

Thirdly, is it possible to also create PDF/X-4 documents that pass Adobe's preflight?

By the way, here's my PDFX_def.ps file:

%!
% $Id$
% This is a sample prefix file for creating a PDF/X-3 document.
% Feel free to modify entries marked with "Customize".

% This assumes an ICC profile to reside in the file (Blurb_ICC_Profile.icc),
% unless the user modifies the corresponding line below.

systemdict /ProcessColorModel known {
  systemdict /ProcessColorModel get dup /DeviceGray ne exch /DeviceCMYK ne and
} {
  true
} ifelse
{ (ERROR: ProcessColorModel must be /DeviceGray or DeviceCMYK.)=
  /ProcessColorModel cvx /rangecheck signalerror
} if

% Define entries to the document Info dictionary :

/ICCProfile (ISOcoated_v2_300_eci.icc) def  % Customize or remove.

[ /GTS_PDFXVersion (PDF/X-3:2002) % Must be so (the standard requires).
  /Title (Title)                  % Customize.
  /Trapped /False                 % Must be so (Ghostscript doesn't provide other).
  /DOCINFO pdfmark

% Define an ICC profile :

currentdict /ICCProfile known {
  [/_objdef {icc_PDFX} /type /stream /OBJ pdfmark
  [{icc_PDFX} <</N systemdict /ProcessColorModel get /DeviceGray eq {1} {4} ifelse >> /PUT pdfmark
  [{icc_PDFX} ICCProfile (r) file /PUT pdfmark
} if

% Define the output intent dictionary :

[/_objdef {OutputIntent_PDFX} /type /dict /OBJ pdfmark
[{OutputIntent_PDFX} <<
  /Type /OutputIntent              % Must be so (the standard requires).
  /S /GTS_PDFX                     % Must be so (the standard requires).
  /OutputCondition (ISOcoated_v2_300_eci.icc) % Customize
  /Info (Info)                     % Customize
  /OutputConditionIdentifier (Custom)      % Customize
  /RegistryName (http://www.color.org)   % Must be so (the standard requires).
  currentdict /ICCProfile known {
    /DestOutputProfile {icc_PDFX}  % Must be so (see above).
  } if
>> /PUT pdfmark
[{Catalog} <</OutputIntents [ {OutputIntent_PDFX} ]>> /PUT pdfmark

Thanks in advance!

Community
  • 1
  • 1
Marcus C.
  • 219
  • 1
  • 3
  • 11

2 Answers2

3

OK first off you can't produce PDF/X-1 using pdfwrite currently, because of limitations with the colour support in PDF/X-1. It is actually almost possible to do now, but Separation and DeviceN colour spaces are not converted to device spaces, and need to be.

Secondly, you should really use the current version of Ghostscript (9.16).

As you noted yourself later in your answer, the documentation states that you can't use /RGB. So the reason your RGB colours are converted to CMYK is because you can't use RGB (see later).

The Ghostscript bug report you reference is 5 years old, what was true 5 years ago isn't true any longer (and wasn't true when 9.10 was released nearly 2 years ago). However as I Noted above you still can't produce PDF/X-1, which is why the bug is still open. Some work has been done, more remains to do.

Setting ColorConversionStrategy in conjunction with PDFX has no effect, because the colour conversion requirements of PDFX supercede the ColorConversion from the command line.

You can't use DeviceRGB space in a PDF/X-1 document unless you specify a DefautlRGB colour space which is not itself a DeviceRGB or DeviceN space. As I recall there is currently no provision in pdfwrite for specifying a DefaultRGB space, which is why you can't use DeviceRGB.

Finally; no you can't yet produce PDF/X-4 file using the pdfwrite device.

KenS
  • 30,202
  • 3
  • 34
  • 51
  • Thanks, @KenS, for this helpful reply. May I ask a few more questions: (1) What do you mean by saying pdfwrite can't produce PDF/X-1 files? As I see it, the PDF/X-3 files produced really seem to be PDF/X-1. They even pass Adobe's PDF/X-1 preflight. If they were X-3, there would be no need to convert RGB to CMYK? (I'm not using DeviceN spaces.) (2) For me, the main advantage of using PDF/X-3 lies in being able to include RGB colors and have the printer handle the conversion. So, if what you're saying is true (and I assume it to be), it seems to me that I really can't produce PDF/X-3 files!? – Marcus C. May 25 '15 at 13:24
  • 1
    The code, as it stands, cannot take arbitrary input and reliably produce a PDF/X-1 output. There are possible inputs which will not be converted to an acceptable device space. Therefore it cannot produce PDF/X-1 (there may be cases in which specific kinds of input will result in a PDF file which would pass PDF/X-1 validation, but it is **not** reliable). You can produce a PDF/X-3 file because it has wider support for colour spaces. Using RGB and 'letting the printer handle the conversion' will lead to poor quality results, unless you have a carefully colour calibrated workflow. – KenS May 25 '15 at 14:34
  • 2
    @KenS: please write "PDF/X-1a", not "PDF/X-1". There technically is a difference between the two and the only thing used today is PDF/X-1a – David van Driessche May 25 '15 at 15:06
  • @KenS: also, why do you say "Separation and DeviceN colour spaces are not converted to device spaces, and need to be"? That is not the case, PDF/X-1a fully supports separation and DeviceN color spaces (not N-Channel) as long as their alternate color spaces as acceptable by the PDF/X-1a standard. – David van Driessche May 25 '15 at 15:07
  • @KenS: Agreed, thanks for the clarification. So, if I understand this correctly, ps2pdf is said to "produce PDF/X-3", because of the possibility to include ICC profiles and CIELAB etc., _even though_ RGB colors are not supported? As to the "poor quality results": That's not my experience at all. My workflow is indeed carefully color managed and (color managed) RGB in PDF/X-3 files is well supported by most printers I work with. Indeed, I would go so far as to say that I would probably not work with a printer that can't support a standard that's over 10 years old. – Marcus C. May 25 '15 at 15:38
  • You don't have to be able to support RGB colours in order to produce a PDF/X-3 file, as David noted below, and pdfwrite currently does not do so. It does produce a valid PDF/X-3 file though. Most printers aren't RGB devices, and RGB->CMYK conversion can result in surprising differences. Especially with transparency, though that's obviously not a consideration with PDF/X-3 and below. – KenS May 25 '15 at 16:07
  • Thanks again, @KenS, for your help. I suspect you may be thinking I was talking about a printing machine when I wrote "printer"... Of course, I would never let my inkjet printer automatically handle the conversion. This, indeed, would lead to poor results. Actually, what I meant was: I usually create PDF/X-3 files for offset printing and let the guys at the printing studio do the conversion. Which is the preferred workflow nowadays. – Marcus C. May 25 '15 at 16:33
  • Actually @Marc C., it may be the preferred workflow, but it is far from the default or universally accepted one. Most workflows I know are PDF/X-1a only (though most printers will also have a policy to accept just about anything because they're afraid to lose customers). Yes, the format is old, but it's the closest to a worldwide standard still. Only now are user associations participating to develop a standard based on PDF/X-4 that I think has a chance to actually be used... – David van Driessche May 25 '15 at 17:44
  • Thank you, @David. I understand that printing houses like to see us using PDF/X-1a, as it makes their life a lot easier. However, I have been working in design and post production for many years and was under the impression that most printing houses (at least in Europe) are accepting PDF/X-3 as much as an official standard as PDF/X-1a. And justifiably so: I can think of a few cases, where it makes more sense for the printing house to handle the conversion, as they know their machines a lot better than I do. The situation is different in the US, though, were PDF/X-1a seems much more common. – Marcus C. May 25 '15 at 18:49
  • 2
    I'm currently the Executive Officer of the Ghent Workgroup (www.gwg.org) which is a standards organisation widely recognised primarily in Europe. *All* of the standards used in different countries are based on PDF/X-1a. That 's not to say there aren't PDF/X-3 based standards, but the ones used are almost exclusively built on PDF/X-1a. The only exception that I know of is Switzerland. You're right about printers knowing their machines better, but with conversion from RGB to CMYK comes responsibility and most printers dislike that :) – David van Driessche May 25 '15 at 19:00
  • So I agree with your assessment, it is *much* better to retain transparency and retain whatever colorspaces you have in your source material (assuming you're tagging things correctly with ICC Profiles); hence why I'm very much in favour of PDF/X-4. But processing PDF/X-4 files correctly is not trivial, and neither - from a business point of view - is taking responsibility for the conversions necessary... – David van Driessche May 25 '15 at 19:02
  • Totally agreed :). It has also been my experience that many printing houses do not like having to take responsibility for color fidelty (and color casts with b&w images and whatnot). But then, I thought, they at least accepted that PDF/X-3 is a standard that they _should_ start to adopt. By the way: Why should it be different with the upcoming PDF/X-4? If anything, this is going to be even more difficult to adhere to (with transparency and such). Thanks for the first-hand information. Much appreciated. – Marcus C. May 25 '15 at 19:18
2

OK, KenS's answer should be accepted as the correct one for this question, but having been heavily involved with standards work for a couple of years (about fifteen now :)), I wanted to add some more general statements.

PDF/X-1a
Please refer to PDF/X-1a, not PDF/X-1. Those are two different things and while nobody uses PDF/X-1 at the moment it would be good to use the correct name of the standard, which includes the "a".

PDF/X-3 and RGB
The statement in the original question "instead of leaving them in RGB (which should be the case with PDF/X-3)" is incorrect or at least misleading (though the intent is correct I think).

The difference between PDF/X-1a and PDF/X-3 is indeed that PDF/X-3 supports color spaces other than CMYK. But that doesn't mean that CMYK is not allowed or that you can't perfectly well use PDF/X-3 for CMYK only files. In fact, most implementations that use "PDF/X-3" that I know of are simply using CMYK only files.

And yes, if you have a PDF/X-3 file that contains only CMYK and/or spot color, and you change the standard metadata fields to PDF/X-1a, you'll end up with a valid PDF/X-1a file; there is very little difference between those standards.

David van Driessche
  • 6,602
  • 2
  • 28
  • 41
  • Thanks, @David, for the clarification regarding PDF/X-1a. Indeed, I keep forgetting the letter "a" all the time. :) As to RGB vs. CMYK: Yes, I'm aware of the fact that it is perfectly fine to use CMYK spaces in PDF/X-3. As I see it, however, the possibility to use CIELAB and (managed) RGB is one of the main advantages of PDF/X-3, which is why I asked if that was possible. – Marcus C. May 25 '15 at 15:49
  • Also, thanks, @David, for the confirmation regarding PDF/X-1a: So, am I correct in assuming that the files that are produced by the above procedure indeed are valid PDF/X-1a files? They seem to pass the validation... but is there anything that I need to pay attention to, when letting ghostscript handle the conversion? – Marcus C. May 25 '15 at 15:50
  • 2
    Yes, as I said there are potential input colour spaces which will not be converted to a valid PDF/X-1a colour space but instead will be preserved unchanged. This will leave the file as a valid PDF/X-3 file, but not a valid PDF/X-1a file. – KenS May 25 '15 at 16:05
  • Unless you have a method that guaranteed produces PDF/X files or throws an error if it can't, or unless you have ironclad control over the PDF generation process, you're really only sure that a PDF file is PDF/X compliant if it passes a preflight check (such as the one you've already done using the Acrobat Preflight plug-in). – David van Driessche May 25 '15 at 17:40
  • @DavidvanDriessche: So it is important to add the letter `a` to the digit `1` when talking about a certain standard. But you can even skip the digit after the `/X-` with impunity?!? *[Never mind, David -- just kidding...]* :-) – Kurt Pfeifle May 29 '15 at 00:06
  • :-) I actually thought about that while writing it but my statement is valid for **all** PDF/X files – David van Driessche May 29 '15 at 05:17
  • @DavidvanDriessche: Actually, I thought so too, but wasn't entirely sure. So there should be a more precise way to express this... maybe put an "all versions of" before the "PDF/X" when it comes to such statements? – Kurt Pfeifle May 29 '15 at 08:36