Improve `--preflight` by supporting different Versions of PDF/X and color profiles

[cmahnke]

I'm now beyond proof reading my book project and now into getting it to be printed.

See this document of the print shop (In German only):
https://www.mybuchdruck.de/media/pdf/cc/a0/58/TB_Q210.pdf

They request PDF/X-4 with a ISOCoatedV2 / FOGRA39 color profile. This is currently not supported out of the box.
I currently creating using GhostScript, but in the log run it would be nice to pass these as --preflight-option. This is my (current) workaround:

gs -dPDFX4 -dBATCH -dNOPAUSE -dSAFER -sDEVICE=pdfwrite -dCompatibilityLevel=1.6 -dPDFSETTINGS=/printer \
  -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=UseDeviceIndependentColor \
  -sDefaultRGBProfile=sRGB.icc -sOutputICCProfile=ISOcoated_v2_eci.icc -sOutputFile=print-press-ready_X4.pdf print-press-ready.pdf

Since this isn't yet supported by the upstream project, should I add it there as well?

[cmahnke]

If anyone else stumble on this, one can use --preflight press-ready-local to use the local version (which is installed as dependency in node_modules) this makes it easier to change settings by hacking the following file:node_modules/press-ready/lib/ghostScript.js

One can add files to node_modules/press-ready/assets, this allows one to change the ICC profile, by replacing the string JapanColor2001Coated.icc with the name of your file.

It's also possible to use a newer PDF/X definition like the official one, make sure to port the variable placeholders {{{title}}} and {{{iccProfilePath}}} to the new file. make also sure to use the file name from the module (PDFX_def.ps.mustache) not the source.

This way it's also possible to use PDF/X-4 using this PDFX_def.ps.mustache:

%!
% This is a sample prefix file for creating a PDF/X-3 document.
% Users should modify entries marked with "Customize".
% This assumes an ICC profile resides in the file (ISO Coated sb.icc)
% in the current directory unless the user modifies the corresponding line below.

% First up, attempt to ensure the user has set ColorConversionStrategy correctly.
% PDF/X-3 only permits Gray or CMYK in the output.
%
systemdict /ColorConversionStrategy known {
  systemdict /ColorConversionStrategy get cvn dup /Gray ne exch /CMYK ne and
} {
  (\nERROR: ColorConversionStrategy not set.)=
  true
} ifelse
{ (ERROR: ColorConversionStrategy must be /DeviceGray or /DeviceCMYK.)=
  /ColorConversionStrategy cvx /rangecheck signalerror
} if


% Define entries in the document Info dictionary :
%
[ /GTS_PDFXVersion (PDF/X-4)
  /GTS_PDFXConformance (PDF/X-4)
  /Title ({{{title}}})
  /Trapped /False
  /Creator (Ghostscript 10.06.0)
/DOCINFO pdfmark


/ICCProfile ({{{iccProfilePath}}}) def  % Customize or remove.

% Define an ICC profile in the output, if the user specified one.
%
currentdict /ICCProfile known {
  [/_objdef {icc_PDFX} /type /stream /OBJ pdfmark

% This code attempts to set the /N (number of components) key for the ICC colour space.
% To do this it checks the ColorConversionStrategy or the device ProcessColorModel if
% ColorConversionStrategy is not set.
% This is not 100% reliable. A better solution is for the user to edit this and replace
% the code between the ---8<--- lines with a simple declaration like:
%   /N 3
% where the value of N is the number of components from the profile defined in /ICCProfile above.
% Note, if you don't set ColorConversionStrategy, the output will likely be invalid anyway.
  [{icc_PDFX} <<
% ----------8<--------------8<-------------8<--------------8<----------
  systemdict /ColorConversionStrategy known {
    systemdict /ColorConversionStrategy get cvn dup /Gray eq {
      pop /N 1 false
    }{
      dup /RGB eq {
        (RGB is not a valid ColorConversionStrategy for PDF/X output)=
        /ColorConversionStrategycvx /rangecheck signalerror
      }{
        /CMYK eq {
          /N 4 false
        }{
          (ColorConversionStrategy not a device space, falling back to ProcessColorModel, output may not be valid PDF/X.)=
          true
        } ifelse
      } ifelse
    } ifelse
  } {
    (ColorConversionStrategy not set, falling back to ProcessColorModel, output may not be valid PDF/X.)=
    true
  } ifelse

  {
    currentpagedevice /ProcessColorModel get
    dup /DeviceGray eq {
      pop /N 1
    }{
      dup /DeviceRGB eq {
        (RGB is not a valid ProcessColorModel for PDF/X output)=
        /ColorConversionStrategycvx /rangecheck signalerror
      }{
        dup /DeviceCMYK eq {
          pop /N 4
        } {
          (ProcessColorModel not a device space.)=
          /ProcessColorModel cvx /rangecheck signalerror
        } ifelse
      } ifelse
    } ifelse
  } if
% ----------8<--------------8<-------------8<--------------8<----------
  >> /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 (FOGRA39) % Customize
  /Info (none)                     % Customize
  /OutputConditionIdentifier (ISO Coated v2 (ECI))      % 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

It would also be nice to be able to set the output DPI for the result of the preflight, it's currently fixed to 600.

If you need to make sure that your changes are permanent you can use patch-package. But since this is just working on the transpiled JS version (original is TS), this is only a local solution

[spring-raining]

@cmahnke Thank you for sharing the details! As you suggested, I believe directly running Ghostscript is the best approach for now. While it would be beneficial to implement similar changes in press-ready, but unfortunately, it's difficult to expect updates for press-ready as the maintainers of that project haven't provided any for a long time.

We agree this situation needs improvement, and there's a growing consensus that we should consider discontinuing the official press-ready in favor of a forked version in the future (#651 (comment); apologies, Japanese only). However, this presents significant challenges, such as identifying who would maintain the forked version, making immediate improvement unlikely.