- From: Badral S. <badral@bolorsoft.com>
- Date: Wed, 08 Jul 2015 06:30:15 +0200
- To: Greg Eck <greck@postone.net>, "jrmt@almas.co.jp" <jrmt@almas.co.jp>, "public-i18n-mongolian@w3.org" <public-i18n-mongolian@w3.org>
- Message-ID: <559CA757.6090906@bolorsoft.com>
Hi all,
MVS was classified temporally into space class between Unicode 5.0 and
Unicode 6.3. So, it's no problem anymore.
There is nothing against it to check previous character of MVS, if we
have no performance problems.
Badral
On 08.07.2015 06:07, Greg Eck wrote:
>
> I would add even U+1822-I to the list { O | U | OE | UE + MVS + A | E
> } as we have about 10 occurrences { I + MVS + A | E } in our database.
>
> The Unicode data on MVS seems to describe its relationship to spacing
> correctly …
>
> http://unicode.org/cldr/utility/character.jsp?a=180E
>
> It does appear that the JAVA methods need to be updated.
>
> Character.isSpaceChar() Yes
>
> Character.isWhitespace() Yes
>
> *Does anyone have a reference on who could help update JAVA method
> information on character U+180E?*
>
> Greg
>
> *From:*jrmt@almas.co.jp [mailto:jrmt@almas.co.jp]
> *Sent:* Wednesday, July 8, 2015 7:27 AM
> *To:* 'Badral S.'; public-i18n-mongolian@w3.org
> *Subject:* RE: NNBSP-MVS Impact
>
> Hi Badral,
>
> >Actually, the separated A|E is only used under N | G | H | M | L | Y | R | W in
> modern Mongolian, maybe additionally have { J + MVS A | E } for only
> one word.
>
> >but someone raises there are additional { S | SH + MVS A|E} in ancient
> Mongolian.
>
> In some case the { W + MVS A|E}, have to be handled as { O | U | OE |
> UE + MVS + A | E } according to some linguistic professionals.
>
> For example , LINGHU-A, CINU-A etc.
>
> 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:*jrmt@almas.co.jp <mailto:jrmt@almas.co.jp>
> [mailto:jrmt@almas.co.jp]
> *Sent:* Wednesday, July 8, 2015 7:53 AM
> *To:* 'Badral S.'; public-i18n-mongolian@w3.org
> <mailto:public-i18n-mongolian@w3.org>
> *Subject:* RE: NNBSP-MVS Impact
>
> Hi Badral,
>
> >This symbol is used only before *final variant* of U1820 (A) and U1821 (E)
> to illustrate ORKHITS. Is it necessary to consider any prefixes? NO.
>
> Actually, the separated A|E is only used under N | G | H | M | L | Y |
> R | W in modern Mongolian, maybe additionally have { J + MVS A | E }
> for only one word.
>
> but someone raises there are additional { S | SH + MVS A|E} in
> ancient Mongolian.
>
> In my personal opinion, I don’t want to see the appearance of other
> characters followed by MVS + A|E shows unreadable Mongolian.
>
> It will destroy the original Mongolian script’s harmony even if it is
> a wrong word.
>
> It seems an accident like the pen ink breaks suddenly.
>
> In my personal opinion, all of this irregular appearance of MVS should
> be filtered and , it should be same with the original forms.
>
> For example { I + M + T + MVS + A|E } = { I + M + T + A|E } .
>
> It is just my personal opinion. It seems most of Mongolian can bear it
> in their mind.
>
> >The only thing, we should consider for MVS is this character never be
> classified into space or bounder class! It should be in formatter,
> joiner or other in rendering systems.
> I agree this. But actually, the MVS is classified in Space now. I am
> not sure who is the proper person to raise this issue to correct it.
>
> For example, according to following URL
>
> http://www.fileformat.info/info/unicode/char/180E/index.htm
>
> The Java properties defines.
>
> Character.isSpaceChar() Yes
>
> Character.isWhitespace() Yes
>
> 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:*Badral S. [mailto:badral@bolorsoft.com]
> *Sent:* Wednesday, July 8, 2015 12:39 AM
> *To:* public-i18n-mongolian@w3.org <mailto:public-i18n-mongolian@w3.org>
> *Subject:* Re: NNBSP-MVS Impact
>
> Hi all,
> I don't understand, why MVS is so complicated to handle?
> This symbol is used only before *final variant* of U1820 (A) and U1821
> (E) to illustrate ORKHITS. Is it necessary to consider any prefixes?
> NO. It makes also no sense FVS1, FVS2, FVS3 after MVS because we don't
> have any variant of MVS. If FVS1-3 occured before MVS, these are only
> relevant to the previous letter of that characters. The only thing, we
> should consider for MVS is this character never be classified into
> space or bounder class! It should be in formatter, joiner or other in
> rendering systems.
> Please redirect me, if I am wrong.
>
> regards,
> Badral
>
> On 07.07.2015 14:24, jrmt@almas.co.jp <mailto:jrmt@almas.co.jp> wrote:
>
> 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
>
> --
> Badral Sanlig, Software architect
> www.bolorsoft.com <http://www.bolorsoft.com> |www.badral.net <http://www.badral.net>
> Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar
--
Badral Sanlig, Software architect
www.bolorsoft.com | www.badral.net
Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar
Received on Wednesday, 8 July 2015 04:30:52 UTC