Re: NNBSP Impact

Hi Greg Eck,

It is better to add following suffixes in DS05, I think.

Dative-Locative Case
--------------------------------------------------------------------
<U+202F><U+1832><U+1820><U+182C><U+1822>
<U+202F><U+1832><U+1821><U+182C><U+1822>

<U+202F><U+1833><U+1824><U+1828><U+1822>
<U+202F><U+1833><U+1826><U+1828><U+1822>
<U+202F><U+1832><U+1824><U+1828><U+1822>
<U+202F><U+1832><U+1826><U+1828><U+1822>

Others(?)
--------------------------------------------------------------------
<U+202F><U+1833><U+1820><U+182D>
<U+202F><U+1833><U+1821><U+182D>
<U+202F><U+1833><U+1820>
<U+202F><U+1833><U+1821>

<U+202F><U+1824><U+1824>
<U+202F><U+1826><U+1826>

Thanks and Best Regards,
siqinbilige.

On 2015/07/08 22:30, Greg Eck wrote:
>
> I have included an initial response to Mr. Jirumutu’s paper entitled 
> _NNBSP_Model_discussion.pdf_.
>
> Comments are welcome.
>
> Also attached:
>
> DS00 – Standard Mongolian NNBSP Model (as updated)
>
> DS05 - detailing all known suffixes with NNBSP impact (updated as 
> requested by Mr. Jirimutu)
>
> Greg
>
> *From:* jrmt@almas.co.jp [mailto:jrmt@almas.co.jp]
> *Sent:* Tuesday, July 7, 2015 8:25 PM
> *To:* Greg Eck; public-i18n-mongolian@w3.org
> *Cc:* 'Behdad Esfahbod'
> *Subject:* RE: NNBSP-MVS Impact
>
> Hi Greg Eck,
>
> Thank you very much for your clarification.
>
> I understand your explanation for NNBSP status.
>
> I think there is three direction to select.
>
> 1.Add some supplementary definition to NNBSP to fit the Mongolian 
> Encoding requirement. (maybe it is impossible because of the other 
> languages)
>
> 2.Replace NNBSP usage in Mongolian with other Mongolian Block 
> character, as I mentioned for example U+180F
>
> 3.Bear the restriction of the NNBSP usage and consider to use NNBSP in 
> Mongolian encoding.
>
> (We need to persuade each application one by one to fit Mongolian 
> requirements just like Dr. Quejingzhabu had done with Microsoft)
>
> Anyone have good idea or solution to resolve the issue ?
>
> Anyway we need to continue to discuss the model to solve the Mongolian 
> Suffix Model either use NNBSP or other character.
>
> Let me send out my NNBSP Model Discussion paper to all members. In the 
> discussion paper, I have included the NNBSP replacement proposals as well.
>
> If you do not agree it, just please ignore it and skip into following 
> discussion contents.
>
> I am also updated the MVS Model discussion paper and included Greg’s 
> response as well as my comments in it.
>
> Please let me know if anyone have any question about it.
>
> Thanks and Best Regards,
>
> /Jirimutu/
>
> /==========================================================/
>
> /Almas Inc./
>
> /101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo/
>
> /E-Mail: jrmt@almas.co.jp <mailto:jrmt@almas.co.jp> Mobile : 
> 090-6174-6115/
>
> /Phone : 03-5688-2081,   Fax : 03-5688-2082/
>
> /http://www.almas.co.jp/ http://www.compiere-japan.com//
>
> /==========================================================/
>
> *From:*Greg Eck [mailto:greck@postone.net]
> *Sent:* Tuesday, July 7, 2015 5:57 PM
> *To:* public-i18n-mongolian@w3.org <mailto:public-i18n-mongolian@w3.org>
> *Cc:* 'Behdad Esfahbod'
> *Subject:* RE: NNBSP-MVS Impact
>
> 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> 
> [mailto:jrmt@almas.co.jp]
> *Sent:* Monday, July 6, 2015 9:17 AM
> *To:* Greg Eck; public-i18n-mongolian@w3.org 
> <mailto: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: jrmt@almas.co.jp <mailto:jrmt@almas.co.jp> Mobile : 
> 090-6174-6115/
>
> /Phone : 03-5688-2081,   Fax : 03-5688-2082/
>
> /http://www.almas.co.jp/ 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 <mailto:jrmt@almas.co.jp>; 
> public-i18n-mongolian@w3.org <mailto: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> 
> [mailto:jrmt@almas.co.jp]
> *Sent:* Monday, July 6, 2015 12:04 AM
> *To:* Greg Eck; public-i18n-mongolian@w3.org 
> <mailto: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: jrmt@almas.co.jp <mailto:jrmt@almas.co.jp> Mobile : 
> 090-6174-6115/
>
> /Phone : 03-5688-2081,   Fax : 03-5688-2082/
>
> /http://www.almas.co.jp/ 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 <mailto: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
>