Re: NNBSP Impact

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