Closed Bug 1211867 Opened 4 years ago Closed 4 years ago

nbsp - wrong character is displayed


(Core :: Layout: Text and Fonts, defect)

41 Branch
Not set



Tracking Status
firefox44 --- fixed


(Reporter: tuczi007, Assigned: jfkthame)



(2 files)

Attached file
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

I have site with nbsp UTF8(160) and regular spaces UTF8(32) (see index.html in I use custom font (see opensans-wc.ttf in with different character ("image") for nbsp and regular space.

Actual results:

Firefox renders nbsp as regular space.

Expected results:

Firefox should used proper character ("image") for nbsp. 
It works in Google Chrome (see ff.png and chrome.png in
The font definitely seems to have different glyphs for U+00A0 and U+0020 and we're showing the latter.

Looking at gfxTextRun.cpp, in gfxFontGroup::ComputeRanges we have:

  2841        if (ch == 0xa0) {
  2842            ch = ' ';
  2843        }

But removing those lines doesn't seem to change anything for me....  Similar for the bit like that in gfxFont::SupportsSubSuperscript.

John, do you know whether we do something like that elsewhere too?

John, do you happen to know whether
Flags: needinfo?(jdaggett)
I believe the primary reason this is happening is that when creating a textrun, we (normally) split the text into "words" and shape each word individually (for caching purposes), and then construct the full textrun by copying shaped words from the cache, with spaces in between. For this purpose, <nbsp> is treated the same as <space> (see IsBoundarySpace() in gfxFont.cpp).

Then, when assembling the textrun from the cached shaped-word data, we unconditionally use <space> as the separator.
Ever confirmed: true
Flags: needinfo?(jdaggett)
Something like this should allow people to render a distinct glyph for non-breaking space, if present in the font. (If it's not supported, we'll still fall back to using the regular space glyph, thanks to code in gfxHarfBuzzShaper::GetGlyph.)
Attachment #8670331 - Flags: review?(jdaggett)
Assignee: nobody → jfkthame
In which version of Firefox this fix will be applied?
That depends on how long it takes to get the patch reviewed and landed, and whether it causes any problems requiring it to be backed out, but most likely Firefox 44.
Attachment #8670331 - Flags: review?(jdaggett) → review+
Bug 1211867 - Use the font's NBSP glyph (if present) rather than rendering NBSP using the standard <space> glyph. r=jdaggett
Bug 1211867 - Use the font's NBSP glyph (if present) rather than rendering NBSP using the standard <space> glyph. r=jdaggett
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
FYI - Some fonts have unexpected glyph (non-whitespace, zero-width space, wide width space)
at &nbsp codepoint (U+00A0).

An issue reported to Chromium:

Reproducing case:,output
43 works good (all &nbsp is displayed as a space), while nightly (44) exposes the issue.

The example above uses Google Web Fonts and I'm contacting the team for resolving the issue,
but there should be probably many fonts which has an unexpected glyph in the wild.
You need to log in before you can comment on or make changes to this bug.