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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel