The current printing setup has functionality to retrieve a list of paper sizes for a selected printer. However, we plan to expose a "Save as PDF" option within the printer list as well.

This option should come with a list of paper sizes to choose from. Presumably we should choose a set of commonly used paper sizes, and hopefully they will be influenced in some way by locale.

Maybe you'd have some useful thoughts on this, Jonathan?

Hmm, pretty hard to know where to draw the line -- there are an awful lot of paper sizes in existence. https://en.wikipedia.org/wiki/Paper_size

The most commonly used, surely, would be A4 and US Letter (depending on locale); we should make the appropriate one of those the default.

Beyond that, the list of sizes that have CSS @page size keywords is probably as good a choice as any.

In an ideal world, I guess it would also be extensible somehow, so that the rare user who really wants to save PDFs in Monarch Envelope size or whatever can make that happen. But that sounds like a future enhancement (a long way down the priority list!)

I wonder if we should use the paper sizes that the user's last used/default/first physical printer supports, if there is one? (Or even the combined list for all available printers?!?) Then the user can create PDFs that are compatible with their printer, and we may even get localization of the printer names for free? Then we'd only have to fall back to our own, possibly less ideal, list?

I wondered about that, too, but am not sure it's a good idea for the list to vary like that. It'd make more sense if "Save as PDF" were a button in the dialog (alongside Print), so it could be used while any other driver is the currently-selected printer, but if we're treating "Save as PDF" as a separate driver, it's less clear where to pull such a list from.

It'd make more sense if "Save as PDF" were a button in the dialog (alongside Print), so it could be used while any other driver is the currently-selected printer...

This is the way it works on Safari.

I also thought about using the list of other paper sizes from printers, but I think that would be unfortunate for the user who does not have a printer, has never connected to a printer, and wants to print to pdf.

At least for an initial implementation -- we can always extend it later if it seems worthwhile -- I propose that we should go with this list of standard/widely-used paper names and sizes:

• A5 (148mm x 210mm)
• A4 (210mm x 297mm)
• A3 (297mm x 420mm)
• B5 (176mm x 250mm)
• B4 (250mm x 353mm)
• JIS-B5 (182mm x 257mm)
• JIS-B4 (257mm x 364mm)
• US Letter (8.5" x 11")
• US Legal (8.5" x 14")
• US Ledger (11" x 17")

These are the paper sizes that have individual keywords in CSS, which seems a good starting point (particularly for a web browser).

What's not clear to me at the moment -- partly because I don't have a good grasp of how the Save to PDF "printer" is implemented -- is where we need this list to live. Do we actually create an instance of an nsIPrinter subclass in all cases (although Save to PDF does not appear in the printer list), or is the Save to PDF path entirely separate on some platforms?

We'll need to enable localization of the names, as they'll appear in the UI.

There might be a case for allowing localizers to customize the actual list (not just the names), as some regions may have different paper sizes that are more commonly used, but I'm not currently convinced this is necessary. I think we should initially keep things simple, and see whether any real demand for more flexibility/complexity arises.

There is currently no implementation of nsIPrinter for save to PDF. The idea was discussed here (1658029), but we decided against it in favor of handling it on the front end here (1658043).

I also don't think that we will need an nsIPrinter impl for this, but I could see exposing a Array<nsIPaper> saveToPDFPaperList in the IDL that is available to the front end, which would contain these paper sizes that you have listed.

I think the chance of these paper-size names/dimensions ever changing is very low, so I don't see any problem with hard-coding the names/dimensions for now.

As you said, if we need a more extensible list, we can worry about it at a later time. What do you think?

Hard-coding the list of dimensions is fine, I think; those are standards that aren't going to change. And initially, at least, a fixed list seems like a good starting point.

But the displayed names for the sizes presumably need to be localizable, so I guess the list will have IDs for each paper size and then there'll be a Fluent .ftl file giving the human-language names.

For a "real" printer, the supported paper sizes (as nsIPaper) are exposed to the front-end via nsIPrinter.paperList. But for Save to PDF we don't have an nsIPrinter. So should we expose saveToPdfPaperList on nsIPrinterList, I guess? Or is there a better place to do this?

Should localization happen inside the implementation of saveToPdfPaperList, so that the nsIPaper instances it returns have localized names, or should it return IDs such as "letter" and the front-end take responsibility for localizing this to "US Letter", "Carta EE. UU.", "美国信纸", or whatever as required?

As a starting point, here's a patch that creates an nsIPrinterList.saveToPdfPaperList, analogous to nsIPrinter.paperList, and populates it with the standard sizes that CSS recognizes.

This doesn't yet address localization of the names.

Ordinarily I would say we should localize on the front-end, but as the other paper lists are provided display-ready, I don't have a strong opinion here. We are already past the nominal cut-off date for new strings for 81 though so identifying the strings and getting them landed asap is a priority. Maybe that changes the implementation decision?

I don't think Chrome localizes their paper names FWIW:

https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/browser/resources/print_preview/data/destination_store.js#L1366

It also looks like the Save-to-PDF list is hardcoded, and the choice between whether the default should be A4 or Letter is based purely on whether the locale is "en-US" or not:

https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/browser/ui/webui/print_preview/pdf_printer_handler.cc#L103

I think it would be reasonable to say that the name localization would be nice to have, but it doesn't seem like a blocker to just getting the name list landed for the sake of having the functionality.

(In reply to Sam Foster [:sfoster] (he/him) from comment #12)

Ordinarily I would say we should localize on the front-end, but as the other paper lists are provided display-ready, I don't have a strong opinion here.

I wondered about that. So if we provide IDs rather than human-friendly names here, the front end would need to do an extra step that it doesn't have to do with "real" printers. That seems non-ideal to me, and is a reason I figured we might want to have localization happen internally in the platform here, so that what the front end gets is directly equivalent to what it gets for any other printer.

On the other hand, I don't actually know how to implement the localization in the C++ code here; will need to ask/poke around.

We are already past the nominal cut-off date for new strings for 81 though so identifying the strings and getting them landed asap is a priority. Maybe that changes the implementation decision?

I have a patch that adds paper-name strings to toolkit/locales/en-US/toolkit/printing/printUI.ftl which I can post for consideration, but they're not currently connected to anything. Would it be useful (if we're happy with the list) to go ahead and land this to get the strings in, even if we're not sure yet quite how to use them?

(I think ultimately they should be localizable, although some locales may just stick with the en-US names; but we could initially ship with them non-localized if it proves to be a hurdle.)

(In reply to Jonathan Kew (:jfkthame) from comment #15)

I have a patch that adds paper-name strings to toolkit/locales/en-US/toolkit/printing/printUI.ftl which I can post for consideration, but they're not currently connected to anything. Would it be useful (if we're happy with the list) to go ahead and land this to get the strings in, even if we're not sure yet quite how to use them?

(I think ultimately they should be localizable, although some locales may just stick with the en-US names; but we could initially ship with them non-localized if it proves to be a hurdle.)

I think landing the strings there and seeing if uplifting them is even possible would be a useful first step.

I need this list of paper sizes for bug 1659757. I've tried working around it for now a couple of ways, but as the PDF is our fallback default "printer", we need something defined somewhere for the paper size picker to initialize for anyone with no printer attached (a common scenario.) But, I'm happy to stub in something temporary on bug 1659757 which gets replaced when this bug is done if necessary.

OK, I've refreshed the patches here and flagged for review; I suggest we get this landed ASAP to give the front-end something to work with.

There are a set of strings for paper-name localization, but they're not currently hooked up; the API just returns hard-coded values, but we could live with that temporarily if we don't get the localization implemented right away.

Backed out 2 changesets (Bug 1659781) for causing bustages in nsPrinterListBase.h

Backout link: https://hg.mozilla.org/integration/autoland/rev/6db3aa6401ef3df3e7d3f7b58dac018b46b14ce8

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedTaskRun=CbIc0C8eS1SHRgvvNeZeOA.0&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&revision=c969b57bb3565164ba30c4da08b2159f0ec2a239

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314060723&repo=autoland&lineNumber=51625

https://hg.mozilla.org/mozilla-central/rev/370a4fd8d865
https://hg.mozilla.org/mozilla-central/rev/47c426304111

Reminder to request Beta approval.

Comment on attachment 9171690 [details]
Bug 1659781 - Create a list of common standard paper sizes for Save to PDF output, and expose them via nsIPrinterList.fallbackPaperList. r=jwatt

Beta/Release Uplift Approval Request

• User impact if declined: Needed as part of the Save to PDF feature in the new Print UI
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: (Expect this to be tested as part of Save to PDF workflow once the UI is more complete.)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Adds a new API to nsIPrinterList; no effect on existing code as it is not used.
• String changes made/needed: The second patch here adds a small set of strings for paper size names; however, localizing them is not critical for now.

Francesco, can you confirm this is ok to uplift?

(In reply to Julien Cristau [:jcristau] from comment #25)

Francesco, can you confirm this is ok to uplift?

I think it's OK, given the type of strings.

Comment on attachment 9171690 [details]
Bug 1659781 - Create a list of common standard paper sizes for Save to PDF output, and expose them via nsIPrinterList.fallbackPaperList. r=jwatt

approved for 81.0b3

https://hg.mozilla.org/releases/mozilla-beta/rev/66bc15a05f9b
https://hg.mozilla.org/releases/mozilla-beta/rev/90e08fe6aca0