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

Robert L Krawitz rlk at alum.mit.edu
Sat Jan 7 14:34:40 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.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



More information about the Printing-summit mailing list