Official protest against bug 1060 / was: Re: Away for afewdays..

[Roland Mainz]

Owen Taylor wrote:
> 
> On Mon, 2004-08-30 at 12:38, Steve Swales wrote:
> > This e-mail suggests there is some confusion about Xprint.  Xprint is
> > part of the official X11 distribution.  It has been for a long time.  It
> > was contributed by HP, long ago, and, though it
> > was not working in a practical sense until Sun picked it up and got the
> > basics working, it was
> > in the distribution, and documented as such.   The work that Roland has
> > done has been to really turn Xprint into a commercially usable
> > component, and ABSOLUTELY his work should be incorporated into the
> > latest distribution.   Xprint has been vilified by many people...  as
> > far as I can tell, these people are all English language chauvinists,
> > and/or they think that because they can imagine something better than
> > Xprint (though they've never been able to PRODUCE anything to replace
> > Xprint), that the need to reject Xprint.    The fact that there have
> > been tens of thousands of people who have downloaded Roland's Xprint to
> > use with Mozilla shows that these detractors do not represent the whole
> > world.  In my opinion, they quite literally represent a very narrow
> > (i.e. American English) audience.   X11 must be a global distribution,
> > representing global interests.
> 
> I really not sure this is the right place to have a technical debate
> about this, but I can't let the above statement pass.
> 
> Something to replace Xprint exists. The basic architecture is:
> 
>  - Client side fonts looked up by fontconfig
>  - A shaping engine (Pango, Qt, ICU, whatever)
>  - Embedding fonts in the generated output file
>  - IPP (cups on Linux) to talk to printers and print servers
> 
> This exists *now* for both GNOME and KDE, and works across a much
> wider spectrum of languages and scripts than I'm aware of being
> supported in any Xprint-based solution.

Owen, it would be NICE if you could READ the documentation FIRST before
making such CLAIMS. For example font download is already implemented in
Xprint and a server-side shaping engine comes with STSF. And Sun has
already _WORKING_ Xprint support for Thai, Tamil, Hindi, Arabic, etc. on
the Solaris platform.
But reading the docs isn't the strength of most of the complainers about
Xprint - some of them even "invent" new stuff even without knowing
exactly what Xprint is actually (or better: They can't answer even basic
questions about it's functionality). The Xprint FAQ has a nice "Myths
about Xprint" entry (and surpirse surprise: the main "contributors" to
this section were gnome-print people, some Redhat staff and Keith
Packard himself) ...

> GNOME supports this, KDE supports this, OpenOffice supports this,
> Mozilla basically supports it. (Support for complex-text
> scripts via Pango is almost ready to be landed.)

Neither Gnome nor KDE implement DPA or something which is
PDL-independent. Or something which avoids forcing an application to one
rendering model (I am not even sure whether some people here have
realised that Xprint supports more than one rendering model).
All their designs are more or less PostScript-centric and don't even
look beyond that barrier. Most of these APIs (and this includes CAIRO as
well) still treat printing as an unidirectional way to feed the printer
with a Postscript stream - regardless whether these data are actually
"suited" for this kind of printer or not. The designers simply seem to
lack of the information that printing is something different: A
bidirectional communication between printer, printer driver and the
application where the last two parts "adopt" to the features of the
printer. Most of todays applications turn that model upside-down and
then wonder why customers are still not satisfied with the results.

It's a pity that some people here are not able to learn from the
mistakes of the past. At least the orginal designers of Xprint were
aware about these issues and made a design which avoids the problems I
have listed above. And they made ONE uniform API. Not a wild mixture of
things which aren't natively available on most non-Linux platforms and
don't really fit together.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)