RE: FVS Assignment for A (was: New Thread - FVS Assignment MisMatch)

Hi Greg,

 

I have get one new book which is written by Professor Que during my business
trip in China.

In this book, he included his 9th version of the mapping rule. I have not
get enough time to look into details.

In this book he listed one section for HaWang font mapping rule separately.

 

I have scanned several pages of the 9th edition of the mapping rule and the
HaWang font mapping rule.

Because of the size, let me attaché the images in separate mails.

 

But my suggestion is that we should only have one standard of variant form
mapping rule. The standard rule apply to all font.

If there are different rule for different font. The standard will not be the
standard actually.

I think the Professor Que”s this approach is not the proper one for our
reference on this point.

 

The reason why I list it here is that if we can include some of the parts
which is most regularly used and possible to implement, 

Include tem  in the standard will be helpful. 

 

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/

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

Inner Mongolia Delehi Information Technology Co. Ltd.

010010 13th floor of Uilis Hotel, No 89 XinHua east street 

XinCheng District, Hohhot, Inner Mongolia

Mail:  jirimutu@delehi.com       Mobile:18647152148

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

 <http://www.delehi.com/> http://www.delehi.com/

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

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Saturday, August 8, 2015 1:35 PM
To: 'Greg Eck'; public-i18n-mongolian@w3.org
Subject: RE: FVS Assignment for A (was: New Thread - FVS Assignment
MisMatch)

 

Hi Greg,

 

> Item#1 – can you give a bit more detail on the HaWang font situation?

I did see the title list of Professors document list in Inner Mongolia.

As my memory, the name like “哈旺体变形显现字符转换规则” was included in
the list.

maybe I am missing some words in the name. 

I am going to China next week, let me try to collect related information
about it.

 

Anyway, it means that he have one forked version of the 9th edition of his
document, 

If it is exist and there are slightly difference with the original version.

 

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: Saturday, August 8, 2015 12:37 PM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Subject: RE: FVS Assignment for A (was: New Thread - FVS Assignment
MisMatch)

 

Item#1 – can you give a bit more detail on the HaWang font situation?

 

Item#3 – 

OK, we can add something.

NONE actually means “No specification”

The implication from that is that the preceding character is
unchanged/unaffected.

We can ask Richard Ishida to add this …

 

Greg

 

 

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

 

Hi Greg,

 

> Item#1 – new glyph needed

Ok. I can compromise on this. Just because we have met this problem on some
fonts.

 

We implemented it in our font. We can change to use Ligature for this
purpose.

I do know that Professor Quejinzhabu have second mapping rule for HaWang
Font actually. Did you know this ?

I have seen his document title in some article, and wandering why we need
second mapping rule ?

It is means,  the special font need special mapping. And what I am advising
here is to handle difference.

Anyway we can pass it, its impact is not big.

 

> Item#3 – Specification of NONE in Font Comparator columns 

I am not totally understand what kind of situation you had faced when
creating the 

first version of Mongolian Baiti based on the MenWenBianMa.

There is a lot kind of confusing things in that book.

When we refer his book we just refer which FVS is using for which form. 

But it is incomplete, For example, I have not find the feminine isolate GA
in in his book.

Sometimes I am thinking that this book have some lake the logical thinking.

If use mathematical permutation, and exclude the unnecessary part it will be
more complete on the structure.

 

> What about Jirimutu’s concern that the font developer is not instructed 

> what to do with mistakenly type <U+1820><FVS2/FVS3>? 

> Is it not clear in the chart, as Richard put it on August 6 

> “1) The 'NotUsed' entries are implicit.  You don't need to list them in
the specification.” 

> There is no mention of a FVS2 nor a FVS3, therefore the reader knows that
they are not specified. 

> Therefore if a user types <U+1820-Isolate><FVS2> it will only be the
default isolate A. 

> The FVS2/3 will result in nothing beyond the default 1820 form at that
given position. 

>  I hold my ground on putting NONE in the NP column where there is no
specification.

 

It seems my explanation not understandable enough.

It is Ok to put None in the unspecified column.

 

We just need one sentence instruction to how to handle the “none” defined
FVS in the Variant Form Note Documentation..

For example:  “None” means do nothing to the leading character and hide
the FVS.

 

I am concerning that the font acts like,  if  the FVS not defined, some will
display the FVS or

Some will delete leading character etc.  This will lead same text have
different display.

 

I am not sure I can explain it clearly or not.

 

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: Friday, August 7, 2015 10:32 PM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Subject: RE: FVS Assignment for A (was: New Thread - FVS Assignment
MisMatch)

 

Hi Jirimutu,

 

Item#1 – new glyph needed

 

It appears to me that this is a stylistic type of thing not demanding a new
glyph nor FVS assignment. What you want it would seem is a means to talk
about the orkhitz A/E while it is connected to a root/stem. Some styles will
handle this fine without the MVS such as the image I sent earlier from
Baiti. The font Jirimutu used designed the orkhitz with space at the top
evidently. Other fonts such as Baiti expect the MVS to provide the space.
Beyond that, and I am not being critical, this font has an attractive
appearance I think, the orkhitz glyph is not designed to join the stem –
there is nothing wrong with that – it is merely a design decision. You
could say that the solution is just to add the new glyph to the font
repertoire and substitute it for the default in the absence of an MVS. That
would probably work, but you would not meet the Quejingzhabu mandate #1
which says that all glyphs must be under control – you must be able to
print/control in a standalone environment. You could make the assignment of
a new FVS. But the question is whether all fonts would require this glyph.
Baiti does not. I imagine it would be a smaller subset which would require
that glyph. I would suggest in this case the use of a variation selector
such as VS01. 

 

 

Item#2 – noted

 

Item#3 – Specification of NONE in Font Comparator columns 

 

I am attaching my DS01 section on U+1820 to show how I attempt to take the
ambiguity out of the FVS specification. This is what I was vaguely referring
to in my note to Martin Heijdra saying that I had some ideas of how to
represent the white on black and black on white FVS images of the MGWBM.

 

Let’s say that the attached chart contains all information needed and see
if we can prove that wrong. Let’s see if it meets your concerns about
communicating how to handle the FVSs that are unassigned.

 

The U+1820 is a unique case in that we have 4 defaults as expected. Then
(given that M+FVS2 -> I+FVS1) we have FVS1 defined for each of the four
positions. And we do not have FVS2 or FVS3 defined at all.

I+FVS1 is used as a full-fledged emotive word expressing surprise.

In+FVS1 is used only after NNBSP as the beginning letter of the ablative
suffix. Therefore it is used in a given, predictable context as stated in
the chart.

M+FVS1 is used only without context as it is an archaic form.

F+FVS1 is used only in the context of the post MVS orkhitz. The chart as
attached states this usage

 

The first objective of the chart attached (as well as U1800.pdf) as I see it
– is to list all glyphs associated with the given code-point. Professor
Quejingzhabu has stated emphatically that he wants to be able to control the
appearance of any glyph associated with a given code-point. I agree
whole-heartedly. We need first of all to be able to list all 8
representative instances of the U+1820. We do that by simulating the
environment around the code-point with the ZWNJ, ZWJ, and the FVS set. There
is no need for the NNBSP nor the MVS here as I see it. I think Martin
Heijdra would be a big fan of this idea also – is that right Martin? There
is no need to use anything other than the ZWNJ, ZWJ, and the FVS set to
print a standalone glyph. So, given that, the first order of the day – to
be able to list, to print, to grab hold of each of the given glyph forms of
the code-point U+1820, we have achieved our objective.

 

Now, the second objective of the chart is to deal with running text. Does
the chart list whether the glyph is context-dependent or FVS-dependent or
both? The second item is a given. If it is specified to be listed in the
presence of an FVS, then it must work with that given FVS (ie.
<GivenCharacter><FVSx>). If a context is commonly used, then that should be
listed somehow also – not the specific context, but at least the fact that
the glyph is commonly shaped in the presence of a predictable context. Then
there is the third case where a given character will use both context and
FVS in running text (these are two different instances – not the same
instance) to control shaping behavior. Case in point is the Final GA U+182D.
Every font developer has no doubt grappled with this one. There is the
default form of the right swept masculine tail. Context of a feminine word
will cause the final tail to sweep to the left. However, to handle that
small set of words which defy the common context for the feminine final GA,
you need the FVS1 to sweep the left-ward tail back to the right; the
feminine word anomalously takes the masculine right-swept tail.

 

Looking at the Quejingzhabu documentation as described by Martin Heijdra, we
see something like this. The FVS is specified in three ways – as a standard
black letter on white image, black letters on white image enclosed in
parenthesis, and lastly white letters on black image. The first is the
standard control to allow a character to be printed in a stand-alone
context. The second with the parenthesis denotes a glyph used in a somehow
non-standard context – maybe a foreign word needs this glyph, possibly a
compound word, possibly an archaic word needs this form. The third
representation – white on black – represents a glyph which can take a
context. The first example found for the white on black in the MGWBM is our
character of choice in this discussion the <U+1820-Medial><FVS2>.  The
second example in the MGWBM is the <U+1828-Medial><FVS3> - this is the Todo
medial N. The third example is the pre-MVS U+182C final undotted QA. The
next four examples are all in the U+182D block. This is followed by the
U+1835-Final subject of our current discussion. The next is the U+1836-Final
also subject to our current discussion. The last example of white on black
in Professor Quejingzhabu’s documentation (in the 1820-1842 range) is the
U+1838-Final loop form – the subject of an upcoming discussion. So, let the
font developer beware when he/she sees the white on black in the MGWBM!

 

The attached chart presents the same information in a different form. The
Isolate variant is the standard case – no annotations as it has no context
– similar to case #1 in the Quejingzhabu nomenclature. The Initial variant
has a context and this is stated – not the specifics, just that it requires
a context – similar to case #3 in the Quejingzhabu nomenclature. The medial
variant is superscripted with a “&” to denote that it is to be used in
some special class – in this case an archaic word – similar to case #2 in
the Quejingzhabu nomenclature. The final variant states that it has a
context – similar to case #3 in the Quejingzhabu nomenclature

 

What about Jirimutu’s concern that the font developer is not instructed
what to do with mistakenly type <U+1820><FVS2/FVS3>? Is it not clear in the
chart, as Richard put it on August 6 “1) The 'NotUsed' entries are
implicit.  You don't need to list them in the specification.” There is no
mention of a FVS2 nor a FVS3, therefore the reader knows that they are not
specified. Therefore if a user types <U+1820-Isolate><FVS2> it will only be
the default isolate A. The FVS2/3 will result in nothing beyond the default
1820 form at that given position. 

 

I hold my ground on putting NONE in the NP column where there is no
specification.

 

Greg

 

 

 

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Friday, August 7, 2015 9:07 AM
To: Greg Eck <greck@postone.net>; public-i18n-mongolian@w3.org
Subject: FVS Assignment for A (was: New Thread - FVS Assignment MisMatch)

 

Hi Greg,

 

Here I continue my discussion around the  FVS assignment for U1820-A.

 

1.       I would like to amend one more glyph for f+FVS2. Please refer
following picture.

I saw you sugesstion image, it is not work on handwriting font. 

Please check the attached image which is zoomed to big enough to see
clearly.

 

2.     I can accept the I+FVS1 assignment, I do agree with Erdenchimeg’s
following comment.

 

> Re point 3, the glyph at I+FVS1 (and M+FVS2 in NSM font)  is only used
after NNBSP, i.e. 

> it is always the first letter of a word suffix/case. 

> Teachers of Mongolian script always refer to this as initial form, which
is the basis for the coding at I+FVS1. 

> However, in the Unicode standard the decision was made to code it as a
middle form (basically because 

> it appears in the middle of the word), which is why it appears at M+FVS2
in some fonts. 

 

> I think the M+FVS2 combination could be omitted, as is done in BS. 

 

The M+FVS2 form of U1820_A should be omitted. We implemented our font as
this.

Just because our  glyph rendering basic principle listed below, there are
one M+FVS2 displaying on the
<http://r12a.github.io/scripts/mongolian/variants>
http://r12a.github.io/scripts/mongolian/variants

 

If there are no different variant forms for FVS2 or FVS3, we implement it
same with the default form 

or it means ignore the FVS2 or FVS3. It is not proper to become blank.  

The none in NP should give definition how to handle it, otherwise each
implementation goes different direction.

 

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: Friday, August 7, 2015 2:17 AM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Subject: FW: New Thread - FVS Assignment MisMatch

 

Hi Jirimutu,

 

If we limit our comments to just the 6 FVS assignments, this is what I see
…

 

·         You are in agreement with my suggestions for the suggestions
being put before the UTC as outlined in my reponse to Erdenchimeg.

·         As to the new variant at U+1820/U+1821-Final swept left with no
space – would it be something like the attached? This is the sequence <
U+180A >< U+180A ><U+1820> with no MVS included. Would this not do?

·         You have further discussion on U+182D – let’s wait until we
find resolution on the 6 variant FVS assignments first.

·         You have further discussion on U+136 – let’s wait until we find
resolution on the 6 variant FVS assignments first.

 

Greg

 

 

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Monday, August 3, 2015 7:01 AM
To: Greg Eck <greck@postone.net>; public-i18n-mongolian@w3.org
Subject: RE: New Thread - FVS Assignment MisMatch

 

Hi Greg,

 

I have some inputs in the FVS assignment MisMatch documents.

 

Thanks and 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> mailto:greck@postone.net] 
Sent: Monday, August 3, 2015 12:14 AM
To:  <mailto:public-i18n-mongolian@w3.org> 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