[hfdb] Re: [Fwd: Summary of the LSM Free Software Printing Summit]

[Zenaan Harkness]

On Wed, 2004-07-21 at 07:53, Zenaan Harkness wrote:
> There are some things in here that are particularly relevant to our work
> (both hfdb and hal).
> 
> I've some comments below.
> 
> FYI
> Zenaan
> 
> 
> -----Forwarded Message----- 
> > From: Roger Leigh <address@hidden>
> > To: address@hidden
> > Cc: address@hidden, address@hidden, address@hidden, address@hidden, 
> > address@hidden, address@hidden, address@hidden
> > Subject: Summary of the LSM Free Software Printing Summit
> > Date: Thu, 15 Jul 2004 21:19:46 +0100
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi folks,
> > 
> > I have spent the past week (5-11 July) at the Rencontres Mondiales du
> > Logiciel Libre (Libre Software Meeting) in Bordeaux.  I attended the
> > Free Software Printing Summit which was one of the topics at the
> > conference, and this message is a short report of the proceedings.  I
> > was there representing both Gimp-Print and Debian.  What we worked on
> > will have an impact on the Debian printing infrastructure in the
> > medium to long term, and this will affect a potentially large number
> > of printing packages, and so I have also CC'd the maintainers of the
> > relevant packages.  I hope this is found to be informative.  Please
> > send any followups to debian-devel.
> > 
> > The conference was attended by these printer manufacturers:
> >   Glen Petrie (EPSON)
> >   David Chamberlin (Kyocera)
> > 
> > And these developers:
> >   Kai-Uwe Behrmann (CinePaint)
> >   Ralph Giles (Ghostscript)
> >   Jody Goldberg (GNOME-Print)h
> >   Till Kamppeter (Foomatic/xpp)
> >   Hin-Tak Leung (epsonepl)
> >   Roger Leigh (Gimp-Print)
> >   Glen Petrie (FSG OpenPrinting)
> >   Patrick Powell (LPRng)
> >   Franz Schmid (Scribus)
> > 
> > And these distribution maintainers:
> >   Till Kampppeter (Mandrakesoft)
> >   Roger Leigh (Debian)
> >   Johannes Meixner (Novell/SUSE)
> >   Klaus Singvogel (Novell/SUSE)
> > 
> > Some people are intentionally duplicated.  Apologies to anyone who was
> > missed out or mischaracterised.
> > 
> > 
> > Talks
> > =====
> > 
> > OpenPrinting
> > - ------------
> > 
> > To start the summit on Monday, Glen Petrie gave a talk about the
> > "OpenPrinting" standard specification being developed by the Free
> > Standards Group.  The FSG publish draft specifications and sample
> > implementations of their APIs for public review, which are finalised
> > once they have been accepted by both upstream projects and GNU/Linux
> > distributions.  Currently, most work has been done on a Job Ticket API
> > (JTAPI) and a Printing API (PAPI), which includes manipulation of
> > printer capabilities, creation and control of print jobs and both
> > raster and vector print commands.  More information is available
> > here:
> > 
> >   http://www.freestandards.org/openprinting/
> > 
> > 
> > linuxprinting.org and Foomatic -
> > The Current Standard of Printing with Free Software
> > - ---------------------------------------------------
> > 
> > To follow, Till Kampppeter gave a talk about linuxprinting.org and
> > Foomatic.  linuxprinting.org is a database about which printer models
> > are supported on GNU/Linux, and what driver support is available.
> > 
> > This talk covered the structure of the Foomatic printer database, how
> > foomatic-configure may be used to generate PPDs (Postscript Printer
> > Definitions) for all free printing systems, with access to all
> > available driver options, and foomatic-rip, which is a
> > spooler-independent interface to Ghostscript, utilising PPDs for
> > specifying printer settings.  See
> > 
> >   http://www.linuxprinting.org/
> > 
> > 
> > Proposed PPD extensions
> > - -----------------------
> > 
> > Patrick Powell then started an unplanned (but very interesting)
> > discussion about the shortcomings of current PPD files and user
> > interfaces.  Currently, PPDs may only contain a single language, which
> > makes internationalisation difficult (translated PPDs are not
> > typically distributed with Debian due to the sheer size).
> > 
> > Patrick proposed a (backward-compatible) solution which would allow
> > all PPD properties to be translated within the same file using a
> 
> If this is implemented, this will make printer PPD "driver"
> integration pretty straightforward - we simply automate the
> extraction of the relevant information from the PPD file, eg:
>  - which 'low level' drivers supported (and which kernels)
>  - which translations are included
>  - printer features
> 
> I imagine the truly canonical location for all this information
> to stay as inside the PDD file. And, for a nice searchable DB
> (hfdb) to be a really useful thing for people looking to purchase
> a printer and/ or looking for driver/ os options. The hfdb will be
> able to cross reference the PPD printer info with low-level driver
> info, to provide something quite useful.
> 
> HAL wll be able to make use of "maximal feature support" metric
> to auto-choose 'best' low level driver for the printer the user
> just plugged in, as well as take advantage of auto-generated hal
> xml printer descriptor files (these can come straight from PPD,
> or if it is useful to include cross reference info with other
> drivers, hardware interfaces (eg. usb, firewire), then from
> hfdb (which is what I'll personally be focusing on)).
> 
> So the way I'm imagining the data transformation flow at this point is -> 
> hfdb -> xml -> hal.
> 
> > special fieldname extension to specify the locale, and also have
> > comments describing what all of the available options actually do
> > (which are also translatable).  He also criticised the lack of use of
> > nested option groups and constraints in PPDs, and the lack of support
> > of many popular user interfaces to allow easy use of constraints
> > (currently conflict resolution is manual and rather tedious).  Once
> > the current user interfaces have i18n and comment and good constraint
> > handling support, printing systems will become much easier to use for
> > many people.  These additional features will simply be ignored by
> > older interfaces.
> > 
> > Johannes Meixner has kindly provided an example:
> > 
> >   At the moment there is only one *LanguageVersion possible:
> > 
> >   *LanguageVersion: English
> >   ...
> >   *OpenUI *InputSlot/Media Source: PickOne
> >   *OrderDependency: 10 AnySetup *InputSlot
> >   *DefaultInputSlot: Auto
> >   *InputSlot Auto/Default: "<</ManualFeed false>>setpagedevice"
> >   *InputSlot Manual/Manual Feed: "<</ManualFeed true>>setpagedevice"
> >   *CloseUI: *InputSlot
> > 
> >   If the PPD is used in an multi-language environment (e.g. on a
> >   print server which is used by users with multiple languages)
> >   then all users always get only the English texts.
> > 
> >   As far as I remember Patrick Powell's proposal was to use the
> >   *LanguageVersion the same as before to specify the default language
> >   (therefore it works with all existing tools) and to add qualifiers
> >   to the option keywords.
> > 
> >   To be in compliance to the PPD spec regarding *LanguageVersion
> >   I suggest to use as qualifiers the values for the "languageOption"
> >   as listed in the PPD spec. because using Linux-specifix "locale"
> >   strings (like "en_US.iso885915") may cause trouble when the PPD
> >   is used with other operating systems.
> > 
> >   The above example for English (default), French and German may be:
> > 
> >   *LanguageVersion: English
> >   ...
> >   *OpenUI *InputSlot/Paper Source: PickOne
> >   *OrderDependency: 10 AnySetup *InputSlot
> >   *DefaultInputSlot: Auto
> >   *InputSlot.French InputSlot/Papier source: ""
> >   *InputSlot.German InputSlot/Papiereinzug: ""
> >   *InputSlot Auto/Default: "<</ManualFeed false>>setpagedevice"
> >   *InputSlot.French Auto/Par Defaut: ""
> >   *InputSlot.German Auto/Standard: ""
> >   *InputSlot Manual/Manual Feed: "<</ManualFeed true>>setpagedevice"
> >   *InputSlot.French Manual/Manuel mecanisme de alimentation: ""
> >   *InputSlot.German Manual/Manueller Einzug: ""
> >   *CloseUI: *InputSlot
> > 
> >   Note that for the translations of the main keyword it is used
> >   as option keyword:
> > 
> >   *InputSlot.French InputSlot/Papier source: ""
> >   *InputSlot.German InputSlot/Papiereinzug: ""
> > 
> >   This way it seems to work well for me - i.e. it passes cupstestppd
> >   without any warning and it seems not to cause problems for
> >   existing tools (i.e. the existing tools like xpp work exactly
> >   as before - i.e. the added main keywords with the language
> >   qualifiers are simply ignored).
> >   Of course detailed testing is required (in particular by printer
> >   manufacturers for their own PPDs) before we can propose it as a
> >   general enhancement request of the PPD specification.
> > 
> > 
> > PDF and Free Software
> > - ---------------------
> > 
> > Lastly, Ralph Giles talked about "PDF and Free Software".  PDF is set
> > to replace Postscript as the common output format of applications in
> > the future.  PDF is the default output format for MacOS X
> > applications, and PDF printers are now available.  PDF offers a number
> > of advantages over Postscript, such as transparency, support for
> > images with larger bit depths and embedded colour profiles.  It is
> > also simpler and more reliable to parse and manipulate than
> > Postscript.  For example, counting the number of pages in a Postscript
> > document is not trivial, but is very simple for the corresponding PDF.
> > Other features such as n-up printing and page rearrangements should
> > also be much more reliable than the current psutils--they just need
> > writing!
> > 
> > 
> > How Not to Build a Printer Database /or/
> > Printer Configuration is not as Simple as I Thought
> > - ---------------------------------------------------
> > 
> > On Friday, Patrick Powell talked about "How Not to Build a Printer
> > Database".  Patrick has been working on the next generation of
> > Foomatic (version 4) and intends to replace the current database used
> > to generate PPDs with plain PPDs (which can have the necessary
> > information extracted from them on demand).  This aims to simplify the
> > information by having a single PPD for each printer model, which would
> > support all of the drivers that work with that model.  In addition,
> > his new scheme to allow translation and help comments in PPDs would
> > allow translation of non-modifiable, copyrighted PPDs without
> > violating any copyright, since they can simply be tacked onto the end
> > of the file, without touching the original content.  The differing
> > requirements and management of small home/office users and users of
> > large corporate networks were also discussed.
> > 
> > 
> > Discussion
> > ==========
> > 
> > For the rest of the week, we occupied a room with a network router and
> > a collection of printers, including various printers very kindly
> > provided by EPSON (C64, R300, R800, Pro 7600 and an EPL 6200L laser)
> > and an HP inkjet.  In between printing all our digital photos on the
> > various printers (the big A1 7600 roll printer in particular, which
> > was used to print an "RIP GIF patent" poster used to stick on a
> > coffin!) we discussed quite a lot of issues relating to printing, some
> > of which I have attempted to summarise below.  Many of our ideas came
> > from the evenings spent in several of the excellent restaurants of
> > Bordeaux!
> > 
> > 
> > Colour management
> > - -----------------
> > 
> > Colour management is used to ensure that the colour you ask for in
> > your application matches the colour you see on the printed page.
> > Currently, we lack an integrated and simple way to manage colour.
> > Other systems provide "ICC profiles" to do this.  Colour
> > transformation uses pairs of profiles: a "source" profile which
> > describes the meaning of the colours in the document being printed,
> > and a "destination" profile which describes the meaning of colours on
> > the printed page.  When combined together to produce a single
> > transformation, accurate reproduction of colour is possible.
> > 
> > Currently, Ghostscript can use source profiles embedded into a PDF
> > file.  However, the destination profile must be obtained from the
> > printer driver in use (e.g. Gimp-Print), and currently there is no way
> > to do this.  This will require Ghostscript (or some overall
> > coordinating program) to negotiate with the driver for the most
> > suitable profile, and pass this to the process doing colour
> > transformation where the two profiles may be combined.  There are
> > several scenarios here:
> > 
> >   - gs and a driver communicating via the IJS protocol (IJS will need
> >     to be able to do this negotiation).
> >   - gs and a native gs driver (obsolete).
> >   - CUPS pstoraster and a CUPS filter driver, e.g. rastertogimpprint
> >     (currently only a unidirectional pipe).
> > 
> > Kai Uwe Behrmann already has colour profiles working with CinePaint
> > and Gimp-Print, used for proofing.  These make a considerable
> > difference to the colour reproduction, such that they are comparable
> > with the colour of professionally-printed offset prints!  However,
> > while the print quality is superb, we need to get colour management
> > integrated into the printing toolchain so that the average user can
> > benefit from accurate colour reproduction.  (I also believe that
> > Scribus offers some degree of colour management.)
> > 
> > There is no doubt that colour management is the future, but since this
> > will require significant cooperation between projects to work upon a
> > unified method of managing colour throughout the whole printing
> > "workflow", in addition to significant reworking of individual
> > projects, this is certainly possible, but will take some time to
> > realise our goal.  For Gimp-Print at least, this will not be possible
> > until after our 5.0 release (hopefully in November).
> > 
> > Another issue is "gamut compression".  Sometimes part of the source
> > image cannot be represented in the colour space of the destination
> > device (for example, bright direct sunlight is way off the scale that
> > an inkjet printer can reproduce, yet may be captured by a digital
> > camera and images stored in floating point).  In this impossible
> > situation, something must be done to give an approximate
> > representation which is pleasing to the eye--this is not an exact
> > science and is an artistic issue rather than something that can be
> > resolved mathematically.  Raph Levien is working on this problem.
> > 
> > Some more information and links are available here:
> > 
> >   http://www.levien.com/gimp/gcmm.html
> > 
> > 
> > epsonepl
> > - --------
> > 
> > Hin-Tak Leung and Roberto Ragusa have reverse-engineered the
> > proprietary protocol used in the "lite" versions of EPSON EPL laser
> > printers which use host-based page rendering rather than a standard
> > page description language such as PS or PCL.  Hin-Tak successfully got
> > the EPSON EPL 6200L to work, which had never before been tried!
> > 
> > Due to the nature of the protocol, which requires bidirectional
> > communications, the current unidirectional filter pipeline in CUPS is
> > unsuited to this type of driver.  The status feedback from the printer
> > indicates how much data may be sent; if this is ignored, the printer
> > will not have enough available memory to store the data being sent.
> > Having the CUPS backend and filter being able to communicate would be
> > very useful, and also has other applications (such as checking the
> > printer has enough ink before printing a page).
> > 
> >   http://epsonepl.sourceforge.net/
> > 
> > 
> > Ghostscript
> > - -----------
> > 
> > Johannes Meixner would like to make Foomatic simpler by making
> > Ghostscript behave more like a native Postscript printer.
> > Additionally, he would like to be able to simplify Foomatic by
> > allowing the gs device and other command-line-only options to be
> > specified in the Postscript directly so that all of the required
> > options can be specified directly in the PPD.  Some reworking of gs
> > internals are required before this is possible to achieve.
> > 
> > Roger Leigh would like gs and all IJS-aware programs to switch to
> > using a versioned shared libijs.so, which will enable all IJS using
> > programs to stay up-to-date with the latest version of the IJS
> > protocol.  pkg-config support is available with ijs, and so a change
> > to the gs build should allow this.
> > 
> > 
> > Gimp-Print
> > - ----------
> > 
> > Johannes Meixner and Klaus Singvogel noted that SUSE have received
> > several complaints regarding the poor print quality of the Canon
> > family driver in some cases.  They would not mind if it was removed
> > from new releases, and suggested spending more time improving drivers
> > which can be made perfect because supporting a partly-functional Canon
> > driver is a waste of effort if Canon are not interested in supporting
> > free drivers.  Informing users that Canon are not a good choice of
> > inkjet printer, and recommending that they buy e.g. EPSON or HP might
> > be a better solution.
> > 
> > Compared with the EPSON Windows® driver, the Gimp-Print driver colour
> > output was significantly darker, with red being more orange, blue more
> > purple, magenta too red and cyan too blue.  This appeared to be a
> > general problem rather than an issue with a specific model.  With Kai
> > Uwe's colour profiles, the output was significantly improved, though
> > not identical to the EPSON driver (although this does not mean it was
> > incorrect without a reference to compare with).
> > 
> > Integration colour profile support is only half of the colour problem.
> > The other is actually creating the profiles, which requires special
> > equipment and lots of time.  Ideally some means by which users could
> > tune their own printers would be a partial solution, but the hard part
> > is having a known standard with which to compare the printed output
> > to.  Another issue is breaking existing profiles when making changes
> > to e.g. the dither or colour code--we might need to guarantee at least
> > some measure of stability of the algorithms in addition to ABI
> > stability.
> > 
> > Allowing easier tuning of printers is planned, but requires moving of
> > the internal data structures currently hard-coded as arrays of structs
> > to dynamically allocated structures read in from XML definitions.
> > Currently only a small part of the data is available as XML.  This may
> > be achievable for 5.0, but should be possible to add compatibly after
> > the release if not.  Ideally, a single XML schema should be usable for
> > all of the supported family drivers.
> > 
> > 
> > GNOME-Print
> > - -----------
> > 
> > Various aspects of GNOME-Print and its user interface were discussed,
> > including an eventual merge of libgimpprintui with libgnomeprintui
> > once the former has been cleaned up by splitting it up into reusable
> > component widgets derived from GObject.
> > 
> > 
> > Paper handling
> > - --------------
> > 
> > OpenPrinting defines a set of paper sizes and standardised names based
> > upon the ISO and US paper sizes, amongst others.  libpaper could be
> > enhanced to support the additional metadata and paper sizes.
> > 
> >   ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf and
> >   ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf
> >   (available in a few weeks)
> > 
> > In particular, the support for standardised names, aliases and storing
> > the paper sizes in any common unit of measure (while allowing for
> > conversion into the type required by the user) are desirable.  For
> > each paper, a "legacy name", multiple aliases, and a "self-describing
> > name" (including dimensions and units) are defined.  We should
> > probably also provide a human-readable name for aesthetic and
> > internationalisation purposes.
> > 
> > 
> > PPDs
> > - ----
> > 
> > PPD i18n issues were discussed with Patrick Powell.  Once a clear
> > specification is available, this should be relatively easy to
> > implement in Gimp-Print, since translated PPDs are already available.
> > 
> > 
> > I'd like to thank ENSEIRB at the University of Bordeaux for hosting
> > the event, Pierre Jarillon of ABUL and especially Till Kamppeter of
> > Mandrakesoft for organising the event and everyone who attended for a
> > very enjoyable week!
> > 
> > Regards,
> > Roger
> > 
> > 
> > - -- 
> > Roger Leigh
> > 
> >                 Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
> >                 GPG Public Key: 0x25BFB848.  Please sign and encrypt your 
> > mail.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.4 (GNU/Linux)
> > Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
> > 
> > iD8DBQFA9ubdVcFcaSW/uEgRAqLYAJ4/JmX91Z6I5ZJni+aoOm7Vb6u9kQCeOB2B
> > LeoKUsB028SztNyKIj4Afaw=
> > =ve/S
> > -----END PGP SIGNATURE-----
>