Cannot print a PDF on Kyocera Laser Printer

Can you follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems, especially of the sections "CUPS error_log" and "Capturing print job data"? Thanks.

Can you attach the PPD file of your printer (KPDL/PostScript mode) to this bug report?

Can you print the file if you use a PCL driver?

Chris, can you have a look at this? There seems to be another incompatibility with Kyocera.

I'll need the exact Postscript being sent to the printer, and the command line invoking Ghostscript to create the PS.

Chris

> Can you follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems, especially of the sections "CUPS error_log" and "Capturing print job data"? Thanks.
done

> Can you attach the PPD file of your printer (KPDL/PostScript mode) to this bug report?
done

> Can you print the file if you use a PCL driver?
yes the PCL driver works here, but has less options and has failed on other PDFs if I remember correctly.

Felix, can you generate a PostScript output stream as it gets to the printer by doing the following:

cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout /etc/cups/ppd/Kyocera-Mita-FS-1350DN-KPDL.ppd

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.

I created the postscript data as descibed in bug #1025061 comment #9.

The commandline seems to be https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/977912/comments/15

Okay, so we think we know the source of the problem.

All the text in the PDF is drawn with text rendering mode 7, which means "add to clip". So drawing the text accumulates an enormous path, which is then use to clip. Hence the limitcheck error on clip.

Now the Ghostscript ps2write output (for some architectural reasons) simply emits the accumulated path, and drops the fonts from the output. The poppler output retains the fonts, and uses the Postscript charpath operator to create the path which it then uses to clip.

So, the question is: does the poppler output work?

There really should be no difference in the complexity of the path that Ghostscript emits explicitly, and the one that poppler creates via charpath, by the time the "clip" operator gets called.

There is a small chance that Ghostscript could be changed to also emit the fonts and use charpath for this class of file, but it would be a lot of work, and rather pointless if it still won't work.

It's possible that the answer is simply: the Postscript resulting from that PDF is simply too complicated for your printer to handle.

So, in conclusion, can we test the poppler output?

I executed ...
lpadmin -p Kyocera-Mita-FS-1350DN-KPDL -o pdftops-renderer-default=pdftops
... to try the poppler version and that fails as well.

The output is:
Error Name: /limitcheck

Offending Command: --clip--

Operand Stack:

As mentioned before this works with the PCL driver.

I have tried to send the attached printout.ps file unfiltered to 2 HP PostScript printers via

nc -w1 <IP address> 9100 < printout.ps

The HP LaserJet 3390 hangs infinitely, the nc command does not complete and the printer stays blinking for more than one hour now.

The HP Color LaserJet CM3530 MFP prints only the first page.

So this is not a Kyocera incompatibility problem. It is either a problem of the original file being too complex and therefore only rendering well when rastering the PDF directly but causing problems when converted to PostScript or the problem is in Ghostscript's PDF-> PostScript conversion. Therefore we also need the PostScript produced by Poppler.

Ok, this is the new poppler based printout now.

I get the following output on print:
fm@thinkpad:~$ nc -w1 laser 9100 < printout.poppler.ps
%%[ Error: limitcheck; OffendingCommand: clip]%%
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
fm@thinkpad:~$

How did you exactly produce printout.poppler.ps?

I did a quick Poppler test by (note that the pdftops here is /usr/bin/pdftops which is the command line converter of Poppler)

pdftops beispielrezepte.pdf
nc -w1 <IP address> 9100 < beispielrezepte.ps

Both printers print this, but very slowly. The LaserJet 3390 needs 5-10 minutes for each page, the Color LaserJet CM3530 MFP around 1 minute per page.

I executed lpadmin -p test -o pdftops-renderer-default=pdftops with a file based "test" printer.
Then I gathered the /tmp/printout.

How should I do it?

Felix, that is perfect. Absolutely correct.

Your printout.poppler.ps seems to contain only the first page,

I sent it to both printers with the nc command and it got printed on both, but on the LaserJet 3390 it needed several minutes.

Frankly, that's what I feared. The Adobe produced Postscript can be made to resemble either the Ghostscript output or the poppler output (depending on the settings used in Acrobat), and it looks to me as though this is simply a case where the (mostly minor) differences in the imaging capabilities of PDF and Postscript result in a Postscript file with a very long path. In such cases, limited resource printers are going to struggle.

Chris

Till, it contains just the first page as chrisl told me on IRC that it gets easier to debug this way.

To summarize the findings for now:
My Kyocera printer cannot print this document no matter what with the PS driver.

Till has two HP printers.
The ghostscript document does not print on the LJ 3390 and just the first page prints on the CM3530.
The poppler document prints on both although slowly.

So I guess fixing ghostscript to produce a document that prints on the HP printers is usefull.
However, priting on the Kyocera seems to be more difficult, can this be tackled?

I can't see any way to reproduce the page description accurately without running into the same problem.

IIRC, some Windows Postscript drivers have the option to produce the page as an image, which I believe is intended to work around this type of issue. Thus reducing the PDL complexity, for such limited printers, at expense of comms traffic.

I'm intrigued by Till's results with the HP because, as I stated above, the path(s) in question, whether they are explicitly described in the PS, or result from character outlines are equivalent in complexity at the time the printer executes the clip operator.

I would expect it to always be slow, because making marks through such a hugely complex clipping path is a very time consuming operation.

Sorry the news isn't better.

I've attached the result of printing the first page from Acrobat, through the KPDL Windows driver. It looks similar to the poppler output (it builds the clipping path using charpath operations).

The Kyocera driver does, indeed, include a "Print As Image" option - although it comes out grayscale, for some reason. I can only assume that option is there to deal with cases like this one.

Printing this I get:
fm@thinkpad:~$ nc -w1 laser 9100 < Downloads/beispielrezepte-kyo-driver.ps
%%[ ProductName: FS-1350DN ]%%
%%[ Error: limitcheck; OffendingCommand: charpath ]%%
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%

As far as I can see my evince print dialog does not have an option to print as image.

Well, I think it's fair to say that if Kyocera's very own driver does not/cannot produce PS that the printer can interpret, it's not unreasonable that we don't. I'm not saying if there were a reasonable way for us to workaround the problem that we wouldn't, on that basis - but frankly, none of us can see a way to do that without taking ps2write away from it's intended purpose, which is to output as accurate a representation of the input as possible, within the limitations of the imaging models and the Ghostscript internals.

I guess it's something to Till to consider, and discuss with the other cups devs: should there be a "Print As Image" option in cups?

That option is in all the Windows Postscript drivers which I have access to, right now, so I have to assume it is included for a reason - and the only reason I can think of is cases like this.

I am in favor of having the "Print As Image" option.

We do not need to ask someone else, the "CUPS" options are all defined by the CUPS filters in the cups-filters package. I can add an option like "print-as-image" to the pdftops filter. Chris, so it would be great if the Ghostscript upstream developers could add such an option to the "ps2write" device, so that the filter can add a command line option to the Ghostscript command line when the user requests "print-as-image".

No, we're not going to add that option to ps2write, that would, frankly, defeat the whole point of ps2write.

There is already a cups imagetops filter, so it would be a lot less work to have the option have Ghostscript convert to pnm and then do imagetops on the pnm.

I also found that someone I know had a problem with the Kyocera fs-1350dn. The workaround found in the end was to plug it in via ethernet and add it as a network printer, and then add the PPD file. It printed fine then. If you only have one PC, you could just share the ethernet to the printer (Shared to other computers under ethernet settings). Hope this helps someone.