• 1 OPS Summary - MONDAY - 24 September 2007
  • 1.1 What is New in CUPS? (Mike Sweet, Apple)
  • 1.2 Open Printing US/Europe (Glen Petrie, Epson)
  • 1.3 Printing API (PAPI) (Norm Jacobs, Sun)
  • 1.4 Cairo Graphics Library (GNOME) for PS/PDF (Behdad Esfabohd, Cairo)
  • 1.5 Generating perfectly text-extractable PDF (Behdad Esfahbod, Cairo)
  • 1.6 OP Japan CUPS PDF Filters (Yasumasa Toratani, Canon)
  • 1.7 Foomatic 4.0: PDF Workflow and XML with DTDs (Till Kamppeter, LF)
• 2 OPS Summary - TUESDAY - 25 September 2007
  • 2.1 KDE Printing (Cristian Tibirna, Maintainer KDE Print)
  • 2.2 GNOME Printing: Behdad Esfahbod (Cairo/Pango)
  • 2.3 Common Printing Dialog (Peter Sikking, Open Usability)
  • 2.4 LSB 3.2 and 4.0: Printing Infrastructure (Jeff Licquia, LF)
  • 2.5 system-config-printer (Till Kamppeter, LF)
  • 2.6 YaST (Johannes Meixner, SUSE/Novell)
  • 2.7 Printer Drake (Marcelo Leitner, Mandriva)
  • 2.8 OP Japan Vector Driver (Yasumasa Toratani, Canon)
  • 2.9 Distribution-Independent Driver Packages (Till Kamppeter, LF)
• 3 OPS Summary - WEDNESDAY - 26 September 2007
  • 3.1 HP Linux Drivers (Shiyun Yie and Raghothama Cauligi, HP)
  • 3.2 HP Linux Binary Plug-Ins (David Welch, HP)
  • 3.3 Canon Printer Driver for Linux (Yasumasa Toratani, Canon)
  • 3.4 SUSE Print Management (Johannes Meixner, SUSE/Novell)
  • 3.5 Third-Party Printing Driver Development (Hin-Tak Leung)
  • 3.6 Printer Driver Validation (Yasumasa Toratani, Canon)
  • 3.7 OPS Wrap-up
  • 3.8 OPS Messages to Manufacturers
• 4 OPS Summary - Open Printing Project Status for 2007
  • 4.1 OP Reference Model - stable
  • 4.2 OP DSH (Directory Structure and Hierarchy) - completed
  • 4.3 OP PAPI (Print API) - completed
  • 4.4 OP JTAPI (Job Ticket API) - completed
  • 4.5 OP PDAPI (Print Driver API, aka OPVP) - nearly complete
  • 4.6 OP PCMAPI (Print Channel Manager API) - work-in-progress
  • 4.7 OP SMAPI (Status Monitoring API) - work-in-progress
  • 4.8 OP PCAPI (Printer Capabilities API) - proposed
  • 4.9 OP DDAPI (Device Discovery API) - proposed
  • 4.10 OP TFMAPI (Transform API) - proposed

The full agenda of the Open Printing Summit in Montreal (with links to slides from most of the presentations) is at:

/collaborate/workgroups/openprinting/summitmontreal

This summary was originally presented verbally at the PWG/OPS Joint Plenary in Montreal on Thursday morning 27 September 2007.
Part I: Printing System Core and Infrastructure

• CUPS Versions in Mac OS X

  - Jaguar/10.2 - CUPS/1.1.15 - August 2002
  - Panther/10.3 - CUPS/1.1.19 - October 2003
  - Tiger/10.4 - CUPS/1.1.23 - April 2005
  - Leopard/10.5 - CUPS/1.3.2 - October 2007 (tentative)

• CUPS 1.3 Features Overview (Mike Sweet)

  - Kerberos authentication
  - More authentication mechanisms for local access
  - SNMP printer discovery (now disabled by default)
  - DNS-SD/Bonjour/Zeroconf support
  - New cupsctl command-line utility (updates cupsd.conf settings)
  - Web interface improvements (help, discovery, sharing, etc.)
  - Localization (new locales, backends localized, multi-lingual PPDs)
  - New side-channel API (for port monitors and backends)
  - New cupsPreFilter attribute in PPD file
  - New cupsAdminGetServerSettings() and cupsAdminSetServerSettings()
  - New cupsRemoveDest() and cupsSetDefaultDest()
  - http_t structure is now completely private

• CUPS 1.4 Proposed Features (Mike Sweet)

  - more open-ended - probably one year out as a release
  - More performance tuning
  - More printer drivers
  - Streaming print API (to avoid extra intermediate files)
  - Updated web interface (better localization, etc.)
  - New PDF filter(s) based on Poppler
  - New libusb version of USB backend
  - New banner file format for filter-generated banner pages

• Introduction and Background on OPWG
• OPWG has identified four principal Printing Environments:

  - Production Printing
  - Office Printing
  - Home Printing
  - Embedded/Handheld/Mobile/STB Printing

• What factors distinguish Printing Environments?

  - Print Volume (number of sheets)
  - Print Job Type
    - Simple
    - Complex but Static
    - Variable Data
    - Incorporate Finishing
  - Print Location
    - Attached/Local Printer
    - Network Printer
    - Print Department
    - Print Shop
  - Computing System Resources
    - Run-Time Memory
    - Processor Speed

• Coherence - Environment Level

  - Means the Users in all environments can (/will/shall/should??) have
    the same experience
  - Differences are mostly artificial
    - Production can request the printing of a single sheet
      - Print a missing or damaged sheet
    - Handheld can request the printing of a 100 copies
      - Kinko's prints 100 sets of presentation downloaded from customer
        PDA
        - Who generated the production job-ticket !!!
        - Could (should?) the PDA do that? - Interesting
  - Use a Scaleable Approach

• Coherence - Software Level

  - User Level
    - Print Dialog - Common
    - Print Attributes - Common representation and terminology
  - Developer Level
    - Print Attributes - Common representation and terminology
    - Application Programming Interface (API) - Design, Format, Calls,
      Error, etc.
    - Code Module - Coding Style, Coding Structure, Variable Typing, etc.
    - Extension: Planning for Change - Vendor, Code, Attributes, Modules

• Coherence Needs - Single Dictionary

  - Independent of
    - Environment, Print Vendor, Solution Vendor, Operating System &
      Application.
  - Defining
    - Terminology, Acronyms, Abbreviations Representation, Relationships,
      Dependencies &, Mathematics (where applicable)
  - Defining
    - Code Level Variable, Object(Struct) Members, Range & Scope

• Coherence Needs - Common / Extensible Print Dialog

  - Being worked on ... (Open Usability)
  - Request 1: Provides for both GUI and GUI-less API's
  - Request 2: Scaleable down to Resource Limited Embedded/Handheld
    Solutions

• Coherence Needs - Software - Application Programming Interface (API)

  - Types: Static Link Library, Dynamic Link Library, Remote Processor
    Call, Other ??
  - Base Library API's: opInitLib_foo, opSuspendLib_foo, opReleaseLib_foo
  - Base Procedure API's: opInit_foo, opProc_foo, opRelease_foo

• Coherence Needs - Software - Basic Code Modules and Basic Headers

  - Basic Types (OP_INT8, OP_INT32, OP_CHAR, etc)
  - Basic Objects (structs) (OP_RECT, OP_POINT, etc)
  - Basic Errors (OP_ERROR_NONE, OP_ERROR_MEMORY_ALLOCATION,
    OP_ERROR_INVALID_ARG, etc)

• Coherence Needs - Software - General Code Module

  - Coding Style - Pick one and stay with it!
  - Coding Structure - Pick one and stay with it!

• Coherence Needs - Software - Extension: Planning for Change

  - Vendor, Code, Attributes, Modules

• Scalability - Environment Level

  - Users in all environments can (/will/shall/should??) have the same
    experience
  - Limitation defined by Available Printer, System and/or Intended
    Features and Capabilities

• Scalability - Software Level - User Level

  - Print Dialog - Common feature and capability parametrics

• Scalability - Software Level - Developer Level

  - Coding
    - API's ... or
    - Printer/Printing capabilities ... or
    - Attribute properties ...
      - as strings-constants for XML based or resource rich environments
      - as integter-constants for resource limited environments
  - Features and Capabilities
    - The scope, the fidelity and the inclusion based on resources and not
      necessarily environment !
  - Extension: Planning for Change
    - The scope, the fidelity and the inclusion based on resources and not
      necessarily environment !

• Models (Architecture and Environments)

  - See slides

• Software - Thin Thread - Overview

  - What is it?
    - Is it a Prototype? Less than but close
    - Is it a Solution? No, not complete.
    - Goal is flush out the architecture, interface and internals
    - We will define it as end-to-end executable that ...
      - follows a single, usually the typically, path through the
        architecture/design
      - provides only limited error checking (memory allocate but not
        parameters)
      - assume resources are limited by the software architecture/design
        not by actual system
      - some functions/processes/procedures provide a single option
  - Start with the ...
    - simplest (feature/capability wise) Environment == Embedded/Handheld
    - API defining features / capabilities == Job Ticketing
    - API managing print == Print Manager
    - API controlling the printer == Printer Driver
    - API supporting printer == Print Channel Manager
    - everything else...

• Software - Thin Thread - Auxiliary Work Products

  - Refining the OpenPrinting Reference Model
  - Refining the OpenPrinting Detailed Architecture
  - Creating an OpenPrinting Dictionary
  - Creating the OpenPrinting Basic Software Header and Source Modules
  - Migrating existing work products to provide coherent, consistent,
    common
    - Software Elements
    - API
    - Solutions

• Objectives

  - Provide applications print service or protocol independence
  - Allow a rich, extensible set of information to flow between
    application and print service
  - Support a rich enough set of operations to be useful to most
    applications with printing needs

• Not a Print Manager

  - Print service independent
  - Provides available features

• Used by

  - GTK (GNOME)
  - Print commands (lp/lpr...)
  - Mozilla - Bug 317450 - patch submitted

• Works with

  - CUPS (IPP)
  - LP
  - LPD (RFC-1179)

• Capabilities Support

  - in progress
  - integrated solution

• PAPI Source Code - SourceForge

  - http://sourceforge.net/projects/openprinting/
  - openprinting-papi-dev@lists.sourceforge.net

• PAPI Source Code - OpenSolaris

  - http://opensolaris.org/os/community/printing/
  - mailto:printing-spool@linux-foundation.org

• OpenPrinting PAPI mailing list

  - /mailman/listinfo/printing-spool/
  - printing-spool@linux-foundation.org

• PAPI/1.0 Spec

  - ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi-v1.0-2005-07-15.pdf

Topic - PDF instead of PostScript as standard print job format

• See slides (very large file) for most details
• Generates PDF/1.4 or earlier versions

  - Ira - should consider ISO PDF/A and IEEE PDF/is support as profiles

• See slides (very large file) for most details
• Cluster analysis is key
• Clusters are uni-directional group of codepoints and glyphs
• Should be implemented by end-of-2007

• Format Converter

  - PostScript - imagetops and texttops
  - PDF - imagetopdf and (texttopdf)

• Layout Processor

  - PostScript - pstops
  - PDF - pdftopdf

• Renderer

  - PostScript - Ghostscript
  - PDF - pdftoopvp (Poppler-based)

• PDF Filters: Status and Plan

  - All PDF CUPS filters at http://opfc.sourceforge.jp
  - Reconsider Job Control Info - Modify PDF filters if needed
  - texttopdf (utf8topdf?) - Needs comments and VOLUNTEERS

• No major changes in Foomatic in several years
• Changes in Printing Infrastructure

  - PostScript as print job format will be replaced by PDF
  - CUPS got new functionality, especially custom option settings
  - Automatic printer driver download from the Open Printing web site

• Foomatic 4.0 Ideas

  - DTD/XSD for the XML database, can change database format
  - Auto-generate printer XML entries from PPD files
  - Easy way to turn user-contributed printer entries into official
    Foomatic entries

Part II: Printing on the Desktop: GUI and Applications

• Status quo

  - Not much changed on the KDE printing front since Atlanta Summit

• Last 17 months (since Atlanta Summit)

  Google Summer of Code:
  - 1st topic: openprinting.org on-line driver support - succeeded
  - 2nd topic: KDE GUI renovation - not successful
  Work on KDE4 started:
  - Printing for KDE4 severely lagging
  New interest from KDE developers community
  - in last 3 weeks

• Protocols and technologies

  - CUPS/1.1 and IPP
  - Other protocols very probably will be dropped
  - CUPS > 1.1 support still not implemented
  - Renovation of CUPS backend required - major rewrite
  - PDF printing flux not supported fully

• Tools

  Minimize centralized/shared library
  Move tools to optional workspace package
  Essential applications:
  - kprinter - ESSENTIAL: "lpr with a GUI"
  - Printer installation wizard
  - Job Viewer (actually very nice job manager - Kurt showed to Ira)
  - Dearly needed: better previewer
  - Dearly needed: PDF editor

• KDE 4 Planning - latest analysis by ad-hoc community group

  KDE4 4.0:
  - KDE3 code porting partially failed { lack of manpower
  - Use Qt infrastructure directly
  - Regressions and limitations over KDE3
  - Very short time for implementation
  KDE4 4.1:
  - Back to full KDE platform:
    - pre-filter, customizable dialog, printer wizard, etc.
  - Using PDF as job format
  - New GUI (usability driven)
  - Look up wishes (and bugs)

• Planning … concretely

  - GUI redesign - wait for consensus?
  - KDE3 GUI was serving well ("it ain't broken...")
  - Pass as much of the job as possible to Qt (natural)
  - CUPS 1.3 - Use greedily (PPD parsing?)
  - CUPS 1.4 - PDF printing already required by developers
  - Take a look at PAPI -> back to supporting many printing backends

• Conclusions

  KDE Printing is no more in acceptable shape
  High steam work in progress for KDE4:
  - KDE 4.0 -> placeholder
  - KDE 4.1 -> full (best) solution (again)
  Acute lack of manpower!

• See slides (very large file) for most details
• Migration to native OS print dialogs
• No GNOME print team

• See slides (very large file) for most details
• “One size does not fit all”
• Clusters

  general inkjet, photo, personal laser workgroup laser,
  high volume wide format, impact printers

• Siena Workshop (Open Usability sponsored)

  3 levels of Printing:
  - Level 1 - "printing does not exist"
    80% or 90% - "will be OK"
    "just print" - an optional bypass of the dialog
    Print - just print
  - Level 2 - quick presets
  - level 3 - tweak printing parameters

• Tags - many-to-many associations
• Work in progress

  - Screen shots of version 0.3 common printing dialog

• LinuxTag - work with the UI platforms

  - Gnome + GTK
  - KDE + Trolltech

• Background on LSB goals and methodologies - see slides
• Printing in LSB 3.1

  System V and BSD command-line tools
  - Two tools: lp and lpr
  - Can print to the default printer or a named printer
  - All other details (spooler tech, network support, etc.) are
    implementation-dependent
  Generic System V/BSD interfaces are not sufficient
  - No way to discover what printers are available
  - No standards for discovering or supporting advanced printer
    capabilities
  - User interface is necessarily limited
  - Lack of backend standardization makes delivering a single driver
    framework nearly impossible

• Printing in LSB 3.2

  System V and BSD command-line tools
  - Pretty much unchanged
  CUPS/1.1 is now the de-facto standard for printing in Linux
  - No other spooler has captured the market
  - Newer versions of CUPS have not yet reached everywhere
  ABIs in CUPS
  - CUPS Convenience API
  - CUPS PPD API
  - CUPS Raster API
  GhostScript will be required by LSB/3.2
  - Must support a standard set of options
  - Must support a standard set of drivers
    - CUPS Raster
    - IJS
    - pxlmono, pxlcolor
    - OpenPrinting Vector
  foomatic-rip will be required by LSB/3.2
  Standard search path for PPDs will be required by LSB/3.2

• Printing in LSB/4.0

  Ideas for LSB 4
  - Uplift of CUPS ABIs
  - SANE
  - PAPI
  - Others?

Topic - Printer Setup Tools

• See slides for most details
• Not presented at OPS due to technical problems

• See slides for most details
• Inherent ambiguity of “printer” versus “queue”

  - hard for end users

• See slides for most details
• Impressions

  - Ira - very nice tool

Part III: Printer Drivers and Printer Validation

• Vector Driver API (PDAPI, aka OPVP)
• Version 0.2 - current spec

  - API Spec - released in 2003
  - HP PCL5, Canon, Epson, and NEC Drivers have been released so far
  - Integrated in many distros as "opvp" driver with ESP GS
  - CUPS PDF filter "pdftoopvp" in 2006

• Version 1.0 - upcoming spec

  - Current status: RC5 (almost done!)
  - ftp://ftp.pwg.org/pub/pwg/fsg/vector/pdapi-spec-1.0rc5.pdf
  - Implementation - opvp based on 1.0 is in beta status
  - Several vendors are already implemented drivers and testing
    ... so far so good!

• Compatibility

  - New "opvp" code for Ghostscript supports both 0.2 and 1.0 driver
  - Automatically detects the API version exported by each printer driver
  - Automatically changes the API calling sequence according to the API
    version
  - Then both the opvp 0.2 compliant printer driver and the opvp 1.0
    compliant printer driver work under the new opvp 1.0 code w/o any
    modifications!
  - Sample driver "opvpnull" is already updated for 1.0
  - Driver feasibility test has almost finished (6 months)
    - Soon available at http://opfc.sourceforge.jp

• See slides for most details
• Problems

  - Distributions do not ship all available printer drivers
  - Free drivers from upstream need to be compiled by users
    - Driver installation too complicated for inexperienced users
  - Manufacturers make packages only for a few major distributions
  - Driver packages often difficult to find on manufacturer's web sites
  - Testing/packaging effort for manufacturers and driver developers too
    high to ship binary driver packages for all distributions

• Existing Infrastructure

  - OpenPrinting database (former openprinting.org) - central database
    for printer/driver info
  - LSB provides tools and infrastructure to create
    distribution-independent binary packages

• Solution - Distribution-independent printer driver packages

  - Based on LSB 3.1 for binary format (later LSB 3.2)
  - Using CUPS, Ghostscript (with IJS, CUPS Raster and OpenPrinting Vector
    interfaces), Perl, and foomatic-rip which is in any distribution (and
    will be required by LSB 3.2)
  - Installing everything in /opt/<supplier>/ to avoid conflicts with
    distribution
  - Linking PPDs to /usr/share/ppd/
  - Discovering system directory/file locations at install time
    - maintainer scripts:  pre/post (un)install) and symlinking system
      files appropriately
  - Make packages part of OpenPrinting database, so that they can be
    easily found
  - Infrastructure for automatic package lookup, download, and
    installation through the internet by printer setup tools

Topic - Driver Development Reports since last OPS

• HP Is Committed to Open Source Printing Software

  - Currently Provide Completely Open Source Software
    - Support over 1,200 Printer models with Connectivity Software
      - Driver
      - Toolbox
      - Scan
      - Fax
      - Photocard
      - Installer

• What's New in HP Linux Software?

  - HPLIP Localized and adding Languages
    - Current languages:
      EFIGS
      Braziliaan Portuguese
      Simplified Chinese
      Russian
  - HP Adding Binary Plug-Ins to HPLIP
    - HPLIP will continue to provide Open Source Code as we do now
    - Some HP Printers require proprietary software technologies to allow
      full access to printer features and performance
    - These technologies cannot be open sourced
    - Binary Plugs work in Conjunction with HP Open Source HPLIP
    - Delivered via binary library
    - Proprietary license between HP and customer

• HPLIP 2.7.9 Plug-In Design

  - Supported by HP Device Manager for Linux
    - PPDs
    - Firmware
    - Plug-Ins
    - Rules
    - License

• History

  - When Started?
    - First Linux Printer Driver developed by Canon was released in
      March 2001 (Ver.1.00)
  - Inkjet Printers as well as Laser Printers
    - Laser Printer Driver Ver.1.00 released in August 2003
    - Cooperate with open source activities boosted by Japanese Agency
  - For Overseas Market (outside Japan)
    - Today, releasing from Europe, Australia sales companies for each
      region market
    - Study for the US market

• Latest Printer Drivers

  - Color/Monochrome Laser Printers and Multifunctionals
    - Ver.1.50 (Released on May 22nd, 2007)
    - Over 140 models Color and Monochrome - imageRUNNER, imagePRESS,
      LaserBase, and LaserShot series supported
    - PostScript, UFR II, CAPT, LIPS IV(Japanese) and LIPS LX (Japanese)
      models
    - "x86" as well as "x86_64" supported
    - Both "rpm" and "deb" packages released
  - Photo Inkjet Printers and Multifunctionals
    - Ver.2.70 (Released on Apr. 26th, 2007)
    - Scanner driver Ver.1.00 for MFPs also released
  - Download Sites:
    http://cweb.canon.jp/drv-upd/lasershot/drv_linux.html
    http://www.canon.com.au/drivers/index.html
    http://software.canon-europe.com/

• No slides posted - see Till's photo of whiteboard
• For print management, need *DEVICE* info (not just queue info)
• For supplies, lifetime, etc, need *DEVICE* info

• Recent Trends

  - Larger Multi-function devices - scanner, fax modems
  - Smart handhelds
  - PictBridge

• How People Do It?

  - How we did it:
    - print to FILE:
    - USB snoop
  - How others do it:
    - Guest OS in Boch/VMware virtualization
    - Hardware signal analyzer

• Disassembling

  - IDA Pro
  - .NET : Reflector
  - Java : ??

• Manufacturer: Linux driver, why not?

  - Fact: Manufacturers are out for making money
    - hardware
    - consumables e.g. ink/toner cartridges
    - support contracts

• Manufacturer: Linux driver, why not?

  - Fact: Manufacturers are out for making money
  - Question: Does it make financial sense?
    - IP, Patents, business advantage, 3rd party sub-contract/licensing
    - Justifying up-front business cost, and subsequent revenue projection
    - Hardware/software co-developed at close proximity - i.e., no specs
    - Cannot admit to hardware design faults and subsequent software work
      arounds, etc.

• Manufacturer: Linux driver, why?

  - Sale opportunities: print servers
  - New emerging market segments:
    - Commodities- tied-in with Bluetooth, mobile+phone, embedded devices,
      PDA, WebPAD
    - PictBridge
  - Product/Market Differentiator - same product class, more OSes
    supported

• Manufacturer: Linux driver, how?

  - Hardware/Consumables
  - Funding
  - Specs
  - Engineering resources/contacts
  - Source code

• Interesting technologies

  - Wine - native bridge?
  - XEN
  - Mingw

• Just to use printer?

  - Cups
  - Samba
  - Redmon
  - Gsprint (Win32 ghostscript mswinpr2 driver)

Topic - Printer Driver Validation

• Discussion Members

  - Mihara<osamu.mihara@fujixerox.co.jp>
  - Miyata<akiyoshi.miyata@avasys.jp>
  - Nagasaka<nagasaka.fumio@exc.epson.co.jp>
  - Ogasawara<naruoga@nts.ricoh.co.jp>
  - Sekiguchi<atsushi.sekiguchi@konicaminolta.jp>
  - Shida<shida.keisho@canon.co.jp>
    - drafting/arrangement
  - Toratani<toratani.yasumasa@canon.co.jp>

• Discussion

  - Collected each member's comment about the Linux printer driver
    validation from the view point of:
    - What kind of things should be validated
    - Who validate
    - How to validate a printer driver
    - Validation cost

• Conclusion of the Discussion

  - Too early to start the Linux printer driver validation
    - We need more discussion first...

• Validation Item

  - First, discussion for defining the validation items should be started
    - Printing result?
    - Printing performance?
    - Printing options?
    - Printing from particular applications?
    - Language?
    ---> Test cases for printing validation

• Validation Tool and Data

  - Next, the validation tool, data and environment should be discussed,
    for instance:
    - OS and Application
    - Test Print Data (text? photo? graph?)
    - Languages
    - and more...

• Validation by Driver Developer

  - Depending on the printing use cases...
  - In many cases, whether the driver works correctly or not can be
    validated only by the driver developer (printer vendor)
  ---> Self Validation

• Validation Cost

  - On the other hand, we should also consider that the Linux desktop
    market is still smaller than that of the major Desktop OSs
  ---> Validation is good, but the balance between the test cases and
       testing/validating cost should be considered

• Let's start the discussion (in Montreal)

  - Multiple test case clusters
  - Multiple validation tools for test case clusters
  - And further discussion is being considered at The Linux Symposium
    Tokyo in November, 2007

Part IV: The OpenPrinting Summit 2007 is Over - Final Thoughts

• Best Quotes:

  - "There is no such thing as printing" - Peter Sikking
  - "There is no printer in the printing system" - Johannes Meixner

• Above are the various OPS topics reviewed during our wrap-up session on

Wednesday afternoon 26 September 2007.

• Below are the various OPS messages to manufacturers discussed during our

wrap-up session on Wednesday afternoon 26 September 2007.

• From Open Source Developers

  - Please publish specifications (not for the proprietary features)

• From Linux Distributions

  - Please make Linux drivers easy to package
  - Distribution-independent drivers
  - Distribution-friendly driver installation
  - CUPS-friendly drivers (for Linux environments)

• From All (OPWG, Developers, Distributions)

  - Please implement Port Monitor MIB (PWG 5107.1) - IEEE 1284 Device ID
  - Please implement coherent printer metadata (USB, parallel, network)
  - Please use standard tokens for languages (PDF, etc.) - action to OP

This section updates last year's presentation at the PWG/OPS Joint Plenary in Lexington in October 2006.

• OP Reference Model Diagram is archived at:

    ftp://ftp.pwg.org/pub/pwg/fsg/architecture/Reference-Model

in the file:

  LF-OpenPrinting-Reference-Model-Diagram-20060410.pdf

• OP DSH standardizes locations of PPD files and print drivers
• OP DSH has been adopted in FHS (Filesystem Hierarchy Standard), LSB/3.2,

and CUPS 1.3

• OP PAPI/1.0 currently in Open Solaris and four Linux distros
• OP PAPI/1.0 reference implementation posted on Source Forge
• OP PAPI/1.0 may be included in LSB/4.0
• OP PAPI/1.0 formally approved by OP in July 2005:

    ftp://ftp.pwg.org/pub/pwg/fsg/spool

in the file:

  papi-v1.0-2005-07-15.pdf

• OP JTAPI/1.0 UML diagrams and C headers are stable and aligned with spec
• OP JTAPI/1.0 reference implementation - work-in-progress in Thin-Thread
• OP JTAPI/1.0 may be contributed into CUPS for LSB/4.0 inclusion
• OP JTAPI/1.0 formally approved by OP in July 2005:

    ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Spec

in the file:

  fsg-openprinting-job-ticket-api-v0100-20050315.pdf

• OP PDAPI/0.2 implemented in Ghostscript in all Linux distributions with

drivers for several printer models from multiple manufacturers

• OP PDAPI/0.2 has been adopted in LSB/3.2 (with required PWG UPDF

namespace and excluded Text/Font API support)

• OP PDAPI/1.0 now technically complete and scheduled for formal approval

by OP before end-of-2007

• OP PDAPI/1.0 Release Candidate 5 spec is archived at:

    ftp://ftp.pwg.org/pub/pwg/fsg/vector

in the files:

  pdapi-spec-1.0rc5.pdf
  pdapi-changes-0.2to1.0rc5.pdf

• OP PCMAPI supports management of communications channels (USB, Parallel,

etc.) to local or network printers

• OP PCMAPI design and implementation work continues
• Current OP PCMAPI draft is NOT posted

• OP SMAPI prototyped in 2004
• OP Steering Committee requested that communications channels be broken

out separately (to PCMAPI)

• After OP PCMAPI is complete, OP SMAPI spec will be updated to use

OP PCMAPI

• Obsolete OP SMAPI draft is archived at:

    ftp://ftp.pwg.org/pub/pwg/fsg/status_monitoring

in the file:

  SMAPI_draft_20040522.pdf

• OP PCAPI should at least support Adobe PPD and PWG UPDF namespaces for

properties (in an abstract manner analogous to OP JTAPI)

• OP PCAPI is currently being designed by Wendy Phillips (Sun)

• OP DDAPI should support multiple discovery methods (SNMP, DNS-SD, LDAP,

etc.)

• OP TFMAPI should support format-neutral API for conversion of print

document formats (source, intermediate, or print-ready) for use by OP PAPI implementations and applications