Please change the print range dialogue to accept a more flexible page range: eg Pages: [1-5,9,30-35,last] and change the "current page" button so that it simply activates the page range so clicking on "current page" gets you "Pages: [30]" 'cos it is dead handy if I want the current page + five more. FWIW it is how acroread behaves.
The printing dialog is provided by the Qt libraries. There is an open feature request on the Qt bug tracker at https://bugreports.qt.io/browse/QTBUG-1311
*** Bug 375991 has been marked as a duplicate of this bug. ***
The QT report has been live since 2012 and is "won't fix" for now and deferred, perhaps it is time for okular (and others) to simply implement a dialogue that has this functionality rather than wait several more years? I note this was set to "resolved" "upstream" but it does not appear to be resolved upstream - perhaps "verified" "wontfix" is more appropriate?
(In reply to davidblunkett from comment #3) > The QT report has been live since 2012 and is "won't fix" for now and > deferred, perhaps it is time for okular (and others) to simply implement a > dialogue that has this functionality rather than wait several more years? Or restart the discussion about whether new features should be implemented in that Qt printing subsystem, given that the new promised class apparently did not materialize? > > I note this was set to "resolved" "upstream" but it does not appear to be > resolved upstream - perhaps "verified" "wontfix" is more appropriate? The status was the correct one for our workflow.
This makes no sense because it is not resolved and it is not fixed up-stream (and it appears that the maintainers here won't fix)...
(In reply to davidblunkett from comment #5) > This makes no sense because it is not resolved and it is not fixed up-stream > (and it appears that the maintainers here won't fix)... It totally makes sense to revisit and rediscuss the decision, also because the plans from the maintainer (who was a bit away lately) did not materialize.