Closed Bug 668996 Opened 13 years ago Closed 13 years ago

Firefox does not render the given characters with certain font families (Georgia, Verdana, Tahoma, Candara)


(Core :: Layout: Text and Fonts, defect)

5 Branch
Windows 7
Not set





(Reporter: cristian.adam, Unassigned)



(4 files)

Attached image Chrome 12 rendering
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

Trying to render the following code, with Firefox 5 on Windows 7:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
<style type="text/css">
h1 {
	font-family: Georgia;
	font-size: 36px;
	font-weight: normal;	
	margin: 10px 0 20px 0;

<h1>&#354;&#355; &#350;&#351; (cedilla)</h1>
<h1>&#538;&#539; &#536;&#537; (comma) </h1>


Actual results:

The cedilla characters were displayed as comma characters. By copy / paste the characters were correct, cedilla and comma characters, as expected.

The behavior is reproducible with the following font families:
Georgia, Tahoma, Verdana, Candara, Calibri, Corbel, Comic Sans MS.

I think the bug relates to all Sans Serif fonts.

Expected results:

The characters should be displayed correctly, cedilla and comma.

I've attached screenshots with the competitive browsers, all of them (Chrome 12, Opera 11.5, Internet Explorer 8) displayed the page correctly.

Note that if the semicolon after the font name is remove, Firefox displays correctly the webpage!
Attached image firefox 5 rendering
Attached image Opera 11.50 rendering
Attachment #543609 - Attachment description: chrome_12.png → Chrome 12 rendering
Severity: normal → major
OS: Other → Windows 7
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Are you running Windows in Romanian, by any chance? 

This looks like language-dependent font rendering, which is supported by an increasing number of modern OpenType fonts (but not by all software).

data:text/html,<p lang="en" style="font: 60px Georgia">&#354;&#355; &#350;&#351; (cedilla)<br>&#538;&#539; &#536;&#537; (comma)

data:text/html,<p lang="ro" style="font: 60px Georgia">&#354;&#355; &#350;&#351; (cedilla)<br>&#538;&#539; &#536;&#537; (comma)

The first example shows the "cedilla" forms, whereas in the second example (tagged as Romanian) they're replaced with the "comma" forms that are more correct for Romanian orthography.

If this is happening by default for you, I'd guess that either the page is being served with metadata indicating it is in Romanian, or else there's no language information but your Windows system locale is set to Romanian and therefore Firefox is using that as a fallback in the absence of actual language tagging.
Yes, locale was set to Romanian. 

This sounds more of a feature than a bug. I was investigating why a webpage was looking good when I knew it shouldn't.

Unfortunately this "feature" produces mixed results. Windows 7 does not have all the fonts with language-dependent features, thus making webpages look inconsistent.

In order to obtain the same results, but this time on a whole page scale, I use the Firefox extension FoxReplace.

I have seen this behavior starting with Firefox 4.
Yes, this is a feature - see bug 24139 (which I just marked as resolved, since this reminded me about it).

You're right that the results may be inconsistent, depending on font support. That's a font bug rather than a Firefox bug. As more software begins to support such features, perhaps this will increase pressure on font developers to include more complete language support in their fonts.
The problem with this automatic conversion is the fact that string matching doesn't work anymore.

If I search after ș (with comma) the character will not be matched even though I see it in the page.

You don't have this problem with FoxReplace.

Also Firefox doesn't have "diacritics insensitive" search, like for example Google Chrome, which would fix this problem. Google Chrome has this feature because they use ICU.

Firefox might use the collation support from the operating system. On Windows Vista and 7 this works for Romanian. On Window XP unfortunately not, see:

I have noticed this feature on
How would the string matching problem be fixed?
We have several bug reports related to accented characters in search; e.g. 202251, 374795, 527472, 595359, 640856. One or more of these would probably cover this issue, if implemented thoroughly with language-appropriate equivalence behavior.

I think we should resolve _this_ bug as invalid, as it's not really a bug at all. Feel free to check the various search-related bug reports and add details about the Romanian issue if necessary, or even file a specific bug about the language-specific behavior needed for search in Romanian text (it should treat Unicode s- and t-cedilla and -comma forms as equivalent).
Closed: 13 years ago
Resolution: --- → INVALID
I've opened bug 670601 regarding the search issue.
You need to log in before you can comment on or make changes to this bug.