Re: Call for NNBSP replacement character in Mongolian Block

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 <greck@postone.net> 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.
>
>>>>>

Received on Thursday, 22 September 2016 09:52:11 UTC