[Printing-architecture] Printing in Qt/KDE

[Printing-architecture] Printing in Qt/KDE

[John Layt]

Hi,

Apologies for not being very responsive on list to the follow up to the 
printing summit and CPD, other priorities intervened.

You may have heard that Qt have decided the forthcoming Qt 4.8 release will be 
the last in the Qt4 series and will be followed by Qt5, the first release 
under the new OpenGovernance development model.  I've just got back from the 
Qt Contributors Summit where the plans for Qt5 were discussed, including what 
to do with printing.  You can see some notes from the meeting at 
http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Printing

In summary, Qt do not have the developer resources to make feature changes to 
printing, but are happy for the community to contribute new features.  For Qt5 
the existing Qt Printing code will moved into a separate module and put into 
support mode to allow the community to develop a replacement printing module 
for inclusion into Qt 5.1 or 5.2.  Basically we've been given a clean sheet 
for designing a new cross-platform api and feature set, but using the old code 
as a starting point.  Obviously CPD will come into consideration in the design 
process.

I plan to start work on this in about 2-3 months after some other Qt5 tasks 
are completed.  If anyone is interested in working on this, or has ideas on a 
nice api and class structure I'd be happy to hear from them.

Moving on to the CPD briefly, I was looking at the api for applications adding 
extra options to the dialog and it looks like it will be insufficent for 
current KDE applications that add complex option widgets.  For an example see 
Gwenview's 'Image Settings' tab.  I'm not sure there's any way such complex 
requirements could be met using a generic DBus api or cross-toolkit dialog.

Cheers!

John.

Re: [Printing-architecture] Printing in Qt/KDE

[John Layt]

On Wednesday 22 Jun 2011 23:49:12 John Layt wrote:
> You may have heard that Qt have decided the forthcoming Qt 4.8 release will
> be the last in the Qt4 series and will be followed by Qt5, the first
> release under the new OpenGovernance development model.

Hi,

Just as a follow up to this, you may have seen that Nokia has now launched the 
Qt Open Governance project at qt-project.org and if you look closely enough 
you will see I have been appointed maintainer of the QPrinter module.  
Basically it means I am now responsible for the ongoing maintenance of 
QPrinter in Qt 4.8, and have the final say on any new code going into QPrinter 
from Qt 5 onwards.  So if you have any issues with Qt printing, you know who 
to kick :-)

With regards to future plans not much has changed, my time is tied up with 
other stuff for Qt 5.0 so I'm starting with a bug triage for now, with new 
code to come in 5.1 or 5.2.

Cheers!

John.

Re: [Printing-architecture] Printing in Qt/KDE

[Petrie, Glen]

Hi John,

I reviewed the QPrinter Class Reference information.  While it appears
that most of the objects, attributes and values needed for printing are
present; I don't see that they align with existing and emerging
standards today; specifically, the PWG.  

The PWG has had IPP and is now creating the PWG: Job Ticket (which
contains the objects, attributes and values) for printing.  Companies
like Google, Apple, etc have stated or hinted they will be supporting
the PWG standards and the Job Ticket.  Therefore, an area for
consideration is for QPrinter to align and extend the current printing
specific enum's to be more inline with the PWG Standards/Specifications.
I have not check if any new QPrinter enum's or functions are needed to
support the above standards; but it is another area for consideration. 

Next, the print paradigm is shifting from print/printer drivers to print
services.   This further implies that a print service now receives a
"print job" which consist of a print job ticket and print content (print
document, if you like).   Like Adobe's Acrobat application which can
generate a JDF Job Ticket, another area of consideration is for QPrinter
to generate a "print job"; consisting of a print job ticket and print
content.   This also helps to support Cloud Printing.   I do understand
that the QPrinter::paintEngine could provide this functionality but
having the functionality built directly in to QPrinter, eliminates
developer having to recreate it. 

Glen


-----Original Message-----
From: printing-architecture-bounces@lists.linux-foundation.org
[mailto:printing-architecture-bounces@lists.linux-foundation.org] On
Behalf Of John Layt
Sent: Thursday, October 27, 2011 10:20 AM
To: printing-architecture@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Printing in Qt/KDE

On Wednesday 22 Jun 2011 23:49:12 John Layt wrote:
> You may have heard that Qt have decided the forthcoming Qt 4.8 release
will
> be the last in the Qt4 series and will be followed by Qt5, the first
> release under the new OpenGovernance development model.

Hi,

Just as a follow up to this, you may have seen that Nokia has now
launched the 
Qt Open Governance project at qt-project.org and if you look closely
enough 
you will see I have been appointed maintainer of the QPrinter module.  
Basically it means I am now responsible for the ongoing maintenance of 
QPrinter in Qt 4.8, and have the final say on any new code going into
QPrinter 
from Qt 5 onwards.  So if you have any issues with Qt printing, you know
who 
to kick :-)

With regards to future plans not much has changed, my time is tied up
with 
other stuff for Qt 5.0 so I'm starting with a bug triage for now, with
new 
code to come in 5.1 or 5.2.

Cheers!

John.
_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Printing in Qt/KDE

[John Layt]

On Monday 31 Oct 2011 09:56:11 Petrie, Glen wrote:
> Hi John,
> 
> I reviewed the QPrinter Class Reference information.  While it appears
> that most of the objects, attributes and values needed for printing are
> present; I don't see that they align with existing and emerging
> standards today; specifically, the PWG.
> 
> The PWG has had IPP and is now creating the PWG: Job Ticket (which
> contains the objects, attributes and values) for printing.  Companies
> like Google, Apple, etc have stated or hinted they will be supporting
> the PWG standards and the Job Ticket.  Therefore, an area for
> consideration is for QPrinter to align and extend the current printing
> specific enum's to be more inline with the PWG Standards/Specifications.
> I have not check if any new QPrinter enum's or functions are needed to
> support the above standards; but it is another area for consideration.
> 
> Next, the print paradigm is shifting from print/printer drivers to print
> services.   This further implies that a print service now receives a
> "print job" which consist of a print job ticket and print content (print
> document, if you like).   Like Adobe's Acrobat application which can
> generate a JDF Job Ticket, another area of consideration is for QPrinter
> to generate a "print job"; consisting of a print job ticket and print
> content.   This also helps to support Cloud Printing.   I do understand
> that the QPrinter::paintEngine could provide this functionality but
> having the functionality built directly in to QPrinter, eliminates
> developer having to recreate it.
> 
> Glen

Thanks Glen.  Yes, the plan for the new printing support in 5.1 or 5.2 is a 
completely new api and class model around modern standards, the IPP, Job 
Ticket and OSX api are high on my list of models to investigate.  As Qt is a 
cross-platofrm toolkit, and CUPS is on two of the three official reference 
platforms, supporting that model will be our primary target, with Windows 
printing being mangled to fit as best as possible.  Devices and the Cloud are 
also of great interest to Nokia and KDE.  And of course there is the CPD to be 
integrated if installed so the api of that will be influential too.

I'll certainly be asking the list for feedback on the design, but that design 
process probably won't start until next year.

Cheers!

John.