Closed Bug 418428 Opened 15 years ago Closed 15 years ago

Printing gets garbled


(Core :: Print Preview, defect, P2)

Windows XP





(Reporter: anttit, Assigned: roc)




(Keywords: regression, testcase)


(4 files)

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

If I print or print preview that url, it gets garbled if settings are "shrink to fit" or 100% but is OK it setting is 80%. Used font is also huge.

Reproducible: Always

Steps to Reproduce:
1.Go to that url
2.print preview or print
3.see garbled text right under "Professional reviews"
Actual Results:  
Garbled text and too big text?

Expected Results:  
Nice printing to page

This worked at least sunday, so it is a regression maybe from 
Attached file Print example
Finally I got some time get regression window and it is: works broken

After that time printing with "shrink to fit" makes prints, that don't fit or are broken and too BIG! Manual settings work though....
Checkins to module PhoenixTinderbox between 2008-02-17 12:30 and 2008-02-17 13:39 :

-->bug 374141
Blocks: 374141
Keywords: regression
Version: unspecified → Trunk
Attachment #304506 - Attachment mime type: text/plain → application/pdf
Attached file testcase
I cannot see the garbled text issue, but I see the text being much bigger now on print preview.
Component: General → Print Preview
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → printing
Flags: blocking1.9?
Garbled text does not happen every time, it depends printing settings heavily.
With my settings I can still see it with that given Url.
(A4 paper size, portrait, margins left 15, others 7, printer is PDF Creator)
If I set printing setting to 80% (from shrink to fit) it disappears.

Shrink to Fit is now 100%, it may fit, mostly not..:-(
roc: 374141 seems to have regressed this, can you take a look?
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
There are really two issues here. The "garbled text" bug is almost certainly a layout bug but I can't reproduce it; that would not be a direct regression from bug 374141, although the fix for bug 374141 might have changed the circumstances under which it appears.

The issues with the text size and shrink-to-fit are a separate issue and we should make this bug about them.
Attached file shrink-to-fit testcase
It seems to me that shrink-to-fit is just completely broken on Mac and Windows (and probably Linux although I didn't test). Not sure when that happened or why it hasn't been reported more...
Well, I'm wrong. The code explicitly refuses to shrink by a factor of more than 0.6. Other than that, shrink-to-fit works fine.
Attached patch fixSplinter Review
Well this is embarrassing. I should have caught this immediately. We were leaving dotsArePixels set to true, which caused the logic "make CSS pixels be an integer multiple of device pixels to kick in", which with the nominal 144dpi meant we were making each CSS pixel 2 device pixels, i.e. 1/72 of an inch, which was too big. Setting dotsArePixels relaxes that constraint and everything looks fine.
Attachment #307166 - Flags: review?(pavlov)
Whiteboard: [needs review]
Antti: shrink to fit looks fine to me. If you can reproduce a bug where shrink to fit obviously isn't doing *any* shrinking when content is overflowing to the right, please file a new bug for that with a detailed testcase and CC me.
Note that in the attached PDF output, even though the text is garbled and too large, we would not expect "shrink to fit" to be shrinking anything since there is no overflow to the right --- everything "fits" horizontally already (although it is big).
Main concern was that "huge" font size and garbling I see on that given page still. I have seen pages which overflow and are cut now with big text (my bank is one) but I have to test and see after the size is right...
Attachment #307166 - Flags: review?(pavlov) → review+
Whiteboard: [needs review] → [needs landing]
checked in
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Yes, It's now OK!  --> verified
You need to log in before you can comment on or make changes to this bug.