Open Bug 474182 Opened 14 years ago Updated 4 months ago
Language specific font preferences do not consider HTML lang attribute
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.4 Instead of considering the lang attribute when selecting a font to be used for rendering, the encoding is considered instead. In an HTML page where there are no font styles / attributes specified at all, the font preferences under Tools > Options > Content > Fonts & Colors > Advanced are used. This page allows you to specify custom settings per language and *not* per encoding; note how the combo at the top of this page says "Fonts for: [list of languages]" and *not* "Fonts for: [list of character encodings]". Reproducible: Always Steps to Reproduce: 1. Go to Tools > Options > Fonts & Colors > Advanced and select Arabic from the first combo. Set the proportional font size to 72. 2. Load http://thegoan.com/dump/arabic-utf8.html Note: I am using font size as a easy way to indicate how these preferences are not being correctly applied. Just like font size, all other font preferences on this page are also ignored. Actual Results: Arabic text is rendered in default size (corresponding to Western "language" setting, usually 16) instead of 72. Expected Results: Arabic text should have been rendered using the size specified for Arabic text, size 72. I say this because the HTML page above contains lang = "ar" attributes for both the <html> and the <body> tags. In addition, Firefox has detected that the language is Arabic - select some of the text, bring up the context menu and select Properties. The resulting dialog mentions that the language is Arabic. Since no font styles are specified in the HTML, I would therefore expect my Arabic language font preferences to be applied. What Firefox seems to be doing is looking at the page encoding, converting that to the language for which that encoding is used and then using this *derived* language to look up the language specific font preferences. This approach is perfect if the lang attribute isn't explicitly specified. In the page above, the UTF-8 encoding is used. So, inspite of an explicit lang attribute specified (and Firefox detecting the text as Arabic) the UTF-8 encoding is converted to a "Western" language and those font settings are used instead. If you go to this page: http://thegoan.com/dump/arabic-1256.html notice that the Arabic text is now rendered large, at size 72; this page is identical to the first, other than the fact that the encoding used in the page is "windows-1256", which is an Arabic character set. It would be rendered in size 72 irrespective of the lang = "ar" attributes. My application has use cases where a single page could contain multiple languages, forcing me to use UTF-8 for encoding; so using a language specific encoding won't work as it will mess up the display of text on the same page in other languages (encoding can be specified only once but lang attributes can specified several times for most block elements). The only option I see is for me to specify language specific fonts explicitly using CSS when I generate the page; this is obviously more work and it also means that I need to build a page on which my users can customize these fonts (even though Firefox already has one), or manually pull these settings from Firefox's preference page. My application is a Firefox extension (http://thegoan.com/firebible), which is why I'm only interested in Firefox and don't need a solution that will work across browsers. I have looked at bug #132341, bug #122779 and bug #105199 while researching this issue; these cover cases where the font settings are explicitly specified in the HTML via CSS (and Firefox did not respect them), in my case I'm not specifying anything in the HTML and I want Firefox's preferences to be used. Also replicated using Firefox 3.1 beta 2. Preliminary discussion here: http://forums.mozillazine.org/viewtopic.php?f=9&t=1024165
This is a mass search for bugs which are in the Firefox General component, are UNCO, have not been changed for 500 days and have an unspecified version. Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
I'm not the OP, but I can reproduce the problem with the latest nightly. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre I see two ways of fixing it: 1) the easy one, by modifying the text in the Options dialog to make clear that it is charset related and not lang related (and to which precise charset each value apply) 2) by making it applying to the language (which may be much harder, maybe more often error-prone far more pages use a wrong lang attribute than a wrong charset. The bug is far from critical though and surely shouldn't block any release (There are several places in Firefox' UI where charset/language set-up is unclear or ambiguous).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Whiteboard: [CLOSEME 2010-11-01]
Version: unspecified → Trunk
As far as I can tell, the font family preference is set per element according to the lang attribute per element, but the font size preference is set per page according to the presContext's mLanguage, which is indeed set from the charset.
Reporter, can you confirm that font family is applied properly and your reported problem is only about font size?
Testing in Firefox 37.0.1, the problem still exists for both font-size AND font-family. You can change both font-family and font-size and observe that both these settings are reflected for the arabic-1256.html page but not for the arabic-utf8.html page.
You need to log in before you can comment on or make changes to this bug.