Kyocera FS-1300DN cannot print with gs backend

The attached file is gatherd according to the instructions at https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data

Felix, thanks. Seems that there is an incompatibility between Ghostscript and your Kyocera printer. I am CCing Ghostscript developer Chris Liddell as he could perhaps help finding a workaround.

Chris, can you help here? It is again a compatibility issue between Ghostscript's PostScript and a PostScript printer.

I can't find a gs command line anywhere in the logs. Could someone post the command line cups gives to GS these days? Perhaps that could be added to the cups logging? Also any PS that gets prepended.....

Oh, it looks like this is one of the printers we opted to disable page "stream" compression, but IIRC, Till, you put in user controls to allow disabling of font compression - that might be a good place to start.....

cliddell, for the command line and workaround code insertion see bug 977912, comment #15.

I'll need the Postscript that gets sent to the printer, too.

Felix, can you run the following commands:

cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout -P /etc/cups/ppd/Kyocera_FS-1350DN.ppd
lpr -P test printout.pdf

printout.pdf is the file which you have attached to comment #2.

Please attach the resulting /tmp/printout to this bug report.

cliddell, this /tmp/printout file will contain exactly the PostScript which has gone to the printer.

Here is the postscript file generated by Till's commands.

Felix,

that's the poppler emitted PS (which is useful, I would probably have asked for it down the line anyway), but I really need the PS generated by Ghostscript, if you could.... thanks.

This is the postscript document after executing
lpadmin -p test -o pdftops-renderer-default=gs
on my virtual printer.

Felix,

First of all, (and I may have told you this before, but I would like it recorded in this, and all relevant bugs): this is *not* a bug with the Ghostscript Postscript output. The GS Postscript is valid - we spent a lot of time confirming that when these bugs started to come to light. The fault is with the printer, and the problem really should be reported to Kyocera. Even if they can't fix it in printers "in the field" they should be able to debug the problem "directly" on the printer, rather than the kind of arm's length "reverse engineering" we'll have to undertake.

If we're going to track down the problem it will probably involve many interations of me "instrumenting" the Postscript file, you running the revised PS, and telling me the result.

However, based on past experience, tells me to look at compression filters first, and the only one left in there was LZW. So, as a first punt, can you try:
http://www.ghostscript.com/~chrisl/nolzw.ps

IMPORTANT: it must be send directly to the printer (not opened in evince or other viewer, and printed from there - that would lose all my changes!). So you need to use:

lpr -P <printer name> -oraw nolzw.ps

There is also a method using netcat but I cannot remember the details......

If you can try that, and let us know the result.

Thanks,

Chris

I cannot print your file at all.

Executing
fm@thinkpad:~$ lpr -P Kyocera_FS-1350DN -oraw nolzw.ps

I get a printout with the following:
%!PS-Adobe-3.0
                             %%BoundingBox: 0 0 595 841
                                                                                   %%Creator : GPL Ghostscript GIT PRERELEA

Darn it! Sorry, I forgot I needed to add the device specific stuff to the file.

http://www.ghostscript.com/~chrisl/nolzw2.ps

Should be more what we want.... apologies again.

Chris

My printout contains
ERROR:
undefined
OFFENDING COMMAND:
m
STACK:
--nostringval--
181
now.

It seems the number on the stack has changed ...

Okay, so it is not a problem with the LZW filter. That still leaves another (non-compressing) filter that could be at fault, but I'll try to narrow things down a bit before we get to that. On that basis, I'll work on modifying the version with the compression, since it's a lot smaller (obviously!).

http://www.ghostscript.com/~chrisl/printout-002.ps

Please use the same method to send that to the printer.

All I have done in this one is add a blank first page. The reason for this is to narrow down whether the error is happening during the "prolog" of the file, or during the actual marking operations.

Felix,

by the way, if there is a more convenient way of communicating for you than using launchpad (e-mail or IRC or something) then let me know. I can summarise progress on the problem here as required.

Chris

I will leave now, but otherwise IRC might offer faster turnaround...

My printer just created _both_ pages with the following content:
ERROR:
undefined
OFFENDING COMMAND:
m
STACK:
--nostringval--
181

When I come back home tonight I can print another ps ...

Hmm, I did *not* expect that :-(

If you can try this one:
http://www.ghostscript.com/~chrisl/printout-003.ps

In this one I have removed all the ps2write "marking content", and replaced it with just a blank page.

If IRC would be easier, I'm on #ghostscript on freenode most days (I'm on UK time) - my nick is "chrisl".

This is a bit better I guess.

It creates a blank page first and on the second I have:
ERROR:
undefined
OFFENDING COMMAND:
m
STACK:
--nostringval--
179

<sigh> Again, I really didn't expect that :-(

http://www.ghostscript.com/~chrisl/printout-004.ps

That one should (on a fully functional printer) produce no output at all - not even a blank page.

Felix joined us on #ghostscript and with his help, I narrowed the problem down to the fonts in the file.

The way ps2write currently works is that it writes a pfb (binary encoded Type 1 Postscript font) and ASCII85 encodes it so the binary data doesn't trip up the communications channels.

The Kyocera printer here seems unable to cope with the pfb font data, it seems to require it in pfa (ASCII encoded Type 1 Postscript font).

We'll investigate solutions, and report back.

For tracking the Ghostscript end of this, see:

http://bugs.ghostscript.com/show_bug.cgi?id=693197

This bug was fixed in the package ghostscript - 9.05~dfsg-6ubuntu4

---------------
ghostscript (9.05~dfsg-6ubuntu4) quantal; urgency=low

  * debian/patches/020120720-01dc18e-ps2write-use-pfa-fonts.patch:
    Embed fonts as PFA and not ASCII85-encoded PFB in the PostScript
    output, some PostScript printers (Kyocera) cannot cope with the
    latter (LP: #1025061).
 -- Till Kamppeter <email address hidden> Sat, 21 Jul 2012 10:58:13 +0200