Re: GNOME font library RFC

On Sun, 28 May 2000, Lauris Kaplinski wrote:

> Freetype is nice, but gnome-font-system should go a step beyound that and
> hide all TTF/TypeX specific stuff from user. Most of that is 
> overcomplicated for users too...

Fonts are complicated, unfortunetly.  Attempts have been made in the past
to simplify the interface, but the end result is usually less than
satisfactory.  I'm sure Owen can list issues that crop up when handling
international fonts.

> All, that user would need in GNOME programs, are IMHO
> - ArtBpath outline

These are going to be too slow.  David Turner told me that his design
beats raph's code, mainly because it is aimed at font's and thus knows
things that raph's code doesn't.  Also, I don't think ArtBpath's support
cubic beziers.

> - Various rendered bitmap formats

I've whinged about the lack of design in this department once before, and
nobody seems interested.

> - Glyph set
> - Ligature lists
> - Kerning lists
> - Various metrics
> - Raw font data

Freetype provides all of these in an easy to use bundle.

> Freetype uses TTF specific data formats, which were created long ago, when
> computers were slow (TTF fonts were usable on 286 too), but are of little
> interest to average programmer. For GNOME I find doubles, ArtPoints,
> ArtBpaths and GdkPoints to be more convenient, than 16.16, 2.14 and 26.6
> floats. The former can be used directly in real situations, the latter
> should be converted by hand by every program.

Yes, the high level interface should be doubles, and ArtPoints etc.  But
the truetype stuff is done the way it is because it has to work on
non-floating point systems(this includes the netwinder).  Considering that
most of font rendering consists of addition, dividing by two and
conversion to integers, I think using integers at this level is
worthwhile(don't forget how costly a float->int is on intel, when you do
something like that for every char, for every pixel, it is worth doing it 
the fast way).

> Also, at least at moment, gnome-font library should deal with both type1
> and TTF fonts, giving common, higher-level API for handling these.

Freetype does TTF, Type1 and did, and will have OpenType support.  The
only other format I can think of worth supporting would be Metafont, and
I'm sure it would be fairly easy to add Metafont into the existing
Freetype library.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]