Kyocera FS1320D needs resolution set in ghostscript filter

It looks like the poppler pstops tool defaults to 300 dpi, compared to Ghostscript's ps2write's 720dpi. Normally, this would not matter (both will always try to preserve scalability whenever possible), but when flattening transparency, the resulting image is created at the requested resolution. Both flatten PDF transparency groups to images in a similar fashion.

I suspect a number of the performance issues with Postscript printers stem from this, so the simple "fix" is to add "-r300" to the GS command line to get comparable output to the pstops.

As stated above, a nice enhancement would be to choose a resolution which is an integer diviser of the actual printer resolution: so for 600, 1200 and 2400 dpi, 300 is a good setting. For 720, 1440, 2880 dpi, 360 would be a good setting.

FWIW, it might be informative to assess the actual operating resolution of the poppler based "toraster" utility in the cups workflow, and see if that was also using a fixed (default?) resolution.

Fix (cups-filter 1.0.14-0bzr1) is uploaded and waiting for approval by the release team.

The pdftops filter calls Ghostscript with the Resolution attribute (" -r ...") now to tell Ghostscript's the printer's resolution or at least a resolution where the actual printing resolution is a multiple of, so that images and flattening out transparency get rendered in this resolution. This makes most built-in PostScript interpreters in printers process Ghostscript's PostScript much faster.

Maximilian, for testing until the package gets approved, please get the same, identical package from my PPA, by simply adding my PPA to your package repositories and updating your system. Follow the instructions on:

https://launchpad.net/~till-kamppeter/+archive/ppa

After that update and you should get cups-filters_1.0.14-0bzr1~ppa1. Then test and report here.

This does not fix the problem. I chose 300 dpi in the printer settings dialog and printed to a "FileDevice" Printer with the Kyocera PPD.

The result is a ~1.0 MB file that takes ages to process. I didn't let it finish because I can't block the printer here for 20 minutes..

time nc -w1 192.168.2.103 9100 < 300dpi.ps
^C
real 5m41.054s
user 0m0.000s
sys 0m0.000s

If I send the 300dpi uncompressed one that cliddell gave me I have this processing time:

time nc -w1 192.168.2.103 9100 < Unbenannt\ 1-300dpi-uncompressed.ps

real 0m0.336s
user 0m0.000s
sys 0m0.000s

I'll attach my "300dpi.ps".

This bug was fixed in the package cups-filters - 1.0.14-0bzr1

---------------
cups-filters (1.0.14-0bzr1) precise; urgency=low

  * New upstream release
     - pdftops: Determine printing resolution from the PPD file and supply
       it on the Ghostscript or pdftops (Poppler) command line, so that
       the renderer does the image rendering with a resolution matching the
       printer's resolution. This avoids too slow processing of the jobs
       by the printer's built-in PostScript interpreter. In addition
       a default resolution of 300 dpi is used for PPDs without any hint
       of the printer's resolution, as most PostScript lasers use multiples
       of 300 dpi as resolution (LP: #977912).
 -- Till Kamppeter <email address hidden> Tue, 10 Apr 2012 19:40:11 +0200

Thank you for testing, Maximilian.

This was a first, less invasive solution, simply trying to get rid of the resolution mismatch but not reducing resolution. I will do the second approach of reducing the resolution to 300 dpi or 360 dpi (depending on the printer) today.

Till,

It is confusing why using the "native" resolution doesn't result in the fastest printing.

Some thoughts (based on some experience with Kyocera products): there may be some extremely poor buffer management going on, meaning that the larger amount of data causes this kind of slow down.

Second, it's possible that the printer is *actually* working at 300dpi dot size, and the higher resolution settings are actually dot *placement* precision - that is rare on laser printers, so I would be surprised, but common on inkjet type printers. We know their *downsampling* of image data is slow.

Third, and something I have seen on laser printers: the printer is using 1200dpi for text and line art, but 300 dpi for contone image work - this is sometimes used because detail is the primary concern with text/line art, whilst colour fidelity is usually more important for contone image output. Again, the slow downsampling would come into play here.

There are plenty of other possibilities, and without some information from Kyocera, we're unlikely to ever know for sure.

Chris

Being the average layman, I'm slightly confused. Shouldn't the filter resolution be <= the max. resolution set in the printing settings? This way one could choose "speedy printing" by using a lower resolution in the settings.

After a *lot* to-fro testing (and a lot patience and help from Maximilian!), we've finally narrowed down the problem, and it is not a simple resolution issue.

It seems that the Kyocera printer is having issues when the data filter chain looks like:
ASCII85Decode->LZWDecode->ASCII85Decode

Which is how CUPS currently calls Ghostscript with ps2write - so we ASCII85Encode image data, which is part of the page data stream. The page data stream is then LZWEncoded, and then that compressed page stream data is also ASCII85Encoded.

So we get that by using the following command line options for Ghostscript:
-dNoT3CCITT -dEncodeMonoImages=false -dEncodeColorImages=false

Which we settled on to work around filter problems with the Brother printers.

To get this Kyocera printer to print in a reasonable time, I used these options:
-dNoT3CCITT -dCompressPages=false -dCompressFonts=false

So we're compressing image data, but *not* the page streams.

I have a *feeling* we tried something like the above with the Brother printers, and it didn't work, but my memory is vague - we tried *so* many things! We might have to ask one or two of the Brother users to test for us again.

Chris

Maximilian, thank you for testing again. I have uploaded a new version of cups-filters (1.0.15-0bzr1~ppa1) to my PPA now. As soon as it got built on the PPA you can get it by simply updating your system. Its pdftops filter uses the command line indicated by Chris Liddell in comment #9 for Kyocera. Please test it and report here whether it solves your problem.

This bug was fixed in the package cups-filters - 1.0.15-0bzr1

---------------
cups-filters (1.0.15-0bzr1) precise; urgency=low

  * New upstream release
     - pdftops: Suppress image compression only for Brother printers as they
       really need this measure to print at all. This accelerates printer-
       internal job processing on most other printers (tested on HP and
       Kyocera). Also suppress page compression on Kyocera printers, this
       works around a bug in Kyocera's PostScript interpreters which makes
       printing pages with images very slow (LP: #977912).
 -- Till Kamppeter <email address hidden> Wed, 11 Apr 2012 22:40:11 +0200

Testing results:

cups/ghostscript ps at 600 dpi:

time nc -w1 192.168.2.103 9100 < output.ps

real 0m11.601s
user 0m0.000s
sys 0m0.004s

cups/ghostscript ps at 300 dpi:

time nc -w1 192.168.2.103 9100 < output.ps

real 0m0.322s
user 0m0.004s
sys 0m0.000s

300 dpi is pretty fast as you can see, but the image in the header looks really crappy then. So I tried the pdf converted with pdftops again, just to see how the poppler solution performs:

time nc -w1 192.168.2.103 9100 < poppler.ps

real 0m3.657s
user 0m0.004s
sys 0m0.004s

Image quality is as good as the 600dpi ghostscript one. So we are a bit slower now, but not far far away like before. So I guess this bug is really fixed. I'm pretty sure one could find fine tune the printer settings and save a little bit more, but that is up to the user. In general I would consider this "bug" fixed. Thank you very very much Chris for your super-human endurance and of course Till for delivering the fix. One last question, for the record: Does this patch apply to all Kyocera printers or only to some/this specific model?

Maximilian, the changes apply for all Kyocera printers as we assume that printers of the same manufacturer have usually the same PS interpreter with the same bugs.

One last thing: (I quote chrisl here)

"actually, it might be worth seeing if tkamppeter_ would be amenable to an enhancement request to allow "decoupling" of the *printer* resolution from the Ghostscript (transparency flattening) resolution - applications like Acrobat and Illustrator offer exactly that setting in similar situations."

As we have it now, 300dpi printing is super fast but the images look pretty crappy. This could be avoided if it was possible to set the printer's resolution to 600dpi and ghostscript's resolution to 300dpi somehow. (for these Kyocera printers at least) Please note that this can in now way be considered a bug but I'll add it here so this idea doesn't get lost...

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
% =====
----------

Sorry, the last comment was meant for another bug.

What we were talking about is, if you look in Acrobat Pro, in the dialogue for creating Postscript, it has a drop down menu titled "Transparency Flattener Preset" which has the options "High Resolution", "Medium Resoluiton" and "Low Resolution". Those options are totally independent of the resolution of the target printer.

It gives the user the option of "I want the best quality, however long it takes", "I want it as fast as possible, and damn the quality" or something in-between.

So, in a similar manner, it might be good to allow users to specify the "flattening resolution" (passed to Ghostscript) independently of the printer resolution (default behaviour would obviously be as it works now). You could even do something like "High" (current behaviour), "Medium" (flattener resolution == printer res / 2), "Low" (flattener res == printer res / 3), or "Custom" (allowing the user the specify their own flattener resolution).

As mentioned above, this is a *feature* suggestion/request for your consideration, not a bug report. It's just something that occurred to me might be useful for a future CUPS release.

Chris