Creating correct PDF/X with ps2pdf (ghostscript)

问题

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!

回答1:

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.

回答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.

来源：https://stackoverflow.com/questions/30434868/creating-correct-pdf-x-with-ps2pdf-ghostscript

标签

pdf

ghostscript