1

My goal is to take arbitrary PDF from the users, and save it as PDF/A-2b.

The current approach is to use Ghostscript 9.21 (via ghost4j) to create the converted file. This works but not without some problems. I got it to work with two different sets of parameters to Ghostscript.

Firstly

Using the option -dUseCIEColor as shown below will work, and produces valid PDF/A-2b with a couple of different test files. This will however print pages of errors into the log saying it is not recommended to use.

These are the full arguments:

-dBATCH
-dNOPAUSE
-dPrinted=true
-sDEVICE=pdfwrite
-dPDFACompatibilityPolicy=1
-sColorConversionStrategy=/UseDeviceIndependentColor
-sProcessColorModel=DeviceCMYK
-sOutputICCProfile=/tmp/icc.icc
-sOutputFile=/tmp/result.pdf
-dPDFA=2
-dUseCIEColor
/tmp/PDFA_def.ps
/tmp/test.pdf

And the PDFA_def.ps is the default supplier 9.21, pointing to the same ICC Profile and this line in the bottom:

<</NeverEmbed []>> setdistillerparams

The ICC Profile is a random (CMYK) profile published by Adobe.

This works, apart from the errors in the log.

Secondly

Then I will try to do as the log errors told, and remove the -dUseCIEColor.

Now some of the test files work, some wont. I suspect this has to do with the color profile of the original PDF, or something like that.

3-heights gives the validation error: A device-specific color space (DeviceRGB) without an appropriate output intent is used.

This can be corrected by switching the -sProcessColorModel=DeviceRGB and switch the ICC Profile to an random RGB profile.

Then for another document, you get the error: A device-specific color space (DeviceCMYK) without an appropriate output intent is used.

Is there something I'm missing with this? It would seem I need to switch the options based on the original PDF file which would be far from the preferred style. If it helps, I would be fine with black and white PDF/A-2b too. Thanks!

kallehj
  • 302
  • 1
  • 9

2 Answers2

1

Its impossible to say what the problems are without seeing the files. UseCIEColor is an awful PostScript hack to try and do colour management, it isn't reliable (in terms of colour) and will effectively defeat any real colour management. Clearly you aren't performing colour management since you are using a random profile, but all the same....

Since you don't really care about colour management, I would suggest that instead of UseDeviceIndependentColor, you select CMYK (as that's the ProcessColorModel you are using). Note that if you select ColorConversionStrategy=/CMYK then you don't need to set ProcessColorModel, that's assumed from the conversion.

Other than that, I'd have to suggest that you open a bug report. If people don't report problems then they won't get fixed....

KenS
  • 30,202
  • 3
  • 34
  • 51
  • Thanks for the reply. Omitting sProcessColorModel will cause another validation error: "The value of the key N is 3 but must be 4.", even with dUseCIEColor. Without it, you get both that and the previous error. I'll check a bug report off the clock, for now I suppose we'll go with the dUseCIEColor. – kallehj Jun 01 '17 at 09:52
  • Did you change the ColorConversionStrategy to /CMYK ? Because that sets the ProcessColorModel. It sounds like you've got ICC profiles in there which have not been converted to device space. That 'shouldn't happen if you set ColorConversionStrategy to something other than UseDeviceIndepenedentColor, but might well do if you don't. TO be honest, I'd really need to see an example file to help. – KenS Jun 01 '17 at 13:43
0

The correct PDF/A-compatible replacement for UseCIEColor seems to be in combination of these 2 options:

 -sProcessColorModel=DeviceCMYK
 -sColorConversionStrategy=UseDeviceIndependentColor

Both DeviceCMYK and DeviceRGB work for me.

exa
  • 859
  • 7
  • 27