https://bugs.kde.org/show_bug.cgi?id=389206
Bug ID: 389206
Summary: Efficiently generate print data when Qt's new
"arbitrary pages" feature is used
Product: okular
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: printing
Assignee: okular-de...@kde.org
Reporter: m.wegh...@posteo.de
Target Milestone: ---
Created attachment 109987
--> https://bugs.kde.org/attachment.cgi?id=109987&action=edit
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...)
--
You are receiving this mail because:
You are watching all bug changes.
