Comment 2 for bug 1026974

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