Created attachment 83838 [details]
File Print Dialog Preview on/off mockup
The page "preview" area in the newer LO print dialog is nice for most users, most of the time.
However, there are times when the delay required to render that preview is annoying. It is especially annoying on slow systems, on thin clients, on complex/big documents, and on users remotely running LO. And the negativity is compounded since the preview is re-rendered with most UI selection/changes (printer change, Properties, Page Layout, etc).
There should be a "Preview" on/off checkbox below the page number indicator- and the setting remembered across sessions. We already have such an option in the file manager dialog when using Insert->Picture->From File.
I have attached a "before and after" mockup graphic attachment.
@Mike - please leave a short comment when confirming bugs - easier to tell who confirmed it :) Thanks for confirming this one
I vote for this enhancement. We run LO on a Windows server with about 30 users and the print dialog is unacceptably slow. This is mostly annoying if the print range is being changed - the preview is unnecessarily rerendered after each digit being typed into the box, even though the preview page does not change. The users complain a lot about that.
The Preview" on/off checkbox could be a solution, but, maybe, it would be enough to rerender only if necessary and not after each change. For example, the "number of copies" control does not enforce rerendering.
Our company has the same trouble with the preview in the print dialog.
We use LibreOffice in a Citrix XenApp environment(build on top of Terminal Servers) and experience a lot of trouble, especially with the Citrix Universal Print driver.
Through the print dialogue preview consumes a lot of cpu power while getting the printer information via network, the print operation might take a lot of time.
The print dialoge is also a problem on older fat clients with weak CPUs and takes up to 1 Minute until users can print a vew simple pages.
In my oppinion a solution to permanently deactivate the print dialog preview is better than render only once, because even the initial rendering slows down the performance
*** Bug 83920 has been marked as a duplicate of this bug. ***
Proposal for solving this issue in general.
Assumption: Also other regularly updated previews are troublesome - besides print preview (e.g. insert diagram, insert picture from file). However, previews itself are considered to be helpful and should be available on demand.
* Add expert option "Render previews automatically" (LibO wide setting)
* Expert option: Since common issue if LibO is set up for remote use / on thin clients - otherwise it might further clutter the UI.
* If option is "true" (default setting), then behave as today (and render previews, see technical note below).
* If option is "false", then ...
** Show/reserve space for preview, show info like "Click for preview"
** If user clicks on space, then previews are being rendered/shown (only for this dialog session).
Note: Technically, previews should only be updated if "something" changed from the user's point-of-view (e.g if the print range is changed, it is not required to redraw the currently displayed page preview, if the previewed page is identical).
Detailed spec / description on demand.
(In reply to Christoph from comment #5)
> Proposal for solving this issue in general.
I like your proposal.
Dear Daniel Silva,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Daniel committed a patch related to this issue.
It has been pushed to "master":
tdf#67905 adds an option to disable print preview in print dialog
It will be available in 6.3.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
This bug was also solved in my feature branch and we havefinally merged it master. Sorry for any inconvenience I may have caused.