print/cups: since update to 1.7.1: error : Send-Document client-error-document-format-not-supported
ohartman at zedat.fu-berlin.de
Tue Apr 8 16:11:49 UTC 2014
On Tue, 8 Apr 2014 16:18:26 +0200
Polytropon <freebsd at edvax.de> wrote:
> On Tue, 8 Apr 2014 15:42:10 +0200, O. Hartmann wrote:
> > Since the update of print/cups from 1.5.X to 1.7.1 I'm unable to print from
> > LibreOffice, Firefox or Claws-Mail, but I can print LaTeX created documents via xpdf
> > or Postscript directly by naming the printqueue.
> Strange, then maybe it's not really a CUPS problem?
Well, that was also a guess, but it has been introduced with the update.
> > Checking the access- and error logs of cups when failing, I always see this weird
> > message (not for the particular queue, but for all):
> > access_log:
> > "POST /printers/OJ8600PRO_SW_A4_simplex_draft HTTP/1.1"
> > 200 36510 Send-Document client-error-document-format-not-supported
> > error_log:
> > [Client 14] Returning IPP client-error-document-format-not-supported for Send-Document
> > (ipp://localhost:631/printers/OJ8600PRO_SW_A4_simplex_draft) from localhost
> Oh the fun of CUPS error messages, how wonderful... ;-)
> Check your configuration files. Sometimes when an update is
> done, things change in those files, so the older ones do not
> keep working. Especially look for filter definitions for
> the MIME types which seem to be the basis of how CUPS invokes
> preprocessing. If you use the "Modify printer" option in the
> web interface, configuration files should be updated automacially
> with the new required settings (as CUPS can maintain those
> files without the user manually editing them).
I did. That was one of the first steps I did after EVERYTHING failed to work. I started
from srcatch with a new /usr/local/etc/cups folder.
It seemed that the old printer definition files couldn't be used anymore, so I had to
setup every queue again - and I did so.
> Reason: Within X and especially from LibreOffice to CUPS
> (but maybe also from other applications), data is sent
> "with no type" (which is application/octet-stream), whereas
> other applications declare a type (like application/pdf or
> image/png when addressing the printer input queue). CUPS
> seems to have lost the ability for properly preprocessing
> those "raw" data (which, sent from LO, actually is PS).
> You'll probably have to "cupsenable" and "cupsaccept" the
> printer afterwards.
> > Has anybody ideas where to look further?
> Check if the printer's "personality" (it's often really called
> personality!) has changed and if the printer refuses to accept
> anything that is not PS (maybe PCL?).
> Maybe one of your CUPS dependencies hasn't been updated properly.
> Are you using some special print filters in combination with CUPS?
> Check /usr/local/etc/cups/mime.convs as described above.
> > I was wondering if I might be the only one with trouble after that cups update.
> Not yet, still using 1.5.4. :-)
There is a report that print/cups-filters needs to be installed. I did so, but that
increased the mess further. With print/cups-filters installed, printing of "a testpage"
is possible, but it ends up in a blank page with "%?" at the end.
Printing PS files (made by gnuplot or LaTeX) from gv is impossible, xpdf doens't print
PDF files then. I deinstalled the cups-filters again and I'm stuck again with the
half-way-damaged system, not a complete dead printing system.
In the meanwhile, I deleted cups, installed it from scratch and installed from scratch a
new queue. it is the same mess.
My printer is a HP OfficeJet Pro 8600 N911a, I use the driver PPD provided by the most
recent port print/hplip. Its precedessor worked fine until the cups update.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the freebsd-questions