Bug 106512

Difficult to implement without many architectural changes in kdeprint *and* in the applications. The main problem is that no print data have been generated when the print dialog opens. This happens *after* the print dialog is closed.

Michael.

These architectural changes do allow the print dialog to become much more powerful in future KDE releases. 

Because the dialog will have the print data readily available, it can do all kinds of things with it. For instance, it can use the print data to recommend certain print settings to the user. If the print data specifies paper size, orientation, etc (A word processor will do that), the corresponding user controls in the print dialog can be locked. If the print data does not contain that information (image editors) the user will be free to interactively choose the best scaling, paper size, orientation, and so on from the print dialog. And the user can see the effect of these settings immediately. 

This identifies one more possible advantage of this architecture change: Graphics applications will no longer have to implement their own printing controls (Currently, few KDE graphics apps have decent printing controls like GIMP has). A single implementation of these controls can be implemented in KDEPrint and all KDE graphics applications will have the same powerful graphics printing controls. 

If there is time to do 'only' the architectural changes for KDE 4, it will allow KDE developers to actually implement more powerful interactive controls in later KDE 4.x releases.

Please correct me if I'm wrong, I don't know much about KDE architecture... ;)

The major problem is that some print options needs to be known *before* the print data generation process starts (paper size, resolution, orientation...), so this question is far from easy.
Note however that the process you describe regarding paper size and option lock-down is something that already exists (at least partially, for paper size and orientation) in koffice applications.

Michael.

> The major problem is that some print options needs to be known *before* the print data generation process starts

Hmm.. that would require an architecture where the app calls the printing system, and the printing system requests print data from the app whenever it needs to, specifying the required paper size and so on. When the user changes settings, the printing system requests new print data from the app, if necessary. When the app says it does not fancy a particular page size or orientation, like an image viewer might do, the printing system can scale, rotate, move the print without requesting new print data from the app.

> Note however that the process you describe regarding paper size and option lock-down is something that already exists

Ah, yes I see it.  Nice.. It goes almost unnoticed because these settings are behind the 'properties' button.

After having programmed printing under .NET/Win32, I must agree that the paradigm used in this system allows maybe more powerful features from the print side. In kdeprint, the application controls the print object, while in the other system, it's more the print object that controls the application through a set of callbacks: the app creates the print object and registers itself to it; then the print object controls how the printing will be done, creates the graphic device object (for drawing) and requests the app to print a page on it; the app then responds with "I need more pages to complete".

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have implemented this wish.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann