FS#28381 - KDE print settings do not persist

Attached to Project: Arch Linux
Opened by cfr (cfr42) - Sunday, 12 February 2012, 16:56 GMT
Last edited by Andrea Scarpino (BaSh) - Saturday, 14 April 2012, 09:00 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andrea Scarpino (BaSh)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Please note that I am reporting this here out of desperation. I am aware that it is, properly speaking, an upstream issue. Nonetheless, an easy partial fix is available and has been for sometime but it is only being applied at the distro level and, for reasons I fail to comprehend, this does not seem likely to change any time soon. So I consider this a request for a bug fix rather than a bug report proper so far as Arch is concerned.

Description:
The QT print dialog contains two parts. One concerns properties of the printer and consists of two tabs - basic and advanced. This part more-or-less accurately tracks CUPS defaults for configured printers. It has no effect on printing. The other consists of options for the print job. These are set independently of CUPS settings and are reset for every print job. This makes it necessary to reset standard options for every job sent to a print queue. Obviously this is highly irritating. It also wastes time, toner and trees if, for example, CUPS defaults are set duplex because QT defaults to single-sided. For me, CUPS is configured for most printers I use to duplex, A4, greyscale with quality options for some printers. QT defaults to one-sided, letter (not clear why?), color and does not offer the quality options.

This affects printing from any application using the QT print dialog and renders the control module configuration of KDE, for example, useless. Defaults set through either KDE control panel or CUPS web interface or CUPS lpoptions have no effect on what is actually printed from these applications. An example of such an application is okular. The problem does not affect applications with alternative print dialogs. These include, for example, firefox and acroread.

Additional info:
Patches have been available for some time. These do not resolve the basic problem but they do mitigate the severity of the annoyance. Unfortunately, KDE considers this an upstream problem and QT appears to have no interest in resolving it. Extensive threads, including patches, diagnoses and proposed solutions are posted in the bugzillas for both QT and KDE.

The most informative and useful of the KDE threads is probably https://bugs.kde.org/show_bug.cgi?id=180051 which includes the patches and discussion of distributions' responsibilities or otherwise for applying them.

I am assuming that QT may be reluctant to pick up CUPS settings because this would not work on Windows but it is difficult to be sure. I do not know why they do not allow the settings to be saved persistently via some other method.

Clearly this is a QT bug. However, it has existed - as have partial solutions - for at least a couple of years. If QT were a smaller package, I would try compiling with the patch myself. However, I have tangled unsuccessfully with QT before. Moreover, it would obviously mean rebuilding QT on every update even if it worked and this would take a very long time on my machine.

For these reasons, I would like Arch's QT packager(s) to at least consider applying the available patch. Since Arch does not run on Windows reasons to avoid having the print dialog utilise CUPS do not apply to Arch's packages and this is the only reason I can think QT/KDE do not use the available patch as at least an interim solution. I am not very proficient at reading code but I do not think that the patch would introduce a dependency on CUPS but only an optional dependency because it seems to use CUPS only if it is available to pick up default settings.

Steps to reproduce:
Basically if you change default settings for CUPS printers either via the web interface or via, say, KDE's control module, those settings are ignored in QT print dialogs such as okular's. (But see comments on my forum thread about this at https://bbs.archlinux.org/viewtopic.php?pid=1056178#p1056178. I don't see how it can be working for somebody... I checked abs and Arch does not seem to use the patch...) Moreover, if you change the settings in QT's dialog and print, the changes will be lost when you print another job.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Saturday, 14 April 2012, 09:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  qt 4.8.1-2
Comment by Andreas Amann (amann) - Friday, 13 April 2012, 23:23 GMT
Unfortunately this bug is (again) present in qt-4.8.1-1
Could you please reapply

Comment by Andreas Amann (amann) - Saturday, 14 April 2012, 01:35 GMT
Just in case, here is a suggested patch.

Loading...