I see other = applications for this representation as a combination of an empty base letter plus a = vowel diacritic, and here again this is related to = collation.

According to the reference documents shown in the proposal, we can see that initial = vowels, when they are not marked using spacing vowels, will be replaced by base = consonants. Here again, we need a decomposition during collation to exhibit the effective = vowel, and match it with an approximant base consonant (like alef, yod, = het=E2=80=A6) and this will be useful when looking for matches with the Hebrew orArabic scripts = or transliterations of Samaritan in those = scripts.

If initial = vowels are ignored at the primary collation level when sorting, but are used in the = secondary level, I have the feeling that they should be treated like if they were = diacritics for the previous letter. This is possible only if the spacing vowels are = considered composed of a ignorable empty base letter, and a combining vowel = diacritic. Depending on the kind of application, the collation may make the empty base letter = fully ignorable, so that the spacing vowels after another grapheme cluster = with a base consonant, is considered as a single cluster sorted with this previous = base letter, but after all compositions using that previous base letter and a possible combining vowel; This will respect the boundaries between the = original clusters, particularly in the case of syllable initials in the middle of = a compound word.

One may argue = that this could be done as well with the encoding of spacing vowels as letter = modifiers only, but given the various usages in tailored collations, it seems that = the decomposition will be present in almost all cases, whether they sort = with the following consonant and are considered as diacritics of it during = collation, or they are considered as special forms of another implicit variable base = consonant depending on the vowel diacritic, or considered as diacritics of the = base letter before them.

So, it should be interesting to see exactly how Samaritans are sorting their dictionaries = when there are spacing initial vowels (I include here the case of the = interletter epenthetic yut, not centered above a base consonant but between two of = them, and that I consider as being also a case of a regular spacing vowel, like = the proposed initial vowels).

The = considerations in the proposal on the fact that letter modifiers have been used in other = scripts is irrelevant here, because it does not correlate directly to Samaritan. = And we have other options for handling the case of initial = vowels.

In fact, = whatever was done in Hebrew, it could have followed as well my analysis and would = have become much more logical if the tricky cases had been solved like this = (but I won=E2=80=99t reform the Hebrew script and its numerous caveats, which come from the = round-trip compatibility with legacy encodings).

For me, it is = much enough to see the existing encoding of the Khmer =E2=80=9Ccoeng=E2=80=9D sign = as a proof that what is proposed here is not a new thing in = Unicode.

It could have = been done as well for Khmer lunar date symbols (and in fact a base symbol was = encoded for it as a format control, but this was discouraged when the lunar date = symbols were finally encoded later without any decomposition, although this = could have been done to preserve the equivalences). But even if this was = discouraged, and no decomposition was explicitly made, khmer collation need to treat the = lunar date symbols as if they were composed when creating collation = keys=E2=80=A6 If Unicode had been logical, the lunar date symbols should have been given canonical decompositions (not excluded from compositions, so that the precomposed = symbols are the normal representation in most = cases).

What I am = suggesting here, is that nothing is new in such proposal of considering the initial = vowels and interletter epenthetic yut as being effectively composed with a base = letter modified by a regular combining diacritic. I admit that the case of = Khmer coeng is a bit different however, because it does not combine with a combining diacritic after it, but with a base letter after it. But the important = thing here is that the combination is still creating a larger unbreakable = default grapheme cluster, treated as such in collation too = !

My concept here = is different from the use of (N)NBSP with a vowel, which will remain only = as a way to exhibit isolated vowel diacritics without any semantic meaning. We = know that this form is a trick just needed for rendering, but it does not create a = new word, and the (N)NBSP have the incorrect properties which cause various complications.

What I really = propose is to encode the empty base letter as a control format (like Khmer coeng), = that can be shown as spacing in isolation within text editors (using for = example an alef within a dotted square) before the effective combining vowel is = added, but the pair then combines graphically into a single spacing glyph (like = Khmer coeng) where the dotted square will = disappear.

Then we make the = proposed initial vowels as being canonically equivalent (with a canonical = decomposition NOT excluded from composition) to this base format = control.

Then, during = processes that ignore vowel diacritics, they will also ignore this format control, = so it will just remain the base letter (without any (N)NBSP in the middle), = or, depending on the application, the grapheme cluster made of this format = control and the initial vowel represented like this will be mappable to a base = consonant. This will be useful for correct collation of texts encoded with vowels = and texts encoded without vowels but were some of them have been converted = to consonants (as seen in the samples of the proposal).

For=C2=A0 = Samaritan linguists, that want the precision of vowels, they will be able to treat combining = vowels exactly like initial vowels, and will be able to sort them correctly, = using several collation schemes.

For renderers, = it will not be a complication (the fact that this empty base character is a = format control and not a regular letter does not change the things, as they = will manage it like all other base letters, and will place the diacritics = correctly on it, they will adjust accordingly the display width of the cluster, = and they will choose to map it to a visible special glyph for editors when it = appears in isolation, using the existing substitution = rules.

So my proposal = would be:

Most probably, encode the empty base before the base letters = (move them one position later) within the Samaritan block (so that it = sorts correctly at the codepoint level).
Name it something like =E2=80=9CSAMARITAN VOWEL HOLDER = MARK=E2=80=9D
Move the existing proposed letter modifiers in the chart = just after it but before the base consonants. Encode combining vowels after = the consonants.
Encode your currently proposed initial vowels (modifier = letters) as canonically equivalent to this base character plus the normal = combining vowel and don=E2=80=99t exclude them from = composition.
Possibly add a syllable initial epenthetic yut (as a = modifier letter too), and treat it like the other proposed initial = vowels.
Give to the Samaritan vowel holder mark a GENERAL CATEGORY = =E2=80=9CCf=E2=80=9D (format control) like the Khmer Coeng sign
In charts, show a special =E2=80=9Carbitrary=E2=80=9D = REPRESENTATIVE GLYPH (like for Khmer coeng) using for example a dotted square containing a = small Samaritan alef.
Give it the Samaritan SCRIPT PROPERTY (to avoid script = breaks)
Give it a null COMBINING CLASS (like other format controls); = the sequence made with it followed by a combining mark will not be = defective.
Give it a RTL direction property like letters (to avoid BiDi caveats and complications)
Give it a null COLLATION key for the first level in the = DUCET (let tailored collations decide if they need to map this holder mark = +combining vowel as another base consonant for compatibility with Hebrew, = unless there are arguments that such tailoring would be almost always = needed and another option should be chosen by default : ask to Samaritan users = about how they conventionally sort words with initial vowels, and how = they handle the case of middle initials and epenthetic yut between two = syllables)
Give it a null COLLATION key for a second level (or third = level but Samaritan is unicameral and so the second level in this case would = be all zeroes), unlike the combining vowels that will have their non null collation value for this level (and the same collation value for = the other proposed initial vowels)
For line-breaking, word-breaking and cluster boundary = properties, make it non breaking between it and a Samaritan letter (I think = that the current breaking algorithm already specifies this behaviour between = a format control and another letter), it will still break between it = and a whitespace or another explicit line break.

With the encoded precomposed initial vowels, it will still be easy to create a suitable = keyboard (AltGr + the key assigned to the combining vowel will generate the = precomposed initial vowel, OR the holder mark plus the normal vowel ; both sequences = will be treated as canonically equivalent). Some text editors will permit = decomposing it to remove the vowel but still keeping the base holder mark which will = become suddenly visible in absence of a suitable Samaritan combining diacritic, = but this visibility will not happen if there are other non-vowel combining diacritics for special cases in epigraphic texts. In browsers an = isolated base holder mark could be visible or invisible (rendered like a zero-width = non-breaking space)

Every Samaritan = combining diacritic will be suitable to combine with the holder mark, not just = combining vowels.

The holder mark = may have a zero width advance in some cases, when it appears as the initial of a syllable in the middle of the word where the previous syllable does not = have its own vowel diacritic.But by default, in renderers it will have a = default width from the size of the special glyph used when it appears in = isolation, and this width will be adjusted accordingly when it combines with other = diacritics and may become zero-width in some cases where the vowel mark can fit = centered on the middle of the gap between two base = letters.

Renderers will = be capable of rendering the encoded precombined initial vowels exactly the same way = (they will just start from a default width of the diacritic, and will reduce = it if necessary if the diacritic can be kerned within the gap between base letters. But = for Unicode encoding purpose, this does not imply anything about the fact that the character will be visible or not or zero-width or not. Conforming = renderers will not be required to show the arbitrary special glyph for the case = where it appears in isolation, thanks to the encoding as a control and not as a = letter.

De : hebrew-bounce@unicode.org = [mailto:hebrew-bounce@unicode.org] De la part de Philippe = Verdy
Envoy=C3=A9 : mardi = 7 ao=C3=BBt 2007 20:58
=C3=80 : 'Peter = Kirk'; 'Michael Everson'
Cc : = hebrew@unicode.org
Objet : [hebrew] Re: = Revised Preliminary proposal for Samaritan

Exactly ! = And I see other reasons why the approach with an empty base letter would be useful = too:

for collation: the spacing vowels should be ignored at the = primary level, like all other vowels.
For conversion from texts written with vowels to texts = written without them. In that case, the centered spacing epenthetic yut and leading vowels would disappear as well. The implicit empty base = letter would have a null collation, completely ignorable in all levels = (except the last implicit level comparing = codepoints);

De : hebrew-bounce@unicode.org = [mailto:hebrew-bounce@unicode.org] De la part de Peter = Kirk
Envoy=C3=A9 : jeudi = 2 ao=C3=BBt 2007 18:48
=C3=80 : Michael = Everson
Cc : = hebrew@unicode.org
Objet : [hebrew] Re: = Revised Preliminary proposal for Samaritan

On 02/08/2007 16:54, Peter Kirk wrote: =

...

The unsupported hypothesis I object to is:

We have seen that, typically, when more than one mark co-occurs with a = base consonant, one of them is centred above the base letter and the second takes its = place centred between the two letters.

Correction: the above is the incorrect observation from which the = unsupported hypothesis was derived. The unsupported hypothesis is that it is = possible to centre vowel marks and place marks like epenthetic yut above the spaces = between letters, and that the rewriting of miyya=CB=98sf=C3=A5=CB=86 riy is acceptable.

--

Peter =
Kirk

E-mail:  peter@qaya.org

Blog:    http://www.qaya.org/blog/

Website: http://www.qaya.org/<=
/font>