Sie sind auf Seite 1von 4

Table of content

QtPrint..........................................................................1
Common Print Dialog (CPD) .............................................2
Windows Support........................................................... 2
XPS Support.................................................................. 2

QtPrint
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 is
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 is planned to introduce a new QtPrint module in Qt 5.1 or 5.2 to replace QtPrintSupport which fully
implements support for modern printing services.
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 its features
* QPrintJob A print job submitted to a QPrintDevice, consisting of QPrintSettings and 1 or more
Page 1 of 3

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 apis:
* 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
All APIs 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.
Will target default support of new library at XPS, i.e. Vista SP2 and later. WinXP will remain with old
library using GDI. For WinRT/Win8 can probably do a separate plugin?

Page 2 of 3

XPS Support
See http://en.wikipedia.org/wiki/Open_XML_Paper_Specification
The only WinXP support is a download for the XPS Document Writer to print to an XPS file from the
print dialog.

Content is available under


Creative Commons Attribution-ShareAlike 2.5 Generic

Page 3 of 3

Das könnte Ihnen auch gefallen