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

[Zenaan Harkness]

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