[Printing-architecture] The Common Printing Dialog and PDF as standard print job format for Qt/KDE applications

[Printing-architecture] The Common Printing Dialog and PDF as standard print job format for Qt/KDE applications

[Till Kamppeter]

Hi,

at OpenPrinting [0] we have developed several new technologies for 
making printing more reliable and much easier for the user. Currently, 
we have 5 Google Summer of Code students and so we get a lot of our 
ideas implemented. Two of our projects need changes in graphical 
applications and/or the GUI toolkit libraries, as for example Qt. One is 
the Common Printing Dialog and the other is the use of PDF as the 
standard print job format. Both features have found a wide acceptance on 
the Printing Summits [10] and implementation has started now. especially 
with a lot of support from the printer manufactures for the PDF printing 
workflow.


Common Printing Dialog
----------------------

As most of you already know, OpenPrinting and OpenUsability have 
developed a Common Printing Dialog for all desktops and applications 
[1], [2], [3]. Ubuntu blueprint at [9]. This should make printing much 
easier as if they get used how to print with application A they 
immediately know how to print from application B. It will also get 
assured that there is always access to all functionality of the printer 
(driver) and the printing system, requiring no effort from application 
developers. We would like to have the support from Qt and KDE to make 
applications interfacing to the new dialog by a plug-in interface. This 
will not only allow to use our dialog as the common one but also any 
other one, as the ones from Qt or GTK for example.

The interface is designed and implemented by Lars Uebernickel, one of 
the Google Summer of Code students [7]. The specs for this interface are 
work in progress on [4]. Requirements are written up on [5]. This 
interface needs also to be implemented in the applications and/or their 
common GUI libraries, in our case Qt. Lars will work on patching the 
libraries, but these patches should not only go into packages of Linux 
distributions but also into the upstream software repositories. So I ask 
you for working together with Lars to make these patches also part of 
the upstream code.

Patches should only be used as a backport of a feature from a future 
software version to the software in the current version of a 
distribution (in the case the software currently under development will 
not make it into the next releases of the distros.


PDF as the Standard Print Job Format
------------------------------------

To improve the reliability of the printing process, especially for 
complex graphics, high color depths, and for jobs where pages get 
separated and reordered (2 pages per sheet, booklets, selected pages, 
...) we are switching from PostScript to PDF as standard print job format.

The server (printing system) side is nearly completely implemented in 
the form of new CUPS filters and file conversion rules.

On the client (application) side it is needed that the applications 
generate the print jobs in PDF and not in Postscript. This would mean a 
change of the application and/or GUI library code, probably only the 
latter (at least for Qt applications). This is not absolutely urgent, as 
  CUPS can convert PostScript to PDF with a pstopdf filter, but 
applications which directly produce PDF have a better control over the 
graphical quality of the print job, and they even solve page management 
(2 on a sheet, booklets, selected pages, ...) problems on old 
PostScript-based servers, as a CUPS filter will generate PostScript from 
the incoming PDF then (pdftops) and this PostScript is much cleaner as 
the one coming from most applications.

So I am asking you whether you can change the Qt library to make the 
"Print" command in Qt-based applications emitting PDF instead of 
PostScript. To not break lagacy, non-PDF-capable environments, make this 
a configurable option. If you have already doe so, please tell how to 
configure the Qt library to output PDF, so that we will make this 
configuration setting the default in all Linux distribution.


I am very grateful for any support from the Qt and KDE side in terms of 
these OpenPrinting projects. They will improve the printing workflow a 
lot and will make many bugs and user complaints go away.

    Till


[0]http://www.openprinting.org/
[1]http://www.mmiworks.net/eng/publications/labels/openPrinting.html
[2]http://wiki.openusability.org/printing/
[3]http://wiki.openusability.org/printing/index.php/Specification
[4]http://www.linux-foundation.org/en/OpenPrinting/Specifications
[5]http://www.linux-foundation.org/en/OpenPrinting/Requirements
[6]http://portland.freedesktop.org/wiki/PrintDialog
[7]http://code.google.com/soc/2008/linux/appinfo.html?csaid=53E53CD78F134BE9
[8]http://code.google.com/soc/2008/linux/appinfo.html?csaid=9D65D29842F34550
[9]https://blueprints.launchpad.net/ubuntu/+spec/applications-printing
[10]https://www.linux-foundation.org/en/OpenPrinting/MeetingInfo
[11]https://blueprints.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format

Re: [Printing-architecture] The Common Printing Dialog and PDF as standard print job format for Qt/KDE applications

[Klaus Singvogel]

Hi,

Till Kamppeter wrote:
[...]
> PDF as the Standard Print Job Format
> ------------------------------------
> 
> To improve the reliability of the printing process, especially for 
> complex graphics, high color depths, and for jobs where pages get 
> separated and reordered (2 pages per sheet, booklets, selected pages, 
> ...) we are switching from PostScript to PDF as standard print job format.

I'm not happy about this decission, as PDF contains the document data
at the end of the document, whereas PS is containing the data in the
head of the document. Means an uncomplete document might partly be
printed in PS, whereas not in PDF.

Another issue for OpenSource distributions will be that PDF guarantees
that several fonts are always in the processing system (the Base 14
fonts). See page 3 on:
http://www.planetpdf.com/planetpdf/pdfs/pdf2k/03e/merz_fontaquarium.pdf
The issue is that these fonts are patented and NOT free to copy nor to
(re)distribute.

But I think, we'll arrange somehow with this decission in future.

Nevertheless: is there a limitation of the PDF version which will be
supported in future or not?
PDF-1.7 is approved as being the new standard:
http://www.theinquirer.net/gb/inquirer/news/2007/12/05/pdf-approved-iso-32000

But most OpenSource programs (like xpdf and clones) support only up to
PDF-1.4.

Therefore I'm asking, will be a PDF limitation made for Linux printing?

If we limit PDF printing in Linux to version 1.4, do we still have the
advantages of the switch from PS to PDF, like: complex graphics, high
color depths?


[...]
> So I am asking you whether you can change the Qt library to make the 
> "Print" command in Qt-based applications emitting PDF instead of 
> PostScript. To not break lagacy, non-PDF-capable environments, make this 
> a configurable option. If you have already doe so, please tell how to 
> configure the Qt library to output PDF, so that we will make this 
> configuration setting the default in all Linux distribution.

For better understanding: you're not asking for equal Gnome support,
because they are already doing so?
How did they solve the configuration of their library to output PDF?

Thanks in advance.

Regards,
	Klaus.
-- 
Klaus Singvogel  -  Maxfeldstr. 5  -  90409 Nuernberg  -  Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D  1994-06-27
SUSE LINUX Products GmbH,  GF: Markus Rex,  HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] The Common Printing Dialog and PDF as standard print job format for Qt/KDE applications

[Till Kamppeter]

Thomas Zander wrote:
> On Sunday 1. June 2008 18:51:51 Till Kamppeter wrote:
>> So I am asking you whether you can change the Qt library to make the
>> "Print" command in Qt-based applications emitting PDF instead of
>> PostScript.
> 
> We did that quite some time ago already.

Where do I have to set which option to make all Qt/KDE-based apps output 
PDF instead of PostScript when using the "Print" command?

    Till

Re: [Printing-architecture] The Common Printing Dialog and PDF as standard print job format for Qt/KDE applications

[Klaus Singvogel]

Hi,
sorry for delay, but our next product is upcoming, and sometimes time
is getting short at the moment at my side. :-)

I noticed that you couldn't fully dispel all my arguments, and
therefore I think you caugth the issues.

Still I've some comments to your last e-mail...

Thomas Zander wrote:
> 
> The usage of references means that it you are right that it is possible to 
> have the first page reference an object at the end of the document, but thats 
> just not how pdf exporters are written.

But the PDF-1.7 reference from Adobe is written so:
http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference.pdf

It could be viewed only (and only with acroread) after the file was
completely downloaded.

[...]
> > But most OpenSource programs (like xpdf and clones) support only up to
> > PDF-1.4.
> >
> > Therefore I'm asking, will be a PDF limitation made for Linux printing?
> 
> On screen PDF viewers are not really relevant here, the support of the 
> standard in the printer is.

Sorry, but how is the printout on non-brandnew or non-PDF-able printers
done?
Isn't there a conversion to older PDF versions or to a printer
specific rasterization necessary?
Which tool do you think is used for doing so, if not xpdf?

> But more to the point, newer versions tend to only add multi-media versions 
> (like 3D stuff) which obviously is not really relevant.

What about the JPEG2000 support (PDF-1.5)? I doubt that it is
multi-media related, and having doubts regarding "non relevant
feature" classification either.

What about the layering? I got bugzilla entries where the layering in
some newer PDF versions produced wrong printouts (different then in
viewer). I.e. https://bugzilla.novell.com/show_bug.cgi?id=377878

A technique, which was introduced with PDF-1.6, I think.


> On another note; KDE and poppler are working hard on getting that support up; 
> which is the obvious correct solution, again IMO.

I agree. But I heard about this rumor quiet some time now, and got
doubts that it will ever be done.

Regards,
	Klaus.
-- 
Klaus Singvogel  -  Maxfeldstr. 5  -  90409 Nuernberg  -  Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D  1994-06-27
SUSE LINUX Products GmbH,  GF: Markus Rex,  HRB 16746 (AG Nuernberg)