- 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

- 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

- 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

- 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

- 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

- 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

- 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)

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

- Vendor, Code, Attributes, Modules

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

- Print Dialog - Common feature and capability parametrics

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

- See slides

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

- 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

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

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

- in progress
- integrated solution

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

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

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

- 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

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

- 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

- 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

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

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)

- 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

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

- Screen shots of version 0.3 common printing dialog

- 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

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!

- 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

- 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

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

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

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

- 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

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

- Wine - native bridge?
- XEN
- Mingw

- 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

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

- 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

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

- 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

- 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

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

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:
  

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

  in the file:

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

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

  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 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)

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