Closed Bug 1211867 Opened 4 years ago Closed 4 years ago

nbsp - wrong character is displayed

Categories

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

41 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: tuczi007, Assigned: jfkthame)

Details

Attachments

(2 files)

Attached file nbsp.zip
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 nbsp.zip). I use custom font (see opensans-wc.ttf in nbsp.zip) 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 nbsp.zip)
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.
Status: UNCONFIRMED → NEW
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
Status: NEW → ASSIGNED
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/acd7efb271c81d078b1f7129ac39bf2518812770
Bug 1211867 - Use the font's NBSP glyph (if present) rather than rendering NBSP using the standard <space> glyph. r=jdaggett
https://hg.mozilla.org/integration/mozilla-inbound/rev/5baceaa01feee58e5dee795f9ef3bd2a596c8448
Bug 1211867 - Use the font's NBSP glyph (if present) rather than rendering NBSP using the standard <space> glyph. r=jdaggett
https://hg.mozilla.org/mozilla-central/rev/5baceaa01fee
Status: ASSIGNED → RESOLVED
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:
https://code.google.com/p/chromium/issues/detail?id=569054

Reproducing case:
http://jsbin.com/navapuweho/edit?html,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.