How to render narrow non-breaking spaces in HTML for Windows?

Question

In French, typography requires that we use narrow non-breaking space (U+202F) at various places (“Comme ça !”).

Apparently every browser on windows fails to support that and they all display a weird character instead. This works on most browsers on Mac OS X as well as Linux.

Does anyone know how to make Windows browsers render it correctly?

(I’m assuming it’s a Windows bug rather than a browser bug since Firefox and Safari both support it as long as it’s not on Windows).

Vanmeter

Answer 1

Hmmm... no. If the only problem is the fact that   (U+2009) is still breaking, I will prefer to use:

<span style="white-space:nowrap">&thinsp;</span>

to correct the breaking behavior. Why?

• Because the French fine is effectively using a nearly fixed width between one sixth to one fourth of a cadratin (0.166 ca. to 0.25 ca., when the standard space is 0.5 ca.) The choice of the width depends on the approach already present within the glyphs defined in a given font.

• Fonts are made to adjust the width of their thin space (U+2009): if these fonts were made by French typographs (for rendering French), the approche (or gaps between letters in words) is narrower than in fonts designed for English: this is because French texts generally contain more letters than equivalent English texts (for exemple the printed Bible), and to avoid increasing the number of printed pages, the glyphs in French fonts were made a bit narrower and with a reduced approach; to compensate this reduction, the French fine was increased in size. (It is often said that U+2009 is one fifth of a cadratin, i.e. 0.2 ca., but this is wrong as this value is just a reasonnable median value, which should effectively be adjusted in fonts according to their design).

• In English with an English typography, the inter-character gaps is already large enough to justify the fact that a no thin space is used in texts near most double punctuation signs. However, if French is rendered with a font using an English typography (which has larger inter-character gaps), the fine should be narrower and should be reduced to 1/6th cadratin.

• So yes, U+2009 (  in the SGML repository) is slightly adjustable, depending on fonts.

• In addition it may be partically justified (when full justification is used, where not just the usual inter-word spaces have their width increased, but also all gaps between characters and normal or ''fine'' spaces (but the other quad spaces MUST NOT have their width adjusted: they are really fixed).

When you are rendering a document whose page layout is already precomputed (with known fonts and with exact metrics), the thin space (U+2009) is already what you want (because you won't have to worry about the breaking behavior.

Unfortunately, Unicode forgot to assign to these quad spaces U+2000..U+2006 (and to the thin space U+2009) the non-breaking behavior in the line-breaking properties.

The only way for Unicode to correct it (for plain text documents only), was to add another character, namely U+202F (the NARROW NON-BREAKING SPACE) in Unicode 5.1, which was later given the SGML symbolic name "nnbsp" for character references (but the mapping of this named character entity to U+202F is not part of any HTML or XML standard, so this named entity should not be used as well, unless your document defines it explicitly in its embedded DTD !)

But unfortunately, most browsers have forgotten to apply this addition and why it was needed: they assume that the character should be in fonts, but this is clearly not the case.

ALL browsers SHOULD treat U+202F as non-breaking (this is already the case, even if they don't know the character in their internal copy of the UCD).

However, browsers SHOULD NOT depend on the fact that U+202F is defined in a font, instead, they SHOULD provide a fallback to U+2009 (THIN SPACE) when rendering it, each time U+202F is not mapped in the current font, but U+2009 is mapped in the same font (this is generally the case with many fonts).

So this is a problem in HTML renderers (i.e. browsers); I also think that this is more than just a problem of fonts, it is really a BUG of browsers (rather than a bug or limit in fonts), if they don't provide such fallbacks for whitespaces. Of course, all new fonts should map U+202F to the same glyph as U+2009.

Given that the thin space (U+2009, or  ) is very well supported in many fonts, and has the correct width for rendering French texts with fonts made with French typographic metrics, or for rendering English texts made with English typographic metrics, this should really be the correct fallback to use each time the narrow non-breaking space is not available !

You can perfectly emulate the desired behavior of U+202F in HTML, by just using U+2009 and making it non-breaking using CSS's "white-space:nowrap". It will always be better than changing the font-size to display a pseudo half-space (because this is not correct with many fonts for which this will still be too large, and also because this does not work as expected in spans of text that have colored backgrounds: changing the font-size modifies the line-height).

So please use this code instead in your HTML or SVG documents (keep U+202F only for plain-text documents):

<span style="white-space:nowrap">&thinsp;</span>

You can save this sequence in a reusable template, that you can name Template:nnbsp in MediaWiki for example, for transcluding it in your pages as {{nnbsp}}.

Note that it is still preferable to reference the thin space symbolically as   rather than forcing an exact Unicode code point like   : the named entity can be remapped by the renderer, or according to user preferences to another working whitespace.

Note that MS-word really uses U+2009 and not U+202F for representing its own fine. It is correct, given that Word documents have a precomputed layout, and given that MS-Word enforces locally the non-breaking behavior when computing the page layout. Word documents are not plain-text documents.

• Exemple of rendering (using background colors to exhibit that the line-height is not modified, but unfortunately this site does not allow setting background colors except in <code> sections like here, which use monospace fonts) :

Exemple de « fine » insécable française correctement codée !

• The same without the <code> container does not display the background color, but it does use the normal proportional fonts, so that the thin space is effectively rendered as thin:

Exemple de « fine » insécable française ; correctement codée !

• Example using   (NNBSP which is generally not supported in most fonts, but this may eventually work with your current browser and the fonts installed on your system, such as DejaVu Sans):

Exemple de « fine » insécable française ; correctement codée !

• Example using   (SIXTH OF CADRATIN, may work but may be too narrow for your fonts, and may not exhibit the non-breaking property):

Exemple de « fine » insécable française ; correctement codée ! (hmmm... not really)

• Example using   (which is almost always too large):

Exemple de « fine » insécable française ; correctement codée ! (hmm... not really)

Brinn

Not only is your answer helpful (if a bit long), it also seems quite educated and well justified. Thanks for your help. It does make our life miserable in the business of localising web sites, since messages that used to be plain-text may now become markup and thus need to skip the escaping part. Do you have any idea then why both FireFox and Safari browsers, which do support   on both Linux and Max OS X, do not on Windows? Is it just that the Linux and Max OS X fonts have that symbol while Windows fonts do not? Which would not be a problem if the browser implemented the fall-back? – Vanmeter

Linux and Mac OSX versions are probably using a text rendering library (or OS service) that implement the fallback when the font does not have the character. The browsers then just use these API or libraries. Given that Windows does not implement this font fallback in its text rendering APIs (GDI, GDI+...) the browsers using it fails to display the character. I know that Firefox uses its own internal fallbacks for some characters, but many of those are quite poor. But I see no reason why a browser would not implement the fallbacks itself for whitespaces. – Brinn

Note that Safari does not display U+202F on Windows, but Google Chrome does display it (even of both browsers are using WebKit which should be using the same text rendering libraries): Chrome is then implementing the fallback outside of Webkit, or it uses a patched version of Webkit. – Brinn

Note that French uses non-breaking spaces, when presenting numbers: the normal <i>fine</i> is used as a separator for groups of digits. But, also in English, for aligning numbers in tables, the <i>figure space</i> is used to replace missing digits, and the <i>punctuation space</i> is used to replace the decimal separator (dot in English, but comma in French, which may be a bit larger, most probably like a <i>fine</i>. These two spaces are also non-breaking, but may still be enlarged in the case of full justification (of intercharacter gaps), like digits and dots. – Brinn

The figure space and dot space have no use in HTML, it's simpler to make them the correct width by using a zero digit or a dot/comma punctuation within a span with CSS's "display:hidden" or "color:transparent", and then to align the tables normally. These two spaces are then only for typographs (when handling documents with precomputed page layout) – Brinn

Hello. I talk to you from the year 2015 and both windows 8 and 10 now displays &#x202F; like a non breaking thin space. Wich is great. &thinsp; still doesn't work tought. – Jammie

For years now I never had any trouble with browsers not displaying &#x202f; and very many higher UNICODE code points flawlessly on any OS, including Windows, BSDs. I can but wonder about the issues you mentioned. – Garish

For the solution itself: It has a serious drawback, as it mixes up content and representation in a very unfortunate way: If someone has a hard time getting some UNICODE plaintext to display properly in browsers, imagine the magnitude of problems he will have getting rid of the HTML-hacks proposed here. – Garish

Answer 2

Addendum 2021: Nowadays, all actual browsers render   (narrow non-breaking space) fine. These "hacks" aren't needed any more :-)

Arsphenamine

Which means we can use &#x202F; just to make it obvious. – Xyloid

Answer 3

I've done a bit more digging, and it does seem like a font problem. FileFormatInfo is very useful for dealing with Unicode issues in general, and it includes a page listing the fonts that support this particular character. There is even a Flash tool (click inside the blue box on the page listing the supported fonts to get to it - I can't make a correct URL for some reason) that lists all your locally installed fonts and shows this character for each one.

Odetteodeum

OK this is definitely helpful. The flash application displays a lot of squares, empty or full, which means I suppose that my fonts do not support it. Since this is a default XP install I assume XP doesn't support it by default. Now trying to download some Vista fonts… – Vanmeter

I've just visited the Flash page on a French-locale Vista installation, and the only font that seems vaguely 'normal' which supports this character (ie there is no box showing) is "Microsoft Sans Serif". – Odetteodeum

Answer 4

Why not just  ?

Cecil

That’s exactly what I am doing but on Windows it does not render correctly. – Vanmeter

The font you are using has probably no glyph for this character. – Cecil

Do you know any Windows font which is supposed to have it? A quick glance into the Character Picker reveals that this character is not in most lists. – Vanmeter

Answer 5

You could do this, but it's not ideal.

<span style="font-size:50%;"> </span>

Odetteodeum

I could, but I’m assuming there has to be a way to make Windows render it correctly… Perhaps it’s a font issue… – Vanmeter

Answer 6

You can press Ctrl+shift+2 in a WYSIWYG editor like CKEditor and then go to source HTML view.

Pemphigus

Answer 7

The worst of hacks:

<span style="margin:-0.08em">&nbsp;</span>

Frederico