Created attachment 18102 [details] cardinal.pdf Ghostscript 9.28rc1 and rc2 report "Recursive XObjects" on multiple-referenced images when interpreting some PDFs. This test file demonstrates both issues. https://github.com/jbarlow83/OCRmyPDF/raw/master/tests/resources/cardinal.pdf A command such as will display the error messages ``` $ gs -q -sDEVICE=pngmono -o _%d.png cardinal.pdf **** Error reading a content stream. The page may be incomplete. Output may be incorrect. **** Error: File did not complete the page properly and may be damaged. Output may be incorrect. **** Error: Recursive XObject detected, ignoring "Im0", object number 14 Output may be incorrect. **** Error: Recursive XObject detected, ignoring "Im0", object number 14 Output may be incorrect. **** Error: Recursive XObject detected, ignoring "Im0", object number 14 Output may be incorrect. ``` The output is blank regardless of DEVICE used. The file contains four copies of the same page rotated in each direction, all of which have an image named /Im0 that is object number 14. Using Ghostscript 9.28, all four output pages will be blank. With Ghostscript 9.27, all pages rendered correctly. Acrobat, qpdf, Ghostscript 9.27 and verapdf all report no syntax or other issues. The issue was found on Debian sid using ghostscript 9.28~~rc2~dfsg-1.
Created attachment 18103 [details] skew.pdf
Another file that produces similar behavior is the attached skew.pdf. This file does not report recursive XObjects, but does claim an error in the content stream, and also works with previous versions of Ghostscript. gs -q -sDEVICE=pdfwrite -o _.pdf skew.pdf **** Error reading a content stream. The page may be incomplete. Output may be incorrect. **** Error: File did not complete the page properly and may be damaged. Output may be incorrect.
(In reply to James R Barlow from comment #0) > Ghostscript 9.28rc1 and rc2 report "Recursive XObjects" on > multiple-referenced images when interpreting some PDFs. > > This test file demonstrates both issues. > The file contains four copies of the same page rotated in each direction, > all of which have an image named /Im0 that is object number 14. Using > Ghostscript 9.28, all four output pages will be blank. With Ghostscript > 9.27, all pages rendered correctly. Acrobat, qpdf, Ghostscript 9.27 and > verapdf all report no syntax or other issues. > > The issue was found on Debian sid using ghostscript 9.28~~rc2~dfsg-1. I've tried this using executables built from the current HEAD and the code in the 9.28 release candidate 2, on both Windows and Linux (Ubuntu 18) and I'm unable to reproduce either problem (cardinal.pdf or skew.pdf). Did you build Ghostscript yourself, from the source in the RC2 archive ? I suspect (from the filename) that you did not, but picked this up from Debian, where it has (presumably) been built by the package maintainer but it would be good if you could confirm that. I'm going to reassign this oen to Chris to take it up with the Debian package maintainer, its possible that they maintainer has added some other patches and that's causing a problem. Certainly I can't reproduce either of these with the RC2 code or the current HEAD.
Jonas, Neither Ken nor I can reproduce this problem with our release candidate (RC2). Would you mind trying it out with your packaged version, please? Thanks, Chris
I can confirm that the error occur on Debian unstable using ghostscript officially built for Debian. You asked which build the original bugreporter use, but that was already clarified initially: The version number mentioned imply that it is the official Debian build.
(In reply to Jonas Smedegaard from comment #5) > I can confirm that the error occur on Debian unstable using ghostscript > officially built for Debian. > > You asked which build the original bugreporter use, but that was already > clarified initially: The version number mentioned imply that it is the > official Debian build. Hmm, that's strange. Are there any patches being applied to the Postscript resource/initialisation files (Resource/Init/*) for the packaging? I didn't see any, but I could be mistaken.
All patches applied are here: https://salsa.debian.org/printing-team/ghostscript/tree/debian/9.28__rc2_dfsg-1/debian/patches I agree, there are no patches touching Resource/Init/* Full build log (for amd64) is here: https://buildd.debian.org/status/fetch.php?pkg=ghostscript&arch=amd64&ver=9.28%7E%7Erc2%7Edfsg-1&stamp=1567789611&raw=0
The files contain JBIG2 images. I would guess that either jbig2dec isn't up to date, or it's an issue we've found and fixed since the last jbig2dec release (there will be a jbig2dec release with the 9.28 gs release).
I can make a snapshot of jbig2dec while waiting for your issuing a new formal release. I'll report back here when done, to tell if that helped. Anything else you can imagine might help?
(In reply to Jonas Smedegaard from comment #9) > I can make a snapshot of jbig2dec while waiting for your issuing a new > formal release. > > I'll report back here when done, to tell if that helped. > > Anything else you can imagine might help? At this point, jbig2dec is really the only thing I can think of.... I'm kind of mired in other things at the moment, or I'd test more myself.
Hmm - latest Debian build of ghostscript accidentally does not link with ibjbig2dec at all: > configure: WARNING: disabling support for JBIG2 files Sure that's an error on my part, but I guess it should be dealt with in ghostscript more gracefully than reported here (if indeed this issue is caused by total *lack* of jbig2dec support. ...that also means there's maybe a way for you guys to reproduce: Try explicitly disable support for jbig2dec and see if things start exploding ;-)
(In reply to Jonas Smedegaard from comment #11) > Hmm - latest Debian build of ghostscript accidentally does not link with > ibjbig2dec at all: > > > configure: WARNING: disabling support for JBIG2 files > > Sure that's an error on my part, but I guess it should be dealt with in > ghostscript more gracefully than reported here (if indeed this issue is > caused by total *lack* of jbig2dec support. Well, except that when I made missing a jbig2 decoder a fatal configuration error, I got bitter complaints from somebody or other. Personally, I think we should make it a fatal error, and be done with it. > ...that also means there's maybe a way for you guys to reproduce: Try > explicitly disable support for jbig2dec and see if things start exploding ;-) I can say with some confidence that it would cause the symptoms described above.
(In reply to Jonas Smedegaard from comment #11) > Hmm - latest Debian build of ghostscript accidentally does not link with > ibjbig2dec at all: > > > configure: WARNING: disabling support for JBIG2 files > > Sure that's an error on my part, but I guess it should be dealt with in > ghostscript more gracefully than reported here (if indeed this issue is > caused by total *lack* of jbig2dec support. I'm not sure how we could deal with this 'more gracefully'. We don't have a complete transcript of the back channel, so I cannot say for sure what messages exactly we are producing, but Ghostscript is clearly complaining about 'something'. If JBIG2 support has been disabled then we won't be able to decode a JBIG2 image in a PDF file. The default for the PDF interpreter is to continue when errors occur, though we do warn the user of a problem, and that is clearly happening. We don't crash, we do tell the user there's a problem, that feels reasonably graceful to me.
The error messages shared by the original poster was all output I received when running same commands. What I mean by "more gracefully" is that _if_ ghostscript supports building without JBIG" decoding support (as evidently is the case currently), then in my opinion it should emit more informative errors than ones about page being damaged. Also, I would expect from an autotools-based project that when explicitly stating "--with-jbig2dec" and that explicit request cannot be satisfied then ./configure should fail. All that said, I am not against changing to have linking with JBIG2 be mandatory.
(In reply to Jonas Smedegaard from comment #14) > The error messages shared by the original poster was all output I received > when running same commands. > > What I mean by "more gracefully" is that _if_ ghostscript supports building > without JBIG" decoding support (as evidently is the case currently), then in > my opinion it should emit more informative errors than ones about page being > damaged. That's not really possible as long as the interpreter is built on PostScript. All we know is that an error occured, which we trap and ignore. If you run with -dPDFSTOPONERROR and potentially with -dPDFDEBUG then much more information would be available, far beyind anything which an ordinary user woulc understand. I stand by my statement that this *is* a graceful handling of the error, under the given conditions (ie not running with PDFSTOPONERROR).
I'm going to propose we make configure fail if a jbig2 decoder is missing, *unless* explicitly called with --without-jbig2dec - then anyone daft enough to want that can still have it, but everyone will know they're getting a compliant PDF consumer.
Fair enough - I won't argue more what is or is not sensible runtime behavior of ghostscript. As for build-time, I recommend to follow the GNU documentation for the logic of detecting/enabling at https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/External-Software.html I.e. it seems you talk about tightening to the pattern in 3rd example. That's good. Alternatively a milder change would be to follow the 1st example which still enables by default (because by default ghostscript ships with an embedded copy of libjbig2dec) and it would loudly detect the error I made (because I did *not* rely on auto-detection but specified explicitly that I wanted linking enabled, which I expected would cause failure to build if unsatisfiable).
This is was indeed that the builds of ghostscript used by original reporter (Debian releases 9.28~~rc1~dfsg-1 and 9.28~~rc2~dfsg-1) is not linked with libjibg2dec: Running same commands with 9.28~~rc2~dfsg-2 - released to Debian unstable last night - succeeds to generate png images with no errors emitted. The underlying cause for Debian builds of Ghostscript not linking with libjbig2dec was git commit 08b91a2 changing behavior of configure.ac to no longer do traditional presence checking if the pkg-config tool is in $PATH of the build host. Arguably this is properly documented in commit message, but it can also be (mis)read as gracefully falling back to conventional checking when pkg-config _file_ is not found, which is common behaviour. This behaviour change affects only derived versions of Ghostscript where the embedded convenience code copy of libjbig2dec was removed - as is the case on Debian systems: Ghostscript as maintained in git and as released tarballs includes a copy of libjbig2dec which containts the expected pkg-config file, so the "traditional presence checking" (reached only when pkg-config _tool_ is unavailable) succeeds. In other words: This is a bug not in Ghostscript but in Debian redistribution of Ghostscript, caused by a change in Ghostscript which is argually not a bug. Hence closing this issue as INVALID.
> I.e. it seems you talk about tightening to the pattern in 3rd example. That's good. Yes, having Ghostscript's configure have a fatal error when both the jbig2dec library is missing and --without-jbig2dec is not explicitly specified sounds reasonable to me. > This behaviour change affects only derived versions of Ghostscript where the > embedded convenience code copy of libjbig2dec was removed - as is the case > on Debian systems: Ghostscript as maintained in git and as released tarballs > includes a copy of libjbig2dec which contains the expected pkg-config file, > so the "traditional presence checking" (reached only when pkg-config _tool_ > is unavailable) succeeds. Was jbig2dec's .pc-file[1] forgotten when it was packaged[2]? If it was by mistake, do you mind adding it to the package? If there's some issue that prevents it from being packaged, please report it in a new bug and I'll try to sort that out. [1] https://salsa.debian.org/printing-team/jbig2dec/blob/master/jbig2dec.pc.in [2] http://ftp.se.debian.org/debian/pool/main/j/jbig2dec/libjbig2dec0_0.16+20190905-2_amd64.deb
> Was jbig2dec's .pc-file[1] forgotten when it was packaged[2]? Yes. > If it was by mistake, do you mind adding it to the package? Already done: https://salsa.debian.org/printing-team/jbig2dec/commit/e36dae4 > If there's some issue that prevents it from being packaged, > please report it in a new bug and I'll try to sort that out. Thanks, but no need - this was a simple mistake on my part :-)
For the record, I just committed the change (mentioned above) to make a missing jbig2 decoder a fatal error for configure, unless specifically called with --without-jbig2dec: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=071b96290c5