Bug 176999

Changing subject as it happens for any program using qprinter and friends

I'm not sure it is a Qt bug, as I recently wrote a Qt only app where it behaves like this: as long as you keep the QPrinter object, it will store the settings. So if okular deletes it and creates a new one when a new document is opened, it needs to store itself the printer settings somewhere.

Are you sure this is the intended usage? assistant and designed have the problem described here too.

This is my experience, but the documentation doesn't clarify how it should behave. Only the source (or Qt support) could clarify it. ;)
But somewhat it makes sense, the settings are in the QPrinter object, the dialog just configures it.
BTW, I'm talking about the Properties dialog that can be invoked from the Print dialog, and just tested with assistant, it remembers the setting until it is started.

Not here:

 * Open assistant
 * Bring up print dialog
 * Press Properties
 * Change page size to Letter (was A4)
 * Press close
 * Press print
 * Bring up print dialog
 * Press Properties
 * Page size is A4 not Letter

Tried again with qt-copy and 4.4.4 from the opensuse packages and in both cases it works as expected. Can't test okular as I don't have a real printer and I cannot select to print into a file. 

There's two issues at play here.  The first is there does appear to be a bug affecting persistence of Page Size in the Properties/Paper tab but not in the Properties/Advanced tab.  The second is that settings don't persist between runs.

As mentioned, if you keep the same QPrinter instance around, then the settings persist between print jobs.  However, quitting the app will lose those settings.  What is needed is Qt to add two methods to QPrinter to serialise and reload the full settings including selected printer.  Apps could then use this to save the settings either at application or document level.  I would like to see direct support for users able to save and load settings in the QPrintDialog like OSX does (see attached), but cross-platform support issues would need to be thought through.

As for the apparent bug, if I go into Properties/Paper/Page Size and change it from A4 to Letter, print, and then come back in, the Page Size is reset to A4.  But if I go into Properties/Advanced/Media Size and change it there (i.e. the PPD setting for page size) then this does persist, and next time the Properties/Paper/Page Size gets set to that value as well.  Also, changing either value does not reflect in the other at the time, which could be seen as a bug as well.  Perhaps there's a matching issue there with the PPD option name?

So that's 1 bug and 1 feature request to go upstream.

Created attachment 29193 [details]
OSX User Settings

John can you take these two issues to Qt people that you've been working/battling with printing?

May I suggest that this bug may be the same as that described in Bug #177360 ?

Nope, as explained, there are two other issues here:

1) where the Properties/Page paper size setting and the Properties/Advanced paper size are not kept in sync by Qt, 

2) where Qt does not provide a means of persisting print settings between application runs.

Both these need feature requests to Qt.

I'm seeing the same behaviour with the print Duplex option in eg kate or okular, ie in Print Properties/Advanced it detects the default printer setting of 2-sided printing = Long-Edge Binding correctly, but in Options/Options Duplex printing shows as None, although it does print as duplex.

Is this close enough to the original bug to stay here or would you like me open a new bug for this issue.

This is not limited to Okular and I don't think that it has been determined that this is a Qt problem.

See comment #5 and #7. Qt problem indeed (missing ability of QPrinter to store/save settings).

Re: Comment #14

It is not possible for Qt to store these settings.  The storage must occur in KDELibs.  To be specific, Qt contains the classes QPrint and QPrintDialog, but there is no way that a class can store information.  Only an instance of a class can store information.  Since the instances of the classes are deconstructed after printing and a new instance is constructed next time printing occurs, there can be no storage at the Qt level.

Slight change in title for clarity.

(In reply to comment #15)
> It is not possible for Qt to store these settings. [...]
> To be specific, Qt contains the classes QPrint and QPrintDialog, but
> there is no way that a class can store information.

This is _exactly_ what is being discussed here: those classes have no such
functionalities, so they should be requested for addition in Qt.

> The storage must occur in KDELibs.

Given the amount of internal settings (both general and platform-related) in
the Qt printing system, it is simply impossible to do a complete save/restore
of the whole settings provided by that. That's why it should be done in Qt.

Qt provides these methods:

void setCollateCopies ( bool collate ) 
void setColorMode ( ColorMode newColorMode ) 
void setCreator ( const QString & creator ) 
void setDocName ( const QString & name ) 
void setDoubleSidedPrinting ( bool doubleSided ) 
void setDuplex ( DuplexMode duplex ) 
void setFontEmbeddingEnabled ( bool enable ) 
void setFromTo ( int from, int to ) 
void setFullPage ( bool fp ) 
void setNumCopies ( int numCopies ) 
void setOrientation ( Orientation orientation ) 
void setOutputFileName ( const QString & fileName ) 
void setOutputFormat ( OutputFormat format ) 
void setPageMargins ( qreal left, qreal top, qreal right, qreal bottom, Unit unit ) 
void setPageOrder ( PageOrder pageOrder ) 
void setPaperSize ( PaperSize newPaperSize ) 
void setPaperSize ( const QSizeF & paperSize, Unit unit ) 
void setPaperSource ( PaperSource source ) 
void setPrintProgram ( const QString & printProg ) 
void setPrintRange ( PrintRange range ) 
void setPrinterName ( const QString & name ) 
void setPrinterSelectionOption ( const QString & option ) 
void setResolution ( int dpi ) 
void setWinPageSize ( int pageSize )

For, KDELibs to have a method that calls these using data stored in a KDE configuration files is far from impossible.  In fact, it is the correct way to do it as stated in the Qt documentation.  Yes, this method could be in Qt rather than KDELibs, however, KDELibs would still have to provide the data since, as I stated, the Qt library cannot store the information.  The information must be in a configuration file and that would best be done in KDELibs.

It seems you are quite new to the Qt printing system, and that explains why you are trying to find solutions that are actually impossible to be done.
I'll just give you one example from the list you rolled up:

> void setNumCopies ( int numCopies ) 

The correct getter for this would be numCopies(), do we agree?
Ok, try to query numCopies() on a X11 system with CUPS: you will always get 1.
This is because Qt is smart enough to just tell to applications to print one copy, while making use of CUPS' copies feature.
As you can imagine, in such configuration is basically impossible for anything out of Qt getting the exact printing information.

> since, as I stated, the Qt library cannot store the information.

Sure it can: for example, look at your ~/.config/Trolltech.conf and ~/.config/Trolltech/*.

"The correct getter for this would be numCopies(), do we agree?"

Most certainly not.  Yes, there is an issue with number of copies.  However, this is not where that issue will have to be addressed.  What you have brought up is the question of what is going to happen to the information the user provided when they set the number of copies in QPrintDialog's widget.  This is an issue, but it is not the same issues as the fact that when this widget opens that the information in it should be the user's defaults and the the user's defaults are best provided by KDELibs.

Yes, there are Qt configuration files.  I don't think that it is best to store user supplied information that way, but I already said that it could be done.  What I said was that the library (the software, specifically the QPrint class) can't remember this information because it does not persist.  Either way, when instances of the QPrint and QPrintDialog is constructed, the information must be read into it, the class cannot store this data.

Now, we could have an abstract discussion of whether it would be best for Qt or KDELibs to have the method to store and retrieve the user's print defaults.  However, the question before us is whether we ask Trolltech to implement features and continue to ship a defective product until they do (if they ever do) or to implement it in KDELibs (which should have been done before 4.0.0 shipped).

Also note that we are talking about the users defaults which would be selected somewhere other than the Print Dialog.  We are not talking about the user being able to save the settings that they select in the Print Dialog.  That is a feature that Qt does not support and we should consider that a Qt bug.

> What you have brought
> up is the question of what is going to happen to the information the user
> provided when they set the number of copies in QPrintDialog's widget.  This is
> an issue, but it is not the same issues as the fact that when this widget opens

No, it is the same issue, as all the printing information are provided by QPrinter/QPrintEngine.
The options provided by QAbstractPrintDialog are just for the configuration widgets, but actually provided via QPrinter.

> What I said was that the library (the software, specifically the QPrint class)
> can't remember this information because it does not persist.  Either way, when
> instances of the QPrint and QPrintDialog is constructed, the information must
> be read into it, the class cannot store this data.

Exactly, _exactly_. QPrinter is missing functionalities here, ie at least the possibility to save/restore its settings, even if the actual saving job is done externally of it.
Until QPrinter cannot do that, saving its information externally (querying it via the getters) will always give partial and incorrect information.

> However, the question before us is whether we ask Trolltech to implement
> features and continue to ship a defective product until they do (if they ever
> do) or to implement it in KDELibs (which should have been done before 4.0.0
> shipped).

Since KDE decided to rely on the Qt printing facilities, the only acceptable solution is to push QtSoftware to implement them, telling they are vital for KDE. There are not others.

Re:Comment #21

"Since KDE decided to rely on the Qt printing facilities"

Perhaps this was a bad decision and it is really this decision that is the bug!

(In reply to comment #22)
> Re:Comment #21
> 
> "Since KDE decided to rely on the Qt printing facilities"
> 
> Perhaps this was a bad decision and it is really this decision that is the bug!

It actually wasn't a "decision", it was simply the fact that there was nobody willing to port the kde3 printing code to KDE4 and make it work across all platforms. Implementing printing support is apparently a rather boring, tedious and time-consuming thing to work on.

I saw a task was created for this: 
http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=244538

But 100% this won't happen in 4.5.0, I doubt they will introduce new functionality in the 4.5.x lines, so IMO the earliest we can see the fix is 4.6 sometime in the future.

So if you ask me, I'd say having a KPrinter or whatever class in KDE that saves/restores what is possible makes sense. In the future the implementation for those can just call QPrinter's save/restore methods. Yes, it introduces some API that will add no value in the future, but at least would give users a better KDE experience.

Re:Comment #24

I would suggest that the task be clarified since Qt already has operators to save and restore "settings".  For example:

void QPrinter::setPaperSize ( const QSizeF & paperSize, Unit unit )
PaperSize QPrinter::paperSize () const

What is needed are KDE methods to read a file and set them and then to obtain them and write to a file.

That isn't all of it however since the Qt Print Dialog does not display all of the printing paramaters (such as resolution and mode [photo/text]).  So, we really need a KPrintDialog class that adds the additional functionality.  This would make it simple to read the file when the instance of the class was created and write it in the destructor.

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

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

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

I've created the two Qt bugs/wishes John mentioned

QPrintDialog for unix has multiple settings for paper size
http://bugreports.qt.nokia.com/browse/QTBUG-6468

QPrinter should provide a way to store/restore the settings
http://bugreports.qt.nokia.com/browse/QTBUG-6469

Please feel free to watch/vote at yuor discretion

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

I think this is related: 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.