[Desktop_printing] Agenda proposal: Replace PostScript by PDF
as job transfer format
mike at easysw.com
Sat Jan 7 16:55:47 PST 2006
Till Kamppeter wrote:
> 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
>> 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?
Derek Noonburg would be the person to contact - I've sent him an email
asking if he is interested and able to attend...
>> 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?
Yes, this is the case. Also, CUPS 1.2 exposes a new
cupsRasterInterpretPPD() API which interprets the PostScript commands
in a PPD file and initializes the page header structure. This should
make it a lot easier to write CUPS RIPs...
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
More information about the Printing-summit