- From: <jrmt@almas.co.jp>
- Date: Mon, 6 Jul 2015 01:03:57 +0900
- To: "'Greg Eck'" <greck@postone.net>, <public-i18n-mongolian@w3.org>
- Cc: "'Behdad Esfahbod'" <behdad.esfahbod@gmail.com>
- Message-ID: <000301d0b73c$337d8810$9a789830$@almas.co.jp>
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
Attachments
- application/pdf attachment: MVS_Model_discussion.pdf
Received on Sunday, 5 July 2015 16:04:26 UTC