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

[Werner LEMBERG]

>> You say `make', and a TTF compiler and decompiler together with an
>> annotated documentation (in HTML format) gets built.  You need Java
>> and its development package (for `javac') for building and running
>> the compiler stuff; it should work out of the box.
> 
> Aehm, but I'm currently not interested in compiling a third party
> tool that probably doesn't do anything more than my operating
> system's built-in tool called ttx.

Basically, I'm not interested either, but this is the way to generate
the documentation.  Simply ignore the non-documentation stuff.  For
me, it's easier to read HTML displayed in a browser than raw XML...

>>> Intended audience is the spec editors and sometimes font
>>> designers.
> 
>> Definitely not.
> 
> ???

I mean that the audience are definitely not font designers; it is not
expected that they work on such a low level.

>> Uh, oh, please give an example that demonstrates your concerns.
> 
> Hmn.  The OpenType specs on their own become relatively silent, as
> soon as it comes to work out the difference from what is specified
> to a random, technically similar apparatus that would after all
> provide the same effective action.

This can be rather easily explained: There was the implementation
first, and then the documentation.  Obviously, it should be exactly
the opposite to get something consistent.  We are suffering since more
than 20 years from that problem.

> You're asking for an example of such a missing definition (delta to
> random other specification), so let me describe one such issue:

No, this is not what I asked for.  You talked about `censoring out
clarification', which I read as `intentionally not clarifying some
issues'.  I want an example for *this* bold claim.

> 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.  Your concerns are fully valid,
and some issues are still not correctly resolved, neither in the
specification nor in the various implementations.

HarfBuzz, for example, comes with a large corpus of tests, mainly to
compare the GSUB and GPOS results with the MS engine.  It contains a
lot of ugly hacks just to stay compatible with the MS behaviour.

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 within
FreeType :-)

> 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!

> 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...


    Werner