Obj: FTLayout (was Re: Short Roadmap)

[David Turner]

Hi Leonard,

> 
> At 11:45 AM +0200 10/20/00, David Turner wrote:
> >   I have also started working on a text layout library, though it's
> >   still on the very early stage. Its available under the module
> >   name "ftlayout" in the CVS. Note that I'll make a complete announcement
> >   and roadmap for it next week.
> >
>         Interesting you should mention that, since I was about to
> start work on the same thing myself!   I'm working on a x-platform
> text layout engine/library which will sit in between a set of "format
> modules" (for handling different file formats) and "output modules'
> (for handling output ;).   I plan to use FreeType for a "rasterizer"
> output module.
>

First of all, I'd like to inform you that there already exists a
beautiful LGPL-ed library called Pango (www.pango.org) to perform
text layout. It seems to have an extremely modular design that
already implements succesfully what you're describing. And it
already contains a FreeType 2 "format module", though it also
deals with X11 fonts and Win32 fonts directly, depending on the
platform :-)


Actually, I was very fond of the idea of using it directly when
I first heard of it, adding OpenType Layout parsing to it wouldn't
have been too much work. However, there is ONE annoying thing
in its design that make it unsuitable for embedded systems:

  Pango uses the "GLib" library, which provides a "checked"
  malloc that simply _traps_ the program/application when
  an out of memory condition is raised.

  that's of course a major convenience when writing client
  applications that must run on a PC with plenty of swap space,
  given that never checking memory allocation _greatly_ simplifies
  C code. However, it's a major disaster when you need to write
  a system-level library that should _never_ crash your system
  or graphics server..

I have tried to find ways to circumvent these limitations (e.g. by
using a "fake GLib" that doesn't trap, using exceptions + GC, etc..
but each one of them seems to have an important downside). I talked
about it with other FreeType guys at our last meeting in Aachen and
we decided we needed something a bit more reliable..

so, my answer would be: if you need something that runs on the
"application side" and where memory shortage is unlikely to happen,
don't hesitate one second to use Pango, it is a lot more mature,
documented, etc.. than anything we can provide for now, and I intend
to share our work on OpenType Layout tables with them..

on the other hand, if you need something more robust, well..
any contribution is welcomed ;-)


>         I'd certainly be interested in coordinating efforts, though I
> don't know yet how much (if any) of the final product will be open
> source.  If I do it, it will most likely be LGPL, so that I can also
> commercially license it (since the reason for doing it, is I have at
> least two clients that want it ;).
> 

I think I'd be happy if you could collaborate. I initially plan to
release FreeType Layout under the FreeType (BSD-style) license, though
I don't think it'd be a problem if we choose the LGPL instead, for
wathever reason..

However, the module already contains a few source files that are
directly related to the validation and parsing of OpenType Layout
tables (that doesn't make a text layout engine, though, far from
it..). These files are:

  - otlayout.h
  - otlvalid.c
  - otlparse.c
  - otltable.c

they've been written to avoid _any_ external dependencies, except an
ANSI C library, and I intend to release them under the FreeType license,
even if the rest of the text layout engine is covered by something
different. This in order to promote their re-use in other projects
(Pango comes naturally to mind). That might be interested by OTL
parsing _now_, instead of waiting for the complete text layout
functionality, which will certainly take a lot more time :-)

More details next week with the roadmap, I have the feeling that
this thread is going to generate lots of traffic, and I want to
dedicate my time to docs for now..

Cheers,

- David

PS: Do you mind if I send a copy of this message to the devel list ??


> Leonard
> --
> ----------------------------------------------------------------------------
> Leonard Rosenthol                       <mailto:address@hidden>
> Sr. Software Engineer                   (215) 922-3509 (voice)
> Digital Applications                    (215) 440-0504 (fax)
> 
> PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397