From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Mar 23 2006 - 10:31:59 CST
From: "Richard Wordingham" <richard.wordingham@ntlworld.com>
> Some of us would like to be able to change individual characters. At
> present it's reminiscent of the ancient editing situation where you had to
> change a line at a time when editing on a teletype. It is frustrating to
> have to delete a cluster of 3 or 4 characters just to change the base
> character. (I can think of a 6 character cluster - 4 visible, 2 invisible -
> in Khmer off the top of my head.) Admittedly changing a character in the
> middle of a cluster can be very difficult, but at least one can correct the
> base character quite easily in a Graphite font.
I don't know what you designate by the "base character", because in Indic scripts it happens quite often that this base character (around which diacritics and other letters are visually composed) is encoded in the middle of the cluster, or that the first encoded character will appear in the middle of the string of glyphs that compose a cluster.
For Unicode, the base character is not that one, it's only the start of a combining sequence, and we all know that a combining sequence is less than an Indic cluster (notably when there are multiple consonnants separated by halant so that some of them are dead consonants, or when there are ZWNJ and ZWJ at end of a consonnant cluster).
There may still be special cases for consonnants coded with nuktas but that have their specific (language sensitive?) plain glyph form, and if they can also have alternative half-forms in the start of a consonant cluster, but here I am still not sure when a ZWNJ or ZWJ could be coded. The case of Marathi for the Devanagari script is an example of such locale-sensitive glyphs that woul merit OpenType feature.
But I still don't know any locale-sensitive conjunct that has special reordering or composition rules (The encoded Marathi letters in the Devanagari block for example don't have final dandas, so the half-form and repha problem does not apply to them and they apparently don't need complex reordering rules, but there may be cases where subjoined forms may occur and should be controled, complexifying the regexps that the font reordering algorithm uses to match the cluster patterns and then select their corresponding string of glyph ids.)
My opinion is that a font has to match a style that first works according to a single locale, and that locale variations are defining a new, separate style, which should be supported in another font, or in a composite OTC font with alternate names to match those styles. In that case, no specific "feature" must be selectedor enabled by the application, it just selects the font by name according to the expected style.
So this will work in the simplest applications such as Notepad, that does not allow the user to specify the language used, or the set of features to enable or disable, or even in browsers that often can't determine the set of features to enable or disable to render some part of the text according to its locale. And with such system it will work also in CSS style rules of web documents that attempt to select fonts according to the value of some element attributes that tag the document. This is for example the simplest way to use a font that implements full-pointed rendering style and a transparent style, for a full-pointed Hebrew or Arabic text: just select another font by name, and you're done.
This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 10:34:16 CST