RE: Final Wrapup

Hi Jirimutu,

Thank you for the good write-up on the Y/W situation.
I will be doing some font development in mid-January and hope to have some comments at that time.
As of now, I have nothing more to say until I can do some testing.

Greg

Sent: Friday, December 18, 2015 10:32 AM
Subject: RE: Final Wrapup

> U1838_WA Second Medial (context-driven )
> Need to clarify the context-driven logic, “before consonant ?” or others.
> But if we use context driven logic to support this variant form, we need over-ride form here.
> It is not a good idea to use toggle logic. It will make a lot of trouble when we do string manipulation as mentioned above.
> I do not see a problem with the current specification here. Can you be specific in why we need to deal with the individual font developer’s logic?
Maybe your question here is asking the U1838_WA Second Medial Form over-ride situation.
I had provide you U1936_YA medial form’s example in last mail. It is valuable to read in details to understand the toggle-logic design bug.

Let me provide the U1838_WA Second Medial Form over-ride requirement here, if we design it as context driven. (We advise explicit specify FVS1 for this form)
This character is regularly used in foreign name spelling. For example.
avl tree - ᠠᠸᠯ ᠮᠣᠳᠤ
avma key - ᠠᠸᠮᠠ ᠲᠦᠯᠬᠢᠭᠦᠷ
awd car - ᠠᠸᠳ᠋ ᠲᠡᠷᠭᠡ
sowld  - ᠰᠣᠸᠯᠳ᠋
Lawrence - ᠯᠠᠸᠷᠧᠮᠰᠧ  or  ᠯᠤᠷᠧᠨᠰᠧ
…
etc.

By the way, did you carefully considered the “Toggle-Logic” design on the Variant Form Selector should be accepted by UTC ?
What is the Variant Selector ? “Combining characters; in conjunction with the preceding character these indicate a predetermined choice of variant” in Unicode explanation.
It means we should predetermine the choice of Variant. It should be uniquely defined what variant selector used for which variant form.
The standard should not include uncertainty case on the Variant Selector ? is not it ?

If so what actually is the “Toggle-logic” based variant selection definition ?.
It only define the individually printed from exactly for example,
U1836_YA First Medial Form <U1836_YA> [https://r12a.github.io/scripts/mongolian/v/1836i.png]
U1836_YA Second Medial Form <U1836_YA><U180B> [https://r12a.github.io/scripts/mongolian/v/1836m.png]

When they are used in the word we can handle them with the context driven logic to select which of them.
If <U1836_YA> default code is used before <U1822_I>, it will select [https://r12a.github.io/scripts/mongolian/v/1836m.png] , otherwise select [https://r12a.github.io/scripts/mongolian/v/1836i.png] as the display form.

But after we explicitly provide Variant Selector, we should not remain any other additional context driven necessity.

But the “Toggle-Logic” based standard will remain continuously.
If <U1836_YA><U180B> second form selector code is  used before <U1822_I>, it will select [https://r12a.github.io/scripts/mongolian/v/1836m.png] , otherwise select [https://r12a.github.io/scripts/mongolian/v/1836i.png] as the display form.

If So, when we want to exactly define one display form, how to use the selector ? do we need another additional Variant Selector ?
Like <U1836_YA><U180B><U180B> [https://r12a.github.io/scripts/mongolian/v/1836i.png]   ( unbelievable )
(we do not need  two Variant Selector to exactly determine one variant selector)

We have to exactly define the display form if there are one Variant Form Selector used.
It is the Unicode Standard basic principle itself. As my understanding. Anyone different opinion on this ?

If so the “Toggle-logic” based standard is asking us to additional information to decide the Variant Form even after we provided Variant Selector.
It is the mistaken design method for standard.

It is better to consider completely on this before showing to UTC experts.
I can predict that it will be rejected by UTC if they clearly understand the real meaning.
Because it is contradicting to the Unicode Standard Principle I think.

Jirimutu