Re: A last missing link for interoperable representation

Note that even if this NNBSP character is not mapped in a font, it should
be rendered correctly with all modern renderers (the mapping is necessary
only when a font design wants to tune its metrics, because its width varies
between 1/8 and 1/6 em (the narrow space is a bit narrower in traditional
English typography than in French, so typical English design set it at
about 1/8 em, typical French design set it at 1/6 em, and neutral fonts may
set it somewhere in the middle); the measure in em may however vary with
some fonts (notably those using "narrow" or "wide" letters by default
(because the font size in em indicates only its height) and in
decorated/cursive styles (e.g. fonts with swashes need a higher line gap,
the font design of the em size may be smaller than for modern simplified
styles for display).

But a renderer should have no problem using a default metric for all
whitespace characters, that actually don't need any glyph to be drawn:
All what is needed is metrics, everything else, inclusing character
properties like breaking are infered by the renderer independantly of the
font and other per-language tuning, or controled by styling effects applied
on top of the font

A renderer may expand the kerning/approach if needed for example to
generate "hollow" or "shadow" effects, or to generate synthetic weights,
including with "variable" fonts support, typically the renderer will base
the metrics of all missing/unmapped whitespaces from the metrics given to
the normal SPACE or NBSP which are typically both mapped to the same glyph;
NNBSP will be synthetized easily using half the advance width of SPACE, and
it's fine; renderers can also synthetize all other whitespaces for
ideographic usages, or will adapt the rendering if instructed to synthetize
a monospaced variant: here there's a choice for NNBSP to be rendered like
NBSP, typically for French as it is normally a bit wider, or as a
zero-width space like in English, or contextually for example zero-width
near punctuations or NBSP between letters/digits).

Fonts only specify defaults that alter the rendering produced by a
renderer, but a renderer is not required to use all infos and all glyphs in
a specific font, it has to adapt to the context and choose what is more
relevant and which kind of data it recognizeds and implements/uses at
runtime. The font just provides the best settings according to the font
designer, if all features are enabled, but most work is done by the
renderer (and fonts are completely unaware of tyhe actual encoding of
documents, fonts are only a database containing multiple features/settings,
all of them bneing optional and selectable individually).

If your fonts behave incorrectly on your system because it does not map any
glyph for NNBSP, don't blame the font or Unicode about this problem, blame
the renderer (or the application or OS using it, may be they are very
outdated and were not aware of these features, theyt are probably based on
old versions of Unicode when NNBSP was still not present even if it was
requested since very long at least for French and even English, before even
Unicode, and long before Mongolian was then encoded, only in Unicode and
not in any known supported legacy charset: Mongolian was specified by
borrowing the same NNBSP already designed for Latin, because the Mongolian
space had no known specific behavior: the encoded whitespaces in Unicode
are compeltely script-neutral, they are generic, and are even BiDi-neutral,
they are all usable with any script).
Received on Tue Jan 15 2019 - 06:31:00 CST