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.

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

*** This bug has been marked as a duplicate of bug 252596 ***

Actually no sorry, this is a different thing

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?

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…

Printing dialogs:

https://wtf.roflcopter.fr/pics/UVSK1bDL/1yGylWIF.png

(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

I relayed some information to the upstream bug:
  https://bugreports.qt.io/browse/QTBUG-77351?focusedCommentId=564096#comment-564096

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 …