[Gnome-print] [Fwd: Gnome printing issues]

[Raph Levien <raph acm org>]

-- 
Raph Levien <raph@artofcode.com>  |  artofcode LLC  |  www.artofcode.com

---

• From: Raph Levien <raph acm org>
• To: hamzy us ibm com
• Cc: gnome-hackers nuclecu unam mx, gome-print helixcode com, rlk alum mit edu
• Subject: Re: Gnome printing issues
• Date: Wed, 13 Sep 2000 15:31:18 -0700

hamzy@us.ibm.com wrote:
> 
> Hello,
> 
> >    In a networked printing scenario, doing the rasterization
> > client-side is potentially a huge performance problem ...
> 
> That is why printer drivers band.  The page is replayed n times to
> a band that is 1/n as large.  Of course, it takes n times as long
> to print, but the memory requirements are less severe.
> Banding uses a journal file, which is a recording and playback of
> the APIs used during printing.  It can be a different format than
> the metafile.  Metafiling is used to allow the application to be
> able to be used immediately after printing.  Of course, there
> are instances where a user wants the printer driver to generate
> the output immediately.

I am familiar with banding, but it only adresses some of the performance
issue, namely storage of the intermediate print buffer. It doesn't help
the network bandwidth issue at all. Metafiles do, of course, but in a
networked environment you have to worry about things like version skew
between the different versions of the metafile format.

The line between metafile and PDL is thin - it may be that there is no
real technical distinction at all.

> >    There was quite a bit of excitement at the Printing Summit about
> > the open sourcing of the IBM Omni driver framework. Perhaps the most
> > exciting thing was the vast archive of supported printers. However,
> > in the actual release, only 100 printers are supported, from only two
> > manufacturers (Brother and Epson). Since most of the driver work was
> > done under NDA, presumably IBM simply failed to obtain permission from
> > the printer manufacturers to release their code. I have no idea
> > whether this is going to change, but until then we should be looking
> > at Omni on its technical merits.
> 
> Its not that we failed.  We are working with printer manufacturers to
> open source the data that they provided to us.  These things take time.

I'm very pleased to hear that this effort is going forward. A collection
of drivers for lots of printers out there is indeed a great gift, and I
thank IBM for it.

> >    From what I understand, image quality in Omni is middling.
> 
> The dithering was designed to be general and support many printers (500+)
> instead of, for example, making six color Epson Stylus' look great.
> The dithering code is a module and can be replaced.  If there is some
> LGPL code out there, we would be happy to include it.

Ah, here is one of the sticking points. There is a great deal of
excellent work out there on image quality, but it mostly tends to be
GPL. Gimp Print of course contains some of the most excellent work, and
there's also my own Rinkj prototype (http://www.artofcode.com/rinkj if
you haven't seen it before).

I'd like to keep a dialog with IBM open about applying some of my image
quality expertise to the Omni drivers. In terms of dithering algorithms,
I'm willing to consider relicensing Rinkj for LGPL release.
Alternatively, IBM can relicense Omni as GPL and be able to use the
Rinkj dithering for free. In the latter case, you would need to change
the Omni invocation interface so that it's in a separate address space
as the application (assuming, quite reasonably, that you don't want to
restrict Omni to printing from GPL applications only).

Another avenue to explore is using my GPL dither matrix generating code
to generate matrices for a thresholding approach - this is what I did to
make the dither matrices for GdkRgb, which most people will agree is the
highest quality ordered dithering for limited-depth displays out there.

If IBM is interested in pursuing any of these avenues, let's talk
offline.

[Other issues elided]

> >                                                   Most inkjet printer
> > manufacturers have indicated their preference for providing binary
> > Linux drivers (in one framework or another). I believe that supporting
> > the Gimp Print work is our best bet for ensuring that our complete
> > printing infrastructure remains free.
> 
> By that, do you mean that since Gimp Print is GPL, then printer
> manufacturers would have no choice to use binary implementations for their
> driver?

No, my argument is slightly different. If Omni becomes popular but to
lags significantly in image quality, there will continue to be an
incentive for printer manufacturers to release Linux binary-only
versions of their proprietary drivers. If Gimp Print were to become
popular, or if the image quality of Omni improves to match Gimp Print,
then this incentive goes away.

Again, thanks for releasing Omni. I apologize if my criticism makes me
sound ungrateful. I just want to see that the inkjet drivers for Linux
become the best possible.

Raph

-- 
Raph Levien <raph@artofcode.com>  |  artofcode LLC  |  www.artofcode.com

---