- From: Badral S. <badral@bolorsoft.com>
- Date: Wed, 29 Jul 2015 15:29:29 +0200
- To: public-i18n-mongolian@w3.org
Hi Andrew, You are right. The problem lies in implementation of these products. But someone, who respects standards then refuse simply to reorder NNBSP, with response it's Unicode properties say that it is space or breaker. It may be the crucial factor, relevant to the standards. I am in favour of changing word boundary property of NNBSP. Indeed, it is best solution in my opinion. https://lists.w3.org/Archives/Public/public-i18n-mongolian/2015JulSep/0009.html But we had simply no power to perform that change. I tend to think, this resulted in this discussion. It was difficult to contact every software vendors to fix that problem. For instance, we had a problem with our spellchecker software. I already (2 years ago) reported it to libreoffice, openoffice communities and ICU (http://bugs.icu-project.org/trac/ticket/10212). But the problem exists until now. So, I suspected, that the words will not be truncated by NEW (suffix joiner) character, which could be introduced just in fonts (without contacting to any vendors). After reading following context, I would follow Andrew's suggestion that we try to influence to change the word breaking property of NNBSP. >... On the Unicode internal (Unicore) mailing list Asmus Freytag suggested that the word break property of NNBSP could be changed so that > by default there would be no word break when the character before and after it belonged to the same category (e.g. both letters, as is the > case for Mongolian). Making this change should solve the word boundary issue, as early as Unicode 9.0 next June if someone makes a > proposal to the UTC soon Badral On 29.07.2015 13:13, Andrew West wrote: > Hi Badral, > >> Any incorrect classified breaker characters (for us NNBSP, MVS- between >> unicode 5.0 and 6.3) corrupt GSUB rules of OTF for Mongolian. > I'm afraid that I don't see how the classification of NNBSP or MVS can > break the GSUB rules. Maybe it has an effect on whether the rendering > system (e.g. Uniscribe) applies the GSUB rules around the character, > but should not affect the GSUB rules themselves. And if the rendering > system is not applying OpenType shaping rules for Mongolian around > NNBSP or MVS then that is a bug in the implementation. > >> The suffixes >> have to be started by "medial" variant after NNBSP. This rule is already >> implemented in every Mongolian Fonts. But every suffix starts with "initial" >> variant, if NNBSP belongs to spaces or word boundary class ... The problem exists on >> Openoffice, Libreoffice, Google Chrome, Safari and Opera as my test. > That would be a bug in the implementation of these products. Of the > above software I only have Google Chrome installed, and that renders > NNBSP + suffix correctly, e.g. on this page > <http://en.wikipedia.org/wiki/Subei_Mongol_Autonomous_County> > NNBSP+yin is rendered with the medial form as expected. > > Andrew > -- Badral Sanlig, Software architect www.bolorsoft.com | www.badral.net Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar
Received on Wednesday, 29 July 2015 13:30:09 UTC