370631 - Printing the page results in text being black-bars and horks PC

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P1)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre Firefox
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre Firefox

Print a web-page with mixed text/grapics - note that text is unreadable and is printed a thick black bars.

Reproducible: Always

Steps to Reproduce:
1. Visit URL
2. Ctrl+P to print page
3. Note text is large black bars.


Expected Results:  
Page should be readable.

I have no idea when this may have regressed.  Any help in finding the regression range would help.

Comment 1

[Neil P. Pena]

I've had that happen to me too, not only on the provided URL but also on another website.  I'll work on creating a minimal test case now...

Comment 2

[Neil P. Pena]

Attachment: Test Case for Bug 370631

I found the part of the style sheet on the CNN website that was causing the black bars to print and created this minimal test case.

This line:

body { min-width:1000px }

causes black bars to print.

Comment 3

[John Dooley]

I have this problem on both eBay, and papal. I can not print receipts. All I get is black bars.

Comment 4

[james davis]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre

On one particular color printer, you can see the text "under" the black bar. It is like the box around the text is getting the "redacted" black over. Some text (boxes) are black and the text shows up white. I guess it all depends on the if the text was white or black to start with. For example: white text on a blue background gets me white text in a black box on the blue background.

I'm going to go back a while to find the date the regression happened.

Comment 5

[Neil P. Pena]

Here's what I've found ... the 2007-02-06-11 build is the last nightly build that does not exhibit the bug (prints properly), but the 2007-02-07-02 build does (prints black bars).

Comment 6

[Steve England [:stevee]]

Regression range from comment 5

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+10%3A00%3A00&maxdate=2007-02-07+03%3A00%3A00&cvsroot=%2Fcvsroot

Due to bug 177805?

Comment 7

[Bill Gianopoulos [:WG9s]]

The testcase prints fine for me.  I suspect this might depend on the printer resolution?

Comment 8

[james davis]

I've tried printing to various color/mono ps printers, ps to a file (deskPDF), canon photo printer and pcl5/6 printers. Virtually all the same problems for all of them using no special options or settings (using #4). So I don't think printer resolution or language has any affect. All I get is a black bar for text using the above testcase in #2. Other sites w and w/o color text have about the same results on various printers. Bill - what printer and trunk rev did you use?

Comment 9

[Bill Gianopoulos [:WG9s]]

Well, all I know is that the attached testcase prints just fine using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre on an HP 648C printer under Windows/XP SP2. 

Comment 10

[Antti Tervasmäki]

Hmm..  I can see this with PrimoPDF and PDFCreator but the testcase prints just fine with Samsung CPL-550N color laser printer. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070224 Minefield/3.0a3pre ID:2007022404 [cairo]

Comment 11

[John Dooley]

When I print the test case, all I get is black bars. I have two computer systems and three printers.
Win XP SP2.  HP K550pro, and Brother MFC8840d

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070224 Minefield/3.0a3pre ID:2007022404 [cairo]

Comment 12

[Eli Friedman]

Okay, I can reproduce... but only when my page scaling factor is set to something less than 100% (i.e. it prints just fine with 100% scaling, breaks with 99%.  I have no idea what could possibly be causing it; the printing code doesn't do anything special for scaling down pages.  It could be a GFX bug, I suppose; CCing some people who might have ideas along those lines.

Comment 13

[Antti Tervasmäki]

Hmmm..  Scaling seems to affect those PDF-printers I used above (100% works OK, normally I use "shrink to fit").
But my Samsung prints fine with all scaling factors...? 

Comment 14

[Antti Tervasmäki]

I have to correct...  My Samsung prints testcase with all scaling factors.
But I noticed that if a page has graphics and other things, scaling does affect so there is definitely something...

Comment 15

[Gary Kitchen]

I have the same problem as described above, black-barred text when trying to print a web page view. You can just barely see some text "beneath" the blackout sometimes. This occurs on any web page printout attempt. Updated to latest nightly version 3.0a3pre as of 2-27-07 11 pm. Still exhibits same behavior. I tried going to the same web pages in Internet Explorer 6.0.2900.2180, and all printouts are normal. So it is definitely Firefox which is causing the bad printouts. Behavior noticed about 2 weeks ago, worked perfectly before that.

Comment 16

[Régis Caspar]

Same problem observed here on a Brother printer (Brother HL-2070N)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 Minefield/3.0a3pre ID:2007022704 [cairo]

Comment 17

[Soothsayer]

Following on from comment 13 above, I can confirm that the scaling seems to be the cause of this problem for me.

I use an Epson R300 inkjet printer and usually have the 'shrink to fit page width' option selected.

When I print most pages (including this one) I currently get is black bars where the text should be.

However, if I print the 'my votes' page (I have none set) then it prints fine. This is probably because no scaling is taking place.

If I switch the 'shrink to fit page width' option off, then this page prints fine.

Comment 18

[Régis Caspar]

(In reply to comment #17)
> I use an Epson R300 inkjet printer and usually have the 'shrink to fit page
> width' option selected.

I have this option set on too (FWIW), disabling it now

Comment 19

[Wayne Mery (:wsmwk)]

... and PC is pretty much hosed until it cancels, which can take forever

Comment 20

[Eli Friedman]

(In reply to comment #19)
> ... and PC is pretty much hosed until it cancels, which can take forever

That's probably just because your computer isn't very happy with so much data getting thrown at it (and possibly also because you can't cancel in the middle of painting a page).  I think it's rendering the entire page as images (for a reason I don't quite understand, although it probably has something to do with changing the way we do print scaling).  As you can imagine, this is a lot slower than the normal path.

I don't know if there's anything we can do to migitate the "hosed-ness" of printing a page full of images.

Comment 23

[darin-mozilla]

This is a -major- problem for me. Printing is almost completely unusable, and thus makes Firefox/Minefield almost completely unusable for the type of work I do. FWIW, I'm using an ancient HP LaserJet 6MP (a 300 dpi PostScript laser printer). This appears to be a very common problem with a lot of people; hopefully it will get fixed sooner rather than later; it should definitely block the final release. It would be nice if there were some way to bump up the priority on this... (I get tired of having to switch browsers whenever I need to print.)

Comment 24

[Ryan VanderMeulen [:RyanVM]]

In my experience, the workaround (setting to 100%) is spotty at best. This is a serious pain in the arse. Is there a way to nominate this for 1.9a5 (since I'm assuming that the ship's already sailed for a4)?

Comment 25

[Eli Friedman]

Hmm, looks like this was partly fixed by bug 367036.  By "partly fixed", I mean there aren't black bars anymore.

We really shouldn't be using an image fallback for simple scaling, though; it's very slow. A fix here be nice, but it's not quite as critical.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Yeah, it's far from ideal to print to PDF only for the text to be one big image instead of selectable text. Not to mention much larger. For comparison's sake, I printed the same page to PDF (using PDFCreator) using both the Trunk and IE7. The Trunk PDF was 350K and the IE7 PDF was 12K, and obviously the IE7 PDF had actual selectable text. Yipes.

So, I'm thinking we should resolve this bug as fixed by 367036 and file a new bug for the whole using images issue.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

This was fixed by the checkin for bug 367036 as noted in comment #25. Bug 378307 filed for the remaining issue noted.