1793220 - For documents with @page { size ...}, Save-to-PDF should offer a "Default" option to use author-specified size by default

Status: RESOLVED FIXED

(Toolkit :: Printing, defect, P3)

Description

[Daniel Holbert [:dholbert]]

(We might already have a bug filed for this; please dupe if so)

For a website with @page { size: ...}: if the user chooses save-to-PDF, we should probably default to generating pages that match the page's specified size, rather than the size that we saved from the most recent save-to-PDF operation.

This will probably be relevant for Google Docs printing work. If the user happens to have most recently saved-to-PDF with A5 size, and then the user print a Google Doc, we should be sure we choose Google Docs' specified page size (e.g. US Letter) rather than just restoring A5 or whatever the user most recently used.

(fchasen, who comes from the publishing world, brought this up to me at all-hands.)

Comment 1

[Daniel Holbert [:dholbert]]

(I initially was thinking we could "just" pre-select the author-provided @page size in our print Paper Size dropdown, but that's not sufficient because the author-provided size might be some bogus page size that doesn't match any of the name/predefined sizes in our dropdown.)

Comment 2

[Mark Striemer [:mstriemer]]

Fred, can you add a test case for this?

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Firefox (left) to Chrome (right). Firefox generates a US Letter size page in the PDF, by default, vs. Chrome just uses the @page rule to size the PDF output

Comment 5

[Emily McDonough [:alaskanemily]]

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

(I initially was thinking we could "just" pre-select the author-provided @page size in our print Paper Size dropdown, but that's not sufficient because the author-provided size might be some bogus page size that doesn't match any of the name/predefined sizes in our dropdown.)

Yeah, we can't do this in the general case because printers just list all of their supported paper sizes, and not what size paper they actually are loaded with. But we should definitely do this for Save-to-PDF, and I think we should be able to just tell it any paper size too?

We should possibly ensure we don't save a paper size selected in this way as the new default/last used size, too.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (custom non-standard "4in by 12in" page size) [IGNORE, better version attached later]

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

[...] the author-provided size might be some bogus page size that doesn't match any of the name/predefined sizes in our dropdown.

For completeness: here's an example of this scenario with an author-specified non-standard page size.

(Right now, we don't offer any way to use this size as the actual paper size, with our save-to-PDF backend. We just let the user pick from a dropdown of named standard sizes. In contrast, Chrome forces the user to use the author-specified page size.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (custom non-standard "4in by 12in" page size)

(er -- I still had some "A5" terminology in the text of the previous attachment. I've updated the attachment to remove that, to avoid confusion.)

Comment 8

[Fred Chasen [:fchasen]]

Attachment: Bug 1793220 - Use at-page size rule as paper size when printing to PDF r=dholbert

Adds a HonorPageRuleSize setting to allow overriding default the default paper size when print to a PDF file.

Print preview now checks for at-page size rules and if honoring them will display the preview at the specified page size.

The preview will also return the page width and height (in inches) during its callback for the frontend to use to override the default paper settings.

Comment 9

[Daniel Holbert [:dholbert]]

As noted on phabricator, I think we need a part 2 to handle & regression-test size:0.

WPT test would look something like this, as e.g. testing/web-platform/tests/css/printing/page-size-zero-001-print.html

<!DOCTYPE html>
<meta charset="utf-8">
<title></title>
<meta name="assert" content="">
<link rel="help" href="https://github.com/w3c/csswg-drafts/issues/8335">
<link rel="match" href="page-size-zero-print-ref.html">
<style>
  @page { size: 0 }
</style>
Hello

...with a title filled in, and a sentence added to the content attribute of the assertion metatag.
We should have -002 and -003 variants that are the same except with e.g .size: 3in 0 and size: 0 3in

All of the testcases should be able to share a reference case, named something like page-size-zero-print-ref.html (that has to match the match tag above). It'd have the same content except no style block (or at least no @page rule), and no match tag.

I just tested something like that^ locally and confirmed that it fails in Firefox but passes in Chrome. My expectation about correctness here is based on the assumption that the size should be treated like auto -- I've just filed https://github.com/w3c/csswg-drafts/issues/8335 to confirm that & get it reflected in the spec.

Comment 10

[Fred Chasen [:fchasen]]

Attachment: Bug 1793220 - Handle at-page size rules that use zero as width or height r=dholbert

Setting an at-page size where the width or height is zero is valid CSS but is unprintable, so a size with zero in it will be ignored with this change.

Comment 11

[Dan Burzo]

Having just finished producing a workflow for rendering PDFs with Firefox Nightly (via Puppeteer), I'm glad this is being worked on. Will this be able to produce PDFs with pages of different sizes? Also, I've noticed in the Firefox 110 release notes:

Firefox now supports CSS named pages, allowing web pages to perform per-page layout and add page-breaks in a declarative manner when printing.

If I understand correctly, elements can request pages of certain characteristics (size, margins, etc.) to which to break?

Comment 12

[Fred Chasen [:fchasen]]

(In reply to Dan Burzo from comment #11)

Having just finished producing a workflow for rendering PDFs with Firefox Nightly (via Puppeteer), I'm glad this is being worked on. Will this be able to produce PDFs with pages of different sizes? Also, I've noticed in the Firefox 110 release notes:

Firefox now supports CSS named pages, allowing web pages to perform per-page layout and add page-breaks in a declarative manner when printing.

If I understand correctly, elements can request pages of certain characteristics (size, margins, etc.) to which to break?

Unfortunately we aren't currently able to create PDFs with different sizes or orientations of paper per page, so only the first size will be used for the paper size.

Named pages can still adjust the margins (for instance swapping left / right pages margin for page spreads) but differently sized or oriented pages will scale up or down to fit within the given paper size.

For a comparison of this behavior you can view: https://www.print-css.rocks/lesson/lesson-named-pages

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/56d615e5385a
Use at-page size rule as paper size when printing to PDF r=dholbert,AlaskanEmily
https://hg.mozilla.org/integration/autoland/rev/a65d3c61d9a4
Handle at-page size rules that use zero as width or height r=dholbert

Comment 15

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/38726 for changes under testing/web-platform/tests

Comment 16

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/56d615e5385a
https://hg.mozilla.org/mozilla-central/rev/a65d3c61d9a4

Comment 17

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 18

[Daniel Holbert [:dholbert]]

Note: when testing this, I noticed that this doesn't seem to work for PDFs themselves (i.e. if you view a PDF and try to save it to PDF, you get our standard paper-size dropdown instead of using the PDF's own size). See that bug for more details.