Qt-5-QtPrint

History

In Qt4 we have QPrinter and related classes. For Qt5 it was decided this solution was inadequate, but that there was not sufficient time to develop a proper replacement solution for 5.0. Instead the existing code was separated in a new library within qtbase called QtPrintSupport. This provided the existing level of support and API but with a new plugin model for platform support. This module was marked as done in the maturity model and will not have any new features developed for it, but it will still be supported for the life of Qt5.

It was planned to introduce a new QtPrint module in to replace QtPrintSupport which fully implements support for modern printing services. A number of steps were implemented towards this in Qt 5.2 and Qt 5.3, with a new QPrintDevice class and platform backends being coded in private which the existing QtPrintSupport library now wraps around. It is planned for these private classes to form the core of the new QtPrint module so we have a single well tested backend implementation. Development has currently stalled on this however due to to lack of funding and time. Anyone interested in funding development should contact John Layt (j.layt @ kde.org).

Features

Key features planned include

• Full IPP v2 and IPP Everywhere feature support
• Settings Management
• Color Management
• Authentication
• Pull and Push Printing
• In-dialog preview
• Print System plugins

What QtPrint will provide:

• Query available printers, features and supported formats
• Submit print jobs
• Save Print Job Settings, e.g. CUPS Instances
• Windows / OSX / CUPS Print System plugins by default
• Community supported print systems like Google Cloud Print, HP ePrint, Android, IPP, etc
• A Qt CUPS/IPP/PDF print dialog

What QtPrint will not provide:

• Configuration of Printers or Print Systems
• Print Queue management
• OSX or Windows Qt print dialogs, native dialogs will be used
• A Common Print Dialog (CPD) implementation

While no management tools will be implemented, the CUPS dialog should provide hooks to launch such tools. A mechanism needs to be devised for this, possibly a new xdg command. At a minimum a web browser could be launched pointing to the relevant CUPS page. Also contact fd.o to add more print related icons to the icon standard, i.e. print-default, print-duplex, print-1up, etc. As an exception here, the Settings Management will save named user configurations in the host Print System if this feature is provided, e.g. CUPS Instances.

Print Queue management api may be considered at a later stage so no decision should be made in the design to prevent this.

The object model will closely follow the IPP model:

• QPrintSystem - The backend system such as CUPS
• QPrintDevice - A physical printer and it's features
• QPrintJob - A print job submitted to a QPrintDevice, consisting of QPrintSettings and 1 or more QPrintDocuments
• QPrintSettings - The settings to use when printing a document
• QPrintDocument - The document to print in native platform format, usually PDF but GDI on Windows

Note that the print system and painting sides need to be kept strictly separate wherever possible to allow different painting models to be mixed-and-matched with different print systems, i.e. on Windows we should be able to choose between printing to to native windows printer or Google Cloud without forcing the app to use a different painting method. The painting side is where I need particular help to clarify how this will work.

The Print System plugins will translate from this IPP model to the native Print System. For most systems this will be fairly transparent as CUPS, OSX, and various cloud services are all based on or support IPP. Windows may require some work as the native system does not use this model, although Windows servers do.

Features for discussion:

• Manual duplex mode - Ability to split Print Job into two to allow user to manually reload pages
• Cross-platform print file manipulation such as Booklet printing and n-up - unlikely cross-platform but could provide hooks for CUPS

Common Print Dialog (CPD)

The CPD is an initiative by OpenPrinting.org to have a common print dialog provided as a desktop service for all toolkits on Linux. It has been proposed that the Qt implementation should be included in Qt as the default. This should not happen. QtPrint and qtbase need to remain as light as possible and the requirements of the CPD are too heavy for this. QtPrint must already provide a fallback Print Dialog implementation for those platforms that do not wish to use CPD so the duplication is undesirable. It would also tie QtPrint development and CPD development too closely together. It is far more preferable that CPD be developed as a separate QtAddon with a QtPrint platform plugin implemented for systems where the CPD is installed.

Windows Support

Windows supports a number of print api's:

• Windows XP used GDI and DEVMODE based printing, spooled using EMF or RAW
• Windows Vista changed spool to XPS, new calls in existing API
• Windows 7 added XPS Print API, XPS Document API, GDI-XPS converter, back-ported to Vista in Platform Update (SP2)
• Windows 8 changed spool to OpenXPS, deprecated XPS Print API, replaced with Print Document Package API
• Windows 10 is as yet not investigated

All API's are supported in all subsequent Windows versions, usually via a conversion layer, so it is best to use the native format for the version you are on.

From QT 5.6 onwards WinXP and Vista support is no longer required, so Windows platform support will target use the XPS Print API. For WinRT/Win8 can probably do a separate plugin?

XPS Support

XPS support will be coded at the same level as PDF support, i.e. an implementation of a QPagedDocument in QtGui.

See http://en.wikipedia.org/wiki/Open_XML_Paper_Specification for details.