Convert PS files to PDF/A via Ghostscript, color space problems

Question

I am faced with a quite similar issue as discussed in this thread. Using GhostScript 9.14 I am trying to create a valid PDF/A from a Postscript file. I am invoking following command:

"gswin64.exe" -dPDFA=1 -dBATCH -dNOPAUSE -dNOOUTERSAVE
-sColorConversionStrategy=/RGB -sOutputICCProfile=AdobeRGB1998.icc -sDEVICE=pdfwrite 
-sOutputFile=output.pdf -dPDFACompatibilityPolicy=2  "PDFA_defRGB.ps" input.ps

After doing so I validate via Apache's PDFBox and online via www.pdf-tools.com. PDF-tools tells me that:

Validating file "output.pdf" for conformance level pdfa-1b
A device-specific color space (DeviceCMYK) without an appropriate output intent is used.
The document does not conform to the requested standard.
The document contains device-specific color spaces.

If I use -sColorConversionStrategy=/CMYK and an appropriate CMYK-.icc.file and PDFA_def the validations fails, too. Here you go:

Validating file "output.pdf" for conformance level pdfa-1b
The value of the key N is 3 but must be 4.
A device-specific color space (DeviceCMYK) without an appropriate output intent is used.
The document does not conform to the requested standard.
The document doesn't conform to the PDF reference (missing required entries, wrong value    
types, etc.).
The document contains device-specific color spaces.

Java PDFBox validation returns true surprisingly (PDF/A is valid).

If I use -sColorConversionStrategy=/UseDeviceIndependentColor instead of /CMYK, online validation fails with the result as above. PDFBox returns a valid file again. If I use -sColorConversionStrategy=/UseDeviceIndependentColor with RGB-settings as shown on top, online validation fails identical to the first error message:

Validating file "output.pdf" for conformance level pdfa-1b
A device-specific color space (DeviceCMYK) without an appropriate output intent is used.
The document does not conform to the requested standard.
The document contains device-specific color spaces.

PDFBox validation fails as well.

When using -sProcessColorModel=DeviceCMYK instead of -sColorConversionStrategy the online validation and PDFBox both detect a valid PDF/A.

output.pdf validated successfully.
Status Information
output.pdf (pdfa-1b)

So, what's the problem? As I understand the GhostScript command, -sColorConversionStrategy should ensure converting the color space of the input-PS into the desired color space of the output-PDF - without knowing what color space the input file has. Apparently that is not possible for I also tested a ps-file with obvious color space CMYK with same results as posted above.

I need to call GhostScript from Java code getting unknown ps-files as input converting them into valid PDF/A-files. So is there any possibility to use GhostScript doing that with the only guarantee that the input file format will be Postscript?

Thank you for any help,

Christopher

Answer 1

The validation is not a problem of PDFBox. As I discussed on the bug-website from GhostScript (see http://bugs.ghostscript.com/show_bug.cgi?id=695686#c10) the problem I described in my first post should be solved with the newest code of Ghostscript (not the 9.15 version, btw).

I solved the issue with a dirty piece of GS-parameter called -dUseCIEColor instead. So I invoke GS this way:

"gswin64.exe" -dPDFA=1 -dBATCH -dNOPAUSE -dNOOUTERSAVE 
-sColorConversionStrategy=/RGB -dUseCIEColor -sDEVICE=pdfwrite 
-sOutputFile=output.pdf -dPDFACompatibilityPolicy=2  "PDFA_defRGB.ps" input.ps

Though Ken Sharp discourages the use of that parameter, I will use it henceforth. I am not able to compile the latest version of GS for my company, only ready-to-use versions are permitted. Calling GS with -dUseCIEColor produces valid PDFAs (Java PDFBox and www.pdf-tools.com).