Closed
Bug 370631
Opened 18 years ago
Closed 18 years ago
Printing the page results in text being black-bars and horks PC
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jmjjeffery, Unassigned)
References
()
Details
(Keywords: regression, testcase, Whiteboard: workaround: scale at 100%)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
Reporter | ||
Updated•18 years ago
|
Version: unspecified → Trunk
Comment 1•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
I have this problem on both eBay, and papal. I can not print receipts. All I get is black bars.
Comment 4•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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?
Keywords: testcase
Comment 7•18 years ago
|
||
The testcase prints fine for me. I suspect this might depend on the printer resolution?
Comment 8•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Product: Firefox → Core
Comment 13•18 years ago
|
||
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•18 years ago
|
||
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...
Updated•18 years ago
|
Flags: blocking1.9?
Keywords: regression
Updated•18 years ago
|
Assignee: nobody → printing
QA Contact: general
Comment 15•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
... and PC is pretty much hosed until it cancels, which can take forever
Summary: Printing the page results in text being black-bars → Printing the page results in text being black-bars and horks PC
Whiteboard: workaround: scale at 100%
Comment 20•18 years ago
|
||
(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.
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9+
Comment 23•18 years ago
|
||
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•18 years ago
|
||
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)?
Severity: major → critical
Priority: -- → P1
Comment 25•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
This was fixed by the checkin for bug 367036 as noted in comment #25. Bug 378307 filed for the remaining issue noted.
Updated•18 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•