PDF workflow flawed, crashes printers

[Valentijn Sessink]

Binary package hint: cups

Under Ubuntu Lucid, the new PDF workflow in CUPS poses various problems for various printers: jobs will either not print (and may crash the printer) or print "very slowly". These are reports from various customers.

We have seen a bunch of Ricoh printers fail (killing the user interface of the printer, a hard reset is necessary to be able to use the printer again); notably a Ricoh Aficio AP4510 PS that crashes; and a Ricoh1224c that sometimes does not print; a Panasonic printer, DP-C265 (printing will sometimes suddenly reset the printer); but also other customers complain about not being able to print anymore, on various brands of printers (we've seen Brother and HP)

We heavily suspect the new PDF workflow in CUPS, as the following workaround works:
change /usr/share/cups/mime/mime.convs to say:
application/pdf application/vnd.cups-postscript 43 pdftops
application/postscript application/vnd.cups-postscript 65 pstops

This, essentially, makes the workflow use Postscript again when either PDF or Postscript is presented.

Unfortunately, a crashing printing interface does not normally tell why it is crashing, so I suspect this bug to be quite hard to dig further into. Somewhere between pstopdf, pdftopdf and cpdftocps, something goes wrong. It may even be the file size (but I couldn't find any size information in the ipp backend log messages that Cups sends out with debug-logging enabled).

There are many bugs that may be related to this: bug #655422 (Sending pdf and ps files to a printer routinely fails), Bug #665978 (Slow Printing), Bug #667102 (Printing errors after upgrade).

[Till Kamppeter (till-kamppeter)]

Your suggestion of modifiying the cost factors of the CUPS filters we have already applied in Maverick. Our implementation is a little different, we have only set

application/postscript application/vnd.cups-postscript 65 pstops

so that for a PostScript printer it is avoided to turn incoming PostScript into PDF and back into PostScript. If the incoming data is already PDF, there is not much difference whether one passes it through pdftopdf and then through pdftops or first through pdftops and then through pstops. The change especially eliminates PostScript to be turned to PDF via the (Ghostscript-based) pstopdf filter. I can issue an SRU (Stable Release Update) for Lucid to apply this change.

The main problem is that applications deliver ineffectively made output files which blow up a lot when converting them, ending up with a huge file sent to the printer and the printer simply runs out of memory.

See also bug 668800 describing a possible cause for slow printing and a suggested solution for Natty.

Maverick does not only have the cost factor change for the pstops filter but also several printing improvements in the code of the filters. So if you do not require to stay on LTS, you could try to use Maverick. If you want to stay on LTS, please try also whether only setting

application/postscript application/vnd.cups-postscript 65 pstops

in /usr/share/cups/mime/mime.convs already solves your problem. Please tell whether this works or only using

application/pdf application/vnd.cups-postscript 43 pdftops

in addition remedies the problem, so that we can make an appropriate SRU. Also try a Maverick live CD only to see whether Maverick has your problem solved without any additional changes.

[Valentijn Sessink (valentijn)]

Op 16-12-10 19:07, Till Kamppeter schreef:
> Your suggestion of modifiying the cost factors of the CUPS filters we
> have already applied in Maverick. Our implementation is a little
> different, we have only set
> application/postscript application/vnd.cups-postscript 65 pstops

I know. (See below).

> so that for a PostScript printer it is avoided to turn incoming
> PostScript into PDF and back into PostScript. If the incoming data is
> already PDF, there is not much difference whether one passes it through
> pdftopdf and then through pdftops or first through pdftops and then
> through pstops. The change especially eliminates PostScript to be turned

That's the theory. In practice, there *is* a difference.

> want to stay on LTS, please try also whether only setting

Yes we do.

> application/postscript application/vnd.cups-postscript 65 pstops
> in /usr/share/cups/mime/mime.convs already solves your problem. Please
> tell whether this works or only using

I did the trick with 65. But then customers complained that they could
not print PDF files, they sometimes would only print half, sometimes it
took very, very long. (I'm not sure if they would also crash the
printer) So that's why we also set the pdftops cost to 43.

So: only setting pstops to 65 does not solve the issue. My feeling is
that there's a problem within the filtering, one that's not easy to spot
but that pops up with the pstopdf stuff.

> SRU. Also try a Maverick live CD only to see whether Maverick has your
> problem solved without any additional changes.

It's only a couple of printers that crash, in live situations, with
print servers at customer premises. So it's a bit hard to check. I'll
see what I can do. Our own HP Laserjet doesn't crash, that's the main
problem ;-)

V.

[Till Kamppeter (till-kamppeter)]

Can you please also try the Maverick live CD only to see whether the filter code changes of Maverick already solved problems?

Can you also follow the instructions of the sections "CUPS error_log" and "Capturing print job data" of https://wiki.ubuntu.com/DebuggingPrintingProblems, once for the original /usr/share/cups/mime/mime.convs having a printer crash and second, for your version with the two cost factors changed and the job coming out correctly. Can you also attach the input file which you have used for the test.

Please attach the files one by one, do not package or compress them.

[Valentijn Sessink (valentijn)]

Unfortunately, with a Maverick installation, the long delay in printing persists. Please note that this is not a live CD, but an installed machine. On the other hand, the install is pretty basic and printing is done through the network, so there is nothing the local Cups is doing.

Our *hacked* print path, on the central server:
application/postscript application/pdf 22222 pstopdf
application/pdf application/vnd.cups-postscript 43 pdftops
application/postscript application/vnd.cups-postscript 65 pstops

On a server with Ubuntu 10.04 LTS, this will output a certain PDF within 4 minutes on a Panasonic DP-C265 with Postscript module.

A regular print path (nothing changed), with the same PPD, on an installed Maverick machine, a print takes considerably more time (more than 15 minutes). I'm currently investigating if this PPD is public (i.e. can be attached to this bug report).

One thing that puzzles me, is that I could not exactly see the differences in the print path between 10.04 and 10.10: 10.04 seems to use Poppler as well?

Anyway, please tell me what I should test next.

[Valentijn Sessink (valentijn)]

> [...] will output a certain PDF [...]
> than 15 minutes). I'm currently investigating if this PPD is public

That should read: if this PDF (the document I'm trying to print) is public.

So, to summarize: a) printing from a Maverick machine to a Lucid server with hacked-up printing path: 4 minutes (prints to Panasonic printer through IPP).
b) Printing on the Maverick machine itself, straight to the same IPP addressed Panasonic printer takes considerably more time (we stopped waiting after 18 minutes, printer still flashing, not sure if anything will come out today ;)

[Valentijn Sessink (valentijn)]

The attached PDF (which is public) will not print or print very slowly (30 minutes) on the above printer with the Lucid/Maverick default print path. With a hacked workflow as described, all pages print within 4 minutes.

[Valentijn Sessink (valentijn)]

I don't think I understand the "Capturing print job data" part of DebuggingPrintingProblems. As far as I can see, disabling the printer will stop the print queue handling *before* filtering jobs. So all I am getting is the PDF that I already attached above. Am I doing something wrong?

[Till Kamppeter (till-kamppeter)]

Valentijn Sessink, it is true that the PDF which you will capture is of before the filtering, but it is not the PDF which you attached with an earlier posting, as PDF viewers, especially Evince do not simply pass through the PDF when printing but they re-render it. They use the same graphics engine as for the screen display (Cairo in case of evince) and create a PDF with it. This PDF is often much bigger than the original PDF, which makes subsequent filters much slower or even crashing. Therefore I need this captured print job. The PDF attached to this bug report and the captured PPD will only be identical if you had printed it with "lpr" and not with a PDF viewer.

[Valentijn Sessink (valentijn)]

That is what I did. (Hence my confusion when the captured file came out identical to the original file ;)

[Valentijn Sessink (valentijn)]

Oh well. Please forget about this attachment. Never trust your end users to tell you if anything did or did not work; as far as I can see, the attached PDF just works (might have been a bit slower under 10.04, I'm not sure). I still do have a PDF that crashes the printer - only if printed from Evince, though. I'll send that shortly.

[Valentijn Sessink (valentijn)]

I now have a verifyable PDF, straight from the print queue, that crashes a certain Ricoh printer - a Ricoh Aficio AP4510 PS, which isn't exactly your entry-level small printer - it's rated 45K pages per month.

The printer crash *only* happens when:
- we print the original document (a PDF) from Evince
- we have the printer output non-duplex (the default is to duplex)

If we set the print options to the default (i.e. duplex), no crash occurs.

I have now personally verified this (no stupid users telling random things in between). We verified the "duplex" or "non duplex" occurence with both Evince (from the original document) and gtklp (with the document that I grabbed from the queue). This gives me 4 new documents in the queue, all bit-by-bit the same; they will have the printer crash due to setting a "non-duplex" option.

Let me repeat that in pseudo-code:
Original.pdf -> printed from Evince, duplex -> CUPS queue: nocrash1.pdf -> prints
Original.pdf -> printed from Evince, simplex -> CUPS queue: crash1.pdf -> crashes printer
nocrash1.pdf -> printed with gtklp, duplex -> CUPS queue: nocrash2.pdf -> prints
nocrash1.pdf -> printed with gtklp, simplex -> CUPS queue: crash2.pdf -> crashes printer

As a check/double/triple-check: nocrash1.pdf, crash1.pdf, nocrash2.pdf and crash2.pdf are bit-by-bit the same, they all have the same md5sum, so the printing options are at stake here.

Now the problem is: the document is not exactly for everyones eyes, i.e. I would not like it to be generally available (through Launchpad, for example).

On the other hand, it's not exactly Top Secret, so sharing it privately with a couple of developers at Openprinting wouldn't hurt.

So my question is: can I send Till . Kamppeter at his Gmail.com account a 546K PDF document that will crash a certain type of printer, when certain printing options are active? Or is there a better place to send such document?

I realise that this may end up being a bug in either Evince or the Ricoh PS firmware, but I'd like at least to be able to know what that bug is.

[Valentijn Sessink (valentijn)]

(I removed the previous attachment; sorry for the fuzz; I simply couldn't reproduce the issue yesterday while I was at the customer's premises, so I suspect a luser reporting nonsense).

[Till Kamppeter (till-kamppeter)]

Valentijn Sessink, please send the file to me by e-mail. It is no problem.

[georgeliu (george-liu-ricoh-tech)]

Let me clarify:
With the following change, the pdf file can be printed successfully?

change /usr/share/cups/mime/mime.convs to say:
application/pdf application/vnd.cups-postscript 43 pdftops
application/postscript application/vnd.cups-postscript 65 pstops

That is a smart change to bypass the new PDF workflow filter "pdftopdf" and "cpdftops".

Different printers deploys different Postscript interpreter in its firmware. Ricoh printers uses Postscript interpreter provided by Adobe, while HP and other vendors use their own in-house developed Postscript interpreters. Each interpreter has different strength and error handling schemes. That's why you experience different print result for the same PDF file.

Ricoh-Aficio AP4510, is indeed a very old model (more than at least 6 years). I do not have access to that model, but I'll see whether the problem could reproduce on another Ricoh model.

George

[Valentijn Sessink (valentijn)]

Printing the file does *not* work with these changes. That is: if you have these changes, and try to print non-duplex, the printer will freeze. Printing duplex does work. Regarding the printer model: I'll get back to you with the specific model, because, actually, it strikes me as a bit odd that this would be a 4510.

[Valentijn Sessink (valentijn)]

Ahem. I did not read your comment too well. I will check your changes, *then* get back.

[Valentijn Sessink (valentijn)]

BTW, is there a possibility to intercept the final PS stream that is sent to the printer? Having an intermediate PDF that crashes in some situations, but prints in other, is helpful, but a bit complicated as well.

[georgeliu (george-liu-ricoh-tech)]

Yes, you can create a "print-to-file" queue using the same PPD file. Instead of sending the job to printer, the data stream will be saved to a file.

To do so, you need to
1. From CUPS web admin page, under "Administration", add "FileDevice True" to the configuration file.

2. Create the print queue using Device URI "file:/tmp/myspoolfile.ps" with your ppd file.
It can also do through command line: "/usr/sbin/lpadmin -p printtofile -E -v file:/tmp/myspoolfile.ps -P myppdfile.ppd"

3. You can send job to the printtofile queue. PS file will be created at /tmp/myspoolfile.ps. Make sure to add read permission to the file. "chmod a+r myspoolfile.ps"

In my previous posting (#14), I didn't want you to try anything new, I just want to know how to reproduce the problem.
Do I need to do the following as specified in your original posting?

change /usr/share/cups/mime/mime.convs to say:
application/pdf application/vnd.cups-postscript 43 pdftops
application/postscript application/vnd.cups-postscript 65 pstops

[Valentijn Sessink (valentijn)]

Hi,

Op 07-01-11 20:47, georgeliu schreef:
> Yes, you can create a "print-to-file" queue using the same PPD file.

I'll implement that next week.

[...]
> In my previous posting (#14), I didn't want you to try anything new, I just want to know how to reproduce the problem.
> Do I need to do the following as specified in your original posting?

Probably, yes. Because otherwise, as far as I understand, CUPS may use
the new PDF workflow.

So:
- set mime.convs options as described
- restart CUPS if necessary (if I understand correctly, it calculates
the print routing only during it's startup, but I may be wrong)
- easiest way is: have gtklp installed, please print the file with this,
make sure you have "duplex" printing OFF.

Please note, that the file you have is the file as found in the print
queue, so it's meant to be printed with lp or gtklp. If you reopen it
with Acrobat or Evince, I'm not sure what it will get you - probably
just a dull print.

Another new fact is, that the printer in question is a NRG MPC4500;
we're only using the 4510 PS file, hence my confusion.

Please note, that because of the duplex/non duplex sensitivity, I'm
still not 100% confident that of the reproducability of this problem,
i.e. there may still be parts missing. Ulrich Wehner from Ricoh USA was
able to crash some older printer, but not his regular MPC3500. So I hope
that the print-to-file option will get us a Postscript file that will
crash the printer directly.

Best regards,

Valentijn

[Valentijn Sessink (valentijn)]

This file crashes a Panasonic DP-C265, when printed under Maverick with either Acroread, Evince or gtklp, print queue running on Lucid with modifications as described earlier, to avoid PDF workflow. Will try to fetch the PS file that is sent to the printer shortly.

[Valentijn Sessink (valentijn)]

Is there a way in which I can send a PS file (as made from the instructions at #18) to the printer, manually, through the IPP backend? To double check if this still crashes the printer?

[Valentijn Sessink (valentijn)]

Done as suggested in comment #18:
added FileDevice True
cp /etc/cups/ppd/kleurenkopieerapparaat.ppd /tmp/pana.ppd
lpadmin -p printtofile -E -v file:/tmp/spoolfile.ps -P /tmp/pana.ppd
lp -d printtofile /tmp/Printcheck_DenHaag_week03.pdf

The resulting Postscript file is attached.

[Till Kamppeter (till-kamppeter)]

Valentijn, in a terminal window run the command:

lpr -P <printer name> -o raw <PS file>

Then CUPS sends the file to the backend without any filtering.

[Valentijn Sessink (valentijn)]

Thanks. I verified, that printing https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1791098/+files/spoolfile.ps on this Panasonic printer crashes the printer - although the printer does not restart, it says "Machine Error - Call TEL. [phone]" - which is the local service organisation; when I reset the printer remotely, it has a "Remove Misfed Paper" message on it's display.
I also tried the other crashing PDF, and this one immediately restarts the printer (even while the "remove misfed paper" message is still there, so the printer apparently starts interpreting the PS even before the paper path is cleared). I'll send this postscript file by private mail.
So far, I haven't been able to do anything to the Ricoh printing problem, because these printers are in a more secure environment, and unfortunately, I can't access them remotely as easy.

[georgeliu (george-liu-ricoh-tech)]

An PS expert from my group looked at the Postscript file (spoolprint.ps). There's a "<</PageSize [210 332]>> setpagedevice " command, which set the Paper Size to 210x332 point, which is unknown to printer.

Probably the original PDF brochure's size.is defined as 210x332, however, the pdf to ps conversion process (whatever filter it is) did not do it properly.

It should tell printer to use the paper size user specified (Letter or A4), and print the original pdf (210x332) to a corner of the page or fit to page.

[David Williams (dwilliams-ricohsv)]

George asked me to look at this spoolfile. Beyond the custom page size, here is a little more information:

1. This print job was prepared with a PPD file for a Panasonic printer and so contains PS code specific to that device - it will cause an error on other devices (such as a Ricoh or maybe even another Panasonic). Posters in this thread mentioned the DP-C265, searching for some of the ProcSet names online returned DP-C405, they seem to be in the same product line. It would be nice to know for sure that the printer and PPD were properly matched, in order to eliminate that possibility.

2. This print job appears to have different settings for the same parameter; now, that's ok in theory, because the last setting simply replaces the previous setting, but it does indicate a potentially confused workflow.
    line 461..........Duplex set to false
    line 3239........Duplex set to true
    line 598..........PageSize set to 595 x 842 (that's A4)
    line 3239........PageSize set to 210 x 332 (custom page size, a little bigger than A7)
    line 3245........PageSize set to 210 x 332 (again! Indicates possible multiple upstream sources for page settings)

3. There is a ProcSet for XPDF at the beginning of the file - I guess this open-source code was used to convert PDF -> PS - the procedure" pdfSetup" defined there is called on line 3239 and sets Duplex, ImagingBBox and PageSize after all other setup commands have executed, including separate commands for all three of those parameters. These parameters can have a significant effect on printer memory when changed, because a big chunk must be allocated for the frame buffer (raster memory) and the size depends on the page size and duplex setting (and resolution, and margins,...). In the case of this print file, the printer is forced to re-allocate memory several times before it even starts to draw anything. Some posts in this thread mentioned strange behavior, ghostly crashes and long print times, this all sounds a bit like a case of trashed memory, doesn't it? It was also mentioned that the duplex setting makes a difference in this case - and duplex is being set by this pdfSetup procedure - so it's all very suspicious.

4. When I remove all the Panasonic-specific feature settings and that dang pdfSetup call, this file prints very quickly (less than 30 sec.) on a Ricoh MP C2800, a relatively old and slow printer. So all of the trouble is in the setup process, which is basically an interaction between the driver and the PPD file.

5. Finally, about that PageSize setting of 210 x 332. When Acrobat is asked to print a custom page size like that, it makes that size a clipping path rectangle on a standard paper size the printer supports, such as A4 or Letter. This job is actually asking the hardware to set up a physical page size like that - something the paper path in the printer doesn't support, who knows what happens.

-David

[3t0g0 (freetogo)]

After I have installed ghostscript from 8.71 to 9.01, the print problem fixed.

You could either download the source, compile and make from the source
http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl901.htm

or to borrow the debs from natty,
https://launchpad.net/ubuntu/+source/ghostscript/9.01~dfsg~svn12005-0ubuntu1/+buildjob/2152489

Pls let me know whether this method work for u.

[Till Kamppeter (till-kamppeter)]

3t0g0, thank for the hint, so I close the main task as this one is meant for Natty.

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".