QPrinterDialog ignores default settings from CUPS

[luxifer]

KDE as well as many QT-Applications use QPrinterDialog as their printing dialog. Thing is: This dialog ignores default settings defined in CUPS - it doesn't even remember that last settings that were chosen. I know this is a QT issue but I kindly ask you not to close this bug as upstream and here's why:

1. This bug has been around for years now - the first report to Nokia about was back in 2008 if I recall correctly.
2. A user doesn't know and doesn't care about whose fault it is. He just knows, that he set his printer settings to default to duplex in CUPS and that his QT applications don't print duplex. At first he might shrug and set duplex in the dialog. Next time the setting is back to simplex. The same is true for other options like collate and color settings. It's just a huge usability issue.
3. The fix below has been adopted by other major distributions for quite some time now. It works for duplex, collate and color settings.
4. It saves lots and lots of trees!

I think it does not work for paper size and in general it doesn't fix the problem that QT can't remember the settings you choose in the print dialog. The paper size may be read from the configured defaults easily, too, but settings saving may be a bit harder. However, you'd implement this fix, you'd do something VERY good for Ubuntu - especially since 12.04 is meant to be an LTS release! If you could even improve the fix that would be huge!

Here's the fix from the KDE bug tracker: https://bugs.kde.org/attachment.cgi?id=41187

More info:
https://bugs.kde.org/show_bug.cgi?id=180051
https://bugreports.qt.nokia.com//browse/QTBUG-6471 (and https://bugreports.qt.nokia.com/browse/QTBUG-23037) and other bug reports from the comments there.

For Oneiric I've made a patched version in a PPA of mine that you could look at. You'll see it's really a minor modification that doesn't take any effort at all to implement. You can find it here: https://launchpad.net/~dhertel/+archive/myfixes

As a side note: I know that KDE is not the default environment in Ubuntu, but it's getting more important for people since Gnome2 officially is no more and Unity isn't exactly better when one doesn't even like Gnome3 to begin with.

So I hope this makes it into Precise...

Cheers,
Dominik

[Gtdev (gtdev)]

Version: (using Devel)
OS: Linux
Installed from: Compiled sources

There needs to be some way to have persistent printer settings. From looking around on the web, it seems like:

* KDE 4 wants to use whatever Qt provides
* Qt does not seem to provide any useful printer settings tools

The current situation is that KDE defaults to non-duplex color printing, and completely ignores existing printer settings e.g. from CUPS (fun enough, it still exposes those settings in the advanced printer setup), making it necessary to re-select those settings. This is *not* a wishlist issue, this is instead a regression from pretty much any KDE 3.

The most convenient solution would of course be an applet in systemsettings.

To get with the expected behavior bulletpoint:
 (1) Start System Settings tool
 (2) Choose "Printers" or something similar
 (3) Be able to configure standards for all settings available in the normal KDE print dialog

Alternatively:
 (1) KDE uses defaults from underlying print system, e.g. CUPS

[Praveen (popapa)]

*** This bug has been confirmed by popular vote. ***

[Dsteeghs (dsteeghs)]

Sorry to be a moaner, but I do feel bad about all the paper wasted since our duplex printers only print duplex if we remember to change the print options for ALL print jobs. This really is the second most annoying feature of my KDE4 experience at present.

Surely setting the default to duplex if the printer supports duplex is an achievable fix that the trees will thank us for? But really, having settings saved is a rather basic feature.

Any update on this regression is appreciated....

[Woelfel (woelfel)]

> This really is the second most annoying feature of my KDE4
experience at present.

I second that.

[Schmuker (schmuker)]

With version 4.3, KDE4 is now finally an improvement over KDE3 in _all_ areas. If it wasn't for this bug. It is definitely not 21st century style having to re-select duplex every time I need to print something. Neither is it good design to ignore the settings in the underlying backend (cups).

KDE4 should use the duplex settings from CUPS, or at least provide an option to save the settings in the printer dialog like KDE3 offered it. Do it for the trees :)

[8slin (8slin)]

In Konqueror print dialog >> Options >> HTML Tab the check boxes are reset each time a page is printed. This is not the behaviour experienced in 3.5 which remembers the previous settings, which to me is far more intuitive.

[Jarauh (jarauh)]

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

[Shoalcreek5 (shoalcreek5)]

Ok, if the other bug is a duplicate of this bug, something funny is going on. I'm using the same (manufacturer-provided) ppd for CUPS now that I used in KDE 3.5, CUPS is set to not print duplex by default, the printer is internally set to not print duplex by default, and yet, whenever I print from a KDE application, it prints in duplex, long-side, regardless of what setting I choose in the KDE print dialog. I am printing to a Brother HL-5250DN. All non-KDE apps (evince, openoffice.org, iceweasel, etc.) act as they should, printing duplex only when I tell them to print in duplex. This is most definitely a regression from KDE 3.5, as KDE 3.5 printing was nearly perfect in every way with my printer.

[Guefz (guefz)]

I see the same behaviour than described in #7 here on my system with a HP CLJ5550DTN. Even using a PPD without duplex definition results in duplex printing. I'm running Debian Sid with currently KDE 4.3.2 and qt 4.5.3

[Schmuker (schmuker)]

Although this bug has first been reported 3 months ago it is not yet assigned to anyone. Point is, there is no "About" dialog in the print dialog, which is where normally developers, maintainers and translators are credited. Hence, we have no idea who is actually maintaining that part of KDE (and I have no clue how to find out).

It might very well be that this bug lives a life which is invisible to the people who could fix it. Does anyone have an idea how to find out who is working on this part of KDE?

[Dsteeghs (dsteeghs)]

As far as I know, the decision was made not to develop a full-blown KDE print infrastructure in KDE4, but instead rely on the print infra-structure provided by QT. I can appreciate the development effort needed to develop a KDE4 print system, but the problem is that the QT printing infra-structure is clearly inferior to KDE3 printing and insufficient. There appears to little development activity on the QT end, while some KDE4 developers are saying this is a QT problem, not a KDE4 problem. I think this circular argument of blame is partly responsible for the lack of progress here. By choosing Qt print infra-structure it IS a KDE4 problem to fix/deal with it, so I would think kde-print-devel to be the right community.

I wish I had more hands-on help to offer here, but I do find it hard to understand why printing remains crippled even at KDE4.3.2 while most other parts of KDE4 have made huge strides. IMHO, deciding to rely on Qt for printing has proven to be a big problem for KDE4.

[Gtdev (gtdev)]

IIRC the argument was that the print handling in KDE 3 was unmaintained. Last I checked, any printing issues were marked to be handled at some undetermined point in time.

By now, I found it to be a neat solution to just use non-KDE applications in any area where printing might be necessary. Gnome somehow manages to at least have a working print settings dialog (i.e. it works for our environment). However, that does not make this bug any less annoying.

As for printer settings overriding QT, I can not confirm that, since over here, QT will always override CUPS/printer settings.

[Schmuker (schmuker)]

I added a bug report against QT's QPrintDialog.

http://bugreports.qt.nokia.com/browse/QTBUG-5196

Let's see what comes out of that.

[Hal Engel (hvengel-h)]

Is anyone considering this:

http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog

The OpenPrinting folks have been working on this for some time and it includes fronts ends in both Qt and GTK+ so the Qt front end should fit in a KDE environment nicely. The UI is designed by a usability expert who does this type of work professionally. There have been Google Summer of Code projects on this for the last two summers and it is close to being ready for real world use.

[Schmuker (schmuker)]

There was a reaction on the Qt side: the bug is now marked as a duplicate of an existing bug: http://bugreports.qt.nokia.com/browse/QTBUG-3567

This other bug has been reported in February, is unassigned and has no schedule. So I guess there's nothing to expect from the Qt side anytime soon.

In the meantime I keep being annoyed by paper waste in my lab, because all KDE4 users send their print jobs non-duplex. I understand that printing may not have top priority among KDE developers, but still it would be nice to see at least some reaction, like acknowledging this bug, or rejecting it.

The point is, a KDE developer might have more impact on the Qt devs than some random internet user who reports a duplicate bug. So if some KDE dev would accept this bug and poke the Qt devs this might save a few thousand trees.

[Dsteeghs (dsteeghs)]

Indeed noticed that and couldn't help but wonder how the duplication was picked up almost instantly, yet the parent bug is still unassigned, and surprisingly marked as 'minor' priority. This bug is the highest ranked 'kde-print-devel' bug in KDE's 'most hated bugs' list...

I cannot see a response yet from a KDE print developer, but I would be interested to see if anyone is actually looking at this bug and to what extent KDE print talks to QT devel. We are not after more features in the print dialog at this point, just a way to make them persistent.

[Schmuker (schmuker)]

Since neither KDE nor QT shows any reaction I submitted a bug against OpenSUSE (which I'm using). In the past they have been a huge supporter of KDE, and KDE 4.3.1 will be the default desktop in their upcoming 11.2 release. Perhaps they are more inclined to address printing related issues than the KDE ot QT team because they also target enterprise users with their distro.

See https://bugzilla.novell.com/show_bug.cgi?id=552218

[C-w-j-lemmens (c-w-j-lemmens)]

Dear fellow KDE4 users,

I solved most of my problems for now by using some workarounds :

1) For our non-KDE programs (firefox, openoffice and some older stuff) I found a perfect replacement for "kprinter" : gtklp !! Take a look here : it solved more than half of my problems : http://gtklp.sourceforge.net/

2) To force doublesided printing inside KDE4 applications I used this :

* I downloaded the source of qt-4.5.3 and configured and compiled the whole bunch.
* Then I hacked the src/gui/dialog/qprintdialog_unix.cpp and added this :

— qprintdialog_unix.cpp.org 2009-10-19 20:19:20.000000000 +0200
+++ qprintdialog_unix.cpp 2009-11-19 14:22:08.000000000 +0100
@@ -424,6 +424,15 @@

void QPrintDialogPrivate::applyPrinterProperties(QPrinter *p)
{
+ // Force some decent defaults, e.g. for Duplex printing !!!
+ p->setDoubleSidedPrinting(true);
+ p->setColorMode(QPrinter::GrayScale);
+ p->setPageSize(QPrinter::A4);
+
+ fprintf(stderr,
+ "Using QPrintDialogPrivate::applyPrinterProperties() hack by KL !\n");
+
if (p->colorMode() == QPrinter::Color)

This forces everything to be grayscale, A4 and duplex unless the user explicitly chooses something else (this is the cheapest for our department !) The extra fprintf statement is only for me to see that I am indeed using the hacked library and not the original.

* Then I reran "make" in src/gui to recompile just a new libQtGui

* I copied the modified libQtGui.so.4.5.3 and its softlinks to a directory /opt/qt-4.5.3-hack/lib/

* Now I had to make sure that each KDE session uses this new library instead of the original one. I did that by hacking /etc/profile.d/qt4.sh (or qt4.csh if you wish) and added this at the end :

export LD_LIBRARY_PATH=/opt/qt-4.5.3-hack/lib

* If you then login again each user will use the new libQtGui library and thus have changed printing settings. I admit it isn't very elegant and still doesn't remember previous settings but at least we have some decent defaults now.

Hope this helps some of you until the Qt or KDE people come up with something more permanent !

Regards,
KL

[Paul Cullum (paul-cullum)]

Is the use of QT for print support mentioned here the reason for the infuriating bug 174354? Is that bug basically blocked because of this issue? Every time I print our office printer blocks because it thinks it should be printing A4.

[Paul Cullum (paul-cullum)]

Vote for http://bugreports.qt.nokia.com/browse/QTBUG-6471

This problem has existed for well over a year and they barely notice that it exists.

There are a lot of bugs opened there trying to explain this problem but this one seems to be the most clear with code that demonstrates the problem.

[Rmj (rmj)]

Paul

You have my vote on this one in the qt BZ.

I've had problems with the defaults for selecting duplex for ages (which I think is releated) and have opened, voted for and followed various bugs at kde and qt o nthe printing system. I really hope http://bugreports.qt.nokia.com/browse/QTBUG-6471 starts to get some traction. I can't believe how this doesn't have a higher profile and some urgency to fix.

[Jeremy Sanders (jeremysanders)]

I've got an (ugly) patch which fixes some problems. It sets the duplex, collation and colour options, in new QPrinter objects and when switching printers in the print dialog, from the default cups ppd settings.

It doesn't do anything with page sizes (is this a problem for some people?), doesn't tell cups to use the new options as defaults and doesn't propagate cups options back from the advanced tab of the properies tab. These issues could probably be fixed.

It could be improved. Maybe the Qt people would decide whether it is a useful way to advance. I think this code would probably be best moved into QPrinterInfo, to make it more general, but I'm wary about messing with the API, especially as Windows versions might need adding.

[Jeremy Sanders (jeremysanders)]

Created attachment 40415
patch to fix some printer issues

[Dsteeghs (dsteeghs)]

Its been over a year since this bug was raised, and its votes now not only make it the most-hated KDE print bug, but it is also in the top 20 of all most-hated KDE bugs. Its clear that from the user point of view, this has some urgency to it, yet I struggle to find any activity at either KDE or Qt that indicates that this is receiving active developer attention.

Thanks for the suggestive patches, but does anyone have any ideas how this awareness can be achieved at kde-print/QT since doing the proper thing of filing a bug and voting for it does not seem to work.

[Rmj (rmj)]

I reported kde printing problems in Fedora 10 more than a year ago at https://bugzilla.redhat.com/show_bug.cgi?id=480954

I was asked to upstream it, which i did by adding comment #12 in https://bugs.kde.org/show_bug.cgi?id=176999.

This was upstreamed to qt as http://bugreports.qt.nokia.com/browse/QTBUG-6468 and http://bugreports.qt.nokia.com/browse/QTBUG-6469

and these are still open. I'm wondering if maybe the problems that we see in the distro (printing from kde apps has a problems) is too far removed from the source of the problem, Qt. It takes some effort to follow these though three bugzillas.

It would be great if someone at kde could champion these issues and help get them resolved. As it is, I have no idea whether the Qt people will ever resolve them.

[Gtdev (gtdev)]

Thing is, Qt provides a framework. They have a printer widget, it can print (even if it's bad at it).

KDE wants to provide a productive desktop environment. So they either use a framework that provides what is needed needed, or they extend an existing one. The first part obviously doesn't work.

This is not about adding a constant-time prime factorization algorithm, it's about remembering a bunch of settings. This also isn't about a return of KDEPrint (oh how I miss thee), it's about remembering a bunch of settings.

[Jeremy Sanders (jeremysanders)]

I'm pretty sure that the right way to save the options is in cups, so that all applications, including non-qt applications, save these settings.

I think it's a matter of taking the patch I uploaded above, and modifying it to also save modified settings to the users' lpoptions file with Cups. Indeed Qt, already reads this file when the user clicks on printer properties - just use a command like
lpoptions -p deskjet -o media=Legal

It really needs to be done in Qt, unless KDE wants to have its own printer dialog (which wouldn't be hard, just inconvenient).

It would be easy to make a Cups printer dialog for KDE. Perhaps it could be nicer than the default one. However, it wouldn't work under Windows. It would also make KDE rely on cups, unless you revert to the old one if it wasn't there.

[Kevin-kofler (kevin-kofler)]

That patch as is causes https://bugzilla.redhat.com/show_bug.cgi?id=566304

The offending lines:
+ // set default color
+ if( cups->currentPPD()->color_device )
+ options.color->setChecked(true);
+ else
+ options.grayscale->setChecked(true);
and later:
+ // set default color
+ if( cups.currentPPD()->color_device )
+ setColorMode(Color);
+ else
+ setColorMode(GrayScale);

They should be changed to:
    if ( cups->currentPPD() )
      {
        // set default color
        if( cups->currentPPD()->color_device )
          options.color->setChecked(true);
        else
          options.grayscale->setChecked(true);
      }
and:
    if ( cups.currentPPD() )
      {
        // set default color
        if( cups.currentPPD()->color_device )
          setColorMode(Color);
        else
          setColorMode(GrayScale);
      }
(I matched the coding style of the surrounding code.)

I'm going to try changing this in the Fedora package and will attach a fixed patch if this works.

[Kevin-kofler (kevin-kofler)]

By the way, your patch doesn't match the coding standards used in the surrounding code (and Qt code in general) at all. I'm also reformatting it to match those standards (which also make much more sense to me personally than yours ;-) ).

[Kevin-kofler (kevin-kofler)]

Created attachment 41187
patch to fix some printer issues (fixed)

Here's a version of the patch fixed to not crash when currentPPD is NULL and reformatted according to the Qt coding style.

Please note that I only know this builds, I haven't done any testing yet. (But all I changed except for formatting is that I added the checks for NULL to prevent crashes.)

[Kevin-kofler (kevin-kofler)]

My fixed patch has now been confirmed to work and fix the crash.

[Hans Meine (hans-meine)]

I also suffer from paper wasted because of KDE's print dialogs defaulting to single-sided printing.

(In reply to comment #26)
> I'm pretty sure that the right way to save the options is in cups, so that all
> applications, including non-qt applications, save these settings.

AFAICS, the situation actually is that the default in CUPS *is* duplex printing. This *is* used successfully by other programs, just not by Qt's printing dialog. Actually, there are two ways to configure duplex mode: one is via the cups properties, available in KDE's systemsettings and by pressing "properties" right next to the selected printer in the print dialog. There, duplex is selected. (This is the same thing as in comment #7 from Brice, only the other way round.)

However, the specialized GUI hidden behind the "options" button, in the settings tab, defaults to duplex OFF.

Looking at the code, the duplex mode GUI is set up from a QPrinter:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/dialogs/qprintdialog_unix.cpp#line434

I am not sure where the QPrinter comes from in general, and how to fix this properly. (Maybe introducing a "DefaultDuplex" QPrinter mode which lets the GUI default to the CUPS setting?)

It actually looks more like a Qt bug to me, too.

[Hans Meine (hans-meine)]

(In reply to comment #30)
> My fixed patch has now been confirmed to work and fix the crash.

While your patch looks sane, I don't think it has much to do with this bug.
(Furthermore, it should be sent to Qt, not KDE.)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "mentioned patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robert Bredereck (rbredereck)]

Any news? Is there a version combining this (VERY IMPOROT PATCH for everyone who has a duplex-printer = most users) with the current 4:4.7.4-0ubuntu8.1?

I sincerely hope that the mentioned patch will be integrated into Precise. Please note that https://bugs.kde.org/show_bug.cgi?id=180051 is one of the most hated bug.

[luxifer (dhertel)]

This patch is not only usefull for duplex printers but for all as it also reads the settings for color and collate...

[cfr (reescf)]

I'm using Arch Linux and Arch is going to say (rightly, I think) that this is an upstream bug...

[cfr (reescf)]

In any case, even if I did use e.g. Fedora, as far as I can tell the patch wouldn't help very much. I'd still be stuck with default letter paper and without access to quality settings needed to get output on some of the printers I use.

[AT (atorgovitsky)]

I applied the patch from the PPA given in comment #62. A couple weeks later I made the mistake of accepting a bunch of updates, one of which was to the qt4 libraries. This of course brought the bug right back. Understandably, the PPA hasn't been updated to this version yet. Is there a way I can downgrade to the PPA version without breaking everything in my system? I'm worried about messing with such a large number of packages, but I really need to have default settings for my printers, its an absolute nightmare not having it.

[luxifer (dhertel)]

@reescf: we use a4 per default and the qt print dialog doesn't default to letter... did you set a4 in /etc/papersize? Also: Sure this is an upstream bug, but as in my filing on Launchpad, I'd say it doesn't matter. Those distros incorporate lots of patches to their packages so this is not excuse. What's more: The users don't care and they shouldn't have to. The patch doesn't fix the underlying problem but it does fix 99% of the annoyance. And with distros like Ubuntu and Arch, still behaving like douchebags in that matter, acceptance for Linux on the desktop takes a hit for affected users...

@Alex: I'll update it as soon as I've got some time for it... I also filed a bug on Launchpad against qt4-x11 and hopefully they incorporate the patch in their next release... It's gonna be an LTS release after all...

[cfr (reescf)]

(In reply to comment #74)
> @reescf: we use a4 per default and the qt print dialog doesn't default to
> letter... did you set a4 in /etc/papersize? Also: Sure this is an upstream bug,
> but as in my filing on Launchpad, I'd say it doesn't matter. Those distros
> incorporate lots of patches to their packages so this is not excuse. What's
> more: The users don't care and they shouldn't have to. The patch doesn't fix
> the underlying problem but it does fix 99% of the annoyance. And with distros
> like Ubuntu and Arch, still behaving like douchebags in that matter, acceptance
> for Linux on the desktop takes a hit for affected users...

I don't have an /etc/papersize. I have never, ever used letter size paper from this machine. I do have a US-with-Euro keyboard but that's it. All printers I use, even CUPS PDF, are set to default to A4 in CUPS, texlive is set to default to A4, all my documents are produced for A4. But I have to set A4 in the QT print dialog every time.

Arch will only patch to fix "serious breakage" and even then, they'd rather not. My understanding is that Arch does not include an enormous number of patches in the way that Debian, Ubuntu etc. do. Whatever you may think of that policy, it is unfair to accuse them of being "douchebags" on grounds of inconsistency. Ubuntu may be inconsistent on this but I can't see Arch is.

Also, I don't think that high a proportion of Arch users use KDE.

If you think not fixing it is problematic because of the hit on users, why doesn't KDE fix it or push for QT to fix it?

You should at least get rid of the "Advanced" tab in the print dialog. Since the settings there have no effect on anything, it is simply confusing. Better to just have the QT options and a note saying, "We know that these options don't reflect the capabilities of your printer or your CUPS defaults. We know they don't reflect the settings you customised via KDE's own print settings control module. (We put that in just to tease!) We should also tell you that any changes you make will be immediately lost and will need to be reset for every document you print. But that's somebody else's problem. We're not sure whether QT or your distro should fix it but we know we're not going to. If you don't like it, use GNOME."

At least that would be straightforward.

Of course it puts me off Linux. I've just switched from OS X and you're telling me I have to compile QT from scratch to get my print settings to stick?!

If I'm fair, though, it puts me of KDE more than it puts me off Linux.

[Ivo Anjo (knuckles)]

(In reply to comment #75)
@reescf: I agree with you that it is very sad that many years after KDE 4.0.0 and printing still completely and insanely sucks.

But, if you distro doesn't do what needs to be done, have you considered switching distros? You don't have to be put off Linux or KDE because of this issue. You could just be put off Arch.

Finally, and again, this has been this way for manymanymanymanymanymanymanymany years. I don't think arguing about this further on bugzilla is going to help a lot. We just have to either do it, or wait for those who can to do it (or offer incentives to help motivate those who can).

[Kevin-kofler (kevin-kofler)]

> Arch will only patch to fix "serious breakage" and even then, they'd rather
> not. My understanding is that Arch does not include an enormous number of
> patches in the way that Debian, Ubuntu etc. do. Whatever you may think of that
> policy, it is unfair to accuse them of being "douchebags" on grounds of
> inconsistency. Ubuntu may be inconsistent on this but I can't see Arch is.

As much as sticking close to upstream makes sense in principle (it is also a Fedora policy), it doesn't make sense to make a religion out of it, the highest priority should be on making things work for the user! Otherwise, what do we even have a distribution for? A distribution which just redistributes unmodified upstream code is useless.

With that said, the paper size should already be read off CUPS settings by the existing Qt code. See QTBUG-6471, which got resolved in Qt 4.7.

[luxifer (dhertel)]

@reescf: try installing libpaper and running "paperconfig -p a4" as root... and I didn't mean to accuse only arch... the same goes to KDE itself... if KDE just use this patch in their QT version or if they switched to and supported openprinting alltogether the problem would be fixed for all... but apparently KDE doesn't consider this a serious issue... Now with Gnome2 dead, XFCE too rudimentary for many and KDE with broken printing, what's left for Linux on the desktop?

So I guess this still makes sense to discuss here. It's still a valid bug in KDE. The bug in the code may be in upstream but the bug in usability is in KDE and that's the point.

[cfr (reescf)]

Thanks. I did that. I also deleted printers I'm not using and set a non CUPS_PDF printer as default. I think the papersize is now right. I now only see this option in the "properties" dialog and not the "options" dialog. But it still, naturally, ignores duplex/greyscale etc.

Somebody else using KDE on Arch claims that his settings (as made via KDE's printer kcm setup) do persist and do determine default printing in Okular etc. However, I checked the build file for QT on Arch and it definitely doesn't use the patch, so I'm not sure how this is even possible.

Personally, I think KDE should move to the openprinting dialog. Even patched, the QT dialog is going to be unsatisfactory because it is insensitive to the actual capabilities of the printers installed and divorces printing from KDE apps from the KDE CUPS interface (which is billed as a way to configure printing and not merely as a way to configure CUPS). I don't really understand why the QT print dialog isn't regarded as *obviously* unsatisfactory and, for a sophisticated DE like KDE, *embarrassingly* stone-age.

[Adam Porter (alphapapa)]

What all this confirms for me is that KDE is basically a developer
playground. I feel like none of the devs in the KDE project care
whether KDE is actually a good DE, whether it's suitable for general,
widespread use, or whether anyone but themselves use it. (This may
not be the case, but I feel like it generally is.)

KDE needs some by-example leadership. Some devs need to step up and
fix the important bugs that are not fun to fix. Doing so would make
KDE viable as an alternative to Windows and OSX for average users and
enterprises. Unless this happens, KDE will languish in obscurity.

And maybe that's ok with the devs. Maybe they're fine with a
take-it-or-leave-it approach. Hey, they're just volunteers who
scratch their own itches, and that's their prerogative. But it's a
shame, because KDE could be so much better. It has the potential to
be a Free Desktop that actually competes with Microsoft and Apple.
And it's not about "sticking it to the man" or anything like
that--it's simply about doing it better, in an open and Free way, for
the good of others.

At least, that's how I think it ought to be.

[luxifer (dhertel)]

@Adam: This is not true. IMHO the KDE devs care MOST whether KDE is actually a good DE... KDE4 has become quite brilliant if you leave this unspeakable bug out of consideration. Now look at the other major DEs as of lately. At least KDE provides massive extensibility and customization features while still providing sane and sensible defaults AND providing a nicely working integrated experience if you use the KDE apps. No other DE does that... not even remotely! Think about it for a moment...

It would be nice though if an actual KDE dev would post something ontopic here...

[luxifer (dhertel)]

Also maybe someone should edit this bug... Severity should be Major instead of Normal.. From the guidelines:

Normal: regular issue, some loss of functionality under specific circumstances
Major: major loss of function

For this bug makes not only "some" loss of functionality and not only under "specific" but rather generic curcumstances, "Normal" doesn't cut it...

ALSO: DEAR KDE DEVS: Why not at least assign this to someone? Status "NEW", really? For THREE YEARS?

[sphakka (sphakka)]

Hi all,

Just my two cents, with disclaimer of heavy off-topic derailments.

I've been loving KDE since its inception, when hovering the mouse pointer over the 'K' start button used to pop up a tooltip saying "Where do you want to go tomorrow?"... 'tomorrow', I guess it meant 'progress' wrt to M$ Windoze.

Now, sadly, I don't see any more that desire to really improve things, at least not for my not-so-powerful laptop: it's mostly about eye candy, rather than functionality. I know there's plenty of good stuff under the hood, but, jeez, where is it? In order to have a functional DE capable of booting in less than an... age, I had to:
- disable all desktop effects -- and that's annoying 'cause I need the zooming feature as my sight, like my laptop, is a bit defective;
- split all the KDE virtual gentoo ebuild, to get rid of that plethora of useless/misbehaving apps and bits -- above all, akonadi and nepomuk... actually, those are not useless, though so buggy that the frontier is fuzzy.
- spend hours at no avail trying to synchronize all my mail/contacts/calendar with gmail + my nokia smartphone. Then, defeated, I decided to remove akonadi & Co...
And still every now and then I must tidy up my ~/.kde folder where config junks accumulates like dust over scaffolds.

Where are we heading to? I don't believe in stupid OS/DE wars. I do believe in progress, cooperation and good management, even geeky and nerdy if you want, but *real*, i.e. one that makes things move forward.
I think that if we can just make it functional, without comparing it to anything else (who really cares when it's free?), that will be progress. What others do should be source of inspiration rather than term of comparison. F***ing hell, libre/open-source SW is not about *competition*, it's about FREEDOM and COOPERATION. Personally, I wouldn't want a MacOS clone; I couldn't care the less because I already decided that my life must be, as much as possible, proprietary-SW-free, so I don't need the illusion of owning what I cannot afford to buy (my salary, fortunately, would allow much more than that). The problem is convincing those who consider eye-candy stuff a paragon that they don't need it: priority is having good tools.

But this policy of just "good looking stuff" is making much of these efforts vane. Even though the recent Qt/Nokia debacle had a part in all this, I say, hey, now that's back and free to the community, let's take a chance to start think differently.

IMHO, KDE folks should look a bit closer at the development process of, as for my viewpoint, more stable projects, like Mozilla products. We users, keep on posting, prodding and proposing! As for this bug, I think that the priority is OK: as far as I can understand, there's a workaround... annoying, yes, but that's it.

Sorry for venting my frustration... I hope nobody got offended.

Cheers,

  ^s

[luxifer (dhertel)]

@sphakka: what the hell? that wasn't even remotely on-topic but one sentence... and that one showed how little you cared to learn about the topic. I wouldn't call a hackish patch for recompiling the whole goddamn Qt framework a "workaround"...

The rest was just off-topic. Why you bitch about how current software doesn't run smoothly on ancient hardware it beyond me, especially since your salary, fortunately, would even allow for much more than a new Macbook. Also beyond me is what you need the magnifier from the effects for when there are tools that work without those or you could just increase the DPI setting.

[vidak (vidakris)]

It seems you didn't really get the point. KDE puts more effort to eye candy than to functionality. That might be the reason, why this bug is here, after three years, being the second on the 'most hated bugs' list. Relatively small thing, but really annoying, convincing the users to leave KDE sooner or later.

[luxifer (dhertel)]

I think the more probable reason is that no relevant KDE dev knows about or feels responsible for this bug. Because Printing is handled by Qt. And the responsibility for Qt lies at Nokia. Problem solved. Also this bug is not a "relatively" small thing... don't let the patch misguide you to that conclusion. the patch is a hackish fix which works for 99% of the people but doesn't fix the underlying problem properly...

Sure this bug will drive lots of people away as soon as Gnome3 has become mature and customizable enough and provides good working extensions to get back to a desktop metaphor...

How you percieve KDE to put more effort into eye candy than into functionality is beyond me however. After all the looks didn't change much since KDE 4.0 - they just stabilized the effects over time. However in the same time they fixed and improved a lot of the inner workings of KDE and the applications it comes with. While all doing this they still managed to come up with sane defaults end excelent integration...

[Mskala+kdebugs (mskala+kdebugs)]

The wrong paper size on every single job, requiring a manual override individually on every single job, is not a "sane default." Providing two configuration dialogues for the same feature, one of which has no effect, and ignoring the configuration set elsewhere by the operating system component responsible for such things, is not "excellent integration."

The big picture of KDE's general development philosophy is interesting, but let's not lose sight of the simple bug that is the reason we're gathered here: CUPS provides default printer settings, which KDE ignores. KDE should read and use CUPS's default printer settings. That shouldn't be complicated or controversial.

[luxifer (dhertel)]

@Matthew: right, it's not a "default" at all... a default is a configuration setting... what you describe is a bug that's causing unexpected behaviour... you confuse that... also: for the paper size problem using and setting up libpaper seemingly worked for reescf... what's more: this is a Qt bug, not a KDE bug... while KDEs ignorance on this one hurts everyone you should really blame Nokia for not fixing the bug...

And again:
1. The bug is in no way "simple".
2. The bug is not within KDE but in Qt.
3. Qt is owned and maintained by Nokia.
4. Nokia has known this for 3+ years and ignores it as well.

What you could blame KDE for though is to be so stubborn about not diverging from upstream Qt in this case. They have good reasons not to do this easily but in this case the patch and therefor the risk isn't very big but well understood and should be outweighted by the advantages that it brings. So this is not a technical issue but a policy/political issue and THAT's what makes it so frustrating...

[Francesco+kde (francesco+kde)]

Q:
>Hi list,
> there is a rather heated discussion in a 3 years old kde bug [1]
>regarding printing, more specifically the print dialog and how it should
>keep/save settings between different call of it.
>
>Could you (as somebody involved in qt5 planning or development) clarify
>what the plan are for printing functionality, managment or whatever?
>
>Expecially a statment like "printing will no be managed by qt" could be
>helpful, pushing somebody to take responsibility for it and solve the
>problem.
>
>best regards,
>Francesco Riosa
>
>[1] Bug 180051 <https://bugs.kde.org/show_bug.cgi?id=180051> - [KDE4]
>Need a way to have default printer settings

A:
Currently we continue to have the Qt 4 printing subsystem in Qt5 (as
libQtPrintSupport), but the longer term plan is to replace this with a new
module, as some of the basic architecture of the old printing module is
not fixable.

For 5.0 however we continue with what we have.

Cheers,
Lars

[luxifer (dhertel)]

So there you have it... we'll have a working print dialog by the time we have flying cars... guess printing dialogs are np-hard... so, kde... finally ready to give up qt for printing?

[Francesco+kde (francesco+kde)]

I had the following today:

>
> I'm the new community maintainer for printing support in Qt, so I can fill you
> in on some of my plans.  You can find a more detailed description on my blog
> at http://www.layt.net/john/blog/odysseus/kf5_localization_and_printing_plans
>
> As Lars has explained, the Qt4 print module has been cleaned up a little in
> Qt5 but we do not plan to add any new features to this code in the future.
> Instead we are planning a new module for 5.1 or 5.2 that conforms to modern
> printing standards and features.  However that is a long time for KDE4 apps to
> wait for the missing features and bug fixes.
>
> My current work plan is to complete the last few localisation features needed
> for Qt 5.0, then to move on to a bug triage on the QPrintSupport module to get
> it ready for 5.0.  The bug fixes here will where possible be back-ported to Qt
> 4.8.  For example, I really want to get the CUPS settings bug fixes in to 4.8.
>
> Once that work is done, I plan to fork off a Qt4 version of QPrintSupport and
> apply on top of it my old patches for adding many of the currently missing
> features.  Once that is stabilised I'll release it as an interim experimental
> print library that KDE4 apps can use if they want.
>
> From there I plan to start working on the new print module, which we will hold
> design session for at the next Qt Contributors Summit.  Hopefully it will be
> ready for Qt 5.1 and so the first full release of KDE Frameworks 5.
>
> I hope that answers a few of your questions.

[Ncoghlan-5 (ncoghlan-5)]

Thanks for the additional information Francesco. Unfortunately, searching for "QPrinterNG" suggests that the plan of improving the situation for KDE 4.8 never came to fruition (and the Feature Plan for 4.9 doesn't appear to include anything along those lines, either: http://techbase.kde.org/Schedules/KDE4/4.9_Feature_Plan).

I don't print very often, so the status quo is a minor irritation rather than a huge problem for me, but it would still be very nice to see this fixed. (I suspect many developers are in the same situation of only rarely printing things out, hence the historical lack of attention to critical printing problems like this one)

[cfr (reescf)]

It is certainly good to know that some attention is planned to be given to this issue at some point. However, I cannot help but feel the the severity of this bug is not appreciated by the developers.

Everyone here admits that the patches available are horrible hacks and do not address the underlying issues. But as I understand it, they would dramatically improve the experience for many users. What is the reason *not* to use the patch as a temporary fix until you have time to address the issue more thoroughly? I realise that there is a lot to be said for doing a job right but there is also a great deal to be said for solving a problem sooner rather than later.

I just don't understand the reasons not to use the patch. It is there. Somebody has written it. People have tested it. Why *not* use it? Maybe it is a sticking plaster but if it can cover up some of the mess which is the current printing dialog, why not use it? I could understand it if the patch had to be developed from scratch but that's not the case. Is it a reluctance to use a less elegant, uglier patch (as everyone admits this one is)? But the current dialog is, frankly, hideous. So something hideous is better than something ugly if the former can be blamed on somebody else while you would feel responsible for the latter? Is that it? If so, I recommend a more utilitarian perspective...

I'm also intrigued that the plans appear to include sitting down to design a new printing interface when openprinting appears to be a good way along the path to developing an excellent one. As far as I can tell - and I am certainly no expert - a great deal of effort is going into ensuring that that design actually works for users rather than merely seeming to the developers as though it should. I am not suggesting that KDE does not have people who know what they are doing in GUI design - clearly this would be grossly unfair. But can you really hope to put the same level of effort into designing one element of the overall system? And, even if you can, why should you duplicate that effort rather than putting those efforts into other areas?

[cfr (reescf)]

I see that there may be some integration with openprinting. This is presented as a cups/linux vs. windows/osx issue. But presumably it is a cups/linux/osx vs. windows issue since osx uses cups as far as I know. (In fact, cups started there as far as I know.)

My concern about this is that what will end up mattering is that it works on windows. Whether it works with cups or not will, once again, be considered a minor issue of little importance.

[luxifer (dhertel)]

I fully agree with reescf... I also want to add some perspective to the windows issue:

IMHO KDEs Windows/OSX ports are a "nice to have" but I can't imagine that these have significant user counts. It's the Linux desktop that draws in the most users, I guess. This is especially true since Gnome2 is dead now.

On the other hand I can't imagine an OSX user who'd mainly use KDE - I wouldn't know what for... The same is true for Windows. I use KDE for Windows only for Kile and I don't care for printing. Under Linux this is a completely different story though.

So I share reescfs concern and I'd really like to know - if it's true - what justifies this stance. Why do the developers think Windows and OSX are so important? Windows and OSX users WILL NOT use KDE as default desktop environment. Don't know about OSX but in Windows one reason for this is that the current implementation suffers from more fundamental flaws like the mediocre installer and unstable runtime.

[cfr (reescf)]

I've never used KDE on OS X. (kile was probably *the* reason I chose KDE on Linux - on OS X, I use TeXShop.) I've never known anybody use KDE on OS X.

But as far as this bug is concerned, OS X integration should follow automatically from Linux integration. Both use CUPS for printing. (Unless Apple have stopped using CUPS in later versions of the OS. I haven't checked, but I would be extremely surprised if they have.)

To reiterate, I still haven't heard any reason not to use the available patch as a temporary, albeit hackish, work around. "Get somebody else to apply it" or "somebody else could apply it" is not a reason. I'm not saying it is a poor reason. I'm saying it is not a reason at all. It is simply irrelevant.

Given that the promised fixes have not made it into 4.8 and that QT 5 is likely to have just the same setup, complete with bugs, as QT 4, I suspect that a "proper" fix is years, probably decades and possibly centuries, off. That makes the case for the temporary fix all the more compelling.

[Kevin-kofler (kevin-kofler)]

KDE cannot apply this patch because they discontinued the repository whose purpose was to carry exactly this kind of patches, the kde-qt repository. (git.kde.org now carries a 1:1 mirror of the qt.gitorious.org repository instead.)

[luxifer (dhertel)]

@reescf: Exactly!

@Kevin Kofler: So? What's the sense of having a 1:1 clone of another repository? Why have an own repository at all then? Why use git then after all? That's not a reason but an excuse and a poor one on top of that.

Plus: This fix is likely to work as long as the bug stays this way so there'd much likely be no trouble applying it to future versions of QT that carry this bug. It's a no-brainer, really. Is the KDE board even aware of this issue and how serious it and its implications are?

[Kevin-kofler (kevin-kofler)]

> @Kevin Kofler: So? What's the sense of having a 1:1 clone of another repository? Why have an own > repository at all then?

Don't ask me! I've always said that dropping kde-qt was a mistake and this is an example of why.

[Schmuker (schmuker)]

Just want to point out that OpenSUSE has fixed the issue in their distro already more than a year ago (see also comment #16).

https://bugzilla.novell.com/show_bug.cgi?id=552218

Maybe those of you using distros without the patch should consider bugging your distributors to include it. Point them to OpenSUSE and that they _have_ the patch.

Chances are that at some point the insight will percolate that it would be much more efficient to include the patch upstream instead of having a copy of it in every distribution. AFAICT rants in this bug report have gotten us nowhere and are not very likely to get us anywhere in the future.

[Robert Bredereck (rbredereck)]

Here is a ppa including the mentioned patch for precise:
https://launchpad.net/~rbredereck/+archive/qt4-print-cupsworkaround

[Launchpad Janitor (janitor)]

This bug was fixed in the package qt4-x11 - 4:4.8.2-0ubuntu6

---------------
qt4-x11 (4:4.8.2-0ubuntu6) quantal; urgency=low

  [ Rohan Garg ]
  * Transition to libtiff-dev

  [ Jonathan Riddell ]
  * Add kubuntu_37_cups_settings.diff from https://bugs.kde.org/180051 and
    QTBUG-25372 use CUPS settings in the print dialogue. LP: #905147
 -- Rohan Garg <email address hidden> Fri, 24 Aug 2012 00:16:10 +0530

[Psychonaut (psychonaut)]

One of the upstream bugs has just been marked as resolved for Qt 5.0: https://bugreports.qt-project.org/browse/QTBUG-6239

[EMR (e-m-reck)]

I have three printers. GTK/Gnome based apps maintain the OS default. KDE apps default to the first printer alphabetically in my printer list, and there's no way to set a default printer in KDE. This is annoying because I end up sending my print jobs to another office.

[Kdebugs-4 (kdebugs-4)]

Searching for bugs about saving printer options in Okular brings one here. Most of this discussion centers on duplex printing, but my issue concerns printing in reverse order. This is possible on-the-fly in Okular, but there is no way to make it the default. That doesn't seem possible even using the 4.13 version of KDE in the just-released Kubuntu 14.04 (4:4.13.0-0ubuntu1).

I can select the option to print in reverse order on the fly in Okular, but I cannot make that the default for all documents and for all KDE applications. The reverse printing option doesn't appear in the System Settings printer dialog, probably because it also does not appear as an option using CUPS via the localhost:631 interface.

Still I can tell Okular to print a document in reverse order, so it should be possible to set it globally for Okular and for all other KDE apps as well. I don't know whether it's a KDE or a Qt or a CUPS problem, but it should be possible to make any printer option a default.

[Djarvie-h (djarvie-h)]

Created attachment 100374
Patch to initialise Qt printer dialog with CUPS settings

There is a Qt code review, https://codereview.qt-project.org/#/c/32127/, with a patch for initialising the Qt printer dialog with all the CUPS settings, including default printer, duplex mode and greyscale/colour. This worked for me with Qt 4.8.6.

I attach a patch file obtained from this code review.

[Michael Weghorn (michaelweghorn)]

The issue that a printer's default CUPS options are not properly initialized in the print dialog has been fixed upstream in Qt now, along with several other improvements of the Qt print dialog.

Most of the improvements will be contained in Qt version 5.11 already (s. [1] for more details), while the proper initialization of the duplex option -- which is mentioned in this bug report pretty often -- will be implemented in Qt 5.12 (s. [2]).

I therefore suggest to close this bug as RESOLVED UPSTREAM - and will do so soon unless any objections are brought up here in the meantime.

[1] https://www.kdab.com/better-support-for-cups-features-in-qt-5-11/
[2] https://codereview.qt-project.org/#/c/226881/

[Michael Weghorn (michaelweghorn)]

(In reply to Michael Weghorn from comment #105)
> [...]
> I therefore suggest to close this bug as RESOLVED UPSTREAM - and will do so
> soon unless any objections are brought up here in the meantime.

I'm doing this now, since nobody raised any objections.

[Andras Badics (gothmog123)]

I still experience this bug in qt 5.13 :(

[4-a-g (4-a-g)]

Sorry, it seems that the issue isn't resolved.
Okular doesn't save the margins values nor the "Force rasterization" checkbox.
If I try to set the values as default, the print tool ignores them while a command-line lp works :
lpoptions -p Zebra -o page-bottom=0 -o page-left=0 -o page-right=0 -o page-top=0 -o fitplot

Kubuntu 19.04
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.4

Quite the same as https://bugs.kde.org/show_bug.cgi?id=404510 or https://bugs.kde.org/show_bug.cgi?id=383697
So I tried with Kate and the values are saved in katerc :
[Kate Print Settings][Margins]
bottom=0
left=0
right=0
top=0

Strangely I just migrated from Kubuntu 14.04 (KDE 4.13) to Kubuntu 19.04 (KDE 5.62) and I didn't face this issue on the previous computer.

[Kevin-kofler (kevin-kofler)]

The issue in this bug is already resolved in upstream Qt.

Your issue is a different issue, i.e., that there is no UI to set default margins. Any settings you make in the print dialog are not intended to be stored as defaults.

The place where you set default settings is using the print-manager KCM, i.e., the Printer tab in Plasma System Settings. But there is no setting for margins there. And of course not for "Force rasterization" which is an Okular-specific setting.

[yvel (yvan-velenik-hispeed)]

*** This bug has been confirmed by popular vote. ***