IssueTracker

Have you actually checked to make sure the paper size is (in)correct? Do you have specific examples where the paper size is wrong? If so, what locale?

This most easily be proven by running PdfPrinterHandlerGetCapabilityTest.GetCapability and setting the locale in the test class to en-CA. The test will fail because the generated default paper size will be ISO A4 instead of US Letter.

This happens because GetPdfCapabilities() in pdf_printer_handler.cc only checks whether the locale is en-US when deciding to fallback on US Letter or ISO A4. This check fails to consider other locales that may be accustomed to US Letter, notably *-CA and es-US.

It's not clear what "setting the locale in the test class to en-CA" means exactly. There exists locale code at several different layers, e.g. base/i18n, ui/base/l10n. So please be specific here. Also, what OS does https://crbug.com/chromium/1026416#c2 refer to?

While studying (modified) unit test behavior is helpful, it is also be good to understand what the high level bug is. The bug report template had a place to write down the steps to reproduce the bug. What would those steps look like?

What steps will reproduce the problem?
Each platform applies language and region preferences differently, but here's how to replicate the problem with a Mac.
(1) Go to Mac Printers & Scanners settings.
(2) Choose a default paper size that is not Letter, Legal, or any of the ISO A paper sizes.
(3) Go to Mac Languages & Regions.
(4) Select Français (Canada) or Español (U.S.) as your preferred language.
(5) Restart Chrome
(6) Open print preview, and select 'Save as PDF' as the destination
(7) Notice that the paper size is defaulted to A4, and not Letter.
(8) If you are not proficient in French or Spanish, hopefully switch back to your language in the Mac system preferences :)

Even though the language is set to French or Spanish, the region is still Canada and the U.S., respectively. Therefore, the default paper size should be Letter, as is custom in those countries.

Is this Mac-specific then?

From what I can tell from the part of the code that causes this, it doesn't have to be Mac specific. It happens whenever PrintingContext::GetPdfPaperSizeDeviceUnits() returns a size that is not ISO A#, Letter, Legal, or Ledger.

The aforementioned function is implemented uniquely for each platform, but on Macs it returns the default paper size specified in the preferences. Windows and ChromeOS seem to derive the default paper size from the locale. And I'm not totally sure about Linux, but it gets some sort of default from the system with gtk_page_setup_new() (I tried finding documentation or source code to see what the defaults are defined as, but couldn't find anything meaningful).

Ultimately, this is definitely a problem for Macs, and perhaps a problem on Linux, but I'll need to investigate further.
It can also be a problem on other platforms if for some reason the locale's default paper size is not one listed one.

Changing locales in Linux is easy. e.g. Just set LANG=ar_SA.UTF-8. I can show. In any case, let's finish defining the scope of this problem first.

BTW, do you have an authoritative list of locales that should use US Letter somewhere? The expectations here are a bit spread out among comments.

I couldn't find an authoritative source with a nice table, but I queried ulocdata_getPaperSize() with every locale and I put the results on a table:
https://docs.google.com/spreadsheets/d/1J4Q8b5xk7dSojd0Fb6HmvIZ91avo7dXxmFSF5MrHkBc/edit?usp=sharing

It's not just the US and Canada that use NA Letter. Most Central American and South American countries do as well.

Not out for review until the entire scope of the problem is defined, but I have a preliminary fix for this: crrev.com/c/1929772

I found a map that corroborates the data presented in https://crbug.com/chromium/1026416#c9

https://en.wikipedia.org/wiki/Paper_size#/media/File:Prevalent_default_paper_size.svg

Status change, as issue has an owner.  Leaving it to dhoss to further adjust if it should be "started".

The CL in https://crbug.com/chromium/1026416#c10 would need some updating if anyone decides to pick this up in the future.

This issue was migrated from crbug.com/chromium/1026416?no_tracker_redirect=1

[Monorail components added to Component Tags custom field.]