Comment 10 for bug 608631

> Message du 02/08/10 10:21
> De : "Nicolas Delvaux" <email address hidden>
> A : <email address hidden>
> Copie à :
> Objet : [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces
>
>
> Yes, fundamentally we may replace all [nbsp] by nnbsp.
>
> But currently nnbsp is not widely used or even known, it's not even on
> our translation guidelines (eg gnome-l10n-fr, lp-l10n-fr, ubuntu-l10n-
> fr...; even if these last 2 will surely change when this bug will be
> fixed).
>
> As said in the first post and by verdy_p, even if nnbsp support seems to be ok now, there might be some bugs with
some fonts or rendering engines.
> And as nnbsp support is quite new in modern browsers, we may need to fallback on [nbsp] for webapps (to support IE
6/7 or such horrible things).
>
> So I think that [nbsp] is still needed for compatibility purpose.

Why? applications that don't support NNBSP can replace them automatically when exporting from Launchpad. Translators
won't have any issue, as the datbase will internally store NNBSP in its history. And there will be no difficulty to
enter it (there's already a way to input NBSP in the editor so that it is preserved in the input form, to avoid the
browser bugs that replace them by standard spaces. So they will be clearly visible.

And applications that are using resources can also preprocess the returned texts before using them, if their
renderer cannot support this character. note also that browser shave made very significant progresses during the
last months, and because of security issues, almost all users are forced to update their browser as soon as
possible. Who uses now a deprecated browser version ? Browsers are integrating the support of NNBSP even if the
selected font does not support it (in fact this support is now part of its text renderer or text layout engine).

> About a "graphical" display, this is a good idea.
> But, unlike spaces or newlines, all keyboard layout do not have a mapping for nnbsp.
> So it may still be necessary to input nnbsp via [nbthin] in some cases.

Not needed. In the online editor of Lauchpad you'll see [nbthin], exactly like you currently see [nbsp]. You don't
need any special keyboard assignment for entering [nbsp], as this is part of the Javascript support integrated in
the Launchpad edit form.

If some users can type NNBSP directly with their custom keyboard layout, no problem: the editor will still dispaly
the colored [nbthin] indicator. same thing if they are copy-pasting texts in the editor.

And anyway in the exports, such characters would be represented in the .po file as \u2009.

Unfortunately, in the latest Microsoft fonts for Windows Seven, Microsoft decided to drop this character from its
best font for UI "Segoe UI" (despite it was present since now very long in Times New Roman, and Arial).

Why ? because the character is handled automatically in the OS'es builtin text renderers, and reuses automatically
the same glyph as "THINSP", treating it as unbreakable for layout purpose, because it is part of the layout engine.
Fontss DO NOT need to include such duplicate mapping for the same glyph as they can't manage themselves the
unbrealable properties (so even the mapping of NBSP is completely unneeded: the renderer will use the glyph and
metrics asigned to standard SPACE).

The same is true for the non-breaking hyphen or the soft-hyphen control (SHY), rendered using also the standard
ASCII minus-hyphen as a default fallback. This was discussed on the OpenType forum : it's not up to font designers
to handle these layout properties.

The Unicode Character database already states how these characters behave, through the decomposition type:

00A0 No-Break Space Zs CS 0 0020
0F0C Tibetan Mark Delimiter Tsheg Bstar Po L 0 0F0B
2007 Figure Space Zs WS 0 0020
2011 Non-Breaking Hyphen Pd ON 0 2010
202F Narrow No-Break Space Zs CS 0 0020

Note that these are the last fallback option, because the UCD CANNOT map a compatibility-decomposable character to
another compatibility decomposable character like:

2009 Thin Space Zs WS 0 0020

Font vendors then decided to NOT include these characters in their recommended layouts, as they urged the
developers of applications and font-renderers or text-layout engines to support these fallbacks directly. The
Unicode standard was also updated since long so that the non-line-breaking begavior was part of the Unicode standard
annex describing line-breakers (that non-breaking property was defined in Unicode long before the NNBSP character
was encoded). This means that all applications that don't render NNBSP correctly are NOT conforming to the Unicode
standard (this should never depend on a mapping of a glyph in an Unicode-mapped fonts).