I reported this bug in Debian's bug tracker but the Debian package maintainer apparently didn't forward it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941864 I debugged it and found the root cause is the final EOD appended to RLE compressed data. It causes my printer to print this error message: PCL6 ERROR - sb_count != -128 POSITION : 0xbc8 (3016) SYSTEM : XLPGP/xl_pattern LINE : 890 VERSION : PCL6 3.34 05-01-2004 Someone else reported in Debian's bug tracker the same issue applies to C2550 (Canon imageRunner iRC2380i): PCL XL Error Subsystem: IMAGE Error: ExtraData Operator: ReadImage Position: 876 I was able to work around it with this change: --- ghostscript-9.28~~rc4~dfsg.orig/base/srle.c +++ ghostscript-9.28~~rc4~dfsg/base/srle.c @@ -329,11 +329,13 @@ run_len_0_n0_read: *++q = n0; } case state_eod_unmarked: +#if 0 if (wlimit - q < 1) { ss->state = state_eod_unmarked; goto no_output_room; } *++q = 128; /* EOD */ +#endif case state_eod: ss->run_len = 0; ss->state = state_0; The same issue still applies to ghostscript-9.50.
(In reply to js from comment #0) > I reported this bug in Debian's bug tracker but the Debian > package maintainer apparently didn't forward it. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941864 You haven't given us an example file or command line to reproduce the problem, which makes it difficult to investigate. Could you supply an example please so we can look into this?
Assigning to Robin, in anticipation of example file and command line, since he was probably last to change this code.
Printing any document will reproduce the issue, as long as the generated PCL/XL has RLE encoded data. FWIW, I was able to reproduce it by printing the CUPS Test Page: https://salsa.debian.org/printing-team/cups-filters/blob/debian/master/data/default-testpage.pdf The test command is in the Debian bug report: gs -sDEVICE=pxlmono -sOutputFile=t.raw -r300x300 foo.pdf I used ghostpdl/pcl/tools/pxldis.py to make it readable. FWIW I assume it is a printer firmware bug since the PCL XL spec says in Appendix Q Compression Methods: "A control byte of -128 is ignored and is not included in the decompressed data."
(In reply to js from comment #3) > Printing any document will reproduce the issue, as long as the > generated PCL/XL has RLE encoded data. FWIW, I was able > to reproduce it by printing the CUPS Test Page: > > https://salsa.debian.org/printing-team/cups-filters/blob/debian/master/data/ > default-testpage.pdf > > The test command is in the Debian bug report: > gs -sDEVICE=pxlmono -sOutputFile=t.raw -r300x300 foo.pdf We really want to have the command line and the specimen file in *our* bug tracker, not someone else's, or a URL to someone else's site. It may seem picky but that way we can always reproduce problems in the future, which can be extremely helpful in understanding why changes were made in the past. We've had examples where people didn't supply us with this information and that has caused us problems years later, because the page or file the URL points to has gone, which means we lose a lot of context. > FWIW I assume it is a printer firmware bug since the > PCL XL spec says in Appendix Q Compression Methods: > "A control byte of -128 is ignored and is not included > in the decompressed data." Yes but..... Because PXL only uses RLE compressed data for images, it is possible for the interpreter to detect when sufficient data has been decompressed to satisfy the image. At that point the EOD has not been read. The PXL specification, unlike hte PostScript specification, isn't clear about whether the EOD is required to terminate the RLE data. For PostScript it is required, but arguably for PXL it isn't, and that seems to be what your Samsung is doing, its regarding the EOD as occuring outside the compressed data. We can't use your proposed fix, because that will break other things I'm afraid.
It's not a proposed fix, it's a workaround, as stated in my initial bug report. It proves that this EOD is the root cause of the issue. I don't have the full knowledge of ghostscript, the development of the real bug fix is left to you. I think now you have all information required to do it? I'm not sure if you have a printer which can reproduce the problem, however in pxldis.py output you can see if the EOD is there or not. If you have a patch I can also offer to test it using my printer. Thanks!
(In reply to js from comment #5) > It's not a proposed fix, it's a workaround, as stated in my > initial bug report. It proves that this EOD is the > root cause of the issue. Indeed, and it's much appreciated. > I don't have the full knowledge of ghostscript, the development > of the real bug fix is left to you. I think now you have > all information required to do it? > > I'm not sure if you have a printer which can reproduce the > problem, however in pxldis.py output you can see if the > EOD is there or not. If you have a patch I can also offer > to test it using my printer. I have a patch in testing now. It would be really helpful, as Ken says, to have the example data attached here, please, without us having to go grubbing around in a different bug database for it, so it doesn't get lost in future. I'll post when I have something I'm ready to share.
Created attachment 18652 [details] CUPS testpage Attaching the CUPS testpage, I'm assuming it's what you meant by "have the example data attached here".
(In reply to js from comment #7) > Created attachment 18652 [details] > CUPS testpage > > Attaching the CUPS testpage, I'm assuming it's what you > meant by "have the example data attached here". Well, I would have thought so, but it seems not. If I run: gs -sDEVICE=pxlmono -sOutputFile=raw -r300 default-testpage.pdf in the debugger, the breakpoint on the code you have #if 0'd out is never hit. As such, my changes make no difference to the output.
My proposed patch is here: https://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=7f3aba18318d39098d02b2411da0f411930113e3
As it turns out I quoted the test command inaccurately, RLE compression doesn't seem to be used when printing at 300dpi. This works: gs -sDEVICE=pxlmono -sOutputFile=raw -r600 default-testpage.pdf I tested your patch on top of 9.50 (Debian package source), it works. (I printed the CUPS test page to confirm, also checked the "raw" file using pxldis.py.) Thanks!
Thanks for the report, and for checking! Fixed in: commit b772aaf901a3cd37baf5c06eb141c689829bf673 Author: Robin Watts <Robin.Watts@artifex.com> Date: Tue Nov 26 14:35:05 2019 +0000 Bug 701949: Add 'omitEOD' flag to RLE compressor and use for PXL. It turns out that some printers (Samsung ML-2250 and Canon ImageRunner iRC2380i at least) object to the EOD byte appearing in RLE data in PXL streams. Ken kindly checked the PXL spec for me, and found that: "The PXL spec does say a control code of -128 is ignored and not included in the decompressed data and the byte following a control byte of 128 (I assume they mean -128 here) is treated as the next control byte. And PCL only uses RLE data for images, so they do know how much data they expect." Thus, the conclusion we reached is that PCL/PXL don't need (indeed, really does not want) the EOD byte. The Postscript spec clearly defines the EOD byte though. Rather than break the streams for postscript, we introduce a flag 'omitEOD' that can be set for the encoder when we want to produce a stream for use with PCL/PXL.
(In reply to js from comment #10) > As it turns out I quoted the test command inaccurately, RLE > compression doesn't seem to be used when printing at 300dpi. > This works: ... RLE is the default for pxlmono/pxlcolor, so it is, AFAIK, always used, if there is any figures or graphics at all (inclusive of large texts / glyphs ), as is the case in the CUPS test page with the logos, etc. The driver would also check that RLE does give any benefit at all, so the only possibility as far as I can see, is that a figure is so small, noisy, and unusual, that RLE-compression actually expands - that's very rare. What's possible is that at some resolution, the EOD bug isn't triggered. That's dependent on both resolution, the original paper size (from the input file), the default paper size (a site/build-wise gs compilation setting), and small rasterization changes and alignments between gs versions. Hence both the input pdf, and the actual output ( "... -o output-file -sDEVICE=pxlmono ... " ) is useful.