RE: NNBSP-MVS Impact

Hi Greg,

 

Here I would like to provide Unicode property description of NNBSP.

 

NNBSP is included in Unicode white-space set according to following URL.

http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:White_Space=Yes
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5b:White_Space=Yes>
:]

 

What we need in Mongolian is non-whitespace categorized character to handle
the suffixes. 

Otherwise, all the suffixes will be separated from their main word in most
of the applications. 

 

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: Badral S. [mailto:badral@bolorsoft.com] 
Sent: Tuesday, July 7, 2015 11:31 PM
To: public-i18n-mongolian@w3.org
Subject: Re: NNBSP-MVS Impact

 

Hi Greg,
Can you deliver some stabilisation problems for other languages as mentioned
like Russian or French etc., because I didn't find something. Thus, I
described it as best method to redefine that symbol. Otherwise, I wrote
something contradictory.
If there exist stabilisation problems really, we need to forget NNBSP and we
have to define new NNBSP control character to replace it's role. In this
case I would also suggest 180F as Jirimutu mentioned. It should be named
also "Mongolian Suffix Joiner".
I tend to think, we don't need to contact so many vendors to release it. May
be Microsoft for Uniscribe, Harfbuzz for OSS world, SIL for ICU, Unicode for
recommendation purposes. AAT and Graphite fonts include rendering rules
itself. So, it's no problem for us font developers.

BTW: Bolorsoft font (MongolianScript) seems incorrect under
http://r12a.github.io/scripts/mongolian/variants.html
May be it's very old version. I will provide our latest version asap.

regards,
Badral


On 07.07.2015 10:56, Greg Eck wrote:

Mr. Jirimutu,

 

I am not the one to answer about redefining the NNBSP since it is defined by
the Unicode Consortium.  However, in reading the past posts from Badral and
others, it appears that redefinition would be problematic at this point as
it is tied to other languages such as French and Russian - stabilization
would be the issue. Can someone else answer this question as stated below?

 

I can represent Dr. Quejingzhabu in his request that upper-level layout
features in MS Word dealing with the NNBSP have been broken for some time. I
think we had a discussion on this at least two years back. His bug report
dealt with word-count across NNBSP-bounded suffixes, along with
CTL-RIGHT/CTL-LEFT word skipping across the same NNBSP-bounded suffixes.

 

Greg

 

Are there other problems that other some of you have found in dealing with
the current implementation of the NNBSP? Let's see if we can put together a
list of problems found in the current NNBSP implementation .

Spell-checking - Badral

Xxx - Mr. Jirimutu

Word-count - Prof. Quejingzhabu

Word-skip (CTL-RIGHT/LEFT) - Prof. Quejingzhabu

.

 

 

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Monday, July 6, 2015 9:17 AM
To: Greg Eck; public-i18n-mongolian@w3.org
Cc: 'Behdad Esfahbod'
Subject: RE: NNBSP-MVS Impact

 

Hi Greg Eck,

 

Thank you very much. I appreciate your attention.

I will prepare my discussion paper for NNBSP include our AAT implementation
logic.

We are discussing in our team how to propose for NNBSP. I will send our
discussion paper in one or two days.

 

As Mr. Badral's mail, the NNBSP is the big problem in the Mongolian
Encodings now. 

Before explain our solution of NNBSP on AAT, 

I would like to ask if is it possible to redefine the Suffix Joiner ?

 

If it is possible to redefine the Suffix Joiner, I would like to propose
U+180F to be the Mongolian Suffix Joiner.

That will be pretty on the code structure and simple on the handle.

 

If it is impossible to redefine, we have to use NNBSP, I would like to
participate into the discussion.

 

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, July 6, 2015 1:17 AM
To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org
Cc: 'Behdad Esfahbod'
Subject: RE: NNBSP-MVS Impact

 

Mr. Jirimutu,

Thank you for the explanation on AAT's handling of the character preceding
the MVS.

Please do let us know how the character preceding the NNBSP is handled also
- that will be very helpful.

Greg

 

 

From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] 
Sent: Monday, July 6, 2015 12:04 AM
To: Greg Eck; public-i18n-mongolian@w3.org
Cc: 'Behdad Esfahbod'
Subject: RE: NNBSP-MVS Impact

 

Hi Greg Eck,

 

I would like to send my some discussion about the MVS today. 

I will follow up the NNBSP soon if I have any comment.

 

>It would be nice to find out whether Apple rendering systems follow suit. 

>If anyone knows of an Apple engineer that we could ask, 

>I will follow up on the matter. Or if there are other rendering systems
>that we should consider, please bring them up.

 

We created the Apple AAT Font on our site and Apple handle this as an static
machine stream.

In the case all of the rules we defined working well on Mac OS X and iOS
system.

The MVS model processing on our AAT font is that 

the string <MONG_INITIAL><MONG_MEDIAL>< MONG_LETTER ><MVS><U+1820 | U+1821>
where MONG is the range U+1820 - U+18AA, 

Our font will tag the MONG_LETTER as <fina>  only if the <MONG_LETTER> is
one of <U+1828-n>, <U+182C-n>, <U+182D-g>,

<U+182E-m>, <U+182F-l>, <U+1830-s>, <U+1831-sh>, <U+1835-j>, <U+1836-y>,
<U+1837-r>, <U+1838-w> as well as 

<U+1823-o>, <U+1824-u>, <U+1825-oe>, <U+1826-ue>. Which Is the Mongolian MVS
requested characters. 

 

Note: Apple system site had one bug on the Mac OS X 10.8-10.10.2 and iOS
8.0-8.2

rdar://problem/18483089> REGRESSION: iOS8 did not able to correctly
rendering Mongolian vowel separator(180E)

this bug had been fixed on Mac OS X 10.10.3 and iOS 8.3 now.

 

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: Saturday, July 4, 2015 11:34 PM
To: public-i18n-mongolian@w3.org
Cc: Behdad Esfahbod
Subject: RE: NNBSP-MVS Impact

 

Behdad Esfahbod, as the Harfbuzz designer,  was kind enough to answer my
questions of how Harfbuzz handles the MVS/NNBSP context. He confirmed my
understanding that Harfbuzz follows the Microsoft Universal Shaping Engine
in the following . Thank you Behdad .

 

>>>>> 

Given the string <MONG_INITIAL><MONG_MEDIAL>< MONG_LETTER
><NNBSP><MONG_SUFFIX> where MONG is the range U+1820 - U+18AA, Harfbuzz
applies the <fina> tag applied to MONG_LETTER

The same processing holds for <MONG_INITIAL><MONG_MEDIAL>< MONG_LETTER
><MVS><U+1820 | U+1821>

>>>>> 

 

It would be nice to find out whether Apple rendering systems follow suit. If
anyone knows of an Apple engineer that we could ask, I will follow up on the
matter. Or if there are other rendering systems that we should consider,
please bring them up.

 

The DS00 charts have been updated. I am also attaching two files that have
been helpful to me in considering the range of usage of the MVS / NNBSP.
DS04 deals with MVS usage. DS05 deals with NNBSP usage.
Comments/corrections/questions are welcome.

 

Let's go on to consider six cases where the MVS/NNBSP affect the shaping
behavior of the character immediately preceeding/following the MVS/NNBSP -
U+1820, U+1828, U+182C, U+182D, U+1835, and U+1836.

 

Greg Eck

 






-- 
Badral Sanlig, Software architect
www.bolorsoft.com | www.badral.net
Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar

Received on Tuesday, 7 July 2015 23:38:55 UTC