print/cups: since update to 1.7.1: error : Send-Document client-error-document-format-not-supported

[O. Hartmann]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20140408/1d97522d/attachment.sig>