-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebView2 PDF printing should default to Actual Size, not Fit To Page #3691
Comments
Thanks, I've added this to our feature backlog. |
Hi @FalconFour, WebView2 follows the Edge browser behavior where the default for printing PDF is Fit To Page. The end user can change this default in the UI. If you would like to change the default you can also build a custom UI and set the scale to the desired value. You can provide feedback to the browser team if you would like this default to be changed. Thanks |
Seems to be a case of one side pointing to the other and saying "file a bug there!". WebView2 says to point to Edge; Edge says to point to WebView2. The closest I've been able to find is https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies#printpreviewstickysettings ( To save a click, this option is described thusly:
The relevant registry key would be at HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge - and create the DWord value "PrintStickySettings". For Mac, it gives much less useful info - saying only "Preference Key Name: PrintStickySettings" and an example value of However, in-line with the irrational option settings, and after confirming it's shown/enumerated in edge://policies, I have tried both "0" (verified after restart in Edge policies) and "1" (also verified), and after printing a page, it still does not retain my "actual size" option. Can we get some cooperation between Edge and WebView2 folks to get this nonsense default scaling option fixed? |
Is your feature request related to a problem? Please describe.
PDF documents are, by design, intended to be one-to-one representations of paper documents. When presented with a PDF, it's almost always the intended behavior to have the document printed "as-is", without scaling - cropped and centered, if needed.
A compounding factor (to make this doubly important) is that the PDF includes inherent margins - it already contains the page margins for printing. These are meant to be cropped into the printer's margins (they typically overlap - blank data is cropped and re-added as printer's margins, in effect), and thus you print an exact 1:1 replica of the PDF document.
This is especially important for printing labels, which are meant to be printed exactly as presented - instead of doing its one and only job, the PDF printing mechanism defaults to manipulating the size of the print, which causes distortion in print.
In "fit to page" mode, it takes the PDF's built-in margins (page size: 8.5" x 11") and shrinks the document to fit within the margins of the printer - typically around 0.1 to 0.25 inches on each side - thus shrinking the 8.5x11" document into about 8 x 10.5, inside a printed 8.5x11" sheet of paper. Thus, we live in a world of PDFs being shrunk ever-so-slightly compared to the original document size they were stored as.
It's almost never proper to print with scaling - which fits the PDF's (blank) margins into the scaled size of your printer's margins. If you were to repeat this, you would quickly experience a hall-of-mirrors effect as a page is "fit to page"'d into another page's margins, etc etc. It's wrong. "Fit to Page" should be a special option for edge cases, not the default.
Describe the solution you'd like and alternatives you've considered
Default setting for PDF printing should be changed to "Actual Size" (or 100%).
Alternatively, expose the setting on the page (do not bury it under "more settings" as it is today).
If it is a setting, it should be remembered between prints/between sessions/for all eternity.
Alternatively, determine if the PDF size is the same paper size as the printer, and default to Actual Size that way - or Shrink to Fit if there's a reasonably large difference.
This is a continuation from #2523 which was ended as "make a feature request", so I did.
AB#45893624
The text was updated successfully, but these errors were encountered: