Closed Bug 643502 Opened 9 years ago Closed 9 years ago
Telugu rendering goes bad if it does not have a font tag specified
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 Everything was good with Firefox 3.*. And everything is even fine with Firefox 4.0 in Linux. But in windows, when a telugu web page (unicode) does not come with a font specified, then it is rendered very badly. But if it has a font face specified, say Gautami or Lohit-telugu, then everything is fine. Telugu text rendering without font face: http://www.twitpic.com/4bvgfp/full Telugu text rendering with font face: http://www.twitpic.com/4bvgo2/full Reproducible: Always Steps to Reproduce: 1. Create a sample html page with some telugu text copied from http://te.wikipedia.org 2. Include this html tag in the beginning of the file - <font face="Gautami"> and open it in Firefox 4 on Windows 7. Everything should look good. 3. Now remove the html tag keeping the text. Open the file in Firefox 4 on Windows 7. Now, the rendering should appear obscure. Actual Results: A faulty font rendering is shown. Expected Results: Text rendered with default font for that language. It might have affected several other languages across the world!
It was said that this default font is set to "Vani" instead of "Gautami" on windows in Firefox 4. The problem will be solved if you can revert it back to "Gautami". I tried changing the font through firefox settings. Unfortunately, it did not work, which is weird. Please correct it and check if there are other languages having such problems.
(In reply to comment #0) > Telugu text rendering without font face: http://www.twitpic.com/4bvgfp/full > Telugu text rendering with font face: http://www.twitpic.com/4bvgo2/full As far as I can see, the rendering without a font tag is still correct Telugu, but it's using the Vani font by default, rather than Gautami (even though that is the default Telugu font specified in the Options dialog). If you add a language tag to your HTML page, it should choose the correct font as specified in the Options; for example: <body lang="te"> ...etc </body> I thought we had a bug filed about better handling of font prefs, based on Unicode scripts, but I'm not finding it right now....
Bug 556237 would provide a better basis for fixing this, though in many cases we could (and should) improve font-selection behavior based on script identity even within the current langGroup framework.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
This indicates a bug that must be hurting performance, too, as it seems we're not correctly using the per-language(group) font prefs during fallback for Unicode-served pages without language tags, but ending up in generic (expensive) system font fallback instead.
It turns out the underlying bug here is that when the relevant unicode-range bits and font preferences were created (in bug 378105 for several Indic scripts and bug 441110 for Tibetan), corresponding cases were not added to gfxPlatform::GetFontPrefLangFor(). This means that although the fonts may be defined in prefs, and they work for language-tagged data, they're not found on the basis of the lang-font prefs when we hit fallback. In the (fairly common) case where there's only a single font installed for a particular script, the problem goes unnoticed because the generic (search-all-fonts) fallback path ends up finding it anyway; but now that Win7 ships with two Telugu fonts (for example), the result of this fallback may not be the one that was chosen as default in the preferences.
Assignee: nobody → jfkthame
Attachment #522238 - Flags: review?(smontagu)
Just to note that the "history" mentioned in comment 5 is not strictly accurate, as gfxPlatform::GetFontPrefLangFor() didn't exist at the time these ranges/prefs were created - that used to be Mac-specific code in gfxMacPlatform, and before that it lived in gfxAtsuiFonts. So this may have initially been a Mac-specific bug, but with the work towards unifying font-handling it became shared with other platforms as well.
Cleaned up Windows line-ends accidentally present in the first version of the patch.
Attachment #522371 - Flags: review?(smontagu) → review+
Pushed to cedar: http://hg.mozilla.org/projects/cedar/rev/51118920ebe1
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
You need to log in before you can comment on or make changes to this bug.