Re: MVS Deficiency & Proposed Solution

Hi Greg,


I think this depends on whether pre-MVS positions are considered medial or final. In words like er-e and em-e, the pre-MVS letters r and m take final forms. How do we get these final forms in your solution?


I would simply type bag-MVS-a with MVS but bagacud without MVS. There are several derivatives of bag-a and they all take the joined form as far as I know.


Weizhe


-----Original Messages-----
From: "Greg Eck" <greck@postone.net>
Sent Time: Sunday, September 11, 2016
To: "public-i18n-mongolian@w3.org" <public-i18n-mongolian@w3.org>
Cc:
Subject: MVS Deficiency & Proposed Solution


Dear all,
The San Jose Unicode meetings are just around the corner.
I wonder if we could discuss a few matters before-hand the meetings get under-way …
There is one deficiency that the MVS has always had. This is in the handling of a suffix directly connected to the orkhitz A/E such as the plural CHUD/UD. I have not seen any font that can handle this case correctly yet. Can we have some feedback on this situation?
I am attaching my current problem description and suggested solution.
Greg
>>>>>
Call for Two New Variants to Handle MVS Deficiency – Orkhitz_A & Orkhitz_E
There is an advanced shaping case in regard to the MVS (U+180E) which is not being handled correctly by any of the existent Mongolian vertical fonts yet. This is the case where you have a STEM + MVS + A/E + SUFFIX. Proper shaping behavior in this case is like this … Given the STEM + MVS + A/E string, there is no problem. The word will form in most fonts correctly showing the left-ward sweeping orkhitz. By definition of the Mongolian script, no letter attaches to the orkhitz in final position. If the orkhitz is followed directly by an “attaching suffix”, then the orkhitz A/E will transform back to its common A/E “shuud/single-tooth” medial form with no space in the shaping of the word. If the suffix following the orkhitz A/E is removed, then the space preceding the orkhitz A/E reappears.
 
Given the following word and suffix:
BAG-MVS-A – noun meaning “team”         CHUD – plural suffix
 
 
Proper shaping of BAG-MVS-A is
Proper shaping of BAG-MVS-A + CHUD(plural suffix)is
 
Current shaping of BAG-MVS-A + CHUD – plural suffix is  which is incorrect (current BAITI font rendering).
The reason that this is incorrect is that the MVS (between the BAG and the ACHUD) …
has a space built into it – therefore it cannot NOT be displayed
the early design of the MVS probably did not take this case into account
OT rulings have no method to hide a character; even if the font “hid” the MVS character, the font would have to “unhide” the MVS once the characters following the Orkhitz A/E are removed
Therefore, I am calling for a new solution which includes deprecating the MVS in future fonts. The new solution might look like this …
Add two new glyph variants to a given font – the orkhitz-A and the orkhitz-E. Instead of typing MVS+A or MVS+E to get the two orkhitzes shaped, the typist would type something like <shift><A> or <shift><E> to get the final orkhitz forms. This is in contrast to typing <A> to get the regular right-ward sweeping “suul/tail” (U+1820-Final) OR typing <E> to get the regular right-ward sweeping “suul/tail” (U+1821-Final).
The rendering machines would not need to be changed as the font would do the display correctly through internal OT contextual rulings. Ongoing processing of the MVS would continue -  however new fonts would not use the MVS anymore.
Internal glyphs could be something like
U1820final_orkhitz_with_space (ie. this is the default)
U1821final_orkhitz_with_space (ie. this is the default)
 
OT rulings would …
display U1820final_orkhitz_with_space given final position as determined by the rendering device (typist depressing <SHFT><A>)
display U1820medial_default (“shuud”) given medial position as determined by the rendering device (typist depressing <SHFT><A>)
 
display U1821final_orkhitz_with_space given final position as determined by the rendering device (typist depressing <SHFT><E>)
display U1821medial_default (“shuud”) given medial position as determined by the rendering device (typist depressing <SHFT><E>)
The direct Unicode encoding impact would be the addition of two variants
These two variants would differ from the two current orkhitz variants only in the addition of the leading space.
>>>>>
Are there other suffixes that would draw out the same deficiency as the CHUD/UD?
Greg