reassign 815001 cups-filters
thanks


On Fri 26 Feb 2016 at 18:10:48 -0500, Ryan Kavanagh wrote:
> 
> I've attached the error logs obtained after running
>     cupsctl LogLevel=debug2
> in various configuration situations.

Very useful; thanks

> For the socket:// setup, it appears to be unable to connect to the
> printer. See error_log.socket.

  D [26/Feb/2016:17:24:05 -0500] [Job 142] Connection error: Transport endpoint 
is not connected
  E [26/Feb/2016:17:24:05 -0500] [Job 142] The printer is not responding.

An nmap of magenta.srv.cs.cmu.edu doesn't show port 9100. It doesn't
matter because the issue doesn't appear to be with the backend used.
 
> Using the same driver as in the initial bug report and lpd://, I obtain
> error_log.lpd.
>  
> Using the driver "HP LaserJet 9050 Postscript (recommended) (grayscale,
> 2-sided printing)" with lpd://, I get error_log.lpd-9050ps

Both these logs show CUPS and the filtering system behaving correctly.
The input file is typed as a PDF, the filters exit without error and the
lpd backend shovels data to the server (magenta.srv.cs.cmu.edu). The
server happily accepts it.

> Using the "HP LaserJet 9000 Series pcl3, hpcups 3.16.2 (color, 2-sided
> printing)" and "HP LaserJet 9050 - CUPS+Gutenprint v5.2.11 (grayscale,
> 2-sided printing)" and "Local Raw Printer' drivers with lpd:// causes a
> sheet of paper complaining about attempting to print a binary file to
> come out (this leads me to believe that the address I have for the
> printer does not point to the actual printer but to some print server in
> between, which may be the source of the problem).

The info sheet you have should have the printer's IP address.

> This appears to occur for all files, though on the odd occasion, I'll
> try my luck and manage to print something without killing the printer.

All three logs have

  D [26/Feb/2016:17:23:31 -0500] [Job 142] Switching to Poppler\'s  pdftops
    instead of Ghostscript for old HP LaserJet (\"LaserJet <number>\",
    no letters before <number>) printers to work around bugs in the printer\'s
    PS interpreters

Please see #742765

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742765

for the reason this is done.

About the best I can suggest is to see how you go on with the Ghostscript
renderer:

  lpadmin -p <print_queue> -v lpd://... -E -o pdftops-renderer-default=gs -m 
<PPD>

From

  
http://www.printertechs.com/printer-troubleshooting/hp-error-codes/192-numeric-error-codes-20-49-hp-laserjet

   49.XX PRINTER ERROR  A firmware error occurred

I think the assumption has be that Ghostscript and Poppler produce valid
PostScript. Bugs in printer interpreters are not unknown and there is
not much we can do about them.

Regards,

Brian.

Reply via email to