From: John Hudson (firstname.lastname@example.org)
Date: Mon Aug 22 2005 - 16:35:30 CDT
Richard Wordingham wrote:
>> GSUB tables don't handle the reordering in Indic languages. It's the
>> responsibility of the OpenType Layout processor, e.g. Uniscribe.
> So how do I get it to live up to its 'responsibility' to support an
> Indic conlang living in the PUA? I'm not even sure that Burmese is
> supported yet.
> While it clearly looks like good practice to have a single per-script
> definition of necessary re-orderings, in practice it is very
> inconvenient if the user (or system administrator) cannot update the
> definitions. For example, Microsoft has little incentive to modify
> Uniscribe to treat independent Devanagari vowels as consonants (or, to
> be pedantic, consonant-vowel ligatures).
If you want something supported, you have to take it through the standards process and get
it approved as part of Unicode or another standard that the software company in question
is committed to supporting. If the behaviour you want to see for Devanagari becomes part
of Unicode's processing requirements for that script, then you can expect Microsoft to
A shaping engine has no 'responsibility' to support an Indic conlang living in the PUA,
because the shaping engine has no way of knowing that a string of PUA codepoints is text
in an Indic conlang.
The very nature of the PUA effectively makes it a dead end for most language processing,
unless you have a very simple script in which there is a one-to-one correspondence between
characters and glyphs and simple sequential, left-to-right display. Shaping engines simply
don't know what to do when you pass them a PUA codepoint, because it could be *anything*.
This is why using non-standard, PUA codepoints for any language processing is such a bad idea.
-- Tiro Typeworks www.tiro.com Vancouver, BC email@example.com Currently reading: Lords of the horizons, by Jason Goodwin Dining on stone, by Iain Sinclair
This archive was generated by hypermail 2.1.5 : Mon Aug 22 2005 - 16:36:39 CDT