[Fwd: Summary of the LSM Free Software Printing Summit]
Zenaan Harkness
zen at freedbms.net
Tue Jul 20 14:53:55 PDT 2004
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 <rleigh at debian.org>
> > To: debian-devel at lists.debian.org
> > Cc: gimp-print at packages.debian.org, cupsys at packages.debian.org, lprng at packages.debian.org, foomatic-db at packages.debian.org, gs-esp at packages.debian.org, gs-gpl at packages.debian.org, libpaper at packages.debian.org
> > 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-----
>
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list