Re: GNOME font library RFC

[Lauris Kaplinski <lauris ariman ee>]

On Mon, 29 May 2000, Nathan Hurst wrote:

> 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.

International text layout is tough issue - yes. But glyph rendering is
simple. I am quite sure, layout should be left to Pango, but rendering
probably not.

> > 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.

You meant quadratic?
Do not forget - computers get faster every year, human abilities stay
constant. So it is generally accepted (I hope), that clean, but not so
efficient API is usually preferred to complex, but efficient one.
What about outline and raster caches? Freetype people specifically said,
they are not interested in adding rendering to RGB/RGBA buffers. For any
efficent font rasterisation, GNOME should have glyph cache - so additional
layer above freetype engine is mandatory.

I am all about using Freetype as rendering library for gnome-fonts. But I
am quite sure its functionality should be hidden from user-level programs
by gnome-font layer. So user simply does:
gnome_font_render_glyph_rgba (font, glyph, buffer, x, y, width, height,
  rowstride, color)
gnome-font layer looks into cache, if it already has Freetype rendered
graymap of that cache. If not, it asks Freetype to render one. That
graymap is then composited to buffer.
The same stands of outlines. wrapper layer should look into cache for
outline, and if not found, construct one, approximating quadratic curves
to cubic ones. Resulting curve can then be fed to additional libart based
processing (clipping, gradienting, stroking etc.)

> 
> > - 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.

>From freetype FAQ
It isn't a high-level text  rendering library, and many tasks will
have to be performed by higher level layers like:

  - glyph caching (outlines and/or maps)
  - text rendering
  - justification, kerning
  - font mapping
  - rotated/slanted text

> 
> > 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).

Hmmm... this is all why we call these fonts and not image sets. Being font
means, that usually every glyph is used more than once, and is thus
usually cached in efficent way. So there is usually no need doing
extensive float->int for every pixel, but only for every glyph.

And don't forget - in free software world easier API usually results in
more and better quality programs. You can do all, you can do with GNOME,
using plain X - but nobody does. Programmers are eager to give up some of
their coding freedom in exchange of clean and high level API.

> > 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.

Agree.
Freetype can well be the backend of gnome font engine, but alone it is not
sufficent.

Regards,
Lauris