My current pages-per-sheet implementation in bug 1669910 is based on what happens in the GTK system print dialog if you use the "Pages per side" dropdown in the Page Setup tab.

Using 4 pages per sheet as an example (2x2 grid), you end up with output that literally just scales & tiles four sheet's worth of content, side-by-side (with the virtual "paper edges" exactly flush with each other).

I took this as the initial approach since it's relatively straightforward & it matched this GTK reference implementation. However, it has a few drawbacks for content that's drawing in the danger zone near the edge of the unwriteable area (e.g. headers and footers which currently are drawn precisely at the boundaries):

(1) Smooshed content: If we're configured to draw page header/footer right at the edge of the page, then adjacent headers-footers end up smooshed together and look like one continuous string, as shown in attachment 9180351 [details] (a screenshot from the center of a page).

(2) Clipped content: If we have (for example) a quarter-inch unwriteable margin, with some content (e.g. the header) positioned right at the edge of that unwriteable area, then when we scale down the whole page by 50%, we'll end up positioning the shrunken header at an eighth-inch from the edge of the page, which means it won't be able to fully paint given the physical limitations of the page.

So: to address this, we should consider tweaking the pages-per-sheet impl to:
(1) restrict itself to the writeable area of the page.
...and either:
(2a) add some sort of small "bonus margin" between the tiled pages. (This doesn't have to be related to the pages-per-sheet; it just needs to be enough to offer some clear separation between one page and the next.)
...OR:
(2b) ensure the page margins (for our "virtual pages") are large enough to make the between-page boundaries clear.

It looks like Chrome does approximately (1) and (2b). They disable the margin customization UI entirely for pages-per-sheet mode, and they also don't draw their headers/footers right up to the edge of the unwriteable area in the first place; they're placed somewhere in the middle of the page-margins, not right at the extremes. So this leaves a clear visual distinction between the tiled pages, without (I think?) needing to add any arbitrary synthetic bonus space between the tiled pages.

Given we'll need to do this to avoid having the multiple pages per sheet option result in clipping (for which/how many printers?), I think we should start this at P1.

Rough plan here:

(A) Subtract (i.e. reserve) the unwritable margins on the physical sheet, when determining the area that we have available for placing our grid of pages.

(B) Let each individual page account for its unwritable margins, too. This happens automatically, so it's easy/convenient. (I don't love it since it's got a hint of redundancy, given that weve already accounted for unwritable margins at the edge of the sheet. Theoretically/arguably, we could "collapse" the exterior per-page unwritable margins into the sheet's unwritable margin, for the pages that are at the edge of the sheet. But that gets somewhat complex due to the possibility of the pages having differing margin from the sheet on the relevant side, due to being rotated in bug 1669905; and it's also complex due to the fact that the unwritable margins are already overlaid with each page's own user-configurable margin. So: this might be fodder for a followup bug, but not something to worry about for now.)

These parts -- (A)/(B) -- address both the "clipped" and the "smooshed" concerns in comment 0 here, except for in the scenario where unwritable margins are 0 (e.g. with print-to-PDF) in which case smooshing is still a concern. To address that, I plan on also doing:

(C) Enforce a minimum separation between the pages on a sheet (maybe 1/8th of an inch).

Note that (A) and (C) will typically end up meaning that we've got a little extra space in one axis or another, since the pages' aspect ratio won't necessarily match the available-area-on-the-sheet aspect ratio. I'll just center the page-grid in whichever axis has extra space. (This is already something that we'll need to handle in bug 1669905 for the scenario where the pages are rotated with respect to the sheet.)

Depends on D98713

I'm going to punt change "(C)" from comment 2 (a solution for middle-of-page "smooshing") to a followup bug, because:

• after the main fix here, that smooshing issue becomes harder to trigger. )It'll only surface when you have ~zero unwriteable margins, which is probably not common for physical printers. They tend to have some nonzero unwriteable area).
• the smooshing is more of an aesthetic papercut than a dataloss issue, so there's probably less pressure and the space of good solutions isn't as clear-cut.
• when smooshing does occur, only our header/footer will be smooshed, if the user's using default page margin settings. (And if the user has asked for 0 page margins, then arguably they're kind of asking for the content to be smooshed.)

I'll be adding a bit more to the mochitests patch tomorrow (adding another couple of testcases, and adding more explanation in the already-included testcase).

The testcase that I included does pass locally. Let's see if Try likes it:
https://treeherder.mozilla.org/jobs?repo=try&revision=5c28f5bf085c0f81a62688298c1c947e19264a69

(The windows try failures are really bug 1680838; it seems we can't reliably set custom unwriteable margin values from test code, on Windows.)

Try run: https://treeherder.mozilla.org/jobs?repo=try&revision=60b8a5688cf12dda12193870bcbab4dd228cc28a

If that doesn't show any issues, I'll go ahead and trigger lando.

(In reply to Daniel Holbert [:dholbert] from comment #5)

I'm going to punt change "(C)" from comment 2 (a solution for middle-of-page "smooshing") to a followup bug

Following up on this: I think bug 1669910 is basically the right fix for this "smooshing" issue. That bug will address the main papercut pain-point where it's possible to trigger a smooshing-issue. For other cases (e.g. if a user chooses "margins:none", and 4 pages-per-sheet, and they print to PDF or another printer with no off-limits areas), it's pretty reasonable that we print their 4 pages as directly adjacent to one another; and the user may even be expecting & depending on this for their use-case.

https://hg.mozilla.org/mozilla-central/rev/8c8bbda7c6fa
https://hg.mozilla.org/mozilla-central/rev/43ad68f18822