From: Richard Wordingham (firstname.lastname@example.org)
Date: Fri Mar 24 2006 - 17:51:41 CST
Philippe Verdy wrote:
> From: "Antoine Leca" <Antoine10646@leca-marti.org>
>> I agree U+0D57 (as are its siblings xx55, xx56 or xx57 in the other
>> do have the same properties etc. as the vowel signs, so this use could be
>> possible without surgical operations on the UCD. But the current (5.0
>> database says... :
>> 0D57 MALAYALAM AU LENGTH MARK
>> * only a representation of the right half of 0D4C
>> And I am not sure this should be interpreted as you did.
>> In fact, I read the word "only" as implying... the complete contrary.
>> The French translation is not clearer:
>> 0D57 SIGNE DE LONGUEUR MALAYALAM AOU
>> * simplement la représentation de la moitié droite de 0D4C
> Unicode isclear in the Indic scripts description chapter.
> It may have happened that some used this au length mark isolately in texts
> that describe the orthography. But this still does not make it a true
> vowel sign; isolately, it acts more like a symbol and it has no meaning as
> a letter in actual language.
It isn't a 'letter'; it's a vowel! I think Antoine should submit a bug
report via http://www.unicode.org/reporting.html to get the (implied)
prohibition of a long length marked removed.
The au length mark is common in South Indian scripts. There are also some
weird interpretations of it - in Burmese it is taken to include the virama!
> However I wonder how one could render a REPHA under a half-form final
> consonant. My opinion is that ZWJ does not block that REPHA from being
> reorderered further, and that ZWJ is technically part of the consonnant
> cluster and not encoded after it: it can be used to block the formation of
> a ligature between a dead consonnant and another consonnant (if such
> ligature exists in the corresponding script) so that the dead consonnant
> remains in half-form. But I may be wrong and this also blocks REPHA from
> moving further to the right, for example on a consonnant encoded after ZWJ
> which adopts a full form given that there's still no full form consonnant
> before ZWJ.
> To block the REPHA from going further, onewould have to use ZWNJ instead,
> and so the REPHA will join with the lastdead consonnant before ZWNJ.
You got it right when you said in another post that ZWNJ causes there to be
two aksharas. To keep in contact with the reality that Unicode tries to
record, it is the lack of any form of joining that matters. At present the
role of ZWJ seems to be script dependent.
> Now you can apply locale-specific conjunct ligatures by pair, starting
> from by the last pair: each pair has a consonnant in half form, and
> another consonnant just after it in full-form (or in conjunct form if it
> is itself a ligature).
No! In Burmese, Khmer and Lao, it is generally the first consonant that
retains the full form and the second one that is reduced or greatly
distorted. I believe the same holds for many Indian scripts, but I am far
less familiar with them.
> I have still not detailed every thing there, but this kind of algorithm is
> the one that will work with all indic scripts (including Tibetan, and even
> with Thai except that with Thai no reordering of leading vowels or vowel
> parts is necessary as these parts are encoded in visual order for
> compatibility with TIS-620).
And (vaguely) phonetic order would not have worked with Thai. You might
think that this is due to Thai not using the 'Pali virama' (phinthu), but
that then has its own nasty problems when writing Pali in the Thai script.
I don't think there is a clean solution to rendering 'Cleanicode' consonant
+ virama + consonant + preposed-vowel. Which consonant the preposed vowel
appears before seems to depend on the syllable structure of Pali - or
perhaps the Thai perception of it! Thus with a nasal plus stop sequence the
preposed vowel will appear between them, but for /sw/ it will appear before
the cluster. In both cases, there is a phinthu below the first consonant,
at least in modern spelling.
What happened to Cleanicode? Has it gone underground?
This archive was generated by hypermail 2.1.5 : Fri Mar 24 2006 - 17:54:08 CST