1669910 - Firefox draws the header/footer at the extreme edge of writeable area, which can lead to clipped header/footer in some situations (e.g. if printer lies about printable region, or if user prints to PDF and then prints that PDF to a physical printer)

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Right now, I automatically seem to end up with 0 as my unwriteable margin for the save-to-PDF printer -- i.e. I end up with 0 in the following prefs:

print.printer_Mozilla_Save_to_PDF.print_unwriteable_margin_bottom
print.printer_Mozilla_Save_to_PDF.print_unwriteable_margin_left
print.printer_Mozilla_Save_to_PDF.print_unwriteable_margin_right
print.printer_Mozilla_Save_to_PDF.print_unwriteable_margin_top

This produces text that's exactly flush with the edge of the page, which doesn't look great in the PDF and also makes the PDF not-usefully-printable on a real physical printer with nonzero unwriteable margins.

This looks especially bad if you've got pages-per-sheet enabled (in a build with bug 1631452's patches). Here's an example of how that looks -- note the page headers and footers smooshed together at the center lines.

We should consider using nonzero defaults here. (bobowen, do you know if the current behavior with 0 is intended? and/or is this issue already tracked somewhere?)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of the smooshed-together page footers/headers with Pages Per Sheet

Here's a screenshot of the kinda-bad part of the example that I linked in comment 0.

I this screenshot: where you see "AM6", the "AM" text is the end of one page's footer, and "6" is the start of the next page's footer. And where you see "/2.0/Mozilla", the "2.0/" is the end of one page's header, and "Mozilla" is the start of the next page's header.

Comment 2

[Daniel Holbert [:dholbert]]

With unwriteable-margin set to 25 instead of 0, the same pages-per-sheet setup gives this PDF output which looks much better: https://bugzilla.mozilla.org/attachment.cgi?id=9180345

Comment 3

[Bob Owen (:bobowen)]

Yeah, I agree that it causes problems, but IIRC that is what other PDF and file based printers do.
So, you have to set a user defined margin, which is a property of our layout (if you see what I mean) not the printer.
I think some printers allow you to set margins, but I imagine that would reflect in our unwritable margins, although I haven't looked at it in detail.

I think maybe that our defaulting of our margin is a bit unreliable, sometimes I think it just comes from the defaults in the settings constructor [1].
But maybe if that gets overwritten then we lose it as a "default".

We could always have a minimum unwritable, but then some printers allow borderless printing, so that would break that.

[1] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/widget/nsPrintSettingsImpl.cpp#50

Comment 4

[Jonathan Watt [:jwatt]]

I don't think the unwritable margins are the issue here. Zero for them seems an accurate representation of where we can draw to, and I think we want to allow content to be drawn right up to the edges of the sheet if the user chooses "None" in the Margins menu. I think we should come up with some way to prevent the margins ending up flush against the edge of the sheet though. The first thing that comes to mind is giving them their own padding. Consider the behavior of data:text/html,<h1>Title when you deselect "Print headers and footers" and select "None" as the margins. That does not end up flush against the paper edges since it has its own padding. Something similar for headers and footers seems desirable.

Comment 5

[Jonathan Watt [:jwatt]]

Also, the unwritable margins are for the sheet of physical paper, not for pages. We should have our own separation between pages when we have multiple pages per sheet. Right now the frontend code has no way to pass a value for that via nsIPrintSettings though, and in fact no UI to collect a user's choice on what the separation between pages should be. I doubt such UI is even desirable. For the separation between pages for pages per sheet, maybe the platform code should decide what it's going to use, and possibly split the space giving some fraction to separation between pages and some fraction to the page content.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #5)

Also, the unwritable margins are for the sheet of physical paper, not for pages.

True.

We should have our own separation between pages

I'm not so sure about this (it's a bit subtle). Anyway, I filed bug 1670068 on the pages-per-sheet aspects here, with a few notes about other reference impls & what we might want to do.

(In reply to Jonathan Watt [:jwatt] from comment #4)

I don't think the unwritable margins are the issue here. Zero for them seems an accurate representation of where we can draw to and I think we want to allow content to be drawn right up to the edges of the sheet if the user chooses "None" in the Margins menu.

Fair enough, true.

Something similar [i.e. a little automatic breathing room] for headers and footers seems desirable.

Agreed. I think we should probably morph this bug here into "hey let's not draw the header/footer right at the bleeding-edge-extreme bounds of where we think we could possibly draw.

Comment 7

[Daniel Holbert [:dholbert]]

AlaskanEmily pointed out that there's some css-page-3 spec text about print header/footer placement; but unfortunately it doesn't actually match what any browser does, so I probably won't use it to inform our behavior here (for now at least).

In particular, the spec wants header/footer-text to be vertically centered in the margin area, which seems kind of reasonable, but no browser does that as far as I can tell. (And it has a downside that if you print two different documents with different margins, the headers/footers will be at different positions which is perhaps annoying.)

I filed https://github.com/w3c/csswg-drafts/issues/5870 to see if we can get the spec to match reality (or to double-down on its requirements if in fact that really is the behavior that more sophisticated print engines have).

Comment 9

[Daniel Holbert [:dholbert]]

https://webcompat.com/issues/130075 has a relevant use-case that's bitten by this bug -- a user doing a two-step print process, where they first print to PDF, and then later they print that PDF to an actual printer (at full scale, no shrinking-to-make-the-PDF-pages-fit-the-printable-area).

This trivially causes the headers/footers to be clipped in the final output, if the user uses Firefox in the first step of the process (to print-to-PDF), since we draw headers/footers right at the bleeding-edge of the page when we're printing to PDF, which is then too close to the edge of the page for the actual printer when the user goes to print the PDF.

Comment 10

[Daniel Holbert [:dholbert]]

(Reclassifying as "defect" given comment 9, and clarifying the defect in the bug title.)