1395339 - E combined with Unicode grave accent combining character does not render properly for some fonts.

Status: RESOLVED DUPLICATE of bug 1309934

(Core :: Layout: Text and Fonts, enhancement, P3)

Description

[Thomas Wisniewski]

On the linked SoundCloud page there is a problem with the è character's grave accent combining character appearing incorrectly on Linux and OSX, for both their Interstate webfont and Nimbus Sans L on my Linux box (on OSX with their Interstate font there even appears to be a space after the accented e). Chrome, Safari and Edge do not have this problem (and they don't seem to just be replacing the combination with the predefined character, either).

Comment 1

[Jonathan Kew [:jfkthame]]

(In reply to Thomas Wisniewski from comment #0)
> On the linked SoundCloud page there is a problem with the è character's
> grave accent combining character appearing incorrectly on Linux and OSX, for
> both their Interstate webfont and Nimbus Sans L on my Linux box (on OSX with
> their Interstate font there even appears to be a space after the accented
> e). 

This is because the font being used doesn't support the combining grave accent character (U+0300), and so font fallback kicks in and the accent is rendered with some other font (Lucida Grande in the case of my macOS system, for example); and attempting to render a base character from one font and a combining mark from a different font tends to have bad results (the whole text-shaping process doesn't operate across font-run boundaries).

Bug 543200 is relevant here, as it would make us (try to) use a single font for a complete grapheme cluster (base + diacritics) where possible.

> Chrome, Safari and Edge do not have this problem (and they don't seem to
> just be replacing the combination with the predefined character, either).

What makes you think that? I'd say they almost certainly *are* replacing the combination with the precomposed form U+00E8 (at rendering time only; this wouldn't be visible by inspecting the text in the DOM).

Note that if the site had used Unicode normalization form NFC (which is the recommended encoding form for the Web, e.g. see https://www.w3.org/TR/charmod-norm/#choice-of-normalization-form), this issue would have been avoided.

Comment 2

[Thomas Wisniewski]

>This is because the font being used doesn't support the combining grave accent character (U+0300), and so font fallback kicks in and the accent is rendered with some other font

Ah, that's very good to know, thanks! I'll see if we can pass that along to SoundCloud so they can use a more suitable webfont for their content to help mitigate this issue.

>What makes you think that? I'd say they almost certainly *are* replacing the combination with the precomposed form U+00E8 (at rendering time only; this wouldn't be visible by inspecting the text in the DOM).

Indeed, I may have been jumping the shark there. I only based on the fact that when I hand-edited the SoundCloud page and compared what the two versions looked side-by-side by eye, at least Edge and Safari were clearly different in how the two versions were rendered. Though now that I check again, it looks like Chrome *is* substituting, while Edge is not (the accent is quite off-center), and Safari may or may not be substituting (the font looks different for the not-precombined version, so it could be the precombined character from another font).

>Note that if the site had used Unicode normalization form NFC this issue would have been avoided.

Also good to know, thanks. I'll also recommend that SoundCloud does that.

Comment 3

[Jonathan Kew [:jfkthame]]

Resolving this as a dupe of bug 1309934, where we consider the possibility of applying normalization to help in cases like this.