Re: [ft-devel] what old/new FontVal says about these fonts

[Jan Bruns]

Werner LEMBERG:

>> The GSUB/GPOS tables describe (amongst others) contructs called
>> "lookup tables".  [...]
>
> GSUB and GPOS are a nice example of overengineering, originally
> targeting a very narrow set of capabilites.  Meanwhile, almost 20
> years later, we know better how to handle such issues, using a *much*
> larger number of scripts that have to be supported, but we are stuck
> with those tables and its support (which is often buggy and
> incomplete) in various applications.

I haven't heard about such complaints, yet.

Especially when taking into account these mechanisms aren't
really meant to do font-independent text processing that
might be associated with scripts.

> Recently, MS introduced `USE', the Universal Shaping Engine, which
> is a *huge* improvement compared to the previously used stuff.

>   https://www.microsoft.com/typography/OpenTypeDev/USE/intro.htm

> However, for backwards compatibility reasons, the old script-specific
> shaping engines must still be supported.

> Honestly, I'm very glad that I don't have to handle this mess

Me too.

>> Since this topic has now been open for so many years, giving a more
>> complete specifiation would mean to introduce new requirements on
>> existing implementations, of course something that the spec-editors
>> intend to avoid.

> I think this should become better with the next revision of OpenType.
> Peter Constable does a good job in improving the text IMHO, adding
> clarifications reported to him.  So *please* contact him if you still
> find problems in the specification!

But it's always difficult to decide wether things are intentionally
left open... it all looks a bit like it's just them that had this
giant idea of rendering text.

>> Very many fonts that have GSUB/GPOS built in are able to define
>> positions for unicode combining marks on a base glyph. These unicode
>> combining marks have some attachment type (iike "above/below base
>> glyph").  The font defined processing often even allows to correctly
>> position mutliple marks.  But this typically works if and only if
>> the incoming text string lists the combining marks sorted by
>> attachment type.

> Oh yes, proper support for combining marks is a special nightmare...

Ok, but the point was, that latin fonts seem to avoid to make
full use of all the gsub/gpos functionality. It shouldn't
be too commplicated to define gsub/gpos tables in a compact way,
that solves this little sorting issue.

Gruss

Jan Bruns