OpenPrinting

1
OpenPrinting

• Plenary Review
• 6/17/03
• Charles Hemstreet for
• Shawn Pratt, Chair

2
Problem Statement

• Current printing solutions
• Lack ease-of-use for end users
• Have limited PDL support
• Are not in-focus with new print technologies
  being introduced
• Do not address multi-function solutions on same
  level as single-function solutions
• Leading to
• Limiting Linux desktop adoption
• Excessive print vendor development for same
  functionality, just different product
• Inconsistent distribution of print models

3
Vision / Strategies

• Printing solutions within Linux are an integrated
  part of the Linux operating system. These
  solutions are on par with other operating
  systems, thus meeting the needs of similar
  customer bases. They follow (and extend) print
  standards, created within the industry, such that
  the customer experience is not degrade, print
  vendors do not have to provide extra efforts,
  solutions are open and extendable and
  distributions can have consistency but provide
  extensibility.
• Create a standardized, scalable printing
  architecture and high-level requirements for
  printing systems.
• Address the needs of desktop to enterprise-ready
  printing, including management, reliability,
  security, scalability, printer feature access and
  network accessibility.
• Structure architecture to allow flexibility such
  that the parts can be used individually or as a
  group, depending on the end users needs and/or a
  Linux distributors strategic direction.

Vision Strategies
4
Org Structure
Charles Hemstreet
Yasumasa Toratani Osamu Mihara
5
Architecture / Focus Areas

• Capabilities API.
• Driver installation / un-installation.
• Font installation / un-installation.
• Graphics API.
• Meta-data / PS generation library.
• Display / Printer color management.
• PDL printer driver API.

6
Architecture

• Notification API
• Bi-di plug-in
• Bi-di communication daemon
• Printer lookup

7
Priorities - Focus

• Better Application / Print Model communication
• Establish a Capabilities API
• Establish a Job Ticket structure / API for data
  transfer
• Better Host SW / Device communication
• Extend bi-directional communication process
  (printer dynamic capabilities)
• Extend device notification API
• Create a bi-directional plug-in architecture
  (status)
• Extend printer lookup capabilities
• Better PDL establishment
• Enhance print driver support (dynamic loading,
  generic support)
• Extend multiple PDL driver support
• Improve print driver performance

8
Priorities - Focus

• Consistency
• Scalability
• Flexibility

9
Status OpenPrinting WG

• Task groups and both regional coordination groups
  functioning. Separate leadership/better focus
  between steering committee and coordination
  groups.
• Partnerships
• Working with Printing Working Group (PWG) on
  print standards and face-to-face focused
  meetings.
• Working with standard groups on open source and
  Linux needs.
• Working for more membership into FSG through
  OpenPrinting memberships.
• Public Releases
• Public beta release on Open Standard Print API
  (PAPI 0.9).
• Provides a common print API that applications can
  use without having to know the distribution or
  underlying print system on which they are
  running.
• Reference implementation runs on top of CUPS.
• At end of public beta and quality pass-off, PAPI
  proposed as a 1.0 specification.

10
Status Americas / Europe Committee

• Focused on Application / Print Model relationship
• Preliminary API discussions / definitions
• Job Ticketing
• Capabilities.
• Focus (Coordinate input from Japan group)
• Defining Job Ticket definition and API.
• Defining application interfaces to communicate
  print capabilities.
• Implementing reference models for various API
  definitions.

11
Status Japan / Asia Committee

• Focused on Host SW / Device communication
• Preliminary API discussions / definitions
• API between bi-di plug-in and bi-di daemon
• Generic PDL print driver API
• Focus (Coordinate input from Americas group)
• Defining the functionality of the bi-di
  communication daemon and the interface between
  the daemon and the upper system.
• Making Notification API which might be included
  in the Spooler API in the future.

12
To dos

• Bring contributors into FSG membership.
• Participation and review.
• Strong participation from printer vendors and
  print applications.
• Weaker participation for open source community.
• Better communication linkages between
  coordination committees.
• Better process control / test support.
• Viable long-term roadmap.
• Better website.

13
Reference links

• URL www.freestandards.org/openprinting
• soon to be
• www.openprinting.com
• Sourceforge Openprinting
• FTP ftp.pwg.org/pub/pwg/fsg