Re: Representative glyphs for combining kannada signs

From: Philippe Verdy (
Date: Wed Mar 22 2006 - 14:14:24 CST

  • Next message: Peter Constable: "RE: Representative glyphs for combining kannada signs"

    > There are no "classic subst/posn" TrueType tables. Apple implemented an extension to TrueType known as TrueType GX, later updated to become AAT, and that added additional tables for substitution and reordering. Microsoft implemented an extension to TrueType known as TrueType Open, later updated to become OpenType, and that added additional tables for substitution and positioning. "Classic TrueType" does not have any mechanisms to support substitution, reordering or positioning.

    May be I didnot explain meclearly enough.

    I did not speak about the old legacy TrueType format where glyphs were accessible directly from 16-bit only codepoints, confused with glyph ids. I really spoke about OpenType whose most important standard addition if the substitution and positioning tables.

    To implement those tables, you don't necessarily need to have a stable set of rules, simplied in standard "feature" tables. Just common tables, out of any "feature", would do the trick, without requiring special interpretation according to the script or feature label in the opentype font, implemented in the text renderer.

    As long as there's a standard OpenType renderer, it would work even in absence ofspecific support for the script in the renderer: the renderer just has to use the subst/posn tables asthey are implemented in the font,and the renderer does not ned to infer more complete tables from a reduced set of rules encoded in a feature.

    A generic OpentType font renderer can then beused even for complex scripts that it even does not know, and for which no script-specific features are recognized and treated specially. Of course this means that this single feature in the font willnot be under control of the application. So the applicationfor example will not be able to control whever ligatures should be honored, or if language-specific rules or subsets of ligatures should be enabled, replaced, or removed, or if defective encoded sequences should bedisplayed with dotted circles for unassociated combining marks, or if control pictures should be used instead of controling the ligatures:

    For all these things you need script-specific features, but this is absolutely not a requirement to support at least one variant of the script within a font. My comment about the Saysettha OT font was that you implied it was a "typewriter-like" font, with poor positioning.

    But when I see how it renders the text, it supports much enough variants for the same characters to say that it is not a simple typewriter-like font producing text similar to the old "ASCII-art" tweaks to produce Latin letters with diacritics (as described in national ISO 646 variants, and abandonned since long in the French ISO 646 variant, but still remaining in other ISO 646 variants), with just simple superpositions of a single glyph per known character.

    The interest of a specific support for a script is that the text renderer can perform a preprossing on the text, such as decomposition, and normalised glyph order toreduce the number of combinations that a font needs to encode internally in its tables. This will be possible only if the font implements some wellknown subset of rendering rules,so that the other substitutions and reordering are handled internally by the renderer. However, the definition of positioning rules (in my opinion) is not the task of the renderer, but it highly depends on the dont design.

    When you say that Idon't knowwhat I'm speaking about, it'sjust that I don't use your terminology, or do not participate to OpenType standardisation group. I do not need it to use font design tools, or to use a text renderer, so I'm sorry if my words seem ambiguous to you. It istrue that my use of these technologies does not adhere any standard (and does not need to do it), but it has its own applications that work for the goals I have to reach.

    Because I am not a foundry, I don't have to support users of various systems, and I don't need interoperability with other unsupported unknown systems. I absolutely don't care if these applications donot work in other environments, because these parts of the softwares is not part of its interface that work with other systems (almost all what I do is in a private blackbox, so this type of code iseasily replacable or enhancable). And not all what I do is software ; in many cases it's just to find away to use existing solutionsto solve a problem (for example installation guides, configuration and tuning, or verification of the results produced by these product solutions.)

    This archive was generated by hypermail 2.1.5 : Wed Mar 22 2006 - 14:16:11 CST