Print Preview, Page Setup, Zoom Scale Factors
I am used to using the CHtmlView control with MFC. So how do you invoke Page Setup, Print Preview and Zoom Scale Factors with this viewer?
For zoom you should be able to use the ZoomFactor property.
Those others sound related to printing right? We don't currently have programmatic support for printing from the WebView2 apis, but you should be able to invoke the print dialogs using the javascript window.print() api. You can call javascript on your page using ExecuteScriptAsync. Can you try that?
I am pleased that use have a facility for setting the zoom factor.
My other queries are indeed related to printing. Right now I am using CHtmlView in my MFC project and at the heart is the HTML Viewer. So I offer via my own menu to kickstart various things like printing etc.
To me, trying to use javascript etc is way to complicated. The user uses a XSL script with a XML data file to create the HTML output for display. So I don't want to complicate things in the XSL scripts.
What I have works so no need to blow it up. I just thought if they were working on a CHtmlView replacement that as a minimum it would offer the same level of functionality with the new browser via its own ExecWB calls.
I've added this as a feature ask on our backlog. We probably won't be able to get to it for a while though, so if you'd like to migrate I would continue to investigate potential workarounds, even if they are more complicated then your current solution.
Adding my comment in here that having to use the javascript API to print has a few problems.
For example, it will display in the webview control rather than outside it, as the original winforms WebBrowser Print would, so if the control is small, you cannot see the entire print area.
We do not have Print and Print Preview, only the browser's print preview.
Also, we use WebBrowser to view PDF and XML files, which are not hosted in a web page and thus cannot have script attached to it. So to move to WebView2 means we can no longer use the browser control to print these.
Thank you!
Sounds like much more work needs to be done on this. As a minimum is should be feature rich and offer what the existing browser control offered, albeit through a different path.
But at the moment it is not possible for me to even consider this webbrowser version because it lacks too much functionality.
I appreciate the feedback @nikki9696 and @ajtruckle, sorry we don't have this functionality yet. I'll update this thread when I have more info to share. Thanks!
Once feature I'm not seeing mentioned is the ability to print silently. Which is to say send a print job to a specified printer without additional user interaction. This is useful in for example POS applications.
In addition to silently printing and print to a specific printer or printer tray, printing landscape automatically would be very helpful. Right now not being able to print landscape is a deal breaker.
The Chromium DevTools Protocol provides APIs to instrument, inspect, debug, and profile Chromium-based browsers. Will the API support Page.printToPDF method to enable developers to implement silent printing to PDF? See Use Chromium DevTools Protocol in WebView2
Adding my comment in here that having to use the javascript API to print has a few problems.
For example, it will display in the webview control rather than outside it, as the original winforms WebBrowser Print would, so if the control is small, you cannot see the entire print area.
We do not have Print and Print Preview, only the browser's print preview.
Also, we use WebBrowser to view PDF and XML files, which are not hosted in a web page and thus cannot have script attached to it. So to move to WebView2 means we can no longer use the browser control to print these.
Thank you!
I noticed the same things. The print window is forced to the browser control which looks odd when the control is part of a dialog. It needs to be ideally like ie where the print preview comes up maximised.
Once feature I'm not seeing mentioned is the ability to print silently. Which is to say send a print job to a specified printer without additional user interaction. This is useful in for example POS applications.
I’m looking for something similar. In the sense that we have:
- webview2 visible on dialog
- Another webview2 not visible for printing
when The user goes to print it uses the hidden webview2 control and invokes a print window. I can’t do this right now.
Hello,
We have added support for the Print API which supports silent printing, page set up, etc. Please let us know if this API addresses your scenario.
Thank you!
Hi @nishitha-burman
I am aware of the new Print API but I am waiting for it to be in the stable release.
The things that it still does not address;
1, Missing properties for printing (eg. specifying the look and feel of header / footer like you could in IE). 2. No ability to print preview full screen (think i raised a separate ticket)?
I know the print api supports customer print dialog which is supposed to address issue 2, but:
- I have no idea how to actually implement it in my MFC application. The help topics describe it but no actual worked example.
- I assume I will have to manage my own set if GUI labels for the print window and I support over 50 languages, So this whole approach is reinventing the wheel and appears to add a huge amount of maintenance / complexity to my program when all I want to do is have a modal print preview that is full screen.
Hi @nishitha-burman
I just read the Print Api notes, but didn't figure out haw to make a page set up (or print preview).
I saw only the CoreWebView2.PrintAsync, CoreWebView2.PrintToPdfStreamAsync, CoreWebView2.ShowPrintUI methods and the print settings objects,
I would like something like webBrowser.ShowPageSetupDialog() or webBrowser.ShowPrintPreviewDialog() for webBrowser in windowsForms.
Is there a documentation somewhere haw I can use the webview2 (or xaml webbrowser) to achieve page set up similar functionality?
Thanks,
Maria
@champnic Note that a workable solution for printing maximized is showing the page in a popup window, maximized and invoking print from there. At least as a workaround.
I know this tiocket also refers to missing properties on the page setup too.
As this is still marked as tracked, and the print api is stable, can I ask what the tracked aspect of the ticket is for? The missing page setup properties for header / footer? Print UI maximised to the display? I am not sure.