From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Oct 29 2003 - 12:26:27 CST
From: "John Hudson" <tiro@tiro.com>
> At 08:17 AM 10/29/2003, Peter Kirk wrote:
>
> >Normally meteg is positioned below and to the left of any other low
> >centred mark. Less frequently it is positioned to the right of a low
> >centred mark. But it is always to the left of a low right mark i.e. yetiv
> >or dehi. It can also be centred within a hataf vowel. In
> >http://www.qaya.org/academic/hebrew/Issues-Hebrew-Unicode.html section
3.4
> >I suggested using CGJ to encode right meteg. Jony Rosenne prefers a
> >separate right meteg character. The best solution for right meteg would
be
> >a single meteg with the same combining class as all low vowels and all
low
> >centred accents. But this would not solve the medial meteg issue.
>
> I'm happy with ZWJ for forming the medial meteg ligature (it pretty much
> has to be rendered as a ligature, as decomposing the hataf vowels and
> repositioning the two pieces on either side of the meteg is both very
> difficult and very inefficient). Although the medial meteg is most common
> in the WTS eBHS text, I content for the medial meteg not to be the default
> rendering and to require a ZJW: <consonant, hataf vowel, ZWJ, meteg>. The
> only live issue seems to be whether it is proper for ZWJ to be used
between
> marks: it works in my various test apps, but there seems to be some
question.
The problem I see here is that ZWJ is not intended to create ligatures
between diacritics, only between clusters that would otherwise still be a
single combining sequence.
Normally CGJ would have fitted better there, but this conflicts with the
intent to address the canonical combining order with CGJ.
In the sil.org proposal, the medial meteg is missing, but not the right and
left meteg, as they are encoded within the same class and their order is
preserved when attached to a vowel.
Logically, the hataf vowel is made of two parts: hataf and a second vowel,
and the medial meteg is put in the middle. There are two solutions:
- either encode <hataf, meteg, second part of the vowel> with the sil.org
proposed new biblical vowels, which all belong to the same class
- or add a medial meteg that combines and modifies the hataf vowel, and will
be normally coded after that vowel.
As the sil.org proposal also keep cantillation marks in the same combining
class 220 as vowels and meteg, the order will be significant, as the medial
meteg must combine with the hataf vowel, not with the cantillation mark.
This is not a problem because other cantillation marks that combine below
are not separated in two halves like hataf vowels. This means that no medial
meteg could occur within a cantillation mark and so only a normal meteg
could eventually occur; but this causes a rendering problem if this is not
normalized directly on input, as no NF form will not reorder them.
So the sil.org proposal PDF leaves open the choice of the combining class to
use for the new vowels and meteg that combine below, and they could be given
class 28 as well, allowing the new meteg to be reordered before cantillation
marks.
So I do think that the new vowels and meteg proposed by sil.org should not
be given the same class 220 as cantillation marks that should be reordered
after all vowels and meteg, and that a class 28 for them would be
preferable, unless there is some proof that vowels or meteg can follow
cantillation marks (meaning that there would be a second logical vowel group
on the same consonnant, and in that case we still have a problem because not
all cantillation marks share the same class 220).
Here again the sil.org proposal does not solve all, and there persists the
need to encode a ignorable control with class 0 to separate two vowel groups
applied to the same consonnant group (I all a "consonnant group" the Unicode
sequence made of: a single base consonnant letter, with a optional sin/shin
dot above right or left, and a optional dagesh/rafe/varika point inside or
centered above).
That's why the choice between 220 and 28 classes in the sil.org proposal is
not important.
This archive was generated by hypermail 2.1.5 : Thu Jan 18 2007 - 15:54:25 CST