Bug 436388

Summary: Printing page ranges doesn't work with "Print to File (PDF)"
Product: [Applications] okular Reporter: Bernie Innocenti <bernie>
Component: printingAssignee: Okular developers <okular-devel>
Status: CONFIRMED ---    
Severity: normal CC: aacid, bernie, null, ostroffjh, Valeryan_24
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Bernie Innocenti 2021-04-30 04:24:55 UTC
On Linux, printing a range of pages does not work when "Print to File (PDF)" is selected - the entire file gets printed.

(forked from bug #422626)

STEPS TO REPRODUCE
1. Open any file with multiple pages
2. Choose "Print..." from the menu
3. Click "Options >>"
4. Select the Pages radio button
5. Enter "2-3" in the text box
6. Select "Print"

OBSERVED RESULT
All pages were printed

EXPECTED RESULT
Only pages 2 and 3 should be printed

SOFTWARE/OS VERSIONS
KDE Plasma Version: git master (20210430)
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2+kde+r188
Comment 1 Bernie Innocenti 2021-04-30 04:26:22 UTC
This happens with all KDE apps. The bug is probably in Qt:
https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/printsupport/dialogs/qprintdialog_unix.cpp#L820

A similar bug was fixed in Qt long ago:
https://bugreports.qt.io/browse/QTBUG-77351

The commit message of the fix reads:

  Unix: Disable complex page ranges widget when printing to pdf

  It doesn't work since it relies on cups to do the heavy lifting and cups
  is not used when printing to PDF

The code is still present in the Qt 5.15 branch:

  // Disable complex page ranges widget when printing to pdf
  // It doesn't work since it relies on cups to do the heavy lifting and cups
  // is not used when printing to PDF
  options.pagesRadioButton->setEnabled(outputFormat != QPrinter::PdfFormat);

Yet, the radio button remains enabled for me. So perhaps it's not working as intended.
Comment 2 Xavier Guillot 2021-04-30 08:14:19 UTC
Hi, I confirm the bug on linux (Ubuntu 21.04) with Okular 20.12.3.

But it only occurs when we select a range from the blank window near "Pages" and enter manually a selection (like 3-6).

If we use the option just above "Pages from XX to XX" with the 2 small windows and arrows to select the number of pages, it works well and only prints the selected pages - see the screenshot for clear explanation:

https://wtf.roflcopter.fr/pics/GzMYcTjq/ibd7DY45.png
Comment 3 Albert Astals Cid 2021-04-30 15:11:31 UTC

*** This bug has been marked as a duplicate of bug 252596 ***
Comment 4 Albert Astals Cid 2021-04-30 15:13:14 UTC
Actually no sorry, this is a different thing
Comment 5 Albert Astals Cid 2021-04-30 15:15:46 UTC
Hmmm, that makes no sense, you're using ArchLinux i guess ? Or manjaro?

You can't select pages https://i.imgur.com/DQam12c.png when printing to PDF.

Can you show me a capture of your print dialog?

Do you by any chance have no other printer than print to pdf?
Comment 6 Xavier Guillot 2021-04-30 16:04:57 UTC
No, as said it's Ubuntu 21.04.

The first time I tried, I had another physical printer enabled, and yes in this case I could not select a range in Pages.

I removed the printer because I don't have it anymore, and with only the "Print to file" printer, the field is no more unavailable.

This field is well enabled in Evince, and we can not only select one, but many ranges like that : 1-2,5-6 which gives a pdf file with the requested pages.

But in Okular it doesn't work…
Comment 7 Xavier Guillot 2021-04-30 16:30:08 UTC
Printing dialogs:

https://wtf.roflcopter.fr/pics/UVSK1bDL/1yGylWIF.png
Comment 8 Bernie Innocenti 2021-05-01 02:41:54 UTC
(In reply to Xavier Guillot from comment #6)
> I removed the printer because I don't have it anymore, and with only the
> "Print to file" printer, the field is no more unavailable.

Looks like QPrintDialogPrivate::selectPrinter() is not being called when there are no physical printers (or it's being called with the wrong outputFormat):

https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/printsupport/dialogs/qprintdialog_unix.cpp#L742

> This field is well enabled in Evince, and we can not only select one, but
> many ranges like that : 1-2,5-6 which gives a pdf file with the requested
> pages.
> 
> But in Okular it doesn't work…

Would be good to see how GNOME handles this case. On Linux, Qt delegates complex page range handling to CUPS, and thus it doesn't work for PDF:

  // Disable complex page ranges widget when printing to pdf
  // It doesn't work since it relies on cups to do the heavy lifting and cups
  // is not used when printing to PDF
Comment 9 Bernie Innocenti 2021-05-01 03:21:37 UTC
I relayed some information to the upstream bug:
  https://bugreports.qt.io/browse/QTBUG-77351?focusedCommentId=564096#comment-564096
Comment 10 Unknown 2024-06-19 13:06:41 UTC
This bug still exists in version 23.08.5!

This is very unfortunate. Consider the following scenario:

A user has a document, where a specific page and the document meta data is sensitive.
While perusing the document with "okular", the user wants to forward all pages BUT this sensitive page and the meta data.
(I know there are other, better tools for the job – the hapless example user perhaps not …)

Printing selected pages to a new PDF is an obvious – but here ill-advised – approach.

This is against the UX principle of "Least nasty surprises"!

At minimum the page selection MUST be grayed out, when printing to PDF – and a warning must be triggered, if a page selection was done before selected a PDF output. And this is definitely not happening! I just tried …

These are the nasty consequences of the very ill-advised decision to deprecate "kprinter" with the transition from KDE3 to KDE4.
With "kprinter" as a generic printer interface for all KDE applications, there was no need to replicate the same function over a multitude of applications. The selection of pages to print, the layout of pages on sheets, a preview of what would actually be printed and the choice of printer targets (including "printing" to files) were in one place, working neatly and consistently and bringing improvements to all applications … (even to "gnuplot", e.g.)

The only SW currently providing a similar functionality – to my knowledge – is "boomaga", which seems not well curated …