Proposal for *U+23FF SHOULDERED NARROW OPEN BOX?

AFAICS the iconic representation of U+202F NNBSP for use on keyboards and in keyboard documentation is not yet encoded. In the 2010-08-27[1] and 2012-09-07[2] proposals to encode symbols for use on on-screen keyboards and in documentation, *U+2432 was aimed for this symbol.

Actual usage probably relies on formatting, PUA, or icons; the latter epecially for on-screen keyboards as I imagine them, because local applications usually have icon libraries and thus must not rely on plain text only. Why mapping invisible characters to plain text symbols for local use should be any easier than mapping them to the already standardized icons, is out of reach of my understanding.

Now in the block of U+237D SHOULDERED OPEN BOX there is _one_ scalar value left. Would it then be a good idea to propose *U+23FF SHOULDERED NARROW OPEN BOX for v10.0.0?

[For the representative glyph, the question is about giving it the same width as that of U+237D by lengthening the shoulders, or reducing the overall width to the same extent as the width of the box. In the first case it might be called SHOULDERED NARROW OPEN BOX, in the second case rather NARROW SHOULDERED OPEN BOX. ISO/IEC 9995-7 standardized the first glyph.]

My personal opinion is quite in favor of a symbol to represent the narrow no-break space. By contrast, though I’m using part of the keyboard symbols, Iʼm not likely to utilize the whole mass of symbols (partly of little obvious use) introduced by ISO/IEC 9995-7:2009 and its 2012 amendment, because for most of them whether I canʼt see any reality behind, or I feel they are way too confusing for end-users, or they are better replaced with more concrete representations―e.g. a letter with hook instead of a symbol for hook applicator, as for dead keys I generally prefer real letters instead of isolated diacritics whatever they are represented with.

Let alone that we never can have usable keyboards with all those deadkeys on them, so that we have to rely on compose sequences, that can be documented in natural language and are far more mnemonic, e.g. ‘compose }’ for palatal hook; ‘compose {’ for retroflex hook; ‘compose ]’ for hook above; ‘compose [’ for a hook as on U+0187..U+0188. A model of practicity are Keyman keyboard layouts, that may use ASCII characters only, to enter whatever letters and diacritics.

So I believe that if the NNBSP symbol hadnʼt been buried in a bunch of other late ISO/IEC 9995-7 symbols, it would now be a part of Unicode.

BTW U+202F NNBSP had been encoded three years before the release of ISO/IEC 9995-7:2002.

Best regards,

Marcel

[1] http://www.unicode.org/L2/L2010/10351-n3897-jtc1sc35n1579.pdf

[2] http://www.unicode.org/L2/L2012/12302-wg1-%209995-7-n4317.pdf
Received on Sat Mar 12 2016 - 19:43:38 CST