Created attachment 9308 [details] CUPS debug log Printer: KonicaMinolta Bizhub C280 OS: Arch Linux Ghostscript versions tried: 9:06, 9.07 Printing any PDF crashes the printer, requiring a power cycle to make it work again. Reported to CUPS bug tracker and they sent me here.
Sorry for the typo there, should have been "Ghostscript versions tried: 9.06, 9.07"
cups debug stuff is no use to us. This really needs assessed, and debugged by the cups people so they can forward a sensible Ghostscript bug report to us. I'm sorry, I'm not playing "bug ping-pong", but we don't know enough about cups to work on diagnosing the problem. I've reassigned this to Till, maybe he can work through the stuff we did on Ubuntu's cups to get various (BROKEN!) printers to work correctly.
The CUPS guys are no help, to be honest. They close the bugs I've opened, killing further discussion. Is there anything you can have me do to help troubleshoot?
The following items are necessary to attempt to solve the problem: 1. Original PS or PDF file that was printed. 2. PS file generated by Ghostscript ps2write device. 3. Access to the printer or your commitment to assist with running dozens of test files.
Created attachment 9309 [details] Original PDF
Created attachment 9310 [details] PostScript from GS 9.05
Created attachment 9311 [details] PostScript from GS 9.07
I've attached the original PDF, along with PostScript files generated using Ghostscript 9.05 (works) and 9.07 (crashes printer). I'll be heading to SCaLE tomorrow, I will be back on Tuesday to run any further tests you require. Otherwise, I will be in the office today until approx. 7pm Central Time (0100 UTC).
As I said, we've been through this for quite a few printers already, and since many Postscript interpreters in printers share a common heritage, we often see the same quirks across several models/manufacturers. This type of debugging is a lengthy process, so I would very much rather avoid going through it only to find a problem that's already known. Is there any chance you could install the latest Ubuntu (maybe in a VM) and try that? The issue you describe does sound similar to a couple we've fixed in Ubuntu.
The most significant differences between those two PS files are that the older gs forgets to add BeginResource comments and: @@ -2839,5 +2849,5 @@ 5 0 obj <</Filter[/ASCII85Decode -/LZWDecode]/Length 25608>>stream +/LZWDecode]/Length 26669>>stream J/grZ!H?$`#D,6r&9A_r'a,KcL2\kh6uNbZ%H,2L4?b8.N")NO#ge+_B*A^`d'9h%C,m(=a!(P_ cs[;!N.tg#ON%]L14kJ#Tm91F+>]PJ_\&E!$8NJf-R2IkEgKM"<%Bgt3%3bn(rGW+$Oe.D%1j). and the matching change in the stream contents. Perhaps the Length is incorrectly calculated? Were there any changes in the lzw encoder?
Oh. Dumb. I forgot that ps2writer hides the postscript inside /ASCII85Decode/LZWDecode. gs should have something in toolbin to maek it easy to decode those obfuscated blobs for debigging purposes.
(In reply to comment #10) > The most significant differences between those two PS files are that the > older gs forgets to add BeginResource comments and: > > @@ -2839,5 +2849,5 @@ > 5 0 obj > <</Filter[/ASCII85Decode > -/LZWDecode]/Length 25608>>stream > +/LZWDecode]/Length 26669>>stream > J/grZ!H?$`#D,6r&9A_r'a,KcL2\kh6uNbZ%H,2L4?b8.N")NO#ge+_B*A^`d'9h%C,m(=a!(P_ > cs[;!N.tg#ON%]L14kJ#Tm91F+>]PJ_\&E!$8NJf-R2IkEgKM"<%Bgt3%3bn(rGW+$Oe.D%1j). > > and the matching change in the stream contents. > > Perhaps the Length is incorrectly calculated? Were there any changes in the > lzw encoder? The Length values aren't use, as I remember. I don't there there have been changes in the LZW encoder. (In reply to comment #11) > Oh. Dumb. > > I forgot that ps2writer hides the postscript inside /ASCII85Decode/LZWDecode. > > gs should have something in toolbin to maek it easy to decode those > obfuscated blobs for debigging purposes. Use -dCompressPages=false -dCompressFonts=false when with ps2write, that avoids the compression/encoding.
Created attachment 9313 [details] PostScript from Ubuntu 12.10
Printing from Ubuntu 12.10 also crashes the printer. I've attached PostScript from the Ubuntu VM, generated using pdf2ps.
Okay, I can start to put together files for you to run to try to debug this, *but* I need to start with the Postscript that actually gets sent to the printer - what you've attached here doesn't have the CUPS added, device specific content. To capture that data, you need to do the following: cupsctl FileDevice=yes lpadmin -p test -E -v file:/tmp/printout /etc/cups/ppd/<PPD file for your printer> Now print the job which failed on the printer "test" and as soon as the job disappears from the queue attach the file /tmp/printout to this bug report. (Credit to Till for the above instructions). If you can attach that here, I will hack up a first test for you to try.
So, CUPS is not cooperating: ejohnson@virtubuntu:~$ sudo lpadmin -p KONICA-MINOLTA-C360SeriesPS-P -v file:/tmp/printout -m ~/Downloads/C360_Series_Linux_v10001.0000/CUPS1.2/EN/KOC360UX.ppd lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cupsd.conf". ejohnson@virtubuntu:~$ sudo grep FileDevice /etc/cups/cupsd.conf FileDevice Yes Ideas?
One of the CUPS folks got back to me and told me to pass on the following: a first comparison of the gs905 and gs907 PS files (I recreated them without compression) showed only two types of differences: a) gs907 replaced a lot of stroked rectangles which gs905 rendered using rectstroke by a sequence of moveto, several lineto, and a closepath b) gs905 left 4 dictionaries on the dictionary stack, gs907 only 1 as indicated by countdictstack at the end of the job. But trying to empty the dictstack by end operators resulted in a dictstackunderflow error with the 2nd "end" with the gs905 file and with the 1st "end" with the gs907 file. But the countdictstack value should be 3 (as it is when rendering the PDF file directly), namely for – systemdict – globaldict – userdict
(In reply to comment #16) > So, CUPS is not cooperating: > > > ejohnson@virtubuntu:~$ sudo lpadmin -p KONICA-MINOLTA-C360SeriesPS-P -v > file:/tmp/printout -m > ~/Downloads/C360_Series_Linux_v10001.0000/CUPS1.2/EN/KOC360UX.ppd > lpadmin: File device URIs have been disabled. To enable, see the FileDevice > directive in "/etc/cups/cupsd.conf". > ejohnson@virtubuntu:~$ sudo grep FileDevice /etc/cups/cupsd.conf > FileDevice Yes > > > Ideas? No, none at all - hence the need for CUPS knowledge before we can apply any Ghostscript knowledge. I just copied those commands from a Ubuntu bug I helped out with the Ghostscript part. (In reply to comment #17) <SNIP > b) gs905 left 4 dictionaries on the dictionary stack, gs907 only 1 as > indicated by countdictstack at the end of the job. But trying to empty the > dictstack by end operators resulted in a dictstackunderflow error with the > 2nd "end" with the gs905 file and with the 1st "end" with the gs907 file. > > But the countdictstack value should be 3 (as it is when rendering the PDF > file directly), namely for > – systemdict > – globaldict > – userdict Whilst the dictstack thing is clearly wrong, I'd be fairly appalled if that actually caused the printer to freeze - throw an error, maybe..... However, it's easy enough to try, once we get the Postscript with all the device specific CUPS additions - without those device specific parts, there is a good chance that sending the generic PS (as you've attached above) to the printer just won't work, or if it does work, it's not really a conclusive test, since it's not entirely what CUPS sends to the printer. I'll see if I can prompt Till to look at this bug when he appears on IRC.
Note that for security reasons CUPS has changed their config file structure. "cupsctl FileDevice=yes" does not work any more. There is a new config file in /etc/cups/, something like cups-files.conf. There you have to add the line FileDevice yes And then you have to restart the CUPS daemon. Then you can do the mentioned "lpadmin" command.
In the CUPS report https://www.cups.org/str.php?L4281 there is ----------------------------------------------------------- Downgrading to cups-filters 1.0.23 fixes the crash, but produces an empty page. ----------------------------------------------------------- We (i.e. SUSE) also got several such kind of issue reports where printng PDFs on PostScript printers does no longer work, see for example https://bugzilla.novell.com/show_bug.cgi?id=774627 https://bugzilla.novell.com/show_bug.cgi?id=776080 https://bugzilla.novell.com/show_bug.cgi?id=795582 The common root cause in all those issues is in the PDF->PostScript conversion step. I assume that printing PDFs on KonicaMinolta Bizhub C280 under Arch Linux also involves a PDF->PostScript conversion step. We (i.e. SUSE) use poppler for the PDF->PostScript conversion. Other distributions use other software for this conversion. As usual under Linux there are several different tools available or the same task. For PDF->PostScript conversion one can use - Ghostscript - Xpdf - Poppler - QPDF - the Adobe Reader Erik Johnson, to find out whether or not the root cause in this particular case is also the PDF->PostScript conversion step, try out if it works when you print your original PDF from the Adobe Reader, see https://bugzilla.novell.com/show_bug.cgi?id=795582#c26
(In reply to comment #20) <SNIP> > The common root cause in all those issues is in the > PDF->PostScript conversion step. Actually, the common root cause in all the cases I've investigated is a broken Postscript interpreter in the target printer. In many cases, they have been interpreter bugs that would prevent the printer from passing the Quality Logic Postscript test suite(s) - the industry standard test suite. There have been a number of patches, and "tweaks" that we have worked out with the Ubuntu CUPS maintainers which work around these broken interpreters (and there may be more to come). I assume these CUPS changes are being fed back into the canonical (as opposed to Canonical!) CUPS repo. The thing is, swapping to another PDF->PS conversion doesn't help us address the issues in the Ghostscript output.
Of course swapping to another PDF->PS conversion doesn't help to enhance Ghostscript's PDF->PS conversion to work around even more bugs in various printer's PostScript interpreters and of course my comment was not meant this way. At last for me it is not yet clear that it must be only Ghostscript where the issue can be fixed. See https://www.cups.org/strfiles/4281/error_log.20130220_1104 which shows -------------------------------------------------------------------------- ... Started filter /usr/lib/cups/filter/pdftopdf (PID 2257) ... Started filter /usr/lib/cups/filter/pdftops (PID 2258) ... Started backend /usr/lib/cups/backend/socket (PID 2259) ... PID 2257 (/usr/lib/cups/filter/pdftopdf) exited with no errors. ... Started filter gs (PID 2260) ... Started filter pstops (PID 2261) ... PID 2260 (gs) exited with no errors. ... PID 2261 (pstops) exited with no errors. ... PID 2258 (/usr/lib/cups/filter/pdftops) exited with no errors. ... PID 2259 (/usr/lib/cups/backend/socket) exited with no errors. -------------------------------------------------------------------------- I don't know what pdftopdf pdftops and pstops exactly do in Arch Linux but it shows that there runs a program that does something with the orininal PDF before Ghostscript gets it and another program that does something with the PostScript that comes out of Ghostscript and I like to point out that in such cases one may have to inspect the whole filtering chain. Printing the original PDF from the Adobe Reader runs a differnt filtering chain and if this works one knows that something in the filtering chain makes the difference. Finally for the user (here for Erik Johnson) it is often a big help when he got an alternative method that works to print his PDFs because then for the user such bugs are no longer "blocker" bugs which in the end helps all of us to work on such issues in a normal way.
(In reply to comment #22) > Of course swapping to another PDF->PS conversion doesn't help > to enhance Ghostscript's PDF->PS conversion to work around > even more bugs in various printer's PostScript interpreters > and of course my comment was not meant this way. > > At last for me it is not yet clear that it must be only Ghostscript > where the issue can be fixed. The problems so far have mostly been around poorly implemented filters, and/or specific filter chains that simply didn't work - IIRC, at least one printer couldn't handle ASCII85 encoded, LZW compressed data. Another fell over reading CCITT Group 4 Fax encoded data in a Type 3 font glyph description (but was fine with the same data outside the font context!!). Those usually produced errors, though. We did have two cases of printers freezing up - one was that after a certain number of calls (and not *that* many!) to the "bind" operator, the printer would just freeze. And the other would freeze on any call to the "currenthalftone" operator. BTW, the bugs you list above seem to be mostly (all?) non-Ghostscript problems. FWIW, I think the idea of moving to PDF as the file format for the print queue was a *huge* mistake. Postscript was designed from the start to be used in that type of setting, PDF was not. In fact, PDF intentionally left out a lot of the stuff in Postscript for device control and the like, needed for exactly this kind of use.
But one question is, why does the PostScript of Poppler's pdftops filter work with all printers and Ghostscript has so many problems?
I posted intentionally those SUSE bugs to show that all reports we got where printing PDFs on PostScript printers does no longer work have been non-Ghostscript problems. It was meant to indicate that it is perhaps not Ghostscript where the issue should be fixed but something else in the filtering chain. In the end all my comments here were meant only to indicate that the issue is perhaps not a Ghostscript issue because from my point of view it looked as if this decision was made too early (that "gs" is run in the filtering chain does not prove that it is actually a Ghostscript issue). I agree that moving to PDF as the file format for the print queue is a mistake - I mean the replacement of the established PostScript workflow is the mistake, see https://bugzilla.novell.com/show_bug.cgi?id=732442#c5 If for PostScript files the established PostScript workflow would still be used and for PDF files a new separated PDF workflow would be used, one could have moved step by step (i.e. user by user, printer by printer, and and application by application) from the PostScript workflow to the PDF workflow, see "the real problem with the switch from PostScript to PDF as standard print job format" in https://bugzilla.novell.com/show_bug.cgi?id=732442#c9 FYI: The matching CUPS issue reports are https://www.cups.org/str.php?L4281 and https://www.cups.org/str.php?L4274 I should have read in particular https://www.cups.org/str.php?L4274 more carefully because therein Douglas Kosovic already described possible alternatives for the PDF->PS conversion via cups-filters. Unfortunately (as far as I see) Erik Johnson did not report the URLs of his CUPS issue reports here and whether or not one of those alternative PDF->PS conversions helped him to print his PDFs on his printer.
(In reply to comment #24) > But one question is, why does the PostScript of Poppler's pdftops filter > work with all printers and Ghostscript has so many problems? I think, from what I have seen, ps2write makes much heavier use of encoding filters than pdftops, so any printers with filter problems, the ps2write output is *much* more likely to find them. Secondly, I strongly suspect that pdftops didn't "just work" from day one, I expect they went through the same kind of process we are now. However, in basic outline, the pdftops output is not totally dissimilar to the ps2write output - they both take the broadly similar approach, so I am surprised at the problems we've seen. Actually, a more significant question is: why are there so many very broken Postscript interpreters in printers out there? As I said, some of these interpreter problems would mean failing the industry standard test suits. And for all the issues we've looked at, no one has yet found anything in the ps2write output that is *not* valid Postscript!
(In reply to comment #25) > I posted intentionally those SUSE bugs to show > that all reports we got where printing PDFs on > PostScript printers does no longer work > have been non-Ghostscript problems. Fair enough - I was looking at it from a Ghostscript-centric POV.
And going back to what I was saying earlier, we're now at comment #28, and we still don't actually have anything that I can actually *do* to help investigate and diagnose the problem (that is in no way a criticism of Erik). Some timely input from the CUPS team, or the ARCH Linux cups maintainer(s) about what's required in these cases would have saved an awful lot of time for all of us, instead of just punting Erik to us immediately.
Erik: Try this on each version, replacing QUEUE with the name of the print queue, as you would pass to »lp -d« or »lpr -P« and VERSION as applicable: cupsfilter -m printer/QUEUE -d QUEUE ps5116.pdf -p /etc/cups/ppd/QUEUE.ppd >ps5116-VERSION.QUEUE This will pass the file through all of the same filters cups does when preparing the file for the printer and generate the same datastream it would send to the printer. There should be %%BeginFeature and %%EndFeature comments in the resulting files. I’ll attach, for comparison, what I get when filtering that pdf to a magicolor 5650 queue, using cups-1.5 and poppler-pdftops (ie what I have installed).
Created attachment 9318 [details] ps5116.pdf filtered by cups-1.5 for a magicolor 5650 printer This is the output of: cupsfilter -m printer/magic -d magic ps5116.pdf -p /etc/cups/ppd/magic.ppd >ps5116.magic where the cups queue magic sends on to a magicolor 5650.
Oh, I should have noted: the postscript-enabled versions of the magicolor and bizhub lines both should use the same QPS interpreter and likely have very similar PPD files, so the magicolor comparison should be relevant. Also, I suspect that most of the errors from sending gs’s ps2writer output to typical printers comes down to RAM. Most printers ship with minimal ram on board (mine came with a single 256M dimm; it has two dimm sockets each capable of 512; just adding a single $30 512 dimm trebled the on-board ram and noticably improved performance) and really need more ram to do complex jobs. Sometimes they even need additional ram just to support duplex printing, since that requires keeping multiple pages in flight at a time. In short, adding ram might help. As might adding that -dCompressPages=false option to the pdftops filter’s invocation of gs.
I'm afraid I'm entering this one a bit late due to vacation. Erik has kindly volunteered to run the tests, so what we need as a starting point is a file (produced somewhere along the line by ps2write) that is known to fail. If the failure is caused by manipulation after creation we'll be able to tell and either remove it or at least flag it to the software authors if it is causing a problem. We can then work on the file to remove stuff until it stops going wrong, then we'll know what the problem is, and probably how to resolve it. So Erik, have you tried sending any of the attached files *directly* to your printer ? Do any of them fail when sent like that ? (I'm not really a Linux user so I can't tell you how to send a PostScript file directly to your printer I'm afraid). James, as Chris said earlier, the *vast* majority of the files which failed have been due to decoder problems in the interpreter, particularly the G4 FAX decoder but also when combining filters. The streams were small and couldn't realistically have caused a RAM problem. The 'bind' problem could have been a memory issue, but its the only one I can think of. Bear in mind that these were test files we had worked on to significantly reduce the scope of the problem, not 'real' files, which reduced any memory usage *very* significantly. Basically these interpreters have very serious flaws. However, I'd like to try and get the problem with this printer sorted out. Till has a method for supplying switches to ps2write to produce 'flavoured' PostScript which works, based on the printer type. Most likely we simply need to get the problem with this printer identified so the correct flavour of output is emitted. (We don't emit the simplest version by default, because it prints significantly slower on the printer) If Erik can somehow produce a PostScript file which fails for us to look at, and is happy to send lots of files to it, then we can figure this out.
If the printer is attached via ethernet, the simplest way to send the raw ps to the printer is to use netcat(1) or nc(1) to send the file to port 9100 on the printer. The KM printers also accept print jobs via ftp. If the printer is connected via usb, then make sure that the usblp kernel modules is insmod(8)ed or modprobe(8)d and use dd(1) to copy to the file to the printer’s /dev/usb/lpN file. You might need to stop cups first. If the usblp module is unavailable and a kernel recompile is out, one can try lp -o raw. Some KM printers have a usb port near the control panel into which one can plug a key drive. The menu allows one to print files from said drive.
I mentioned this in an earlier comment, but I was out of the office all weekend and today, and will be able to test again on Tuesday.
FYI: Regarding "how to send a file directly to a printer device": When there exists a CUPS print queue for that printer device one can use the command $ lp -d queue_name -o raw file The "-o raw" option tells CUPS not to do any filtering but only send the content of the "file" as is to the printer device that belongs to the print queue named "queue_name". To verify that CUPS did not do any filtering run $ grep PID /var/log/cups/error_log | tail -n20 This should show only the "backend" started by CUPS when the "-o raw" option was used. Regarding "filter" versus "backend" you may have a look at http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
Created attachment 9328 [details] PostScript generated after setting FileDevice=Yes and printing through CUPS
I have attached the postscript generated after setting FileDevice to Yes and printing via the normal means.
(In reply to comment #37) > I have attached the postscript generated after setting FileDevice to Yes and > printing via the normal means. Great, that perfect, thanks Erik. So, just to confirm: the output from Ghostscript 9.05 works, and the output from 9.06/9.07 fail? Also, do you mind if I contact you directly via e-mail? As mentioned above, we could be going back and forward running a lot of files, and most of that would be just "noise" in the context of this bug thread.
(In reply to comment #38) > (In reply to comment #37) > > I have attached the postscript generated after setting FileDevice to Yes and > > printing via the normal means. > > Great, that perfect, thanks Erik. > > So, just to confirm: the output from Ghostscript 9.05 works, and the output > from 9.06/9.07 fail? > Correct. > Also, do you mind if I contact you directly via e-mail? As mentioned above, > we could be going back and forward running a lot of files, and most of that > would be just "noise" in the context of this bug thread. Sure.
There is also a Ubuntu bug report about this problem: https://bugs.launchpad.net/bugs/1053443
For everyone who wants to helpe here, here are instructions for Ubuntu (and other recent Linux distributions): https://wiki.ubuntu.com/DebuggingPrintingProblems section: "PostScript (PDF) printer chokes on the PostScript (PDF) coming from Ubuntu"
As already mentioned on the Ubuntu bug: Investigation by KonicaMinolta UK suggests that this is a firmware bug which has been addressed in the most recent revisions - I've yet to receive confirmation from the user on that, but KM were unable to reproduce the crash on their own test units with up to date firmware. Thus the first step should really be to arrange a firmware update.
I'm still waiting on being able to get that firmware upgrade (at my office, requests like this need approval, for good reason), but I'm optimistic that this will resolve the issue.
After this long: if the new firmware doesn't fix the issue, please open a new bug.