User Tools

Site Tools


Table of Contents

Open Printing Summit Summary
27 September 2007

The original of this document is archived at:

in the files:



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:


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
          - 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 &
    - 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
  • 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)
  • 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
    - 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
        - provides only limited error checking (memory allocate but not
        - 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,
      - 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
  • PAPI Source Code - OpenSolaris
  • OpenPrinting PAPI mailing list
    - /mailman/listinfo/printing-spool/
  • PAPI/1.0 Spec

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
    - 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: 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
    Generic System V/BSD interfaces are not sufficient
    - No way to discover what printers are available
    - No standards for discovering or supporting advanced printer
    - 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 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!)
    - 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
    - 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
    - Sample driver "opvpnull" is already updated for 1.0
    - Driver feasibility test has almost finished (6 months)
      - Soon available at

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 - 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
    - 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:
        Braziliaan Portuguese
        Simplified Chinese
    - 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)
      - "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:

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
  • 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<>
    - Miyata<>
    - Nagasaka<>
    - Ogasawara<>
    - Sekiguchi<>
    - Shida<>
      - drafting/arrangement
    - Toratani<>
  • 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 Reference Model Diagram is archived at:

in the file:


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:

in the file:


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:

in the file:


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:

in the files:


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


  • Obsolete OP SMAPI draft is archived at:

in the file:


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,


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

openprinting/summitmontrealsummary.txt · Last modified: 2016/07/19 01:21 (external edit)