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

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....

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

I second that.

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 :)

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.

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

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.

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

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?

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

Created attachment 40415 [details]
patch to fix some printer issues

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.

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.

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.

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.

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.

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 ;-) ).

Created attachment 41187 [details]
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.)

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

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.

(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.)

IMHO there is a usability problem here. The printing dialog includes two settings, the Cups printing settings in Properties->Advanced, and the Qt Printing options in Options. The Qt Printing Options override the Cups options in any case, which is very confusing.

To fix this, in the GUI, both option menus should be in sync to prevent "surprising" outcomes. That means, that on startup the Qt Printing Options should reflect the Cups printing settings (if duplex is the default in cups, it should be the default in Qt). If I change a setting in the advanced cups dialog, Qt should reflect that immediately. If I change a setting in Qt, the advanced dialog should also show that (but not necessarily change the default setting in cups without asking the user first).

The printing dialog is a mess anyway. Some settings you can set in the menu right away (such as color or black and white printing in kolourpaint and such) but printing mode (draft, normal, foto) is only available under printer settings. And often you cannot even set oritentation to landscape as it is just greyed out. 
KDE has such a nice file-open-dialog (which I don‘t think comes from qt directly?) so why not provide a nice printing dialog as well. You have one since Windows 95 and we‘re in 2010 here. (And when configuring my printer with KDE, it always spits out an additional testpage (or an empty one if I am quickly enough at the printer to press cancel) after each printing job)

I recently reported this bug on RedHat Bugzilla for 6.0 Beta but that doesn't seem to have gone anywhere either.
https://bugzilla.redhat.com/show_bug.cgi?id=587016

Here is a related problem. Seems to me the source of evil might be the same, so I'm not filing a new bug report just yet: When I want to print a landscape document, in the printer dialog under "Properties" Orientation automatically is set to "Landscape". The image next to it indicates a correct layout. However, the document is then printed in "portrait mode", i.e., the landscape contents is printed on a page that's oriented vertically. Funnily enough, one can fix that simply by switching  the check box back to "Portrait". This is really confusing.

It seems to me that this "duplex printing" bug is not getting enough attention. The truth is that less experienced users are simply not printing in duplex. I know what I'm talking about - I have two high-school kids and a wife who are using KDE. They all waste a lot of paper, and each time I notice, I explain over and over again that they are supposed to click on this darn check-box each time they want to print. From a non-developer point of view, this bug is embarrassing for KDE - it should be easy to fix (now, admittedly I don't know what I'm talking about), but it's not being addressed. Even if the idealistic approach is to say this should be fixed in QT, this might not be the right way to deal with it. In particular, when such an (alleged simple to fix) bug makes it on the Top Ten list of the Most Hated KDE Bugs, I wish a more pragmatic approach would be applied.

Get your distro to apply the Qt patch from comment #29. Fedora has been using that patch for months.

Bonus points if you can get Nokia to merge it.

(In reply to comment #38)
> Get your distro to apply the Qt patch from comment #29. Fedora has been using
> that patch for months.
> 
> Bonus points if you can get Nokia to merge it.

There is little hope for success. The bug has been reported in OpenSUSE, but it is closed as upstream (see https://bugzilla.novell.com/show_bug.cgi?id=552218 )

In fact, fixing this bug downstream on distro level is far from ideal (it doesn't really help me much, that it's fixed in Fedora). Ideally, it would be fixed upstream in QT. But I am not very optimistic that this will happen in the near future (and apparently so are you). So I wonder whether fixing it on KDE level would be an appropriate and pragmatic solution. If not, I'm curious why. After all, it is listed as  one of the top ten most hated bugs on the KDE(!) Bug Tracking System.

It is impossible to fix this at KDE level without rewriting the whole print dialog.

> There is little hope for success. The bug has been reported in OpenSUSE, but it
> is closed as upstream (see https://bugzilla.novell.com/show_bug.cgi?id=552218 )

It was closed as upstream by somebody who doesn't seem to be an openSUSE packager. Just reopen it and link to the patch here.


FWIW, what KDE can do is to add the Qt patch to the qt-kde tree in git. Several distros ship the Qt patchset from there (I know Fedora does, I'm not sure about openSUSE), so it'd get picked up automatically by those. But I also think that getting that patch (or a better one, if Nokia doesn't like the patch as is) into upstream Qt is the best solution.


By the way, whatever you do, make sure you use the version of the patch I fixed, from comment #29, not the original one which contained a crash bug. (But the credits for the patch should still go to Jeremy Sanders, I only fixed the crasher.)

It can not be fixed in the KDE level, we use Qt for printing so the code is in Qt repository where we don't have access to commti fixes. So instead of complaining here that has *zero* effect on getting the patch fixed go an vote for the existing bugs in qt bug reporting webpage and open new ones if needed.

http://bugreports.qt.nokia.com/

Too early in the morning, when i say "getting the patch fixed go" i meant "getting the bugs fixed go"

This problem can be fixed at the KDE level.

If Nokia decide they don't want to add our patches, or work on the dialog box themselves, we could make the decision to implement a new KDE printing dialog box which would replace the Qt one. Applications could then move to using the new dialog box.

I'd be interested in looking at doing this.

I'd also like to remind you of the existence of http://qt.gitorious.org/qt/kde-qt , a Qt tree to which all KDE developers can commit (you need to have an account on gitorious.org and request kde-developers group membership there), which is shipped by several distributions. (Fedora ships it as a patchset against Nokia's Qt. I know we're not the only ones.)

(In reply to comment #32)
> (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.

I stand corrected: I had not looked at the attachment, but only at the diff in your comment (and in comment #30 you wrote "confirmed to work and fix the crash", but it does not only fix the crash, but actually let the dialog default to duplex - yeah!).

Your patch is exactly what I had in mind as the necessary solution, so I applied and compiled it and tried it out - IT WORKS! :-)

> (Furthermore, it should be sent to Qt, not KDE.)

This is still valid; while you might want to try applying to qt-kde, the policy is that qt-kde should deviate from upstream as few as possible!

Anyhow, thanks a lot for the patch to both Jeremy and Kevin, this really bugged me a lot!

Thanks for the comments and explanations (of course, Albert, my intention was not to complain, but rather to get movement into this, as this bug will soon celebrate its second anniversary). It's great that a patch exists, but I still like Jeremy's idea of reimplementing the print dialog, as the current one has several other problems besides the one that is, as I understand, addressed by the patch. E.g., those from #33, #34, and #36. In addition, e.g., the collate option can be set in the "Advanced Properties" but at the same time be unset in the main print dialog.

It appears that OpenPrinting.org may have arranged funding to continue work on the Common Print Dialog.  As more details become available I will make sure this information is available here.

I take it kdeprint is now unmaintained.  Could this bug be moved to the new product?  I take it this is the print-dialog component of kdelibs.

every time i print a paper oriented in portrait - the printer paper orientation is set to portrait and when i print a landscape pdf the printer paper orientation is set to landscape - but my printer only has portrait oriented paper - therefor printing in landscape creates the wrong output for my printer - so i have to change this setting every time i print a landscape oriented file...

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

How many issues are covered by this bug? I was browsing through similar bug reports because of issues with duplex printing, and none of them are worded well enough to figure out if it is the issue that I'm having. The issue with the default settings (http://bugreports.qt.nokia.com/browse/QTBUG-6471) is claimed to be fixed in Qt 4.6.3 which was released about the time when I bought a printer and I haven't experienced it, but the override for the duplex in Options doesn't work for me, and I have to set the duplex setting from Properties -> Advanced -> Double-Sided Printing (this would also be http://bugreports.qt.nokia.com/browse/QTBUG-6468 I think).

Anyway, the new QPrintDialog is largely inferior to what KDE 3.5 had. First, this upstream issues that the upstream seems to be largely ignoring, then there is the lack of a nice application such as kprinter, and lastly I can use printing filters any more. 

KDE 3.5 allowed me to create booklets and all the crazy stuff with ps filters such as psnup, etc. None of them worked correctly for me, true, but I was planning on filing bug reports and/or trying to fix them myself, and I even got some of them working from the command line. The lack of ps filters is a major drawback of the new version. I have to learn to make those from the command line, and store everything in cheat sheets. With KDE 3.5 I could simply create a new filter that performed exactly what I was interested in, and then share it with everyone else, etc.

The idea of using an unified printing framework like org.openprinting.PrintDialog sounds really nice, but what about creating KDEPrintDialog that supports all the features kprinter did that I listed above *and* provides the org.openprinter.PrintDialog dbus interface at the same time? :) I'm personally voting for that path, if it is possible at all.

I have been experiencing this issue since I switched to KDE4. I thought I was just stupid and did not know how to save the settings once for all. I find it
extremely annoying. This definitely gets the maximum votes I can give it.

In my humble opinion:
-default should be duplex if the printer driver supports it (trees matter)
-whatever the default is, the user should be able to save her/his own preference, instead of having to set them again at every single print

Is this issue about duplex printing or the more fundamental problem of Non-Persistent Print Settings in the KDE+QT print system? 

There are many bug reports on the disto, KDE and QT trackers with unique headings that all relate to problems with non-persistent print settings in KDE apps. For example: KDE Bug 205802 and QT BUG-15351 relate to non-persistent margin settings. 

Installing the CUPS system-config-printer 1.2.5  (http://cyberelk.net/tim/software/system-config-printer/) will allow Printer related settings, such as Media Size, Print quality, Media Type, Media Source, Manual Feed, Duplex, Toner Save, Screen Lock & BR-Script Level, to be changed persistently. (thanks Red Hat!)

But other source related print settings (such as: margins, page orientation, etc., etc.) are outside scope of this program. These remain non-persistent and a source of frustration for KDE users. Having to change 4 margin settings for each print job is a distraction and a big waste of time. The many 'user' errors (!) that do slip through cause a shameful waste of paper. The problem is reproducible in many KDE apps, including Konqueror, Kwrite, Kate and Kmail. 

Entering, eg. margin settings, with the CUPS lpoptions command is not effective in my case (openSUSE 11.4 KDE 4.6). Such 'source related' print settings tend to be a bit more transient than 'printer related' settings so having to change them via CUPS may not be desirable, even if possible. 

Perhaps the many bug reports about non-persistent print settings in KDE + QT generally should be collated, analysed and actioned strategically? If so, that needs high level attention from the relevant distributions, KDE and QT, jointly.

Is this issue about duplex printing or the more fundamental problem of Non-Persistent Print Settings in the KDE+QT print system? 

There are many bug reports on the disto, KDE and QT trackers with unique headings that all relate to problems with non-persistent print settings in KDE apps. For example: KDE Bug 205802 and QT BUG-15351 relate to non-persistent margin settings. 

Installing the CUPS system-config-printer 1.2.5  (http://cyberelk.net/tim/software/system-config-printer/) will allow Printer related settings, such as Media Size, Print quality, Media Type, Media Source, Manual Feed, Duplex, Toner Save, Screen Lock & BR-Script Level, to be changed persistently. (thanks Red Hat!)

But other source related print settings (such as: margins, page orientation, etc., etc.) are outside scope of this program. These remain non-persistent and a source of frustration for KDE users. Having to change 4 margin settings for each print job is a distraction and a big waste of time. The many 'user' errors (!) that do slip through cause a shameful waste of paper. The problem is reproducible in many KDE apps, including Konqueror, Kwrite, Kate and Kmail. 

Entering, eg. margin settings, with the CUPS lpoptions command is not effective in my case (openSUSE 11.4 KDE 4.6). Such 'source related' print settings tend to be a bit more transient than 'printer related' settings so having to change them via CUPS may not be desirable, even if possible. 

Perhaps the many bug reports about non-persistent print settings in KDE + QT generally should be collated, analysed and actioned strategically? If so, that needs high level attention from the relevant distributions, KDE and QT, jointly.

Created attachment 62234 [details]
Patch to make okular respect the printers default duplex setting

Apparently the duplex setting of QPrinter defaults to DuplexNone. Changing it to QPrinter::DuplexAuto fixed the issue for me (see attached patch).

That's not the correct solution. QPrinter needs to respect the default set in CUPS. If we override it in Okular,
1. it will only work in Okular and
2. it will ignore the user's setting in CUPS.

The correct solution is the patch to Qt I attached (the fixed version of Jeremy Sanders's patch).

Margins are also not remembered in Kate/KWrite (nor any other KDE application, afaik). This is a huge issue, see bug #205802. A fix would make a lot of users happy, but it seems there is no interest, see https://bugreports.qt.nokia.com/browse/QTBUG-15351

Git commit 1aa12bace62fffbcad357623842a0fc01607b3c0 by Dominik Haumann.
Committed on 07/08/2011 at 14:26.
Pushed by dhaumann into branch 'master'.

attempt to work around Qt printing bugs

NOTE: Saving & loading the margins works around QPrinter/QPrintDialog bugs:
- https://bugreports.qt.nokia.com/browse/QTBUG-15351
- https://bugs.kde.org/show_bug.cgi?id=205802
- https://bugs.kde.org/show_bug.cgi?id=180051
Changing the margins now works. However, when you reopen the print dialog
later, the WRONG margins are displayed. The correct ones are still used.
This is a critical bug in Qt.

The real issue is Qt. And it's a critical one. But since it wasn't fixed for
years, it probably will never get fixed. That's why this workaround is better
than nothing...

CCBUG: 205802
CCBUG: 180051

M  +43   -1    part/utils/kateprinter.cpp
M  +2    -0    part/utils/kateprinter.h

http://commits.kde.org/kate/1aa12bace62fffbcad357623842a0fc01607b3c0

Please go en masse to vote for this bug as it seems to be the bottleneck
blocking everything:
https://bugreports.qt.nokia.com/browse/QTBUG-3567
Ask reopening of this bug with a comment:
https://bugreports.qt.nokia.com/browse/QTBUG-6239

Save the trees! Fix this bug! :)

I've created an Ubuntu PPA with QT4-libs patched with the patch from comment #29... you can find it here: https://launchpad.net/~dhertel/+archive/qtprintfix1

The builds aren't compiled yet but I've already tested them before on another PPA and they work... just made one for their own because they take up quite some space :) So they'll be avaliable as soon as Launchpad has built them...

Cheers

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

I don't know about anything being fixed in 4.6.3. It isn't fixed here at 4.8.

In my case, I use multiple printers in different places and need to remember the settings for each. The vast majority can do duplex. Okular defaults to single-sided though its properties list for the printer claims duplex, I think, but the options say otherwise.

So there go some trees.

It defaults to colour though all the printers I use are either B&W or being used to print B&W. The print dialog is the same for every printer regardless of the printer's capabilities. There goes some time and energy.

It gets worse. Some more trees are about to go.

Okular defaults for every job for every printer to US letter paper. None of the printers I have ever used with this machine have this size of paper. None of the printers I am at all likely to use with it in the foreseeable future will have this size of paper. Most of the printers in the world don't have this size of paper. In most places, including this one, it is virtually impossible to obtain this size of paper even if, for some reason, you wish to do so.

CUPS is the right way to do it. Why even include the print settings in system settings? It has zero effect although it sometimes crashes.

You need the Qt patch from comment #29 or from http://pkgs.fedoraproject.org/gitweb/?p=qt.git;a=blob;f=qt-everywhere-opensource-src-4.6.2-cups.patch;h=e0305e11b89aa6332573a0e9bb955f38038a8123;hb=HEAD (it's the same patch). (Thanks to Jeremy Sanders for the original patch which I fixed.)

Thanks for pointing to the patch referenced above.

I assume that would require compiling QT from sources and configuring things to use the hacked library as explained around comment 17?

I don't, frankly, think I am up to managing that. I've tried compiling QT in the past and it has always ended in failure. I did once manage to compile something but as I remember it didn't actually work. Plus it is an awful lot of work and I don't really have time to do that for every update, something I'd assume would be needed.

In any case, if I understand the patch's function correctly, it won't really help me much. It won't pick up the CUPS paper size so without intervention, KDE will still send everything formatted for letter paper rather than A4. It also won't pick up the quality settings I need set for some of the printers I use in order to get output which is dense enough to photocopy legibly. QT's print dialog doesn't even give display most of these options because it is insensitive to the actual capabilities of the printer as provided in the ppd. Non-saving of settings is only part of the problem - there are also the settings which I cannot set through the dialog but which should be available from CUPS. (QT's dialog shows them in Properties but I'm not sure what the point of that bit of the dialog is. Doesn't seem to have a function.)

In any case, telling end-users that the fix for a problem involves patching QT source and building the whole thing from scratch is not a solution.

The available patch is also out of date. It is for 4.6.2 and the version installed from my distro is 4.8.0.

Is there any reason *not* to consider e.g. the openprinting dialog? That looks to be very thoroughly thought through and researched. I know that is in its infancy but even if it is a bit buggy, it may well be better than the current dialog. Wouldn't this offer a solution which would fit in well to the KDE interface (since there's a QT version) and avoid relying on the development by QT (which clearly won't happen any time soon), while not requiring KDE developers to build a separate dialog for printing themselves? Since that will also likely be adopted by other DEs, it would also have obvious advantages in terms of adhering to common standards etc., and early adoption would make it more likely that the specific needs of the KDE ecosystem will be fully reflected in the development.

I don't know much of anything about development but there seem to be compelling reasons to consider an alternative to the QT default dialog and a promising alternative already in the works.

But that solution seems not to have been addressed...

> I assume that would require compiling QT from sources and configuring things to
> use the hacked library as explained around comment 17?

That's what a distribution is supposed to be for.

> The available patch is also out of date. It is for 4.6.2 and the version
> installed from my distro is 4.8.0.

The patch applies unchanged to 4.8.0. We apply it to the Fedora builds of 4.8.0.

> Is there any reason *not* to consider e.g. the openprinting dialog?
Yeah, I don't see any reason either. The rest of his reasoning is also sound... Now I have to find the KDE-Devel wishlist :-D If there's already a ticket voting for this, please someone point us to that so we can vote, too...

> I assume that would require compiling QT from sources and configuring things to
use the hacked library as explained around comment 17?
Depends on your distribution. On Ubuntu it's just "apt-get source qt4-x11", unpacking it, throwing the patch in the right directory, make a brief edit to 2 files, package the change via a single command and send it to your PPA on launchpad via a single command... After that it's waiting for launchpad to build the packages... When it's done, you can add your PPA as repository and upgrade the packages via apt... dunno if Fedora has such facilities...

> dunno if Fedora has such facilities...

Fedora already carries the patch in its official Qt packages.

> Fedora already carries the patch in its official Qt packages.
nevermind... I must have understood reescf@gmail.com as such that his distro was fedora somehow... it's still early in the morning and I've only had one coffee yet :-)

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

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.

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.

@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...

(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.

(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).

> 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.

@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.

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.

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.

@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...

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?

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

@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.

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.

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...

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.

@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...

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

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?

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.

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)

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?

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.

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.

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.

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.)

@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: 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.

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.

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

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.

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.

Created attachment 100374 [details]
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.

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/

(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.

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.

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.

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