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)

x86
Linux
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.
(I've verified that this affects actual printing as well as print preview, btw)
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
Using CUPS 1.4.4, in case that's relevant.
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
Severity: normal → S3

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.