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

[Jan Bruns]

Werner LEMBERG:
>> Hm, I didn't get how aots is meant to be used,

> 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 thrid party
tool that probably doesn't do anything more than my operating
system's built-in tool called ttx.

>> The annotations are written against OpenType 1.4. Some of which
>> seem to have been adopted into OpenType 1.8, others cover topics
>> that a technical article optionally could mention (like "is it an
>> error if a font specifies an empty action list?"). Many more cover
>> Adobe internal language preferences (like the recommendation to
>> call every processing request a "program").

> Yes.  Adobe provides the document as-is; it is mainly intended as a
> guide to developers who are trying to parse or build OpenType data.

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

> Definitely not.

???

>> They obviously didn't have third party implementations in mind.  It
>> feels like they censored out clarification of open issues relevant
>> to anyone that might be concerned in the specs as soon as a topic
>> could become of some relevance to third party implementors.  May
>> this be intended or accidently, it just feels this way.

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

And in the "opentype.xml" annotions, I definetly see NO effort
to act as a supplementary specification.

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

The GSUB/GPOS tables describe (amongst others) contructs
called "lookup tables". Depending on if these constructs
appear in GPOS or GSUB, these construcs describe rules to
define positioning of glyphs (like kerning) or to text
processing (like the substitution of a glyph by some
other glyph), respectively.

Fed with a string of text (already represented in glphIDs
instead of unicodes), these constructs called lookup tables
use some pattern matching mechanism to identify wether or
not some fragment of text should become applied the specific
action associated with the construct.

How an application should generate the portions of text
strings to become subject to that construct's processing
is left unspecified. Asssume this will be something like
a word or paragraph based portioning.

A single such construct can process a complete string,
and if there are mutiple such constructs active in a font,
they'll typically be preocessed in a well defined order
one after the other, each fed with the preceeding one's
output.

Some of these constructs however specify the action
to apply in terms of recursive calls to other such
constructs. Despite the fact that such a recursive
call allows to define relatively complicated but
practically useful processing in a compact way, the
specs (as well as aots) do not decribe all the details
required to implement such recursive rule processing.

Given that the nature of these constructs is to
take a string of text to apply pattern matching based
actions, one could expect the Open Type specification
to define how to gernerate the input to subsequent,
inherently recursive construct calls, and how to
combine the output of such calls with the current
working items of a calling pattern match.

For example, it is totally left open if a single
subsequent construct instance called due to some
pattern match of some other construct should be
allowed to match+apply multiple times.

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.

For font designers however, this means they'll
either have to count on the target platform to implement
a specific, non Open Type specified behaviour, or not
make use of these powerful features already implemented
in some way or the other, almost anywhere.

An visual example for the last mentioned (not totally
sure if this is caused specificly by this reucrsion issue,
but definetly about spec-shortcomings):

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.

Gruss

Jan Bruns