Хммм ... нет. Если единственная проблема заключается в том, что   (U + 2009) по-прежнему ломать, я предпочитаю использовать:
<span style="white-space:nowrap"> </span>
исправить разрушающее поведение. Зачем?
Поскольку французский тонкой эффективно использует почти фиксированную ширину между одной шестой до одной четвертой в cadratin (0,166 примерно до 0,25 примерно, когда стандартное пространство 0,5 ок) Выбор ширина зависит от подхода, уже присутствующего в глифах, определенных в данном шрифте.
шрифты сделаны для регулировки ширины их тонкого пространства (U + 2009): если эти шрифты были сделаны французскими typographs (для рендеринга по-французски), то approche (или пробелы между буквами в словах) является более узким чем в шрифтах, предназначенных для английского языка: это потому, что французские тексты обычно содержат больше букв, чем эквивалентные английские тексты (например, печатная Библия), и чтобы не увеличивать количество печатных страниц, глифы во французских шрифтах были немного более узкими и с сокращенный подход; для компенсации этого сокращения, французский штраф был увеличен в размере. (Часто говорят, что U + 2009 составляет одну пятую часть кадратина, то есть 0,2 ca., но это неправильно, так как это значение является просто разумным медианным значением, которое должно эффективно корректироваться в шрифтах в соответствии с их дизайном).
На английском языке с английским книгопечатания, пробелы между символами уже достаточно велик, чтобы оправдать тот факт, что не тонкая пространство не используется в текстах рядом с большинством двойных знаков препинания. Однако, если французский шрифт используется шрифтом, использующим английскую типографику (которая имеет большие межсимвольные пробелы), то штраф должен быть уже и должен быть уменьшен до 1/6 кадратина.
Так что да, U + 2009 (  в репозитории SGML) слегка настраивается в зависимости от шрифтов.
Кроме того, это может быть частично обосновано (при использовании полного оправдания, где не только обычные межсловные пространства имеют увеличенную ширину, но и все промежутки между символами и нормальные или «штрафные» пространства (но другие квадроциклы пространства не должен иметь их ширина регулируется: они действительно фиксированные)
при визуализации документа, чей макет страницы уже предварительно вычислены (с известными шрифтами и с точными метриками), тонкое пространство (. U + 2009) - это то, что вы хотите (потому что вам не придется беспокоиться о нарушении правил.
К сожалению, Unicode забыл, чтобы присвоить этим квадратам U + 2000..U + 2006 (и к тонкому пространству U + 2009) неразрывное поведение в свойствах разрыва строки.
Единственный способ для Unicode исправить его (только для текстовых документов), должен был добавить еще один символ, а именно U + 202F (NARROW NON-BREAKING SPACE) в Unicode 5.1, который позже получил символическое имя SGML «nnbsp» для ссылок на символы (но сопоставление этого именованного символьного объекта с U + 202F не является частью какого-либо стандарта HTML или XML, поэтому этот именованный объект также не должен использоваться, если только ваш документ не определяет его явно во встроенном DTD !)
Но, к сожалению, большинство браузеров забыли применить это дополнение и почему оно было необходимо: они предполагают, что персонаж должен быть в шрифтах, но это явно не так.
ВСЕ браузеры ДОЛЖНЫ рассматривать U + 202F как неразрывные (это уже так, даже если они не знают символ в своей внутренней копии UCD).
Однако браузеры НЕ ДОЛЖНЫ зависеть от того, что U + 202F определяется шрифтом, вместо этого они ДОЛЖНЫ предоставить резервную копию U + 2009 (THIN SPACE) при рендеринге, каждый раз, когда U + 202F не отображается в текущем шрифте, но U + 2009 отображается в одном шрифте (обычно это относится ко многим шрифтам).
Так что это проблема в средствах визуализации HTML (то есть в браузерах); Я также думаю, что это больше, чем просто проблема с шрифтами, это действительно ОШИБКА браузеров (а не ошибка или ограничение в шрифтах), если они не предоставляют таких резервов для пробелов. Конечно, все новые шрифты должны сопоставлять U + 202F с тем же символом, что и U + 2009.
Учитывая, что тонкое пространство (U + 2009, или  ) очень хорошо поддерживается во многих шрифтах и имеет правильную ширину для рендеринга французских текстов с шрифтами, выполненными с французскими типографскими метриками, или для рендеринга английских текстов с английским текстом типографские метрики, это действительно должно быть правильным резервным, чтобы использовать каждый раз, когда узкое неразрывное пространство недоступно!
Вы можете идеально эмулировать желаемое поведение U + 202F в HTML, просто используя U + 2009 и делая его неразрывным, используя CSS-пространство «white-space: nowrap». Это всегда будет лучше, чем изменение размера шрифта, чтобы отобразить псевдопостоянство (потому что это неверно со многими шрифтами, для которых это все равно будет слишком большим, а также потому, что это не работает так, как ожидалось, в частях текста, имеют цветные фоны: изменение размера шрифта изменяет высоту строки).
Поэтому, пожалуйста, используйте этот код вместо этого в ваших HTML или SVG документов (держать U + 202f только для простых текстовых документов):
<span style="white-space:nowrap"> </span>
Вы можете сохранить эту последовательность в многоразовый шаблон, который можно назвать Template:nnbsp в MediaWiki, например, для перевода его на ваши страницы как {{nnbsp}}.
Обратите внимание, что он по-прежнему предпочтительнее ссылаться на узкое пространство символически  , а не принуждать точную точку кода Unicode, как  : именованный объект может быть переназначен визуализатором, или в соответствии с пользовательскими предпочтениями к другому рабочему пробельных.
Обратите внимание, что MS-word действительно использует U + 2009, а не U + 202F для представления своего собственного штрафа. Это правильно, учитывая, что документы Word имеют предварительно вычисленный макет, и при условии, что MS-Word обеспечивает локальное устранение неполадок при вычислении макета страницы. Документы Word не являются текстовыми документами.
- Exemple рендеринга (с использованием цвета фона, чтобы показать, что высота строки не меняется, но, к сожалению, этот сайт не позволяют установить цвет фона за исключением
<code> секций, как здесь, которые используют MONOSPACE шрифты):
Exemple de « fine » insécable française correctement codée !
- то же без
<code> контейнер не отображается цвет фона, но лань s использовать обычные пропорциональные шрифты, так что тонкое пространство эффективно визуализируются как тонкие:
Exemple де «& thinsp; отлично & thinsp;» insécable française & thinsp ;; исправление codée & thinsp ;!
- Пример использования
  (NNBSP, который, как правило, не поддерживается в большинстве шрифтов, но это может в конечном итоге работать с текущим браузером и шрифтов, установленных в системе, например, DejaVu Sans):
Пример: «& # x202F; fine & # x202F;» insécable française & # x202F ;; исправление codee & # x202F ;!
- Пример использование
  (Шестое CADRATIN, могут работать, но могут быть слишком узкими для шрифтов, и не могут проявлять неразрывное свойства):
Exemple де «& # x2006 ; fine & # x2006; »insécable française & # x202F ;; исправление codee & # x2006 ;! (hmmm ...на самом деле не)
- Пример использования
(что почти всегда слишком большой):
Exemple де « прекрасный » insécable française ; исправление codee ! (hmm ... not really)
Не только ваш ответ полезен (если он немного длинный), он также кажется довольно образованным и обоснованным. Спасибо за вашу помощь. Это делает нашу жизнь несчастной в бизнесе локализации веб-сайтов, поскольку сообщения, которые раньше были обычным текстом, теперь могут стать разметкой и, следовательно, необходимо пропустить исключающую часть. Есть ли у вас какие-либо идеи, почему оба браузера FireFox и Safari, которые поддерживают & # x202F; на Linux и Max OS X, не на Windows? Разве только, что шрифты Linux и Max OS X имеют этот символ, а шрифты Windows - нет? Что не было бы проблемой, если бы браузер реализовал спад? – FroMage
Версии Linux и Mac OSX, вероятно, используют библиотеку текстового рендеринга (или службу ОС), которые реализуют резервную копию, когда шрифт не имеет символа. Затем браузеры используют эти API или библиотеки. Учитывая, что Windows не реализует этот резерв шрифта в своих API-интерфейсах для визуализации текста (GDI, GDI + ...), браузеры, использующие его, не могут отображать символ. Я знаю, что Firefox использует собственные внутренние резервные копии для некоторых персонажей, но многие из них довольно бедны. Но я не вижу причин, по которым браузер не будет реализовывать резервные копии для пробелов. –
Обратите внимание, что Safari не отображает U + 202F в Windows, но Google Chrome его отображает (даже в обоих браузерах используется WebKit, который должен использовать те же библиотеки воспроизведения текста): Chrome затем реализует резервную копию за пределами Webkit, или он использует исправленную версию Webkit. –