Re: Off-topic -- Is anyone involved in the New Rendering Model project at XFree86?

[David Turner]

Hi Miles,

> 
> I really didn't mean to imply that nirvana is to be found in the XFree86
> context alone.  :-)  I am just curious how the development community can
> best reduce redundant work.  Again, since Open Source developers are
> precious commodities, it would be great if there were one set of
> libraries could be the focus of the folks working in this area.

It seems others in the list have done a pretty good job at explaining
you why XFree and FreeType are unrelated, so I won't do it there :-)

However, I'd be rather surprised to see a convergence of efforts or
a reduction of redudant work in the near future. Developers have a
large tendency of wanting to do things themselves (especially when
they do not understand the depth and complexity of the task),
which sometimes leads to surprises and disaster (and I'm speaking
from personal experience ;-).

But often, the reason is more simple: developers start from very
different requirements and end up with incompatible or un-mergeable
results. Here's a very good example:

I'd like a text service on top of FreeType to perform various text
layout operations (advanced typographic features, line breaking,
hit-testing/selection, WYSIWYG, etc..). There already exist a
library called Pango that does it pretty well. However, I cannot
use it because it relies on GLib. Here are the details:

  - GLib has become a huge monster now, and really isn't suited
    for the embedded market. We could however write a "fake" GLib
    to compile Pango, only providing the necessary functionality
    (which basically is the simple "GList" and "GHashTable" types)

  - GLib has a very serious limitation that makes it really
    impractical for embedded systems: its memory allocator simply
    traps the whole process when there's no memory left !! Once
    the limit is reached, you're a pretty dead duck.

    Of course, this was done so that GLib applications would never
    have to worry about a failed allocation. And indeed, they _never_
    check any pointer.. that includes Pango too.. I won't comment
    on the stability of Gnome apps and libraries ;-)

This is a striking example where an initial design decision, made to
greatly facilitate the life of other developers, has far-reaching
consequences.. What's appropriate in one domain ("desktop" environment)
becomes broken to no end in another.. (embedded systems)..

It's a bit like the "we won't add anti-aliased text to XFree until we
fix the rendering model itself" issue. I'm pretty certain that it's
possible to "patch" the XFree sources to display AA text, but it
certainly can't be anything else than a major hack :-) Though,
sometimes such a hack is necessary..

(Note that I have no problem with the LGPL license (that covers Pango)
and wouldn't see any reason not to  release the text service under it
if it uses Pango.)

Note also that I have not contacted the Pango authors regarding
this problem (let's release FT2 before :-) but will sure do it
rather soon !!

> Since, as you point out, there will be other windowing environments
> that need anti-aliased font support, is there a good reason why the
> XFree86 team is looking to implement the new rendering model without
> simply reusing the FreeType code?
> This is the case, isn't it?
> 
I have no idea of their intents regarding fonts. The white-paper written
by Keith Packard doesn't seem to indicate that they've put significant
thought to this problem, as they basically want to draw anti-aliased text
and provide outline data to applications.. That's clearly not enough in
my opinion, but I have no alternative implementation to propose.

I'm on the render list though, and I'll make a few comments when the
font issue comes back in discussion :-)

Cheers,

- David


> Thanks again,
>                 Miles