Bug 500416

Summary:	Okular wrongly applies a custom User Id and User Code from a printer's default settings
Product:	[Applications] okular	Reporter:	Julius Wenzel <julius.wenzel>
Component:	printing	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	kde
Priority:	NOR
Version First Reported In:	24.12.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Julius Wenzel 2025-02-19 14:48:30 UTC

SUMMARY
For some printing jobs, a User Id and a User Code have to be sent to the printer. Those data can be set permanently in the printer's default settings, for example via the CUPS web interface. There are often used values for both, but it is possible to set a "custom value" for both.
When printing, the User Id and User Code have to be included into the printing data (PostScript). In case of a custom User Id and a custom User Code, Okular handles this incorrectly, making printers refuse to print the jobs. Instead of the actual code/Id, okular includes the word "Custom".

STEPS TO REPRODUCE
1. Set a custom User Code and a Custom User Id in the printer's default settings (for example, set both to 2357), for example via the CUPS web interface (select the printer -> set default settings -> Job Log -> User Code / User Id)
2. Print a document using Okular and the printer configured in step 1
3. Intercept the Communication to the printer (I use an IPP printer and listen to the communication using wireshark)
4. Look inside the PostScript data and search for the directives '/usrid' and '/usrcode'

OBSERVED RESULT
There is a directive '/usrid(Custom)def' and a directive '/usrcode(Custom)def' and the printer refuses to print the document

EXPECTED RESULT
There is a directive '/usrid(2357)def' and a directive '/usrcode(2357)def' and the printer prints the document (given that the User Id and the User Code are the correct ones)
(This behavior has been observed using other programs for printing, such as Firefox, LibreOffice or Zathura)

SOFTWARE/OS VERSIONS
Linux:
'uname -a' gives "Linux [hostname] 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux"
KDE Plasma Version: not installed
KDE Frameworks Version: 6.11.0-1
Qt Version: 8.6.2

ADDITIONAL INFORMATION
The printer is a Ricoh IM C3010, CUPS (2.4.11) is using the PostScript PPD from Openprinting to communicate with the printer

Comment 1 Sune Vuorela 2025-02-19 15:39:47 UTC

I'm not sure I see where okular is actively involved here.

Also given it is also applying to completely different applications like Firefox and Libreoffice I'm guessing that something happens lower in the stack. Maybe foomatic-filters or cups-filters or cups or something along those lines.

Comment 2 Julius Wenzel 2025-02-19 15:47:43 UTC

"Also given it is also applying to completely different applications like Firefox and Libreoffice I'm guessing that something happens lower in the stack. Maybe foomatic-filters or cups-filters or cups or something along those lines."

Maybe I described badly: The "Expected Result" always appears when using any other document viewing program other then Okular. The "Observed Result" (the faulty one) only appears when using Okular.

In short: I'm able to print documents, except when using Okular, so it looks to me as if Okular is actively involved here.

As far as I understand, filters transform the document to be printed. What I want do do here is to transmit information independent of the document's type or structure.

CUPS also looks to work as expected. As I said, when using any other program, it correctly applies the defaults set in CUPS.

Comment 3 Sune Vuorela 2025-02-19 15:49:57 UTC

(In reply to Julius Wenzel from comment #2)
> Maybe I described badly: The "Expected Result" always appears when using any
> other document viewing program other then Okular. The "Observed Result" (the
> faulty one) only appears when using Okular.

> In short: I'm able to print documents, except when using Okular, so it looks
> to me as if Okular is actively involved here.

Aha. I misunderstood you.

Does it happen with another Qt6 based program, or only Okular ?

/Sune

Comment 4 Julius Wenzel 2025-02-19 16:15:08 UTC

I just could reproduce the same behavior as in Okular in qpdfview.
This looks like an issue with the Qt printing libs. I'll report there and close this.
Thanks for the support!

Comment 5 Sune Vuorela 2025-02-19 17:24:38 UTC

(In reply to Julius Wenzel from comment #4)
> I just could reproduce the same behavior as in Okular in qpdfview.
> This looks like an issue with the Qt printing libs. I'll report there and
> close this.
> Thanks for the support!

Thanks for checking. Feel free to post the bug number here - maybe others notice the same thing and can use a pointer.