summitmontrealsummary

Open Printing Summit Summary

27 September 2007

The original of this document is archived at:

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

in the files:

  Open-Printing-Summit-Summary-20070927.htm
  Open-Printing-Summit-Summary-20070927.pdf

Contents


OPS Summary - MONDAY - 24 September 2007

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


What is New in CUPS? (Mike Sweet, Apple)

  • 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
    


    Open Printing US/Europe (Glen Petrie, Epson)

    • 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
    


    Printing API (PAPI) (Norm Jacobs, Sun)

    • 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


    Cairo Graphics Library (GNOME) for PS/PDF (Behdad Esfabohd, Cairo)

    • 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
      


    Generating perfectly text-extractable PDF (Behdad Esfahbod, Cairo)

    • 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


    OP Japan CUPS PDF Filters (Yasumasa Toratani, Canon)

    • 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
    


    Foomatic 4.0: PDF Workflow and XML with DTDs (Till Kamppeter, LF)

    • 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
    


    OPS Summary - TUESDAY - 25 September 2007

    Part II: Printing on the Desktop: GUI and Applications


    KDE Printing (Cristian Tibirna, Maintainer KDE Print)

    • 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!
    


    GNOME Printing: Behdad Esfahbod (Cairo/Pango)

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


    Common Printing Dialog (Peter Sikking, Open Usability)

    • 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
    


    LSB 3.2 and 4.0: Printing Infrastructure (Jeff Licquia, LF)

    • 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


    system-config-printer (Till Kamppeter, LF)

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


    YaST (Johannes Meixner, SUSE/Novell)

    • See slides for most details
    • Inherent ambiguity of "printer" versus "queue"
      - hard for end users
      


    Printer Drake (Marcelo Leitner, Mandriva)

    • See slides for most details
    • Impressions
      - Ira - very nice tool
      

    Part III: Printer Drivers and Printer Validation


    OP Japan Vector Driver (Yasumasa Toratani, Canon)

    • 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
    


    Distribution-Independent Driver Packages (Till Kamppeter, LF)

    • 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
    


    OPS Summary - WEDNESDAY - 26 September 2007

    Topic - Driver Development Reports since last OPS


    HP Linux Drivers (Shiyun Yie and Raghothama Cauligi, HP)

    • 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
    


    HP Linux Binary Plug-Ins (David Welch, HP)

    • HPLIP 2.7.9 Plug-In Design
      - Supported by HP Device Manager for Linux
        - PPDs
        - Firmware
        - Plug-Ins
        - Rules
        - License
      


    Canon Printer Driver for Linux (Yasumasa Toratani, Canon)

    • 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/
    


    SUSE Print Management (Johannes Meixner, SUSE/Novell)

    • 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


    Third-Party Printing Driver Development (Hin-Tak Leung)

    • 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


    Printer Driver Validation (Yasumasa Toratani, Canon)

    • 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


    OPS Wrap-up

    • 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.


    OPS Messages to Manufacturers

    • 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
      


    OPS Summary - Open Printing Project Status for 2007

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


    OP Reference Model - stable


    OP DSH (Directory Structure and Hierarchy) - completed

    • 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 (Print API) - completed

    • 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 (Job Ticket API) - completed

    • 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 (Print Driver API, aka OPVP) - nearly complete

    • 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 (Print Channel Manager API) - work-in-progress

    • 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 (Status Monitoring API) - work-in-progress

    • 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 (Printer Capabilities API) - proposed

    • 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 (Device Discovery API) - proposed

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


    OP TFMAPI (Transform API) - proposed

    • 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

  • Groups: