Bug 374807

Summary:	print ranges
Product:	[Applications] okular	Reporter:	davidblunkett <dav1dblunk3tt>
Component:	printing	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	luigi.toscano, phi.reporter
Priority:	NOR
Version First Reported In:	0.25.0
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugreports.qt.io/browse/QTBUG-1311
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description davidblunkett 2017-01-09 12:04:38 UTC

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.

Comment 1 Christoph Feck 2017-01-09 20:23:12 UTC

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

Comment 2 Christoph Feck 2017-02-06 12:04:51 UTC

*** Bug 375991 has been marked as a duplicate of this bug. ***

Comment 3 davidblunkett 2017-02-09 20:50:18 UTC

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?

Comment 4 Luigi Toscano 2017-02-09 20:52:46 UTC

(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.

Comment 5 davidblunkett 2017-02-11 16:50:01 UTC

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)...

Comment 6 Luigi Toscano 2017-02-11 19:16:13 UTC

(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.