1337114 - Diacritics rendered incorrectly with decomposed unicode and Proxima Nova

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[vojtech]

Attachment: Screen Shot 2017-02-06 at 21.22.56.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce:

Everything is described precisely in Stackoverflow post:

http://stackoverflow.com/questions/42076418/strange-font-encoding-in-all-browsers

In general this website does not render correctly in Firefox whereas in Chrome it is okay:

https://goout.net/cs/muzea/apple-museum/wucb/


Actual results:

The font is rendered incorrectly.


Expected results:

The font should be rendered correctly.

Comment 1

[Jonathan Kew [:jfkthame]]

The site is using decomposed Unicode (encoding form NFD), where diacritics are encoded separately following the base letters; but the font being used (an embedded version of Proxima Nova, possibly subsetted?) does not actually support this, and so font fallback comes into play for some of the characters, and results in the stylistic mixtures and poor rendering.

Make sure the font being used supports all the characters that are present in the text. (Modifying the CSS to use, for example, Times New Roman instead makes things look much better.) It will also help to use encoding form NFC (precomposed) rather than NFD, as that is much better supported by many fonts.

Similarly, in the "source" view on jsfiddle (referenced from the stackoverflow post), the Inconsolata font being used lacks support for the decomposed accents; modifying the CSS to use (for example) Courier New instead makes things look better.

So this is not really a Firefox bug, I think; it's an authoring problem. The font provided by the site is being rendered correctly for the subset of characters that it supports, but it lacks support for the diacritics and so they end up being drawn from a different font.

Comment 2

[vojtech]

Thanks for your detailed response. This is just a text which was copy-pasted from another site – this is not the way it is provided by the website/server and other pages are displayed correctly. 

I am happy to implement some kind of preprocessing/text-repairing on the server side, but I actually don't know how, as this seems to be a very specific issue. 

The reason I am reporting it is that Proxima Nova on Chrome is displayed correctly whereas on Firefox it is not.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

In case it is relevant, I note that this renders correctly for me on Linux nightly (probably due to different fonts and/or fallback behaviour?).

Comment 4

[vojtech]

I fixed it on our server, so these kind of characters are preprocessed with Normalizer tool. What matters is the jsfiddle, where it is unmodified.

Comment 5

[Jonathan Kew [:jfkthame]]

As noted in comment 1, the jsfiddle source view is using a font that does not have support for the decomposed accents, so results will be system- and browser-dependent (as available fonts and fallback rendering behavior may well differ).

One thing to note is that I believe Blink applies NFC normalization by default in its rendering code, which means that in some cases (quite likely including this one) it will successfully render "decomposed" text even though the font doesn't directly support it. Currently, Gecko doesn't do that; it presents the text as authored to the font for rendering, so if the text is encoded in a way that the font doesn't support, you lose.

Comment 6

[Thomas Wisniewski [:twisniewski]]

As a user on Reddit just indirectly pointed out, Webkit/Blink's normalizing behavior ultimately makes Firefox appear to be the problem (though to be fair Edge also does not normalize): https://www.reddit.com/r/firefox/comments/8zdbsv/what_the_hell_firefox_incorrect_diacritics/

Perhaps we should revisit this as a full-blown interop issue?

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Even if this isn't our fault, maybe we should workaround the issue to provide the same feature as chrome/safari

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 10

[Jonathan Kew [:jfkthame]]

The examples here and in the linked bug 1588206 no longer seem to reproduce, but I believe that's because sites and fonts have been updated; in principle this is an issue that could still occur. In practice, though, it's rare, being dependent on uncommon text encoding (using decomposed sequences, where precomposed Unicode characters exist) combined with a font that lacks adequate support for the diacritics used.

Bug 543200 would be a way forward to improve this, but will need careful handling to ensure we don't regress performance for "normal" content that doesn't run into this kind of issue.