User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120104 Minefield/3.0b2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120104 Minefield/3.0b2pre When trying to print a page with graphics, text prints fine, but graphics are printed as a solid black box. Firefox 2 prints the page just fine. Reproducible: Always Steps to Reproduce: 1. Go to any website with text and graphics 2. Print it 3. Actual Results: The text prints fine, but graphics are printed as back boxes Expected Results: A printed page similar to the displayed rendered web page I can't believe nobody reported that, but I couldn't find any relevant entry in bugzilla.

Printing preview works fine. I upload a printed page photo taked with my phone.

taked=taken. English, ugly third language... :-)

Works for me printing http://images.google.com/images?q=mozilla to a postscript file. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120104 Minefield/3.0b2pre ID:2007120104

Can't block until I get a confirmation ...

Printing to a postscript file works fine. Printing to real printer prints graphics as solid black boxes.

Sending that postscript file (it displays fine in the monitor) to the printer... shows black boxes!!!!. What the hell!. Converting that postscript to PDF using "ps2pdf" without parameters, generates a pdf file that prints fine both in screen and printer. That said printer is a "HP Laserjet 4000N". Printing to a (network) "HP Laserjet 5 Si MX" (B&W) and to a Xerox Phaser 8550 (color) shows graphics perfectly. I guess we are hitting a Postscript generation bug at Cairo level. Maybe we are generating postscript level not supported by that printer. This printer only supports PostScript Language Level 2. In any case, I have no problems with any other program, neither Firefox/Thunderbird 2.* . I think this is a serious issue. I don't think this issue is limited to this printer model, so it is going to hit hard when FF3 is widely deployed. Should I open a bug with cairo itself?.

Looking at th postscript generated file, I see something "strange": %%Creator: cairo 1.5.3 (http://cairographics.org) (I've installed Cairo 1.4.12. No idea of 1.5.3 is coming from) %%LanguageLevel: 3 (My printer only support level 2) How can I change generated PS Language Level?. A possible relevant thread: http://lists.freedesktop.org/archives/cairo/2007-September/011431.html If Cairo is generating Level 3 postscript by default, I guess the right thing to do is adding a postscript level selector in the print dialog.

Can anybody with a "PS LanguageLevel 2 only" printer reproduce this issue?.

Seems Firefox includes Cairo library inside. In particular Cairo 1.5.3, that is generating PostScript level 3 by default. So the Cairo lib in my system is not used. Can I force Firefox to use my system cairo lib instead the included one, without compiling FF myself?.

Studing Cairo sourcecode included in firefox, I see the following in routine "_cairo_ps_surface_create_for_stream_internal": surface->ps_level = CAIRO_PS_LEVEL_3; Seems Firefox should call "cairo_ps_surface_restrict_to_level" to set PS LanguageLevel=2. I located cairo code in "libxul.so". I would try to patch the binary by hand, to check it out, but the library has no usable symbols to locate the right byte to modify...

I renamed the bug: my printer is generating the black boxes instead of correct graphics because generated graphics use PostScript level 3 features and my printer only supports level 2. The black boxes are artifacts my printer uses to pinpoint problems. Other printers could use any other procedure (including "ignoring" the offending code). The real issue, then, are not black boxes. Black boxes are symptoms. The real issue is that Firefox is generating PostScript Level 3. Cairo changed the default PS level recently (September 2007, seems). I think the right approaches would be: 1. Add a single line patch to Firefox to set Cairo PS level backend to PS level 2. 2. Add "Use Level 2" or "Use Level 3" radio buttons in the print dialog, like many other programs do (for example, Adobe Acrobat Reader).

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2007121304 Minefield/3.0b3pre Debian lenny (testing, so not anything particular for many libs) The resulting file contains strings like: %%Creator: cairo 1.5.3 (http://cairographics.org) %%LanguageLevel: 3

This regression seems critical enough and simple enough to solve to request Firefox 3 blocking.

can we get the postscript level info from cups?

No idea about CUPS abilities. OpenOffice 2.3.0 generates PS Level 2 for my printer. Going to the printer configuration, I see a selector called "PostScript Level" with options: "from driver", "level 1" and "level 2". So maybe CUPS could provide this info.

Uh, why did this get moved into Firefox::General? This is a printing issue, and belongs in that component. I agree with your assertion that it should get blocking status, and we definitely have enough information here for a confirmation.

blocking1.9, I'll let the component owner decide on priority.

Mike, my fault. Sorry. Race condition between your change and my last comment :-).

(In reply to comment #15) > can we get the postscript level info from cups? > Yes. See attached example.

I understand that CUPS will filter PostScript level 3 to print on a level 2 printer. Your HP 5si MX should be a level 2 printer, but you say that printing to it works. Could you check the PPD file that CUPS is using for your 4000N and see if it specifies a postscript language level?

""" castor:/etc/cups/ppd # grep -i languagelevel general.ppd *LanguageLevel: "2" castor:/etc/cups/ppd # grep -i languagelevel LaserJet-5Si.ppd *LanguageLevel: "2" """ "General" is the HP 4000N. Now I'm confused. CUPS is not doing any translation for my 400N printer, apparently. In fact, if I print a file using Adobe Acrobat Reader, and I explicitely ask for level 3 output, the page printer shows a nice "level 3 unsupported by this printer, configure your program for level 2 output". The question then is... why the 5si printer is working?. But this printer is "proxied" by a (windows) remote printer queue, so I can't comment about the kind of magic running there.

(In reply to comment #20) > Created an attachment (id=293114) [details] > Show PS Level Compiling & executing this code, it identifies my default printer and shows its PS level correctly.

(In reply to comment #21) > I understand that CUPS will filter PostScript level 3 to print on a level 2 > printer. I did some more research, and it looks like this is wrong. You could probably get CUPS to do this by altering the PPD, but it won't do this by default, certainly not with a generic PPD. When printing to a non-PostScript printer, CUPS will render PS through ghostscript, which will happily accept PS level 3. It seems counterintuitive that CUPS support for non-PS printers would be more flexible than its support for actual PS printers.

I've added some code the cairo PS prolog to check if the printer supports the PS Level of the print job. If the printer does not support the job a message stating the required PS level is printed and the job aborted. http://gitweb.freedesktop.org/?p=cairo;a=commit;h=9bccc968466e6b83ceccb76680d5f54912424e8e

(In reply to comment #25) > I've added some code the cairo PS prolog to check if the printer supports the > PS Level of the print job. If the printer does not support the job a message > stating the required PS level is printed and the job aborted. Since Cairo can output PS level 2 without any issue (the default cairo level until september), I can't see the reason to "deprecate" all level 2 printers out there. A far better approach would be to query CUPS about printer PS level support and use that. Or a radio button in the printing dialog. Or simply configure Cairo to output PS level 2 ALWAYS. The only "regression" would be bigger files :-). I must insists: If I am not mistaken, the issue is caused by Cairo defaulting to PS level 3 instead of level 2. That change was commited in Cairo last september. The trivial patch could set the default mode to level 2 again (Cairo added a function to set PS level explicitly). All FF3 nightlies until september used level 2. The "right" patch would be to query the printer driver. But I rather default to level 2 than deprecating level 2 printers. See comment #12.

Querying the printer driver isn't a long-term solution. Bug 193001 would replace Gecko's direct CUPS interface with an interface into GTK's printing system. GTK doesn't include a way to check the PS level supported by the printer.

(In reply to comment #27) > Querying the printer driver isn't a long-term solution. Bug 193001 would > replace Gecko's direct CUPS interface with an interface into GTK's printing > system. GTK doesn't include a way to check the PS level supported by the > printer. Understood. Then the approaches proposed in comment #12 are still valid. The only ones, in fact.

Reported GTK+ issue here: http://bugzilla.gnome.org/show_bug.cgi?id=509788

How is going?. I really think we should default to PS Level 2, as it was until September. New Cairo has an explicit function to do it.

Reassigning to Michael. Using level 2 sucks but it's the only way until GTK+ can tell us what level to use, and today it can't.

I think this works, but this is the first time I am brave/stupid enough to touch Cairo and Thebes so...

Comment on attachment 301761 [details] [diff] [review] Use Level 2 this will be fine for now.

Checking in gfx/thebes/src/gfxPSSurface.cpp; /cvsroot/mozilla/gfx/thebes/src/gfxPSSurface.cpp,v <-- gfxPSSurface.cpp new revision: 1.10; previous revision: 1.9 done

Firefox now should generate PostScript level 2 files. In fact, the file header says so... But Cairo backend is generating PS level 3 code inside this declared PS label 2 file. So the original bug is solved in Firefox, but it shows now a bug in Cairo backend code. To reproduce: - Print to a file a page with images, in Postscript. - Load the file in an editor. It says "PostScript Level 2" in the header. - Try to print that file to a PostScript level 2 printer. Result: The images are not printed, since they are encoded in a way only PS Level 2 printers can manage. I reopen the bug, although the issue is not in FF, but Cairo, it seems. The patch in FF is right!. Must I open a new bug?

(In reply to comment #35) > Result: The images are not printed, since they are encoded in a way only PS > Level 2 printers can manage. I tested on my Level 2 printer and it works. It is a bit slow but I've committed some recent changes to cairo to improve the printing performance. Is everything printing correctly except images? What specifically in the PostScript output is Level 3 PostScript? It looks like all Level 2 PostScript to me. It would help to see the PostScript output you are getting.

Let's close this bug since we are now requesting level 2 from cairo. Jesus, please file a new bug with a specific testcase, CC Adrian and mark it as blocking this bug. You probably need to attach your generated Postscript to that bug.