If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

printing complex web pages to HP LaserJet 4000 causes printer to crash and/or lose the print job

RESOLVED WONTFIX

Status

()

Core
Printing: Output
RESOLVED WONTFIX
10 years ago
6 years ago

People

(Reporter: zwol, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [notacrash][needs debugging help from HP], URL)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5pre) Gecko/2008030922 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5pre) Gecko/2008030922 Minefield/3.0b5pre

Any webpage of sufficient complexity, when printed to my LaserJet 4000 (in postscript mode, not PCL) will cause the printer to do one of the following:
give up and report out-of-memory back to the computer; display
"79.00FE Printer Error" on the front panel and freeze up until
power-cycled; or (most common yet also most aggravating) blink its
data light for a few minutes and then forget about the job entirely
and go back to waiting-for-requests state.  This happens whether I
print directly or first to a file.

I'm not sure exactly what the trigger is, but the URL above does it for me every time.  (I had previously thought it was the presence of a color image in the webpage being printed; this is wrong.)

Ghostscript 8.61 has no problem with the postscript file generated from that webpage, so I imagine this isn't so much a case of *wrong* PS as PS a bit too difficult for my printer's tiny little mind -- but I think it should still be fixed in the browser; it is much easier to do that than upgrade the printer's firmware, assuming there even is an upgrade.

Firefox 2 does not show the problem, so I suspect this has something to do with Cairo and/or the new gtk+ print backend.

I can provide the postscript output I'm getting on request, but the file is almost five megabytes even after bzip2 compression, so I'm not going to attach it to the bug.

Reproducible: Always
Version: unspecified → Trunk

Comment 1

10 years ago
I would need to see the PostScript to see what can be done to reduce the memory usage.

How much memory does your printer have available? You can usually find this on the printer configuration page that you can print from the printer menu.
One problem that we have currently is due to the way I draw borders, OPERATOR_ADD gets used.. which ends up triggering image fallback for the entire region contained within the borders, even though just the edges are drawn.  I thought that borders were being drawn with OPERATOR_OVER when we're printing (because that print resolution the difference isn't noticeable), but I need to make sure.  However, I'm going to spend time next week minimizing the areas were OPERATOR_ADD is used -- since it's only needed at the corners.

That may not be the underlying problem here though, but it's pretty common.  That page has a region with a border-top and border-bottom which shouldn't be triggering the fallback, though (as there are no joins).
(Reporter)

Comment 3

10 years ago
(In reply to comment #1)
> I would need to see the PostScript to see what can be done to reduce the
> memory usage.

OK to email you a five megabyte file?

> How much memory does your printer have available? You can usually find this on
> the printer configuration page that you can print from the printer menu.

It says eight megs.

Comment 4

10 years ago
(In reply to comment #3)
> (In reply to comment #1)
> > I would need to see the PostScript to see what can be done to reduce the
> > memory usage.
> 
> OK to email you a five megabyte file?

Yes. But I suggest printing with the latest nightly build (2008-03-15) as the most recent cairo update adds some extra debugging information to the PostScript output.

Comment 5

10 years ago
$ grep Fallback cairo-color-image-bug-2.ps
% Fallback Image: x=49, y=80, w=522, h=336 res=300dpi size=9135000

The PostScript output has a fallback image that covers nearly half the page. The best solution here is for firefox to avoid any unsupported operations that result in image fallbacks. That way the image will be sent to the the printer at it's original size like what firefox 2 does. In the above file the image is  scaled up to 300dpi, or 2175x1400 pixels.

I'm not sure if the resolution field in the Advanced tab of the print dialog is setup to call cairo_surface_set_fallback_resolution. You could try reducing this resolution. Due to the halftoning your printer can probably only print color images at about 120dpi so there is no benefit to using 300dpi.

Updated

8 years ago
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Whiteboard: [notacrash]

Updated

8 years ago
Summary: printing complex web pages to LaserJet 4000 causes printer to crash and/or lose the print job → printing complex web pages to HP LaserJet 4000 causes printer to crash and/or lose the print job
Whiteboard: [notacrash] → [notacrash][needs debugging help from HP]
(Reporter)

Comment 6

6 years ago
Years later, I have come to the conclusion that the PostScript interpreter on this printer (which I still have) is just no good, and not worth trying to adapt anything to; I switched my computer over to send it PCL instead, and have had no grief since.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.