Printing Deutsche Bahn ticket on Kyocera PS printer takes 5 minutes (regression to 11.10)

Btw. this just happens with evince. Printing from okular is just fine and prints in seconds.

This is a problem of Cairo (library used by evince) producing awkward PDF which makes Ghostscript very slow (https://bugs.freedesktop.org/show_bug.cgi?id=48260). Okular does not have this problem.

In addition, there is a speed problem with Kyocera PostScript printers which I have fixed yesterday (bug 977912). Please take care to have your system completely updated. You should have cups-filters 1.0.15.

Please post on these bugs if you still have problems after updating.

See also bug 968785.

The fix in cups-filters does not work for me I guess.

I am using 1.0.15-0bzr1 and it still takes several minutes to print a page.

Btw. the time must be spent within the printer there is no printing realted process using any CPU. The file does not get big either. According to the job viewer it is 218k ....

Can you attach a sample input PDF file and the PPD file used with your printer (from /etc/cups/ppd/)? Thanks.

I sent the files to you via mail as they contain private data.

Can you try to print with a resolution of 300 dpi? Does the page come out in a more reasonable speed then.

Attached is the PPD file which Felix has sent me in private.

Felix, note that the PPD file does not contain any personal data. It is published by Kyocera.

Till, printing with 300dpi results in something like 10 seconds for printing. That is at least usable for printing tickets ;)

The PDF file with which this problem was observed was an online ticket from Deutsche Bahn AG. As the original poster does not want to have his ticket attached here for privacy reasons, I have attached one of my tickets. It should cause the same problem.

Felix, can you try to print my attached ticket to see whether it causes the same problem as yours.

Chris, can you perhaps help here to find out what is going on here? Should I perhaps set the image rendering resolution generally to 300/360 dpi for Precise?

Till, I am afraid your ticket has another problem. I cannot print it at all (I tried 600 and 300dpi).

ERROR:
undefined
OFFENDING COMMAND:
m
STACK:
--nostringval--
17

I printed right afterwards my ticket again without any problem. :-(

As there is no transparency, no shaded fills and no CIDFonts in this file, there is nothing which is really affected by changing the resolution for ps2write.

Given the error observed above, I would guess this is another filter problem.

If Felix can attach the PS from Till's test PDF, I can take a look, and create some tests to *possibly* help track down the problem.

Also, can we confirm *exactly* the command line being used to drive Ghostscript in this case (sorry, but with all the changes recently, I've slightly lost track!).

Chris

I need an explaination how to get the correct PS from Till's PDF.

However, I just to make clear. I cannot print Till's PDF with evince at all (it works with okular) (see comment #16).

If it helps I would be willing to upload my ticket as well...

Felix,

The main thing is, I need the PS that actually gets sent to the printer so that I can get the device specific settings that are inserted by CUPS (and are not present in the "bare" Ghostscript output). Then I can create variants of the PS from Ghostscript, and "hand patch" the Postscript to include the device specific settings - that way we can try different options to Ghsotscript, without having to create new CUPS packages for every option to test.

I'm somewhat hopeful that fixing the error with Till's PDF will also address the performance problem with yours.

Till,

Is there a method to "inject" Postscript into the CUPS workflow at the point that Ghostscript would normally have created the PS? (I'm just wondering if there is an easier method for testing that me hand editing the printer specific stuff into the Postscript, and having the user "nc" it to the printer).

Chris

To get the PostScript which CUPS sends to the printer, proceed as follows:

Create a clone from your print queue, running the following commands:

cupsctl FileDevice=yes
cupsctl LogLevel=debug
lpadmin -p test -E -v file:/tmp/printout -P /etc/cups/ppd/<queue name>.ppd

Then print the PDF into this new queue and attach the output, /tmp/printout, which is a PostScript file. Also attach the /var/log/cups/error_log file.

Do this for both my and your ticket, also attach your original ticket.

To make CUPS inserting PostScript code into the PostScript which comes out of Ghostscript, you can add a "*JobPatchFile" keyword into the print queue's PPD file in /etc/cups/ppd:

*JobPatchFile 1: " ...
...
..."
*End

Restart CUPS after hand-editing the PPD file.

To get PDF output from evince to be able to do experiments with Ghostscript on it, use "Print to File" in the print dialog of evince and choose PDF as output format.

Till,

Sorry, that's not quite what I meant by "inject Postscript". What I was hoping for was a way to bypass the PDF print queue (PDF is *so* unsuitable for that!), so that an end user can take Postscript directly out of Ghostscript and push it into the CUPS "back end" to have the PPD derived stuff added, and CUPS related workarounds added, and then sent to the printer.

It would save me having to hand edit all the Postscript files to add the PJL, the "bind" workaround, the PPD settings and such to every test job we try.....

Chris

The Ghostscript command line used by pdftops when the printer is Kyocera is the following:

gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -r600 -dCompressPages=false -dCompressFonts=false -dNoT3CCITT -c save pop -f /tmp/02bbe4f8e7e74

The resolution (" -r...") is always the actual printing resolution derived from the PPD file. The file name after the -f is the name of the PDF input file.

In addition, pdftops adds the following workaround PostScript code right after %%BeginProlog, being the first non-comment code in the output PS file:

----------
% ===== Workaround insertion by pdftops CUPS filter =====
% Kyocera's PostScript interpreter crashes on early name binding,
% so eliminate all "bind"s by redifining "bind" to no-op
/bind {} bind def
% =====
----------

Chris, if you want to push manually generated/edited PostScript into the CUPS queue, you can print it via

lpr -o raw ...

This makes it getting printed without any filtering.

Till,

AIUI,
lpr -o raw ...

Is just a passthrough direct to the printer, so I *still* have to manually edit *every* test file to get it to work on the printer.

If it's the pdftops filter that adds (at least some of) the printer specific stuff, then I'll assume there's no way for me to avoid the hand editing :-(

I am sorry for it but I do not have access to the computer and the printer anymore for the next two months.

I am back at my printer and have installed all updates. I think this is solved. It takes 10s now for the print to start.

thanks, closing the bug then, feel free to reopen or open a new bug if you get it again or get new issues

Felix, note that we have issued a Stable Release Update (SRU) for cups-filters in Precise. to address bug #668800, bug #951627 (comment #30), bug #998087, bug #992982 (comments #26, #27, #30, #31), bug #997728, bug #994477, bug #998087, bug #978120, and bug #862167. The change is switching pdftops from using Ghostscript back to using Poppler and limiting the maximum rendering resolution to 300 dpi. The behavior is configurable though, so please try the following commands:

Switch renderer (Ghostscript or Poppler):

lpadmin -p printer -o pdftops-renderer-default=gs
lpadmin -p printer -o pdftops-renderer-default=pdftops

Back to default:

lpadmin -p printer -R pdftops-renderer-default

Switch maximum resolution (0 is for no limit):

lpadmin -p printer -o pdftops-max-image-resolution-default=1440
lpadmin -p printer -o pdftops-max-image-resolution-default=0

Back to default:

lpadmin -p printer -R pdftops-max-image-resolution-default

Replace "printer" by the actual printer name as shown by "lpstat -v".

Please try the different posiibilities and tell us what works for you and what not, so that we can find out what causes bad performance and find the best defaults for the future (Ubuntu Quantal, 12.10).

Hi Till,

I just did the whole test series. I have tested every scenario just once, to save some trees.

Here is the result:
                             renderer
                    | default | gs | pdftops
            default | 11 | 5 | 11
resolution 1440 | 12 | 5 | 12
                  0 | 11 | 4 | 12

This is all with your attached 3NSH8B.pdf.

try again. looking at the above launchpad does not like ascii art with numbers ...

                             renderer
                    | default | gs | pdftops
            default | 11s | 5s | 11s
resolution 1440pt | 12s | 5s | 12s
                0pt | 11s | 4s | 12s

Thank you very much. This means that we can work well with Quantal's defaults of gs and 1440dpi.

I am sorry, for comment #13 I just timed the printing process by listening.

I did not realize that all the gs prints did NOT print successfully although they were fast.

Instead of your ticket, I see the following:
ERROR:
undefined
OFFENDING COMMAND:
m
STACK:
--nostringval--
179

So Quantals gs default will NOT work at all!

Felix, so can you report a new bug with the usual stuff attached, meaning that you follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Assign the bug to the "ghostscript" package. With this I can organize a fix by the upstream Ghostscript developers rather quickly, especially in time for Ghostscript 9.06 and Quantal. I will also consider an update for Precise then.

I have opened bug #1025061. Thanks.