[Printing-architecture] [Fwd: [Desktop_printing] Printing Summit is
Norm.Jacobs at Sun.COM
Wed Jan 11 15:22:01 PST 2006
For those of you who didn't attend the desktop printing summit planning
am including the contents of a couple of email messages that pretty much
the areas of discussion (date/location, agenda). The short version is
that the summit
looks like it will happen on April 10-12 in Atlanta, GA, USA. This is
the week after
the PWG/P2600 meeting and LWE.
I would like to get people's thoughts on making this an FSG OpenPrinting
face meeting, having a joint PWG/FSG OpenPrinting plenary at the end of the
PWG/P2600 meeting and/or having one at a PWG meeting later in the year
I know that there was more to add to this discussion, but I'm all
meeting'd out today.
-------- Original Message --------
Date: Wed, 11 Jan 2006 11:49:41 -0800
From: John Cherry <cherry at osdl.org>
Subject: [Desktop_printing] Printing Summit is set
Thanks to those that attended the call this morning and helped us to
settle on a time and location for the OSDL Printing Summit.
Date: April 10-12
Location: Atlanta, GA (Lanier facility)
April 10-12 is the week after LinuxWorld Expo, so hopefully this will
allow some that travel across the pond to make a single trans-atlantic
More logistical information will be coming out as they are nailed down,
but you should be able to mark your calendars and start making travel
arrangements where it makes sense.
Invitations with the latest logistical information will be out prior to
January 20. The following is a list of names that have been contacted
and/or on the desktop_printing list. Please let me know if there are
others that should be informed or invited to the summit.
Yves van Belle
wendyp AT sun.com
Albert Astals Cid
Till Kamppeter wrote:
> Here is the originally suggested agenda with some points mentioned on
> the mailing list added:
> John Cherry wrote:
>> The starting point for the Open Printing Summit agenda is:
>> 1. Making printing user friendly - it should just work
>> * Usability
>> * Consistent methods for printing, job handling, and printer
> * "Printing as a desktop service" - non-native apps and apps
> from ISV should use standard printing dialog from KDE/GNOME
> (Kurt Pfeifle)
>> 2. Hardware support
>> * Drivers and PPDs, preferably from printer manufacturers and free
>> * Plug and Print (not plug and play; plug the printer and play for
>> hours with different drivers)
>> * Auto-download and auto-install of drivers
> * Certification of printers working with distros (Waldo Bastian)
Also reference previous quicky form I posted...
>> 3. OpenPrinting.org implementation
>> 4. CUPS 1.2 integration with desktops, apps, drivers, distros, etc.
> 5. Transition of job transfer format from PS to PDF (Till Kamppeter,
> Mike Sweet)
> + More portable
> + High color depth, color management
PostScript also supports high color depth and color management,
just not as easy...
> + Easy post-processing (N-up, booklet, scaling, page reordering,
> + Transparency support
PostScript also supports transparency, it just isn't as easy...
> + Smaller files
> + Better interoperability with Mac OS X
> ? Free software support: GhostScript vs. XPDF (how well
> maintained? Is newest software version free?)
> - Free software has to implement all new features which Adobe is
> adding to PDF, PostScript is "finished".
PDF is also used for international standards and printing/prepress;
we could just standardize on a particular version of PDF (e.g. PDF/is)
rather than chasing the latest version of PDF.
- PDF is already supported by CUPS
- Current path for PS printers is: pdftops -> pstops -> printer
- Future path for PDF-capable printers is: pdftopdf -> printer
- Current path for raster printers is: pdftops -> pstops ->
pstoraster -> printerdriver -> printer
- Future path for raster printers is: pdftoraster -> printerdriver
- Add discussion of job ticket stuff, and embedding them in PDF.
I can do a presentation on this...
> 6. Modularizing built-in drivers of GhostScript (Till Kamppeter)
> + Easy change of printing workflow without loosing hardware
> support (exchange renderer version, transfer format, simplified
> workflow for embedded ...)
It is worth noting that this can be done over time - the existing
driver will still work in the short term without changes...
> 7. Did I forget anything important which we discussed on the list?
> - Please post ASAP
> - Please mention on phone meeting
- Writing printer drivers - CUPS DDK, IJS, etc?
More information about the Printing-architecture