(In reply to Christopher from comment #0)

> using GhostScript 9.14/9.15

Which ? 9.14 or 9.15 ? If you are using 9.15 there's little point in reporting 9.14. Oh, and if you are using 9.14 my first reply will be 'try 9.15' :-)


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

Why are you setting OutputICCProfile ? I think you do not want to do that in this case.


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

Various tools are better/worse at detecting validation problems, at least one (no I cannot remember which) has been seen to give false negatives on valid PDF/A files in the past.


> So, what's the problem?

As you haven't supplied a specimen file, I can't say, I can't even say if there *is* a problem.


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

Both PDF/A conversion and the conversion into specific device spaces are known to work. Possibly you have found a case which doesn't and that would be a bug, but without seeing the file I can't tell.

Created attachment 11321 [details]
input PS-file

Created attachment 11322 [details]
PDFA_defRGB

Created attachment 11323 [details]
PDFA_defCMYK

(In reply to Ken Sharp from comment #1)
> (In reply to Christopher from comment #0)
> 
> > using GhostScript 9.14/9.15
> 
> Which ? 9.14 or 9.15 ? If you are using 9.15 there's little point in
> reporting 9.14. Oh, and if you are using 9.14 my first reply will be 'try
> 9.15' :-)

Sorry :-). I meant to say that I tried both versions. But the version used in my company is 9.14. 9.15 was only for test purpose. 


> 
> >     "gswin64.exe" -dPDFA=1 -dBATCH -dNOPAUSE -dNOOUTERSAVE
> >     -sColorConversionStrategy=/RGB -sOutputICCProfile=AdobeRGB1998.icc
> > -sDEVICE=pdfwrite 
> >     -sOutputFile=output.pdf -dPDFACompatibilityPolicy=2  "PDFA_defRGB.ps"
> > input.ps
> 
> Why are you setting OutputICCProfile ? I think you do not want to do that in
> this case.

Referring to the ghostscript documentation (http://www.ghostscript.com/doc/9.14/Ps2pdf.htm#PDFA) I set the ICCProfile - and I had the impression, that I have to set it. Do I not have to set it?


> > 
> > So, what's the problem?
> 
> As you haven't supplied a specimen file, I can't say, I can't even say if
> there *is* a problem.
> 

Sorry! I just uploaded the files.

Created attachment 11324 [details]
CMYK icc

Created attachment 11325 [details]
RGB icc

There is a special case for handling PDF/A-1, because we could not guarantee that an ICC profile was a version 2 profile, and PDF/A-1 does not permit higher version profiles to be embedded. This case caused us to use the 'old' colour management system (equivalent to -dPDFUseOldCMS).

Unfortunately, I missed this when converting to the new system, and so the special case code remained in place, forcing the use of the old code. The old code did not set ProcessColorModel from the ColorConversionStrategy, unlike the new code, and also uses the ProcessColorModel to mange the colours.

So, in order to create PDF/A-1 files you will need to also set ProcessColorModel appropriately for now.

Or, download the latest source code and rebuild it with this commit:

abcaeaace08efa5d1596ef6a50f3d809d0b07a4a

Which I believe will fix this problem (by using the new colour management code).

I still don't believe its necessary (or useful) to set OutputICCProfile when creating a PDF/A file, if I get time I'll try and check that.

> Unfortunately, I missed this when converting to the new system, and so the
> special case code remained in place, forcing the use of the old code. The
> old code did not set ProcessColorModel from the ColorConversionStrategy,
> unlike the new code, and also uses the ProcessColorModel to mange the
> colours.

Aha! Thank you a lot! I started a new try calling ghostscript:

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

Though ProcessColorModel has been set, the PDF/A is still not valid. PDF-tools.com displays an error message:

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.

So what now? I found the parameter -dUseCIEColor and gave it a try, though you strongly discourage using it (http://stackoverflow.com/questions/26040997/convert-pdf-files-to-pdf-a-via-ghostscript/26970051#26970051).

So my ghostscript command is now like that:

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

And it works! Java's PDFBox and pdf-tools.com both assert that I do have a valid PDF/A. It's only one file so far I have tested the -dUseCIEColor setting with, but I will try some more right now.

So is it bad indeed to use that parameter? It is the only one that worked till now and I have been facing the pdf/a-ghostscript-issue for several days now - having the first real success right now.

> 
> So, in order to create PDF/A-1 files you will need to also set
> ProcessColorModel appropriately for now.

As said above, it unfortunately doesn't work. 

> 
> Or, download the latest source code and rebuild it with this commit:
> 
> abcaeaace08efa5d1596ef6a50f3d809d0b07a4a
> 
> Which I believe will fix this problem (by using the new colour management
> code).

Thank you. I would do so, but for company reasons it's not that easy just to set a new software version that is not even officially deployed.

> 
> I still don't believe its necessary (or useful) to set OutputICCProfile when
> creating a PDF/A file, if I get time I'll try and check that.

As you can see I now omit setting the OutputICCProfile.

Looking forward to your answer.

(In reply to Christopher from comment #9)

> Though ProcessColorModel has been set, the PDF/A is still not valid.
> PDF-tools.com displays an error message:
> 
> 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.

Well, it worked for me using the latest code (before my commit) but it seems it doesn't work with the 9.14 release. I'd suggest you upgrade to the latest source.

BTW why do you set -dNOOUTERSAVE ?

> So is it bad indeed to use that parameter?

Yes its an ancient piece of PostScript hackery from the days before decent colour management. Its slow (because all colours are first converted into a CIEBased colour space, then into an ICCBased space, then into a final device space. Its also pretty much guaranteed to mess up some colours, and you won't be able to take advantage of many of the new features, such as preserving separation colours while converting their alternate space if required.

(In reply to Ken Sharp from comment #10)

> Well, it worked for me using the latest code (before my commit) but it seems
> it doesn't work with the 9.14 release. I'd suggest you upgrade to the latest
> source.

I will take some tries with 9.15. Building from your commit unfortunately won't work for me because we got too many systems it has to run stable with and I will not be able to convince my colleagues to apply a not officially released version of Ghostscript for professional use - no offense. Ghostscript has done a really good job for us so far and will so in future! :-)

> 
> BTW why do you set -dNOOUTERSAVE ?

I admit, I don't know. I just adopted it from the suggested example command line in the online Ghostscript documentation (section 9, Creating PDF/A).

> 
> > So is it bad indeed to use that parameter?
> 
> Yes its an ancient piece of PostScript hackery from the days before decent
> colour management. Its slow (because all colours are first converted into a
> CIEBased colour space, then into an ICCBased space, then into a final device
> space. Its also pretty much guaranteed to mess up some colours, and you
> won't be able to take advantage of many of the new features, such as
> preserving separation colours while converting their alternate space if
> required.

That's a pity! Performance is not the problem at this moment, but if it will probably mess up colours - uh! That doesn't sound too good. But it's so enticing to use, because it's the first pdf/a-creation that worked :-).

(In reply to Christopher from comment #11)

> > BTW why do you set -dNOOUTERSAVE ?
> 
> I admit, I don't know. I just adopted it from the suggested example command
> line in the online Ghostscript documentation (section 9, Creating PDF/A).

I definitely wouldn't do that, and I'll amend the documentation to remove that from the example.


> That's a pity! Performance is not the problem at this moment, but if it will
> probably mess up colours - uh! That doesn't sound too good. But it's so
> enticing to use, because it's the first pdf/a-creation that worked :-).

Requiring -dUseCIEColor is a consequence of using the old CMS, and its one of the reasons we would rather people didn't continue to use the old CMS.

I tried following command with Ghostscript 9.15:

"gswin64.exe" -dPDFA=1 -dBATCH -dNOPAUSE  -sColorConversionStrategy=/XXX -sProcessColorModel=DeviceXXX -sDEVICE=pdfwrite -sOutputFile=output.pdf -dPDFACompatibilityPolicy=2  "PDFA_defXXX.ps" input.ps

XXX stands for RGB or CMYK. If the input.ps has the same color space as set in the parameters -sColorConversionStrategy and -sProcessColorModel, the output.pdf is fine! A valid PDF/A results. That is an improvement to 9.14.

In case it is not, I get that error message (from pdf-tools.com; converting from CMYK-ps to RGB-pdf:

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.

So if there would be any possibility to be independent from the color space of the input file, everything would be fine and I could integrate Ghostscript into the workflow of our software. Setting -sColorConversionStrategy=/UseDeviceIndependentColor will not succeed, by the way.

Looking forward to further ideas!

(In reply to Christopher from comment #13)

> Looking forward to further ideas!

To the best of my knowledge, this is fixed in current source code.

(In reply to Ken Sharp from comment #14)

> To the best of my knowledge, this is fixed in current source code.

Thanks. "Current source code" means the current code you are working with, not an official, already built release?

(In reply to Christopher from comment #15)
> (In reply to Ken Sharp from comment #14)
> 
> > To the best of my knowledge, this is fixed in current source code.
> 
> Thanks. "Current source code" means the current code you are working with,
> not an official, already built release?

What's in the Git repository.

We are an open-source company, the 'releases' are simply a convenience for users where we build binaries. There is no great difference between what's in the repository and a release, except that we try not to make 'risky' (ie higher probability of introducing problems) commits in the 2 weeks or so leading up to a release.

Oh, and we make sure that all our tests are run on the release code, some of our tests only run weekly so a given commit might take up to a week to run through all our tests. Its very rare to find a problem there though.

(In reply to Ken Sharp from comment #16)
> (In reply to Christopher from comment #15)
> > (In reply to Ken Sharp from comment #14)
> > 
> > > To the best of my knowledge, this is fixed in current source code.
> > 
> > Thanks. "Current source code" means the current code you are working with,
> > not an official, already built release?
> 
> What's in the Git repository.
> 
> We are an open-source company, the 'releases' are simply a convenience for
> users where we build binaries. There is no great difference between what's
> in the repository and a release, except that we try not to make 'risky' (ie
> higher probability of introducing problems) commits in the 2 weeks or so
> leading up to a release.
> 
> Oh, and we make sure that all our tests are run on the release code, some of
> our tests only run weekly so a given commit might take up to a week to run
> through all our tests. Its very rare to find a problem there though.

Thank you again for your quick and kind support. Of course I know that it is open source and I really am fond of your work! Nevertheless I do not have the possibility to compile and build a Ghostscript right here, so I will have to wait for your team to build new binaries including the fixes you are talking about. Then I will give them a next try. I will have an eye in the Ghostscript-website for being updated :-). So long and thanks again for your efforts!