1211867 - nbsp - wrong character is displayed

Status: RESOLVED FIXED

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

Description

[tuczi007]

Attachment: 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)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Jonathan Kew [:jfkthame]]

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.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Use the font's NBSP glyph (if present) rather than rendering NBSP using the standard <space> glyph

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.)

Comment 4

[tuczi007]

In which version of Firefox this fix will be applied?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

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

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out for build bustage: https://treeherder.mozilla.org/logviewer.html#?job_id=15631186&repo=mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/653d103fbf14

Comment 8

[Jonathan Kew [:jfkthame]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=25483f286fb4

Comment 9

[Jonathan Kew [:jfkthame]]

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

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5baceaa01fee

Comment 11

[Takayoshi Kochi]

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.