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

Michael Sweet 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
>> 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?

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 mailing list