Re: [Devel] Regarding the layout table formats & FreeType 2

[Antoine Leca]

Salut,

David Turner va escriure:

> II. API Comments:
>
> * the API is still _clearly_ alpha/beta, since positionning support
>    isn't there yet and will clearly require changes to public
>    structures like FTL_GlyphRec to add positioning information; or
>    maybe a second glyph record type like in FT1 ?
>
>    I'm also unsure that the current API matches the requirement of a
>    project like Pango, even in the case of substitution (I'm mainly
>    thinking about the issue of logical clusters and re-ordering),

There is something that strikes me.
At the moment, the API is build around two concepts, on one side the
FTL_FeaturesRequest, and on the other the FTL_GlyphsArray. They are
completely independant. At a given moment, only one FTL_FeaturesRequest in
active in the font. So the only active function (SubstituteGlyphs) operates
on some FTL_GlyphsArray, using the active FTL_FeaturesRequest.

>From your comment about GX (I do not know GX), this seems to fit perfectly
GX behaviour, even at a rather macroscopic level (many glyphs at a time).

However, I do not see this being very effective for OpenType, at least in
the context of complex script rendering. With OpenType, we need to restrict
the features to specific glyphs in the whole string (e.g, 'init' only on the
right-connected ones). This is clearly shown in Werner's fundamental
ftstrtto.c, where one can apply a feature to the whole string, but he had to
encode glyph per glyph the requested features to render Arabic correctly.

Should we split the input string into as much FTL_GlyphsArray as there are
glyphs? I am afraid about performances..., and also the needed bookkeeping
for avoid memory leaks (keep in mind that a typical Indic scripts needs 12
consecutive features to be applied. Of these, about 6 are glyph specific,
'rphf', 'blwf', 'half', 'pstf', 'vatu', and 'haln').

Otherwise, we may apply the features to a selected range of glyphs (like
painting).
This might be an additional API, much like Werner's one.

Look at another example: let's have some string with some feature applied
string-wise (saying, 'liga', ligatures). Then, how can we retrieve a glyph
knowing its initial index? This would be needed to place the caret (unless
you are willing to call twice SubstituteGlyphs each and every time you move
the caret, once for all characters before, once for all characters after...)


Antoine