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: "<</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 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.
Description: Digital signature