From: Peter Constable (petercon@microsoft.com)
Date: Tue Feb 24 2004 - 12:13:55 EST
> From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
On Behalf
> Of Peter Kirk
> The option < ta, ZWJ, virama > is mentioned in the document, but
> dismissed without proper argument although it would seem to me that
this
> is a far more logical encoding than < ta, virama, ZWJ >. After all,
the
> character in question can easily be understood as a ligature of ta and
> virama, but certainly not as ta followed by a ligature of virama with
> the following character.
I had indeed thought of < ta, ZWJ, virama > because of the fact that the
khanda ta is kind of like a ligature of ta and virama. But the generic
use of ZWJ for requesting more-ligated forms is *not* applicable to
Indic scripts. (If it were, < C, virama, C > should produce a half form
and < C, virama, ZWJ, C > should be required to generate the conjuct
form.) It would *not* lead to more reliable implementations and better
usability to mix usages of ZWJ like this unless absolutely necessary.
> While I can understand the objection that this
> "involve[s] innovations into the general Indic encoding model", there
> does come a time when such innovations are preferable to kludges of
the
> existing model.
Using < ta, virama, ZWJ > for khanda ta is hardly a kludge. While khanda
ta does not have behaviours typical of a half form wrt clustering (and
so is probably best not referred to as a "half form"), it *is* referred
to as such by some, including some Bengalis. The Indic model specifies
the use of < C, virama, C > normally and < C, virama, ZWJ, C > and < C,
virama, ZWNJ, C > for explicit overrides, and this is precisely what is
being proposed here.
> Another alternative which should be considered is use of a variation
> selector.
None of the stakeholders on this issue has suggested that option, and I
suspect would reject it outright. There is no need to introduce a
variation selector; it would constitute yet another innovation in the
Indic model and would only lead to more confusion.
While the notion that a different presentation form for what is in some
sense the same thing does provide some motivation for the suggestion,
the Indic model already has mechanisms for dealing with this in the
context of Indic scripts. In this context, then, this would be a far
greater kludge than a minor deviation from prototypical behaviour of ZWJ
wrt clustering.
I was aware of these other possibilities; I left them out of the
discussion for a reason: they would only serve to make the document
longer with no real benefit.
Peter
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
This archive was generated by hypermail 2.1.5 : Tue Feb 24 2004 - 13:05:24 EST