[Desktop_architects] Printing Summit 2006

[Egbert Eich]

Till Kamppeter writes:
 > Oi,
 > 
 > as I already told during the meeting, I would like to organize a
 > Printing Summit in 2006.
 > 
 > Also Mike Sweet (creator of CUPS) showed with his slides that he is
 > interested.
 > 
 > 
 > Who should participate?
 > -----------------------
 > 
 > - Developers on important printing-related projects, like CUPS,
 >    linuxprinting.org, Gutenprint, HPLIP, GhostScript, driver projects,
 >    Cairo, X-Print, ...

I know a vibrant supporter of Xprint. Yet many in the X community feel
that Xprint was a bad idea and should go away. Currently it's considered
legacy. (Please correct me if I'm wrong)
* In the old days of lpd XPrint provided print queue management and a 
  uniform API for that. That's done better by CUPS and libCUPS these days.
* Xprint provided conversion of the core X requests to different printer
  languages. Many of these core X requests are not used much today.
  Modern extensions like RENDER are not (yet?) supported by Xprint.
* The issue often pointed out that applications that did screen 
  output could also provide printing without changes to the app 
  is not really true or the results are not really high quality.
  With pdf/ps backends to high quality drawing libraries as cairo or
  the one contained in Qt we may actually be better off.
* There are some arguments brought forward by people in support of
  Xprint:
  a. Xprint provides backends for numerous printer languages unlike
     CUPS that 'favors' postscript.
  b. Xprint does not rely on X for printing as it supports applications
     to submit data in the printer's natural language.
     (needless to say that unless someone expects that drawing libraries
     will aquire backends for all sorts of printer languages argument
     a. and b. contradict each other).
  c. Xprint supports printer fonts. 
     Printer fonts helped reduce the amount of data that
     had to be downloaded to the printer. On the other hand they
     limit applications to the fonts available on the printer.
     This creates problems with i18n support as a lot of scripts
     are not available on (non high end) printers.
     Please correct me if I'm wrong:
     Printer fonts are close to useless in a Postscript/PPD
     environment as PPDs only provide font names available on the
     printer (and no metrics information).
     Xprint tries to solve this problem by shipping font metrics 
     files for every font available on printers it supports.
  d. Xprint exposes the true printer resolution to the app.
     This is indeed a problem with the printing dialogs of most
     apps that live in a pixel oriented world: 
     Instead of providing pixel images in an arbitrary resolution
     and leaving it to the print engine to do the rescaling these
     apps should let the user select the printer and resolution
     beforehand and obtain this information from CUPS to draw
     the image in the printer native resolution.

All in all I don't know if we want to advertise yet another 
printing API to application developers. We will need Xprint for
legacy app support and therefore it is good that it has received
a backend for CUPS.
     
 > 
 > - Developers for color management

I can give you a contact there.

 > 
 > 
 > When should it take place?
 > --------------------------
 > 
 > At a time where as many as possible can participate.
 > 

Somewhere on the East cost would be a good place -
assuming that the majority of participants come from
the US and Europe.

 > 
 > Venue/Hosting
 > -------------
 > 
 > We need conference rooms, the hacker room, cheap accomodation
 > 
 > Perhaps one could connect it to another event, like LinuxWorld or similar?
 > 

This may help to get free facilities. On the other hand LinuxWorld
is a show - not a conference. Therefore it will attract more show
people than developers. Also it is usually held in places where
accomodations are rather expensive.
That's what I always point out for meetings of my organization.
OSDL may be a good venue.

Egbert.