|
|
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. I hope this is found to be informative. Please send any followups to debian-devel.
|
|
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. 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)
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
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: "<>setpagedevice"
*InputSlot Manual/Manual Feed: "<>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: "<>setpagedevice"
*InputSlot.French Auto/Par Defaut: ""
*InputSlot.German Auto/Standard: ""
*InputSlot Manual/Manual Feed: "<>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
=66rom 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=C2=AE 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 of 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.
|
