940944 - Glitch on showing a diaeresis

Status: UNCONFIRMED

(Core :: Graphics: Text, defect)

Description

[Gil Forcada]

Attachment: Captura de pantalla 2013-11-20 a les 13.06.33.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

Text that has the following unicode sequence is displayed incorrectly (it should be än but it shows the umlaut on top of the n):

- Unicode Character 'LATIN SMALL LETTER A' (U+0061)
- Unicode Character 'COMBINING DIAERESIS' (U+0308)
- Unicode Character 'LATIN SMALL LETTER N' (U+006E)

See it in action in the text above the image: http://www.freitag.de/autoren/juloeffl/ins-freie (attaching a screenshot)



Actual results:

The umlaut is on top of "n" instead of "a". See the verändern word on the screenshot.


Expected results:

The umlaut should be on top of character "a".

Comment 1

[Gil Forcada]

As an additional note, these two python lines give the same output, but not when rendered on Firefox:

>>> print u'vera\u0308ndern'
verändern
>>> print u'ver\xe4ndern'
verändern

Comment 2

[Jonathan Kew [:jfkthame]]

The site is using a webfont (TheAntiquaF_Regular.woff) that does not support the combining diaeresis (U+0308). As a result, font fallback comes into effect for this character and we end up rendering it from a different font (Georgia, if available, as that's the next family listed in the CSS). Mixing fonts within a base+accent cluster is a recipe for trouble...

Note that W3C recommendations call for the use of Unicode normalization form C (NFC) on the web.[1,2] In this case, the a-umlaut would be encoded as the single character U+00E4, which *is* supported by the Antiqua font being used, and so it would render as expected in all browsers.

In principle, we could try to improve Gecko's rendering here by applying NFC internally, e.g. during the font-matching process. However, this could have performance costs, and might have undesired effects on rendering in other cases with other fonts.

FWIW, the site also looks bad (in a slightly different way, but for the same reason) when I view it in Safari on OS X 10.7, and in IE on Win8.1 Preview. It looks correct in Chrome, which I presume means Chrome is applying NFC normalization to the text at some level.


[1] http://www.w3.org/TR/charmod-norm/#sec-UnicodeNormalized
[2] http://www.w3.org/TR/charmod-norm/#C300

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Gil Forcada from comment #1)
> As an additional note, these two python lines give the same output, but not
> when rendered on Firefox:
> 
> >>> print u'vera\u0308ndern'
> verändern
> >>> print u'ver\xe4ndern'
> verändern

Whether they'll render the same in Firefox is entirely dependent on the font being used. Relatively few fonts have good support for the combining marks, so it's likely you're seeing a mixed-font result again.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: screenshots from other browsers

For comparison, screenshots of the "problem" site's text as rendered by Safari on OS X 10.7 (left) and by Internet Explorer on Windows 8.1 Preview (right).

Comment 5

[Gil Forcada]

Many thanks for this great answers, I will try to make sure we convert this characters to a single unicode character, close the report if you think so.

Again, many thanks for sharing your wisdom!