Re: Call for NNBSP replacement character in Mongolian Block

Hi Greg and Andrew,
I totally agree with Andrew for all NNBSP issues. It is top priority 
urgent issue.
Name of "Mongolian Suffix Connector" is logically correct. For category, 
I would prefer to avoid the name of "space". Because, it causes 
confusions among developers. (engine, font, app developers).
For encoding, I also vote for U+181A.
I didn't undersood MVS issues. We had no problem with MVS since Unicode 
6.3. I will read back previous thread.

best regards,
Badral S.

On 22.09.2016 11:51, Andrew West wrote:
> Hi Greg,
> I have reached the same conclusion as you regarding NNBSP, and agree
> that there will always be problems with it because it has different
> contradictory functions for Mongolian and not-Mongolian, and it has a
> compatibility mapping to U+0020 SPACE which encourages applications to
> treat it as an ordinary space.  I therefore strongly support your
> proposal to encode a dedicated character in the Mongolian block.  I
> think that this should be made our top priority, and if nothing else
> is achieved at next week's WG2 meeting I hope we can get agreement on
> the replacement for NNBSP. If that is possible, then the proposal can
> be put to the November UTC meeting, and it may just be able to squeeze
> into Unicode 10.0 in July 2017.
> "I am calling for a new control character "Mongolian Suffix Connector"
> placed at U+181A "
> 1. Why not U+180F? That would be next to MVS, and in a contiguous
> range of five VS and format characters, which seems more logical that
> 181A.
> 2. I think the name Mongolian Suffix Connector is OK, and like that it
> denotes that it joins not separates.
> 3. In Unicode terminology it would be a format character not a control
> character, so in the proposal be careful to call it a format character
> to avoid confusion.  It could be defined as a space character (general
> category=Zs) as long as it has no compatibility decomposition to Space
> or any other character, but I prefer to define it as a format
> character (general category=Cf) as its job is to modify the shaping of
> adjacent characters.  The proposal should list all the required
> Unicode properties for the new character.
> I think that this change will not be as disruptive as (for example)
> the proposal to replace MVS with two new characters as fonts can
> continue to support NNBSP for compatibility with existing data as well
> as supporting the new character.  As NNBSP is ignored anyway in many
> contexts, including web searches, replacing it with a new format
> character (which will also probably be ignored for web searches),
> should mean that  functions such as web searches will not be adversely
> affected by the introduction of the new character.  In short, I think
> that the benefits of encoding a new character considerably outweigh
> the problems.  Moreover, fixing this issue once and for all will be a
> big step forwards towards getting Unicode Mongolian accepted by the
> user community.
> Andrew
> On 22 September 2016 at 03:01, Greg Eck <> wrote:
>> We have all be frustrated with the difficulty in working with the NNBSP in
>> Mongolian. After our discussions last year and the kindness of the UTC to
>> promote the changes to the NNBSP’s feature set, I felt that we would be able
>> to make the NNBSP fully usable. Over the last few months, however, given new
>> problems encountered with NNBSP usage, I am ready to concede that it really
>> needs to be placed within the Mongolian code-point space for reasons alluded
>> to in the article below. I am seeking everyone’s support for this move.
>> I want to express appreciation to the UTC for the considerable effort they
>> went through to effect changes in the definition of the NNBSP over the past
>> year. These changes will no doubt help in the interim as we look to the
>> possibility of a replacement to the NNBSP’s function in Mongolian usage.
>> We plan to make the following proposal at the WG2 meetings next week in San
>> Jose.
>> Comments are very welcome,
>> Greg
>> Call for New NNBSP character in Mongolian Block
>> Even with the changes that were effected in the NNBSP re-specification
>> (Unicode version 9.0), there are still deficiencies in proper functionality.
>> These deficiencies include the following:
>> ·        Display problem if Fallback Font includes its own version of the
>> NNBSP (U+202F). This problem occurs at the Application level.
>> ·        Certain applications such as PDF viewers will drop the NNBSP upon
>> cut & paste as well as other operations
>> As much as we fix the NNBSP in Mongolian to display correctly in different
>> situations, we continue to find more areas where it will fail. The most
>> recent finding over the summer was that given an application that is
>> displaying Mongolian text AND given a font selection that is not a proper
>> vertical Mongolian font AND given NNBSP+Suffix forms in the text AND given a
>> fall-back font that uses its own NNBSP, the display of the suffixal forms
>> will fail. The reason is that the fall-back font definition of the NNBSP
>> does not include the OT rulings to do proper and necessary substitutions
>> based on the NNBSP context.
>> There is considerable frustration in the Mongolian user community with the
>> ongoing problems we are having with this one control character. At the same
>> time, we see much momentum in the Mongolian community to adopt the Unicode
>> encoding if it will work correctly. This is significant as there are huge
>> swaths of Mongolian text using ASCII legacy era vertical Mongolian fonts. We
>> cannot miss this moment of opportunity to provide a simple solution to this
>> one biggest trouble of our Mongolian encoding – the NNBSP. It is felt that
>> once an NNBSP-replacement is encoded within the Mongolian block, both
>> rendering engines as well as fonts will be able to exercise adequate control
>> as to display suffixal forms correctly.
>> I am calling for a new control character “Mongolian Suffix Connector” placed
>> at U+181A to replace the current functionality of the NNBSP (U+202F) in
>> Mongolian contexts. Transitional fonts, of course, would have to implement
>> both the NNBSP as well as the replacement control character for backwards
>> compatibility. Keyboards could be changed to use the new control character
>> instead of the old NNBSP mechanism. Even if it took a considerable period of
>> time to cast the encoding, I think all parties dealing with Mongolian
>> vertical fonts will embrace this move.

Badral Sanlig, Software architect |
Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar

Received on Thursday, 22 September 2016 10:58:40 UTC