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

[George Williams]

On Fri, 2004-03-26 at 13:08, David Turner wrote:
> > Sorry to ask you more contribution: I would like being able to figure it
> > myself, but my knowledge on GX is simply much too limited.
> > 
> > Can you imagine that every possibility of GX (in this area, i.e. as exposed
> > by this API) might be implemented on a subsequent OpenType font, decomposing
> > it into a series of actions dealing with OpenType features?
> > 
> 
> This is simply not possible. The gap between these two technologies is so
> large that they cannot be converted easily into one another, at least in
> a general way. Of course, that doesn't mean that a font editor shouldn't be
> able to generate both kind of tables from a single higher-level description.
I agree with David that there is a large gap between the two.

Apple's state machines can perform some operations that can never be
performed in OpenType (for example, and a conditional substitution
active on an arbitrarily long string is easy in a state machine and
impossible in opentype).

Similarly OpenType can express things that I don't think can be
expressed in a state machine (at least not easily). OpenType allows the
same substitution to be applied to the same glyph slot several times
(ie. a conditional substitution where two glyph slots are active can hit
any glyph twice).

Apple has the indic rearrangement table that OpenType assumes the word
processor will do without help.

I tried to write something higher level description that could handle
both and gave up (on the general case. For the common stuff it isn't
hard).

> > However, if the answer is no, well we are rushing ourselves into David's
> > option, having two separate APIs (which will certainly make no favour to GX
> > as a technology)
> > 
> I prefer that one, unless someone can give me another explanation on how the
> technologies work :-(
I tend to agree with David. The requirements on when to apply features
are wildly different. The abilities of the conditional features are
different.

The mechanisms for non-conditional kerning and simple substitution can
be translated from one format to the other without difficulty.

If one assumes that the ligatures inside apple's ligature state machines
are all unconditional, they they can also be translated without too much
difficulty.

But figuring out when to apply these features after converting from one
format to another...