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

[Till Kamppeter]

Robert L Krawitz wrote:
>    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.
> 

Mike, what about 16 bit in XPDF? Can you also suggest XPDF people to be
invited to the Printing Summit?

> Would this still use PPD files, or would there be other ways of
> exposing printer capabilities to applications?
> 

I think, PPD files could be also used in a PDF-centric printing
environment (that is currently done with the CUPS in Mac OS X). Mike?
Other experts?

> 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.
> 

I could make such a list. First step would be to search the Foomatic
database for drivers of the execution style "GhostScript" and then look
at those which are "recommended" for at least one printer. Then look
whether alternative modular (IJS, CUPS, filter, ...) drivers are
available and whether they give the same support quality as the
compile-in one. If not, the compile-in driver needs to be modularized.

Mike told that the OpenPrinting vector driver team is working on a PCL
6/XL driver, this would eliminate the need of "pxlmono" and "pxlcolor".
Does someone know if the Epson/Avasys people are already porting their
drivers to the OpenPrinting vector interface?

   Till