Re: MVS Deficiency & Proposed Solution

Hi Greg,

I'm very glad that you managed to find a solution to the problem using
OpenType, as encoding new characters and invalidating existing data
should be a solution of last resort (which may be the case with
NNBSP).

When the Mongolian block introduction to the Unicode Standard is
updated, the section on MVS should be updated to discuss this
situation, and include BAG-MVS-ACHUD as an example.

Andrew



On 21 September 2016 at 15:47, Greg Eck <greck@postone.net> wrote:
> Hi Andrew,
>
> After today's testing, I find that you are exactly right. The MVS will be
> "hidden" when not in use. With some modifications to our OT rules, we find
> that the example BAG-MVS-A continues to shape fine and that with the plural
> suffix added BAG-MVS-ACHUD also shapes fine (and with no space – as
> desired). So, thank you for pushing us to look into the matter more. As far
> as we can see now, the extra code points will not be necessary and we can
> handle this case for all suffixes following the MVS_A/E with just two new OT
> rules.
>
> This is our solution so far ...
>
> Let the current OT rulings for STEM + MVS + A/E stand as they are. It is
> important to understand that this will be considered the default shaping
> behavior.
>
> Modified behavior to handle a suffix after the Tsatslag_A/E can be effected
> by the following two rules ...
> 1.) Change the Tsatslag A/E to the default medial A/E
>         uni1820.init -> uni1820.medi  in the context of  MVS + uni1820.init
> + any_glyph_starting_a_suffix_which_can_be_appended_to_the_tsatslag_A
>         uni1821.init -> uni1821.medi  in the context of  MVS + uni1821.init
> + any_glyph_starting_a_suffix_which_can_be_appended_to_the_tsatslag_E
>         NOTE: The lone tsatslag is tagged as an isolate by the rendering
> engines; however as soon as another letter is appended to the tsatslag, it
> is tagged as an initial and is no longer tsatslag in form but initial.
>         NOTE: We need help in defining the glyph pool "
> any_glyph_starting_a_suffix_which_can_be_appended_to_the_tsatslag_A/E";
> Comments are very welcome here.
> 2.)  Change the final forms of
> U+1828/U+182E/U+182F/U+182C/U+182D/U+1835/U+1836/U+1837/U+1838 preceding the
> MVS to the default medial forms
>         uni18xx.fina -> uni18xx.medi in the context of    uni18xx.fina + MVS
> + uni1820.medi +
> any_glyph_starting_a_suffix_which_can_be_appended_to_the_tsatslag_A
>         uni18xx.fina -> uni18xx.medi in the context of    uni18xx.fina + MVS
> + uni1821.medi +
> any_glyph_starting_a_suffix_which_can_be_appended_to_the_tsatslag_E
>         NOTE: The previously_isolate_tsatslag_then_turned_initial_A/E has by
> this time been changed to a medial by rule#1 above.
>         NOTE: The MVS will be happily and invisibly sitting in the middle of
> the string, ready to do its tsatslag-marking life job again if all suffixing
> following the A/E is removed.
>
> If the post-MVS_A/E suffix string is removed, then the default shaping
> behavior mentioned above should return.
>
> Comments and corrections are welcome,
> Greg
>
>
>
>>>>>>
> From: Andrew West [mailto:andrewcwest@gmail.com]
> Sent: Tuesday, September 20, 2016 11:45 PM
> To: Greg Eck <greck@postone.net>
> Cc: Jargal Badagarov <bjargal@mail.ru>; public-i18n-mongolian@w3.org
> Subject: Re: MVS Deficiency & Proposed Solution
>
> Hi Greg,
>
> This is certainly a worrying situation which needs to be fixed, but I am not
> convinced that the answer is to deprecate the MVS and encode two new
> characters.
>
> You state that "The problem is that the MVS carries its space internally by
> its definition. Therefore all through the above process, the MVS space was
> there."  In fact, by definition MVS is a format character (general category
> = Cf) not a space character (general category = Zs), so it does not have an
> inherent space.  Andrew Glass will know the answer better than me, but I do
> not see any reason in principle why the OpenType feature cannot be
> implemented in the font so that MVS only results in a space when followed by
> a/e alone, and behaves as if it were not there when followed by a/e +
> suffix.
>
> I believe that fixing the problem in the fonts will be a better, and far
> less disruptive solution, than encoding two new characters.
>
> Andrew
>>>>>>
>

Received on Wednesday, 21 September 2016 16:19:51 UTC