> Message du 02/08/10 10:21 > De : "Nicolas Delvaux" > A : > 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).