- From: <jrmt@almas.co.jp>
- Date: Fri, 18 Dec 2015 11:31:51 +0900
- To: "'Greg Eck'" <greck@postone.net>, <public-i18n-mongolian@w3.org>
- Message-ID: <000701d1393c$4139e7f0$c3adb7d0$@almas.co.jp>
Hi Greg, > 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. It is just a remind from mine. 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/ =============================================================== From: Greg Eck [mailto:greck@postone.net] Sent: Thursday, December 17, 2015 1:45 PM To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org Subject: RE: Final Wrapup Hi Jirimutu, My responses are below in yellow highlight. Greg >>>>> > 4.) Regarding the U+1828_NA – I don’t know how many are using a toggle design to turn the NA dotting off and on. > We had a problem of available FVS’s at the medial location. If we say that the design is actually a toggle, > it takes care of the space problem as we no longer need the FVS4 for the default over-ride. Our team strongly suggest use the over-ride logic. The toggle logic will make things tricky when we process string manipulation. It will lost the real meaning in substring. We should omit the “Toggle Logic” from the entire standard if exist. It will make a lot of troubles when we do string manipulation. There are several parties who use a toggle on the U+1828 medial – therefore we cannot leave out the possibility in consideration a specification in the medial. In the same way, there are others, Almas included, who do not use a toggle in the U+1828 medial. So, we need to accommodate for both. It appears to me then that we still need the U+1828-Medial default over-ride. I suggest the following: Such a specification will have to necessarily differ from the Chinese Standard, as most likely, the Chinese based font developers will all use the toggle. > Everyone, please let me know if this is an acceptable specification. > If not, then we may need to add the medial default over-ride with either VS01 or a new FVS4. It is better to add one more FVS4. It is better to exclude VS** from normal Mongolian text. There are two known and identifiable cases now where an extra FVS mechanism is needed. I would not be surprised to see the new Chinese Standard calling for another FVS also. I think it may be time to propose an FVS4 also. The two cases referenced then are U+1887-FifthFinal as well as this one here U+1828-FifthMedial. >6.) We found one mistake in the specification during our Hohot Discussions – that of the U+1887 Second Isolate. >This form is actually a final and requires a new VS assignment – >either VS01 or FVS4. For now, I have changed it to the Final+FVS4 in the DS01 document. >Should we propose another FVS4 or use the VS01? Either one brings a good amount of work with it. >But, we might be safer in staying with the FVS set and propose FVS4. > We are already looking at other situations needing the FVS4 (U+182D_Medial, possibly U+1828_Medial). What does everyone think? It is better to add one more FVS4. It is better to exclude VS** from normal Mongolian text. Yes U180A_NIRUGU Siqin already write to you our comment. If we define small tail for NIRUGU as my advice before, it is better to define with FVS1 The default NIRIGU final have other usage. I am waiting on a response from Hohot on this one. U1836_YA Second Medial Form (Context-driven AND also needed to over-ride default context) We are pending this till we communicate with our users. For the context driven logic if it is only restricted on ‘before U1822_I‘, maybe it is acceptable to our users. At least we have confirmed and clearly defined the default form of the U1836_YA Medial form and can process normally before other vowel. And also we have confirmed there no Diphthongs spell with U1836_YA in final. I would like to discuss this with our major users in the year end. 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. Personally, our team’s preference sequence for this character solution is 1) No context driven logic, use the explicit FVS1. – best solution 2) Use Over-Ride third form needed, use FVS2 to over-ride to the default. – maybe acceptable, depend on users 3) Use “Toggle Logic” – use FVS1 to over-ride the default – It is harmful design. I have nothing more to say here as I have not had time to do further testing 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? U1840_LHA Final Form It is better to select the form with small tail like current NP. I think it is better to follow the Chinese Standard here and have changed the NP accordingly back to how it was at the beginning of our discussions. While it would appear that a tail would match the pattern of other letters in the same block, I personally have not done the research necessary to strongly substantiate it. I am therefore withdrawing my earlier support for the tail on U+1840, U+1841, U+1842. U1841_ZHI Final Form It is better to select the form with small tail like current NP. As above. Jirimutu >>>>>
Attachments
- image/png attachment: image003.png
- image/png attachment: image004.png
- image/png attachment: image005.png
- image/png attachment: image006.png
Received on Friday, 18 December 2015 02:32:43 UTC