W3C home > Mailing lists > Public > public-i18n-mongolian@w3.org > January to March 2016

RE: New Proposal Status

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:07:50 UTC