On 02/14/2012 01:05 PM, Dom wrote: > On 14/02/12 17:26, Camaleón wrote: >> El 2012-02-13 a las 15:01 -0600, Mark Copper escribió: >> >> (Mark, remember to reply to the list, not just me ;-) ) >> >>> On Mon, Feb 13, 2012 at 12:10 PM, Camaleón<noela...@gmail.com> wrote: >> >> (...) >> >>>> I would try to add a new printer instance (keep the one you already >>>> have, just add a new one) for the printer but using a PCL6 file instead >>>> ("pxlmono") and try to print the same page with it, just to compare >>>> both >>>> outputs. >>> >>> This sounds like a reasonable approach. I'll give it a look. >>> >>> Just to put out as much info as I can. This problem also occurs with >>> Fedex shipping labels which do not involve explicit pop-up windows >>> (but a lot of javascript). >> >> I think the pop-up window is not relevant for the problem but the >> generated image/code by the courier web services. They can contain some >> data your printer driver cannot handle and thus outputs the error. >> >>> Also it is worth remembering there is *not* a problem printing to the >>> same printer from either squeeze on AMD or wheezy on i386 machines, I >>> beleive. >> >> You mean the 32-bits wheezy install can print that pages without >> troubleshoot, using the same PPD file? It could be then a problem with >> the 64-bits CUPS packages... anyway, I would try first with "pxlmono" >> and see how it goes. > > I don't know that it's a problem with the 64-bit Wheezy. I have the same > model printer and have been puzzling for a while why sometimes web pages > print that error message, and others work fine on my 32-bit Wheezy setup. > > However I hadn't got any further into my investigation, as I printed > them successfully on my other printer (Epson inkjet) instead. > > Now I will take more notice of which pages fail and examine the html and > the generated postscript files. > This is an aside concerning a very interesting coincidence between my experience and yours.
I use an application called Zim. Zim's method of printing is to "print" to a browser. (I can use the system default browser or any other.) To get a paper printout, one then has to print to the printer from the browser. On my Wheezy AMD64 system this always results in pure black output on our HP OfficeJet 6310, which is a combination printer / scanner / fax. On our i386 systems running Wheezy and the same CUPS and PPD we get proper output. This has been going on for months. It is the same with all browsers (epiphany, iceweasel, chromium, midori). The workaround for the 64 bit system is to print from the browser to a PDF file using cups-pdf. Printing the PDF file then produces perfect output. After seeing this thread and comparing the information in it to my own situation I'm thinking this must, indeed, be an issue with the CUPS package in the the AMD64 version of Wheezy. This HP printer has to be installed via the hp-setup utility if you want the scanner and / or fax to work. The hp-check utility does show a bunch of errors when run, but it has always done that -- even when the printer was working perfectly well. Sorry if I'm just adding noise to the thread. I' hoping that the additional information might help you in some oblique way with your approach to solving the problem. As I said, I have a workaround that isn't too burdensome. Regards, Gilbert -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3aa99c.80...@comcast.net