Right, again with much help from Felix, we're narrowed the problem down
to the fact that the images in the originating PDF request
interpolation, thus so does Ghostscript's Postscript output, and it
seems that, for the class of image in question, at least, the 1350D's
implementation of interpolation is unacceptably slow.

There may or may not be a future enhancement in GS to control whether it
preserves the interpolation requestion, but for now, at least, the
quickest solution would be to add bit more to the Postscript workaround
CUPS already prepends to PS for these Kyocera printers.

Augmenting the existing workaround as per below, improves the speed to ~12 
seconds for the job in question:
%%BeginProlog
% ===== 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
% Some Kyocera printers have an unacceptably slow implementation
% of image interpolation.
/image 
{
  dup /Interpolate known
  {
    dup /Interpolate undef
  } if
  systemdict /image get exec
} def
% =====

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1026974

Title:
  Printing Bahn ticket with gs backend takes 6:03 minutes on Kyocera
  1350DN

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1026974/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to