Open Bug 1337114 Opened 7 years ago Updated 2 years ago

Diacritics rendered incorrectly with decomposed unicode and Proxima Nova

Categories

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

x86
macOS
defect

Tracking

()

People

(Reporter: vojtech, Unassigned)

References

Details

(Keywords: parity-chrome, parity-safari, Whiteboard: gfx-noted [webcompat])

Attachments

(1 file)

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.
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.
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.
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?).
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
OS: Unspecified → Mac OS X
Priority: -- → P3
Hardware: Unspecified → x86
Summary: encoding → Diacritics rendered incorrectly with decomposed unicode and Proxima Nova
Whiteboard: gfx-noted
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.
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.
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?
Flags: webcompat?
Whiteboard: gfx-noted → gfx-noted [webcompat]
Even if this isn't our fault, maybe we should workaround the issue to provide the same feature as chrome/safari
Version: 51 Branch → unspecified

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

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: