Re: FT2 design question

[Werner LEMBERG]

> > To be clear, there will not be a text-rendering API available with
> > FreeType 2 when it is first released (I mean, something that can
> > convert "Office" into the glyphs for "O", "f", "fi", "ce" or "O",
> > "ffi", "c", "e" depending on the font's content).  The main reason
> > is that there are too many ways to provide this, and we want to
> > stick purely to font services for the high-level interface.
> 
> ok.  I can live with not having ligatures for the next few months :)
> Whether this functionality will be available through FreeType itself
> or through an extension library doesn't really matter for my own
> work, I simply want to find out what the correct way is to access
> this information.  I imagine some API where I feed in a sequence of
> characters and I get back a sequence of glyphs.  That should be
> basically all.

Yes and no.  There are always features which can't be handled
automatically.  For example, some OT fonts have a feature which
provides small caps.  If you activate it, you get small caps instead
of lowercase glyphs.  This feature is both script and language
dependent.

But you are right if you assume that you input a string of characters
and you get a string of glyph indices returned.

If you want to use OpenType features, use the TT_GSUB_Apply_String()
interface (or whatever it will be called after porting to FT2).

Take for example the font pala.ttf.  If you provide `Office' as an
argument to TT_GSUB_Apply_String() with no features activated, you
will get back a string with the glyphs `O' `f' `f' `i' `c' `e'.  If
you specify the latin script, activating the `liga' feature, you will
get `O' `ffi' `c' `e':

You can test this with:

  ftstrtto -s latn -f liga 60 pala Office

A font which doesn't provide the ffi ligature but only, say, fi and fl
will then return `O' `f' `fi' `c' `e'.  Whether a font has `ffi' or
not is not predictable!  Only a complete analysis of the OT tables in
the font can provide this information.

To get a correct rendering of `shelfful' if the `liga' feature is
activated, the user must insert e.g. U+200C, Unicode's zero width
non-joining character between the two `f's (if you use Unicode as the
input encoding), and the client application has to break the input
string into `shelf' and `ful' if it finds U+200C in the input stream,
feeding TT_GSUB_Apply_String() with these two substrings.  Or you use
a lookup dictionary of words which provides this information or...
Alternatively, the client application doesn't break the input string
into substrings but enables the features on a per-character basis: in
the example of `shelfful', all glyphs get the `liga' property assigned
except the first `f'.

Note that it is not possible in general to assume that the OT tables
in the font can handle non-typographic characters properly.  For
example, pala.ttf has no glyph for U+200C, returning the `unkwown
glyph'.  cyberbit.ttf, on the other hand, has a glyph for U+200C which
looks like a vertical bar, but this isn't the expected behaviour
either.

> The tricky part (for text processing) is that this mapping is font
> (and therefore DrawingKit) dependent.  Not all DrawingKits provide
> the same fonts.  However, the logic in the scene graph which must
> provide the semantics of character editing, cursor positioning
> etc. can't depend on the glyph mappings.  To complicate things even
> further, the actual size of the glyphs depend on the DrawingKit as
> well, so how can we abstract from that if doing the layout of the
> text?

IMHO the layout of a text is always dependent on the particular font
you use.  I don't know exactly what your problem is.  Are you talking
about the situation where a font for printing is not the same used for
displaying on the screen, and you want to approximate the text layout,
i.e., having identical line and page breaks both on the screen and
paper?


    Werner