Re: how are html pages printed?
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<noelamac@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
Reply to: