- From: <jrmt@almas.co.jp>
- Date: Wed, 13 Jan 2016 10:46:43 +0900
- To: "'Greg Eck'" <greck@postone.net>, <public-i18n-mongolian@w3.org>
- Message-ID: <000801d14da4$419871e0$c4c955a0$@almas.co.jp>
Hi Greg, I have returned back to my office now. I found some sentence is lost some words in my last mail which is written from my iPhone. Let me correct the mistaken sentence as bellow. Sorry about it. >For the purpose to define perfect standard, I do not care who is saying what, I just care what is correct and what is wrong or what is perfect and what is incomplete. >I will agree and support the correct and perfect, argue on the wrong and incomplete. >Hope all members can understand this kind of treatment of mine in this discussion forum. I can understand your consideration of rolling up the discussion in this stage and prepare our proposal to UTC quickly. I can understand our forum here is not the final round of the refinement of the Mongolian. I can predict there will be a lot kind of refinement proposal for Mongolian even post of Professor Quejingzhabu. But I have to write some argument here, because if the proposal has been accepted by the UTC with some issues, it will become more difficult to correct it in the future. It is better to include it in now if we already know the best solution. I have read Erdenechimeg's mail and strongly agree her opinion and solution for the issue. Let me copy her mail here again. 1. Regarding the discussion about the MVS, I strongly agree with Jirimutu that the treatment of MVS should be uniform, i.e. the logic should be the same whatever the preceding letter. Furthermore, Mongolians say that the letter immediately preceding the MVS is in final form. I therefore feel that it is wrong to define the forms of NA/QA/GA/YA/JA (NB I also include JA here) that precede MVS as middle forms - they should be final forms. (In the old proposal these forms were included twice, once as middle form and once as final form. This is definitely wrong! But the final forms should be kept and the middle forms removed, not the other way round.) I completely agree this. It is not the correct treatment to leave it as MGWBM or TR170. Even all of these document defined the character before MVS as medial. No one font developer is following this rule. All of the font developer is simply ignoring these character as my observation. If we do not provide clear logic in the standard level, it will be more hard to the new font developers. 2. Similarly, the form of the letter A that follows NNBSP is always said to be initial form. (More generally, all forms of all letters that have the "crown" element are considered to be initial forms.) So I think that what you have in the proposal as the third medial form of A should in fact be the second initial form. (Again in the old proposal this form was included twice, once as middle form and once as initial form, which is also definitely wrong. So in this case the initial form should be kept and the middle form removed, not the other way round.) I cannot understand why Professor Quejingzhabu insist this A before NNBSP as medial form. We strongly disagree this definition. If anybody insist this as medial form. I would like ask add one more medial form to all of the other characters which is possible to use before NNBSP !!! 3. One other point I'd like to raise: in several cases one of the variant forms of a letter has the same glyph as the base form in a given position (e.g. the first and fourth medial forms of the letter I), the identical variant form being presumably used to override the font rules and display the base form instead of any variant. I wonder if it might be better to generalise this, e.g. by introducing a variant selector which always selects the base form of a letter irrespective of what the actual letter is? This way it would be possible to get the base form in any context whatever variant the font rules actually produced. This is one perfect solution for over-riding default form selection after context-driven logic. We should propose new Base Variant Selector in Mongolian to handle all kind of over-riding phenomena. I have checked all of the FVS4 requirement is because of over-riding. We should define this new Variant Selector as - Base Form Selector (BVS) or Default Form Selector (DVS). I would like to ask you reconsider our proposal for FVS4. 4. I have searched the U180A_NIRUGU stuation in Professor Quejingzhabu's specification 9.0 in his new book. I have not found the definition of the NIRUGU with hook. Even his specification 9.0 included this definition, there is no reason to follow him and confuse all of other users using this as the other meaning. U180A U180B as the NIRUGU with hook solution is adding new definition, there will be no impaction to existing context and fonts But, U180A as the NIRUGU with hook and U180A U180B as the NIRUGU without hook solution is changing existing standard itself. Please remember we are refining existing standard now as you said before. We should select the less impaction one. Thanks and Best Regards, Jirimutu =============================================================== Almas Inc. 101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo E-Mail: <mailto:jrmt@almas.co.jp> jrmt@almas.co.jp Mobile : 090-6174-6115 Phone : 03-5688-2081, Fax : 03-5688-2082 <http://www.almas.co.jp/> http://www.almas.co.jp/ <http://www.compiere-japan.com/> http://www.compiere-japan.com/ <http://www.mongolfont.com/> http://www.mongolfont.com/ =============================================================== From: Greg Eck [mailto:greck@postone.net] Sent: Monday, January 11, 2016 12:20 AM To: public-i18n-mongolian@w3.org Subject: New Proposal Status I am attaching the two documents that will go to the UTC. Please let me know of typos as well as suggestions. I have included the new U+1829-Isolate as it seems well attested to. I will be submitting these documents to Deborah Anderson in the next few days for her review also, so if there are areas not covered or typos, please let me know quickly. I have looked over the FVS Mis-Match area again. Badral, Jirimutu, I have tried to give it one more square and objective look as you have suggested. There are 7 areas of concern (1820, 1828, 182C(2x), 182D, 1835, 1836). But as we looked over the entire issue in our past discussions we found 10 more areas similar in nature (1822(2x), 1824(3x), 1826(3x), 185E, 1873). If we continue research in the same vein, we will find more. The DS01 (and other similar documentation in the future hopefully) documents the specification and the actuality of implementation, so it should be clear to new font developers how to do the implementation. There is a definite disconnect in the seven situations mentioned above. However, we are going to create more problems by trying to change the past documentation than leaving things as they are and explaining how the disconnect came about historically. All font developers agree on how the 7 areas are actually handled within the font/rendering_machine interaction. All of our fonts are working fine in these seven areas. I suggest that we just let it be and go on. Remember that the specification does not tell us where to implement the glyph context-wise - it only tells us where to place the FVS. The designers at the time of writing the MGWBM and the TR170 Report made a decision to consider everything between the initial letter and the final letter (MVS/NNBSP sequences included) as medials. Implementation time came around and the writers of Uniscribe, Harfbuzz and other rendering engines found it better to implement initial/final contexts around the MVS and NNBSP. Each font developer found a work-around the mis-match. We all understand the situation today. Each side has its own argument. Each side has a good argument. But the time has come to put the past behind us and move ahead. Let's not change anything more than we have to that has been set in the past. Greg
Received on Wednesday, 13 January 2016 01:47:30 UTC