Generating correct PDF / X with ps2pdf (ghostscript)
I've 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 generate correct PDF / X-1 and PDF / X-3 documents. Yes, I know ps2pdf is said to only support PDF / X-3 (see this thread and this thread and this thread ). However, since PDF / X-1 is basically a subset of PDF / X-3, I assume that 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 I create are converted to CMYK, rather than 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 Preflight.
Which brings me to the first part of the question: How can I prevent the RGB color defined in the original PDF from being converted to CMYK? The switch "-dColorConversionStrategy = / LeaveColorUnchanged" doesn't seem to have any effect. (In fact, I read here that such a conversion is not even possible. So why is this happening? Or is it outdated information?)
Second, why does the documentation say that "RGB is not allowed" when combined with "-dPDFX"? Doesn't that mean PDF / X-3?
Third, is it also possible to create PDF / X-4 documents that skip the Adobe preview?
By the way, here is 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!
source to share
OK, at first you cannot create PDF / X-1 with pdfwrite at this time due to color support limitations in PDF / X-1. In fact, this can be practically done now, but the Separation and DeviceN color spaces are not mapped to device space and should be.
Second, you really should be using the current version of Ghostscript (9.16).
As you noted later in your answer, the documentation states that you cannot use / RGB. So the reason your RGB colors are converted to CMYK is because you cannot use RGB (see below).
The Ghostscript bug report you link is 5 years old, what was true 5 years ago is no longer true (and was not true when 9.10 was released almost 2 years ago). However, as I noted above, you still cannot create PDF / X-1, so the bug is still open. Some work has been done, there is still much to be done.
Setting the ColorConversionStrategy in conjunction with PDFX has no effect, as the PDFX color conversion requirement will override ColorConversion from the command line.
You cannot use the DeviceRGB space in a PDF / X-1 document unless you specify a DefautlRGB color space, which is not itself DeviceRGB or DeviceN. As far as I remember, there is currently no provision in pdfwrite to define the DefaultRGB space, so you cannot use DeviceRGB.
Finally; no, you cannot create a PDF / X-4 file with the pdfwrite device yet.
source to share
OK, KenS's answer should be accepted as correct for this question, but for several years he has been actively involved in standards development (about fifteen now :)), I wanted to add some more general statements.
PDF / X-1a
Please refer to PDF / X-1a and not PDF / X-1. These are two different things, and as long as no one is using PDF / X-1, at this point it would be good to use the correct name for the standard that includes "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 (although the intent is correct, I I think).
The difference between PDF / X-1a and PDF / X-3 is that PDF / X-3 supports color spaces other than CMYK. But that does not mean that CMYK is not allowed or that you cannot perfectly use PDF / X-3 for CMYK files only. In fact, most of the implementations that use "PDF / X-3" that I know of just use only CMYK files.
And yes, if you have a PDF / X-3 file containing only CMYK and / or spot color, and you change the standard metadata fields to PDF / X-1a, you will get a valid PDF / X-1a file; there is very little difference between these standards.
source to share