Re: GPOS support available!

[Werner LEMBERG]

> Maybe it's good to have a look at Microsofts' OpenType Services
> Library (not sure if it's even available, maybe they have some
> doco).  If it turns out their API is well designed and potentially
> useful, I'd say, copy it to the extent that's practical for
> FreeType.

I've intentionally *not* looked at their API to be really independent
and not biased towards a certain way to implement it.

> Obviously I haven't seen Microsofts' stuff, but I imagine a layout
> engine could work along these lines:
> 
> input:
>   - an array of character codes
>   - desired features/script/language
>   - initial x,y position
>   - point size/transformation
>   - ...?
> 
> output:
>   - an array of glyph indices
>   - an array of glyph positions

I'm doing it just like this -- nevertheless, there are still some
problems which I (resp. David :-) hope to remove in the transition
FT 1 -> FT 2:

My API is missing a well defined interface between the OT engine and
the core TT engine.  For GSUB support, this isn't necessary, but GPOS
is heavily intertwined with glyph outline data.  Currently,
TT_Load_Glyph() is used to access the glyphs, relying on the client
program to replace this with something more appropriate (e.g. using
cached data).  Additionally, I tried to design the GPOS output to be
device-independent which causes a rather strange implementation of
TTO_GPOS_Data -- IMHO, the client program must do too much to get the
final glyph positions (as demonstrated in ftstrtto).

> Such an API could be made to work with non-OT fonts also, and might
> then just be a convenient way to access kerning.

This is a good idea, but defining a well working interface is
non-trivial.  Any suggestions are highly welcome.


    Werner