From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Dec 20 2004 - 01:37:39 CST
> Well, yeah. That's the problem of the conflation in the first place.
> AFAIK, the WTS text does not yet make the distinction (I think someone
> still has to confirm all the cases). Such a text would be happily served
> by the option of *not* making the glyphs distinct, as mentioned, or by
> making the distinction in another way (longer stem for atnah hafukh, or
> V-shape). Changing the yerah-ben-yomo shape will, indeed, affect such
> texts; that's what I meant by "let the chips fall where they may."
So why not encoding Atnah Hafukh as a composite ? I mean making it a
modifier of Yerah Ben Yomo also encoded in the text?
Isolately an encoded Atnah Hafukh would have no meaning. Isolately Yerah Ben
Yomo isolately would keep its shape... The new encoded modifier would act
(for renderer) as if it was a variant selector, but aplied to a diacritic
(instead of base letters with classic variant selectors), and with a
semantic (unlike variant selectors).
Why are we constrained to give a code point only to isolated diacritics?
Alternatively, do we need this separate encoding? Can't it be replaced by a
double occurence of the existing diacritic, where the double codepoint would
create a ligature to make this distinction? Are there cases where a double
Atnah Hafukh or double Yerah-Ben-Yomo can apply to the same letter?
If yes, then we still have the solution of encoding a diacritic modifier, as
a combining letter too, with the same combining class as the existing
diacritic to facilitate the rendering and interpretation (and collation) of
strings in normalized forms. This diacritic modifier could as well be given
a minor collation weight level, or could be made completely ignorable for
texts mixing explicit and implicit encoding of the difference (which could
remain invisible if using fonts with no glyph difference, but would keep the
semantic difference present in some parts of the encoded text). The good
question is which of the two semantics would best be encoded with a
supplementary diacritic modifier...
This archive was generated by hypermail 2.1.5 : Mon Dec 20 2004 - 12:03:16 CST