1275193 - Umlaut accented character rendering

Status: UNCONFIRMED

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

Description

[sam]

Attachment: FF-46-MacOSX.png

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

Steps to reproduce:

We are hosting a Google webfont (OpenSans-Regular) as .ttf on our server.

All accented characters are rendering fine but for the umlaut accent (¨).
Worst this doesn’t happen all the time we have texts that are completely fine and others
that display the problem. We have been through the source code which are totally identical (no hidden characters, same encodings); though if a page display the problem it will always display the problem and it cannot display both problematic and non-problematic words.
We have seen this on different platforms and different OS with different FF versions


Actual results:

Accented characters get a space after them "wö rd" 


Expected results:

"wörd" with no space after the ö

Comment 1

[sam]

Another example of this kind of behaviour with most accented characters this time on these public slides; the problem appears on some slides but not all. Strange when we consider that from one slide to another there is no reload of the font

https://docs.google.com/presentation/d/1U6yBrx3jFrbfdT0nPk7CSf7oOMfwOvhhomR4wYpJW_c/edit#slide=id.g3410afe80a_1_7

the accented characters appear with a space after them only on FF 58.0.2 : "Pé riode gé ologique" when other browsers display them correctly "Période géologique"

Comment 2

[Jonathan Kew [:jfkthame]]

I'd guess the author copy/pasted that particular block of text from a source that used a decomposed representation of the accented letters, whereas the rest of the content uses precomposed characters.

(FWIW, the decomposed text doesn't render very well when I load that slide in IE or Edge, either -- because the accents are drawn from a different font, without positioning control, they are stylistically wrong and appear "floating" too high and to the right above the letters.)

W3C recommendations call for the use of precomposed characters on the Web, to minimize issues like this. Alternatively, ensuring that the webfont used has full coverage of all the characters -- including combining marks -- used in the text would avoid the problem.

Comment 3

[sam]

Thanks for your infos :jfkthame that explains a lot. But still why can’t we see the decomposed chars in the source of the pages… I am at lost wether all this is a FF bug or not :/

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to sam from comment #3)
> Thanks for your infos :jfkthame that explains a lot. But still why can’t we
> see the decomposed chars in the source of the pages… 

They are there, but what you see may depend on the tool you're using to look at the source. Some editors may normalize the text to precomposed characters; or if you're viewing it with a font that supports the combining mark, you won't see any difference.

I saved the page to a local file and then examined it with an editor that can show non-ASCII characters as hex values, and confirmed that there are definitely decomposed accents on that page: e.g.

<text x="0px" style="font-family:Raleway;font-size:32px;fill:#FFFFFF;font-weight:700;white-space:pre;" y="0px" text-rendering="geometricPrecision">Pe\0x0301riode</text><text x="136.89665937423706px" style="font-family:Raleway;font-size:32px;fill:#FFFFFF;font-weight:700;white-space:pre;" y="0px" text-rendering="geometricPrecision">ge\0x0301ologique,</text>

(note the two occurrences of \0x0301, which is the decomposed acute accent).

> I am at lost wether all
> this is a FF bug or not :/

More of an enhancement request than a bug, I would say; what Firefox is doing is reasonable, given the limitations of the webfonts used by the site (which lack support for the combining characters) together with how the text is encoded. But having said that, it's an area that we would like to improve, so that the browser handles cases like this more robustly.

Comment 5

[sam]

(In reply to Jonathan Kew (:jfkthame) from comment #4)
>
> They are there, but what you see may depend on the tool you're using to look
> at the source. Some editors may normalize the text to precomposed
> characters; or if you're viewing it with a font that supports the combining
> mark, you won't see any difference.
> 
> I saved the page to a local file and then examined it with an editor that
> can show non-ASCII characters as hex values, and confirmed that there are
> definitely decomposed accents on that page: e.g.
> 
> <text x="0px"
> style="font-family:Raleway;font-size:32px;fill:#FFFFFF;font-weight:700;white-
> space:pre;" y="0px"
> text-rendering="geometricPrecision">Pe\0x0301riode</text><text
> x="136.89665937423706px"
> style="font-family:Raleway;font-size:32px;fill:#FFFFFF;font-weight:700;white-
> space:pre;" y="0px"
> text-rendering="geometricPrecision">ge\0x0301ologique,</text>
> 
> (note the two occurrences of \0x0301, which is the decomposed acute accent).

Great ! Thanks, I see them as well now ;)

> More of an enhancement request than a bug, I would say; what Firefox is
> doing is reasonable, given the limitations of the webfonts used by the site
> (which lack support for the combining characters) together with how the text
> is encoded. But having said that, it's an area that we would like to
> improve, so that the browser handles cases like this more robustly.

I totally agree with this : as i am developing websites and webapps, i heavily rely on what the browser and debugging tools tell me; if what i see in the "show source code" is already an interpretation of what the server sends to the browser it is much more difficult for me to tell what is what.

Thank you for your help