RE: Final Wrapup

Hi Greg,

 

Thank you very much.

I can understand your mail thanks to you understanding. 

It is the Christmas and New year  season in  the world and let me say to all members, Merry Christmas and Happy new Year.

 

As my understanding, All of our discussing point here is not one simple thing and just simple technical  matters. 

There will be a lot of work around and compromise exists s well as several or a bunch of rigid people as Badral said to me 

(Sorry to Badral, please forgive me if my word is hurt to you, I am only struggling for our Mongolian to get one simple, understandable, and acceptable and uniquely defined standards as soon as possible.).

But I think all of the people is talking and discussing the things forward to the best and perfect direction.

Of cause there are  exist some people want to  use the standard to promote their existing theory or existing products.

But I think either of them all contributing to Mongolian Script and Culture’s future. 

Only one point we are concerning is that we will have to follow some of the incorrect direction after the standard be approved by one bunch of experts or professionals.

Even the main leader of the group have highly respected or  government representatives. 

We should confirm the result carefully and proven the  extra story in the standard and the technical fields. 

 

I am on the road to Hohhot now.  I will consult our discussion and DS01 report with my main users and client,  

as well as the teachers in the local school in the Inner Mongolia and he government representatives as well. 

 

I will prepare one detailed response from all of the side after mid-January as well.

 

Thanks and Best Regards,

 

Jirimutu

===============================================================

Almas Inc. 

101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo

E-Mail: jrmt@almas.co.jp <mailto:jrmt@almas.co.jp>    Mobile : 090-6174-6115

Phone : 03-5688-2081,   Fax : 03-5688-2082

http://www.almas.co.jp/   http://www.compiere-japan.com/

http://www.mongolfont.com/

---------------------------------------------------------------

Inner Mongolia Delehi Information Technology Co. Ltd.

010010 13th floor of Uiles Hotel, No 89 XinHua east street XinCheng District, Hohhot, Inner Mongolia

Mail:  jirimutu@delehi.com <mailto:jirimutu@delehi.com>        Mobile:18647152148

Phone:  +86-471-6661969,      Ofiice： +86-471-6661995

http://www.delehi.com/

===============================================================

 

From: Greg Eck [mailto:greck@postone.net] 
Sent: Tuesday, December 22, 2015 4:59 PM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Subject: 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>  

U1836_YA Second Medial Form <U1836_YA><U180B> 

 

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 , otherwise select 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 , otherwise select 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>   ( 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