W3C home > Mailing lists > Public > public-i18n-mongolian@w3.org > July to September 2015

RE: New Thread - FVS Assignment MisMatch

From: <jrmt@almas.co.jp>
Date: Thu, 6 Aug 2015 20:41:47 +0900
To: "'Greg Eck'" <greck@postone.net>, <public-i18n-mongolian@w3.org>
Message-ID: <000001d0d03c$e0ef78f0$a2ce6ad0$@almas.co.jp>
Hi Greg,

 

> But we cannot and should not specify the sequences that are not specified.

> Maybe I am mis-understanding your statement, but we cannot do this. It is
overkill.

> Please correct me if I do not understand.

It seems the word "sequences" making misunderstanding, it not means the
sorting sequences.

What I am talking here is the Form Selection Sequence of the each Mongolian
character.  

Default form is first, FVS1 is the second, FVS2 is the third, FVS3 is the
fourth.

 

Our purpose is to define full and clear specification for Default, FVS1
form, FVS2, FVS3 forms of each character in Isolate, Initial, Medial, Final
word position.

What I mean here is, we should select the regular form studied in primary
school text book as the Default form, 

The other regular form in the primary text book comes to next and  we select
them as the FVS1 form. 

The other irregular form or abnormal form come to Next or Last, select them
in the lowest priority Variant Selector like as FVS2 or FVS3.

 

> Let's distinguish between specification lists and testing lists.

> Testing lists can be exhaustive and can also be informative in that they
might show forms 

> that our fonts are actually rendering at positions we were unaware of -
thereby providing us diagnostic information to fix errors. I am all in favor
of this.

> Specification lists should be non-ambiguous, trim, tight  and complete.
Specification lists should not be expected to contain items not specified.

 

I agree this.

 

> If we take one example from the font comparator site
(http://r12a.github.io/scripts/mongolian/variants ) and look at U+1820.

> We see that Isolate+FVS1 is specified.

> Isolate+FVS2 AND Isolate+FVS3 are not specified as they are "don't care
conditions".

> These two sequences are left to the judgment of the font designer to
handle.

> However, I am in general agreement with you that the common font
implementation will render 

> the Isolate+FVS2 as the Isolate_with_no_FVS_following. 

> The common font implementation will render the Isolate+FVS3 as the
Isolate_with_no_FVS_following. 

> But this is just because there is no OT ruling to substitute something for
the default Isolate form.

I have commented for it in another mail like this. 

I agree Richard's point of view on this.

"don't care conditions" should means same with original. 

If we left the Isolate+FVS2 AND, Isolate+FVS3 of U1820 to font designer to
decide the usage, There will be other new unstable elements appears in the
future.

 

>Could you help me understand Point #6 a bit better.

 

This is for printing the FVS1, FVS2, FVS3, MVS mark which is printed in
U1800.pdf Unicode Mongolian Chart in the Mongolian Text.

That is the dotted line bordered rectangle mark which include the code name
in the rectangle.

Sometimes we need to describe  how to use these symbols to users in
Mongolian text context.

 

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/

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

 

 

 

 

From: Greg Eck [mailto:greck@postone.net] 
Sent: Thursday, August 6, 2015 10:56 AM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Subject: RE: New Thread - FVS Assignment MisMatch

 

Jirimutu,

 

Sorry, I have been out of contact for several days.

 

Let's first deal just with the issue of specification of the FVS set.

 

What we want is full and clear specification, but we cannot have
over-specification on the other hand either.

 

Yes, we need to make clear every standard assignment of FVS1, FVS2, FVS3 to
the full code range U+1800 - U+18AA.

But we cannot and should not specify the sequences that are not specified.

Maybe I am mis-understanding your statement, but we cannot do this. It is
overkill.

Please correct me if I do not understand.

 

Let's distinguish between specification lists and testing lists.

Testing lists can be exhaustive and can also be informative in that they
might show forms that our fonts are actually rendering at positions we were
unaware of - thereby providing us diagnostic information to fix errors. I am
all in favor of this.

Specification lists should be non-ambiguous, trim, tight  and complete.
Specification lists should not be expected to contain items not specified.

 

If we take one example from the font comparator site
(http://r12a.github.io/scripts/mongolian/variants ) and look at U+1820.

We see that Isolate+FVS1 is specified.

Isolate+FVS2 AND Isolate+FVS3 are not specified as they are "don't care
conditions".

These two sequences are left to the judgment of the font designer to handle.

However, I am in general agreement with you that the common font
implementation will render the Isolate+FVS2 as the
Isolate_with_no_FVS_following. The common font implementation will render
the Isolate+FVS3 as the Isolate_with_no_FVS_following. But this is just
because there is no OT ruling to substitute something for the default
Isolate form.

 

Could you help me understand Point #6 a bit better.

 

Thanks,
Greg

 

 

 

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Sunday, August 2, 2015 11:56 PM
To: Greg Eck <greck@postone.net>; public-i18n-mongolian@w3.org
Subject: RE: New Thread - FVS Assignment MisMatch

 

Hi Greg,

 

Before discuss into the individual variant form U1820-U1842( or
U1820-U18AA),

I would like to ask if we have any basic principle for the FVS1-3 usage ?

If we can create one basic principle for the FVS1-3 usage firstly, 

I think it will be helpful to make the discussion more efficiently and more
smoothly.

And also make the encoding more readable to users.

If we have no basic principle, maybe we will get into endless argument on
some the linguistic argument point.

I think the discussion will become inefficient, we need to prevent the long
term and endless argument in our discussion.

I would like to confirm this with all members.

 

For example, following is my personal consideration. 

1. We select the most commonly used isolate, initial, medial, final form of
the character as the default Variant form (No need FVS1-3).

   The variant form listed on the primary school first year pupil's text
book comes first (is the default form).

   The default isolate form have to be same with the Unicode encoding chart.

 

2. To exactly specify the second regularly used variant form, we will use
FVS1. 

   The next regularly used form will come to second (FVS2) 

   the least regularly used variant form come to the last (FVS3).

   If there are 2 or 3 additional variant form, 

   we can select the one written before vowel form first(use FVS1), and
select the form written before consonant comes next(FVS2).

   Or we can select the masculine form first(FVS1) and select the feminine
form next(FVS2). 

   the least regularly used form will be selected as the last (FVS3).

   When it is possible to distinguish using the contextual condition like
masculine or feminine word condition in the text, 

   We will ignore the FVS in the text and we only add the FVS when it is
written in stand-alone environments. 

 

3. When we select the FVS1-3 for one character, the normal form comes first
and the abnormal forms come to next.

 

4. If one character use one of FVS1-3 to display its one variant form in
text (isolate, initial, medial, final), 

   it is displayed exactly same form when it is written in stand-alone
environments. 

 

5. If one character have only one variant form in the it's isolate, initial,
medial, final form, the character+FVS1-3 always display the default variant
form.

   If one character have two variant form in the it's isolate, initial,
medial, final form, 

   The first regularly used one is the default form and the second one use
FVS1. The character+FVS2-3 always display the default variant form.

   If one character have three variant form in the it's isolate, initial,
medial, final form, 

   The first regularly used one is the default form and the second one use
FVS1. The third one use FVS2, the character+FVS3 always display the default
variant form.

 

6. For display FVS1, FVS2, FVS3 mark, we use ZWJ+FVS1, FVS2, FVS3 (maybe we
can select both ZWJ/ZWNJ for this purpose). The MVS mark can be displayed in
same way.

 

Maybe my list is not proper or complete, but I think all of the proposal,
variant formatting rules and  all of the font implementation have their own
assuming principle exist.

Because of the previous existing Mongolian Variant formatting rule have not
clearly, uniquely defined the form selection. 

 

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/

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

 

 

 

From: Greg Eck [mailto:greck@postone.net] 
Sent: Monday, August 3, 2015 12:14 AM
To: public-i18n-mongolian@w3.org
Subject: New Thread - FVS Assignment MisMatch

 

We are winding down on the NNBSP discussion. 

 

Let's go ahead with another topic as attached dealing with 6 FVS
assignments. The basic issue is that the current specification says to make
the assignment at one position whereas the glyph is processed by OT rulings
at another position.

 

Greg
Received on Thursday, 6 August 2015 11:42:15 UTC

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