[Desktop_printing] Agenda proposal: Replace PostScript by PDF asjob transfer format

Bastian, Waldo waldo.bastian at intel.com
Mon Jan 9 15:00:32 PST 2006


>   Date: Sat, 07 Jan 2006 23:14:58 +0100
>   From: Till Kamppeter <till.kamppeter at gmx.net>
>
>   I have talked with Mike Sweet on the phone, for him all days in
>   March are good. Also East coast is OK with him. He would like very
>   much to come.
>
>   And Mike and me have aggreed on one proposal for changing the
>   printing architecture under Linux and Unix:
>
>   The standard format for print job transfer should be moved from
>   PostScript to PDF, to have a more powerful and reliable format and
>   a format which is better supported by free software, as the free
>   GhostScript versions (GNU/GPL/ESP) are already old (one year older
>   than AFPL) and not maintained as well as AFPL, but XPDF is
>   well-maintained and XPDF people are more cooperative with the CUPS
>   developers. One should add IJS, CUPS,and OpenPrinting vector
>   interfaces to XPDF to talk with drivers and modularize the
>   remaining GhostScript compile-in drivers into one legacy-driver IJS
>   plug-in (GhostScript-aware developers needed for that). A side
>   effect of separating all drivers from GhostScript is also that by
>   adding IJS, CUPS, and OpenPrinting vector interfaces to Cairo one
>   could print on embedded systems without memory-consuming high-level
>   transfer formats (PDF, PostScript).
>
>   What do you think about this step?
>
>It would probably be desirable to support higher level output for
>printers that support it, although when I ran even a low end, high
>speed HP laser printer, it had no trouble keeping up with raster
>output.
>
>Does PDF (and the xpdf engine) support high bit depths (such as 16
>bits)?  I'd like to see us move in that direction.  There's nothing
>wrong with 8 bits for a lot of things, but if the engine supports 16
>bits it could e. g. support color management without losing too much
>precision.  That would save each driver from having to implement color
>management itself.
>
>Would this still use PPD files, or would there be other ways of
>exposing printer capabilities to applications?
>
>As far as Ghostscript goes, I personally wouldn't much mind not having
>to support it in Gutenprint.  Even though the IJS API is simpler than
>the raw Ghostscript API, it's still clumsy compared to the very simple
>CUPS API.
>
>Till, do you have a list of what devices are supported in legacy
>Ghostscript drivers that aren't supported in some other driver (HPLIP,
>Gutenprint, and Omni between them support a lot of printers)?  I
>suspect that Epson impact printers are a significant fraction of the
>list, and I suspect that it wouldn't be too hard to support them in
>Gutenprint if someone wants to volunteer to do that.

What would the benefits of such a transition be? I understand that
compiled-in drivers isn't exactly the way to go, but are there benefits
that would justify investing in such migration?

So far the case for PDF seems to be rooted in a vague notion that xpdf
is better maintained than ghostscript. I'm a bit skeptical about that
because my exposure to xpdf in a KDE context has been limited to
security advisories about xpdf buffer overflows [1] and the
unwillingness/desinterest of the xpdf maintainer to provide xpdf as a
shared library implementation (hence poppler)

Cheers,
Waldo

[1]
http://www.kde.org/info/security/advisory-20051207-2.txt
http://www.kde.org/info/security/advisory-20050119-1.txt
http://www.kde.org/info/security/advisory-20050120-1.txt
http://www.kde.org/info/security/advisory-20041223-1.txt





More information about the Printing-summit mailing list