Bug 389206

Summary: Efficiently generate print data when Qt's new "arbitrary pages" feature is used
Product: [Applications] okular Reporter: Michael Weghorn <m.weghorn>
Component: printingAssignee: Okular developers <okular-devel>
Status: REPORTED ---    
Severity: wishlist CC: jeremy.lorelli.1337, m.weghorn, nate, oliver.sander, simonandric5
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Patch that demonstrates the evaluation of pages to be printed (not meant for inclusion "as is")

Description Michael Weghorn 2018-01-19 14:13:35 UTC 
Created attachment 109987 [details]
Patch that demonstrates the evaluation of pages to be printed (not meant for inclusion "as is")

With https://codereview.qt-project.org/#/c/215390/, the possibility to select arbitrary page ranges in the Qt print dialog is introduced, if CUPS is used as a printing system.
This will be part of the upcoming Qt version 5.11.

By default, the application still generates all pages to be printed and the actual selection is done later by CUPS (based on the "page-ranges" option that is passed to it).
    
This can be very inefficient, e.g.  when printing just a few pages of a large PDF document.

For example:
* If a single page out of a large PDF document is selected for printing using the "from page X to page Y" option in to print dialog, this is very fast, since only this page is taken into account to generate the print data.
* If however, the new "arbitrary pages" option is chosen to select the very same page, this may take very long, since Okular uses all pages to generate the print data, which is inefficient.

It would be good to improve the effiency when the arbitrary page selection feature is used and only use those pages for print data generation that are actually selected.

The current problem/difficulty about using this feature properly is the "arbitrary pages" feature is not part of Qt's public API.

The attached patch "0001-TEST-Demonstrate-use-of-arbitrary-page-options-intro.patch" is a "quick and dirty" solution, but I do not really like the approach (which is also why I have not submitted a review request to Phabricator), s.a. the comments in the code.

Ideas on how to properly implement this are welcome.

(In my opinion, the nicest solution would probably be to have the feature as part of Qt's public API...)
Comment 1 Oliver Sander 2018-01-23 15:09:52 UTC 
Does the problem you describe vanish when you let Okular directly into a QPrinter (i.e., by printing with rasterization)?
Comment 2 Michael Weghorn 2018-01-23 16:52:03 UTC 
(In reply to Oliver Sander from comment #1)
> Does the problem you describe vanish when you let Okular directly into a
> QPrinter (i.e., by printing with rasterization)?

No, the behaviour is the same, since Qt basically handles everything like it does for the "print all pages" ("QPrinter::AllPages" is set) and just passes the "page-ranges" option to CUPS, which then selects the relevant pages in the next step.
Comment 3 Yuri Chornoivan 2020-05-18 05:45:06 UTC 
*** Bug 421670 has been marked as a duplicate of this bug. ***