font: use actual NBSP character for \h

\h is often used in typesetting purely for horizontal padding.
We already correctly expand \h to NBSP (0xA0) during parsing, but then
later replace it with a space (0x20) for shaping run detection. Actual
shaping though again uses NBSP, but still uses the font face indices
from shaping run detection. This can lead to problems if the font
detected for a regular space doesn’t also provide a NBSP character.
HarfBuzz automatically substiutes a missing NBSP character with the
font’s space character, hiding the issue. With FriBidi doing shaping,
\h will end up as a TOFU box.
Stop replacing NBSP with a regular space,
so font substitution can take place properly.

Note: some subs rely on GDI picking Arial for a NBSP fallback.
This commit makes no attempt to nudge fallback selection
to any particular font.

This reverts 33a3ab2c8777241b73ad85024158e19fb1f9c699. We no longer know
what problems the original commit tried to solve, but know for sure the
current replacing causes issues (and that VSFilter too uses a different
font for fallback NBSP).

Fixes: https://github.com/libass/libass/issues/2

1 files changed, 0 insertions, 3 deletions

diff --git a/libass/ass_font.c b/libass/ass_font.c
index 0e5888d..853dc97 100644
--- a/libass/ass_font.c
+++ b/libass/ass_font.c
@@ -556,9 +556,6 @@ int ass_font_get_index(ASS_FontSelector *fontsel, ASS_Font *font,
         *face_index = 0;
         return 0;
     }
-    // Handle NBSP like a regular space when rendering the glyph
-    if (symbol == 0xa0)
-        symbol = ' ';
     if (font->n_faces == 0) {
         *face_index = 0;
         return 0;