Thoughts regarding executing ghostscript with stderr_to_stdout: true?

[metabren]

Hey team, love the library — thank you so much for putting this out there in the world. It's an invaluable part of my app.

I have a question around the logs / errors generated by ghostscript...

Are there any downsides / risks to using the the stderr_to_stdout: true option here?

I ask because I am constantly getting warnings generated with every PDF generation (using print_to_pdfa). I tried updating ghostscript to 10.03.0 but I'm just getting different warnings now, e.g.:

Detected SMask which must be in DeviceGray, but we are not converting to DeviceGray, reverting to normal PDF output

They can be silenced with stderr_to_stdout: true set, so I was wondering:

1. Is this a safe thing to do? (from the perspective of this library)
2. Do you ave any preference as to how this might be done? Happy to submit a PR.

Thanks again!

[maltoe]

Hi @metabren,

may I ask what gs spits out for you? It's completely silent for us.

stderr_to_stdout would work, sure. But maybe hidden behind a :discard_stderr option akin to the Chrome one, and let it default to false so we don't accidentally break anything?

Alternatively, a ghostscript_args would be more versatile, I guess. Does -q suppress the warnings you see?

[metabren]

Hi @maltoe, thank you for getting back to me! This is the only warning I'm getting now:

Detected SMask which must be in DeviceGray, but we are not converting to DeviceGray, reverting to normal PDF output

I was getting a couple of others, but changed from the default of PDF/A-3b to PDF/A-2b and that stopped a couple of them. I'll change it back in the morning (it's evening here) and report back.

Does -q suppress the warnings you see?

I haven't tried this but can tomorrow. Will report back here.

[metabren]

Hey again @maltoe! Just wanted to report back on my findings.

---

It seems the -q argument is already added so it makes no difference.

Calling print_to_pdfa/3 only with output_file_path, these are produced with gs 10.03.0:

GPL Ghostscript 10.03.0: Can't use Object streams before PDF 1.5, ignoring WriteObjStms directive
GPL Ghostscript 10.03.0: Can't use an XRef stream before PDF 1.5, ignoring WriteXRefStm directive
GPL Ghostscript 10.03.0:
Detected SMask which must be in DeviceGray, but we are not converting to DeviceGray, reverting to normal PDF output

Calling print_to_pdfa/3 with output_file_path and pdfa_version: "2", the result is only:

GPL Ghostscript 10.03.0:
Detected SMask which must be in DeviceGray, but we are not converting to DeviceGray, reverting to normal PDF output

Additionally, I was having a look around some of the other forks, and noticed one of changed the gs compatibility level to 1.7 from 1.4.

I tried this, and it removed the WriteObjStms and WriteXRefStm warnings I was receiving with PDF/A-3b, so back to only this:

GPL Ghostscript 10.03.0:
Detected SMask which must be in DeviceGray, but we are not converting to DeviceGray, reverting to normal PDF output

Finally, if I make sure there are no images or emoji present in the original PDF (that Chrome produces), then the warnings disappear.

---

stderr_to_stdout would work, sure. But maybe hidden behind a :discard_stderr option akin to the Chrome one, and let it default to false so we don't accidentally break anything?

Haha I was hoping that perhaps you'd have a good idea if we were breaking things or not 😅. No worries though, I can investigate this.

Alternatively, a ghostscript_args would be more versatile

I believe something like this would be beneficial (see my earlier example of changing the compatibility level to 1.7). However, there needs to be some thought / care around this. Sending through bad arguments, for example, would break things.

I'll keep digging.

[maltoe]

@metabren the warnings make total sense considering the 1.4 compatibility level, right? :) I remember that we used to need this 1.4 compatibility level as otherwise it wouldn't generate valid PDF/As. Check https://verapdf.org/ for the validator tool.

The other warning you receive also makes me warning if you actually get a PDF/A still ("reverting to normal PDF"). With regards to the rest of this line, PDF/As need to only contain images or text colors in some specific color space DeviceRGB and DeviceGray. It sounds like you may have an image in grayscale but it's not converted. You could play around with the sColorConversionStrategy option, or maybe set the AutoFilterGrayImages option to true.

To be honest, my knowledge of Ghostscript and PDF/A is also somewhat limited. Our set of gs options has been found by lots of trial and error on ghostscript 9.26 or something, so things might have changed.

[maltoe]

looks good without the option #306

[metabren]

Hi @maltoe, thank you for your further investigation.

the warnings make total sense considering the 1.4 compatibility level, right? :) I remember that we used to need this 1.4 compatibility level as otherwise it wouldn't generate valid PDF/As. Check https://verapdf.org/ for the validator tool.

Absolutely! At first I wasn't sure if chrome itself was putting out a < 1.5 PDF, but after making this tweak and seeing the warnings go away it was the logical conclusion.

It sounds like you may have an image in grayscale but it's not converted

Strangely enough, this happens any time I have an emoji in the printed page. If I remove all emojis, and all images, no warning.

You could play around with the sColorConversionStrategy option, or maybe set the AutoFilterGrayImages option to true.

I'll have a go and report back.

looks good without the option #306

That makes sense. According to the latest gs docs, 1.7 is now the default.

I'll let you know how I get on!

[maltoe]

@metabren ℹ️ released v1.16.0 with removed -dCompatibilityLevel=1.4 switch

I'm going to close this for now, hope that's ok. Feel free to open a PR for a discard_stderr: false equivalent for GS.

[metabren]

Hey @maltoe thanks for the update. Apologies for not getting back to you sooner. I actually ran into an issue with PDF generation in later versions of GS (it was "cutting off" the top part of text, but only when displayed in Safari / Preview on macOS) so I reverted back to an earlier version.

I still may open a PR for discard_stderr: false for GS, but I'm also weary of introducing anything that might cause problems. Right now we're just sticking with the messy log files. Thank you!