When the “Printer Properties -> Page” is first opened from the Print Dialogue it is populated with (what I assume) are default settings, for example left/right/top/bottom margins.
If I change those to what I require, close the dialogue and print, the next time “Printer Properties -> Page” is opened the settings have reverted back to the “default”. This is irrespective of the printer selected, so are not printer defaults.
This was not the behaviour under KDE4, once changed, the settings remained until one changed them again.
It is, to say the least, somewhat annoying to have to set the print margins every time one wishes to print. >:(
Is this a genuine bug, or am I doing “something” wrong?
Also, if a bug, what component should the bug report be against?
I can’t offer technical advice on this but I can confirm the problem.
My (dumb user) take on this is that yes, it seems to be a QT thing - QT started with mobile phones, so persistence was not of utmost importance to those developers, they wanted (and got) a clean instance created fast and on the fly. So fixing persistence issues with QT was/is not so easy. The same issue arose with the birth of KDE4. At first minor print issues like this were drowned out by loud objections to the many other functional ‘downgrades’ from KDE3 - so it goes. It took a long time for users to get a fix because … it’s complex. The bug reports were user specific (ie. ignorant of the underlying engineering issues), they related to many different print problems with many different KDE software projects and were filed on different ‘bug lists’ in an uncordinated way. It was unclear which team should act so the issue bounced around the different silos for quite a while: project developers <> openSUSE <> KDE <> QT - you know the story. So it took a few years for someone (bless them) to pull it together, set a target (QT), write a patch and make it ‘really easy’ for QT to fix it. There was a rumour that a SUSE developer was involved. I guess SLES needs a working printer. I do hope that person is still around. They won’t be reading this. They may need a few good bug reports from ‘big client’ admins, linked and posted to openSUSE, SLES, KDE and QT lists and quite a few ‘me too’ user follow-ups.
In the mean time the ‘tab’ key is your friend. With it you can reduce a possible 24 keystrokes to correct a default print margin (4.26mm !!) to about 12 keystrokes.
Hope this helps.
As you’ve found the desktop printing options are not persistent. If you want settings to be persistent, you can do that via the CUPS web interface http://localhost:631/printers
Select the printer > Administration > Choose Default Options
You can also add another printer queue with specific printing options set for different situations. For example, full colour vs grayscale printing.
I don’t know where KDE/Qt is obtaining it’s “default” margin settings from, but it’s not the printer driver defaults, as the “defaults” are identical irrespective of the printer selected (including Print to File).
If I change the (driver) default margin settings (which I can only do for the HP, the Samsung has no settings for that), using either “YaST -> Printer Configuration -> (Select Printer) -> Edit -> All options for current driver -> (Margins)”, or via the CUPS web interface, the KDE/Qt Print Dialogue still shows it’s “default”; and, it is those settings that are used (unless changed there) when printing.
This is what I’m always presented with upon first opening of the print dialogue…
… and it is those settings that are applied, if I change the margins there it will print with those settings. Re-open the print dialogue and it reverts back as shown in the screenshots.
Both printers are connected, available, and work… (The HP is directly connected via the parallel port, the Samsung is a network printer).
This is on TW (20170816), Plasma 5.10.4, KDE Frameworks 5.36.0, Qt 5.9.1
Thanks for the further clarification. Although I’m using KDE Plasma 5, I don’t often print via KDE applications. At the most the occasional firefox page printed, and sometimes direct from the command line, so I can see how this would be annoying. I guess an options specified in ~/.cups/lpoptions are ignored as well?
I assume that the Qt margins are likely hard-coded.
There is a lot of stuff hard coded in QT printing support, like the list of paper sizes for example. See https://bugreports.qt.io/browse/QTBUG-58733 for the bug report. No one in QT seems to be the slightest bit interested in fixing these issues. This one stops me from printing on certain printer supported sizes which are not standard. It affects all applications using QT.
Yes, I recall that ‘bug’. It’s incomprehensible (to me at least) that they don’t utilise the relevant info from CUPS or even perhaps at least save/use printing preferences in ~/.cups/lpoptions.
Thinking about it for only a moment, it would make sense that individual (KDE) applications maintained their own settings. Question now is, why is that no longer the case, at least with kate, I’ve yet to investigate others…
Looking at “~/.config/katerc” on both a Leap 42.3 and TW system there are no “Kate Print Settings” and if that section is added it is, as I expected it to be, ignored.
I feel a kate, bug report, regression, wish, whatever coming on …
I am just wondering if when applications move to QT Print Support all this stuff is no longer possible and it all has to be done in QT? I notice Kate had the paper issue as it uses QT but last time I tried it GIMP for example did not and all the old ways of setting paper size worked, at that stage I guess it had not move to QT.
It’s only KDE applications that will use the Qt Print Dialogue, or at least that’s my assumption.
There’s no problem with non KDE applications. GIMP, Firefox/Thunderbird, and Libre Office for example, all operate as before, fully capable of controlling the printers functions.
Hmm… Paper size hasn’t been an issue with me, as I only print to A4.
I see what you mean though; in the (Qt) printer dialogue the drop down list for paper sizes appears to list all of the sizes supported by the selected printer - but many of them, when selected revert to the default A4 size. >:(
I suppose a rather dirty and time consuming method of printing on your preferred paper size would be to open the images in GIMP and print from there, rather than printing directly from digikam.
Yes that is what I am forced to do currently. I suspect if you look carefully you will see sizes listed that your printer does not support, probably as well missing some it does support like 5x7 inch.
I doubt adding users to the ‘sys’ group would help in any case. (Even the CUPS administrator is group root by default.) This needed QT changes to effect such user-level persistence as broadstairs and others have already pointed out.
I was a bit inaccurate, sorry. I mean that you can open the /etc/cups/cups-files.conf file and look at the line:
SystemGroup sys wheel
If you are a member at least of one group from the list (not necessarily sys), then the KDE print manager won’t ask you for password when playing with printer’s settings.
At least I know it’s not “just me” - Thanks.