Closed
Bug 675457
Opened 13 years ago
Closed 1 year ago
Print / print-preview has no "unwritable margin" (between headers/footers & page-edge) until you switch Paper Size
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dholbert, Unassigned)
References
Details
(Keywords: regression)
STR: 1. Open Firefox with fresh profile 2. Visit about:blank or any other page. 3. File | Print Preview --> Note that header/footer (page title, URL, pagenum, datestamp) are flush with the edge of the page. 4. Enter "Page Setup" (it's a button on Print Preview, at least in Linux) 5. Pick a different Paper Size, and hit "Apply" --> Note that header/footer (page title, URL, pagenum, datestamp) are now offset somewhat from the edge of the page. 6. Repeat steps 4-5, going back to your original Paper Size --> Offset persists - header/footer are still not flush w/ edge EXPECTED RESULTS: Header/footer should be offset from edge of page somewhat. ACTUAL RESULTS: Initially, header/footer are *flush* with the edge of the page. Only after you've switched Paper Sizes, *then* they become offset in subsequent print/print preview operations. I believe this is a regression, though I'm not sure how old.
Reporter | ||
Comment 1•13 years ago
|
||
(I've verified that this affects actual printing as well as print preview, btw)
Reporter | ||
Comment 2•13 years ago
|
||
Note that this offset-from-edge-of-page is controlled by prefs named "print_unwriteable_margin_[top,right,bottom,left]" If I simply open up Page Setup and close it (without changing the paper size), these prefs get created for my default printer with the value "0" (e.g. printer_PSC-1500-series.print_unwriteable_margin_top = 0). That's incorrect. Only after I explicitly change the paper-size (and then, optionally, change it back), do these prefs get nonzero values.
Confirmed on SeaMonkey 2.4.1 (x86_64, Gecko 7.0.1), margins in an existing profile are ignored even though it worked in earlier versions, until the procedure described above is performed.
Keywords: regression
Comment 6•12 years ago
|
||
This stil seems to be the case with Firefox 10.0.3 ESR on Linux. However, for me selecting a printer (any from the list in printer-setup) and clicking Apply moves the margins to reasonable defaults - it looks like cups is providing the answers... Oddly selecting a Paper type caused all but the bottom_margin to be set reasonably. So after selecting a printer (b025) I might find that prefs.js contains: pref("printer_b025.print_unwriteable_margin_bottom", 17); pref("printer_b025.print_unwriteable_margin_left", 17); pref("printer_b025.print_unwriteable_margin_right", 17); pref("printer_b025.print_unwriteable_margin_top", 17); I'm guessing that 17 is extracted froim the PPD in some way. But if I select a A4 (which is the default for these printers anyway), I get prefs like: pref("printer_b025.print_unwriteable_margin_bottom", 50); pref("printer_b025.print_unwriteable_margin_left", 25); pref("printer_b025.print_unwriteable_margin_right", 25); pref("printer_b025.print_unwriteable_margin_top", 25); For the moment I'm adding defaultPrefs like this into a .cfg file (these numbers match what we used to get in firefox 3.6.x but maybe 17 would be better): defaultPref("printer_b025.print_unwriteable_margin_bottom", 20); defaultPref("printer_b025.print_unwriteable_margin_left", 25); defaultPref("printer_b025.print_unwriteable_margin_right", 25); defaultPref("printer_b025.print_unwriteable_margin_top", 25); to hide this from the users... (and yes I have to have those repeated for every printer), unless someone has a better trick... -- Jon
Updated•2 years ago
|
Severity: normal → S3
Reporter | ||
Comment 7•1 year ago
|
||
We fixed this at some point; haven't run into this in recent memory, and I can't reproduce now.
(Note, header/footer will still be flush with the page-edge if you have "save to pdf" as your print target, but when I choose a physical printer, I do see the header/footer shifted inwards in print preview to accommodate the unwriteable area.)
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•