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
