643502 - Telugu rendering goes bad if it does not have a font tag specified

Status: RESOLVED FIXED

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

Description

[Gopal/గోపాల్]

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!

Comment 1

[Gopal/గోపాల్]

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.

Comment 2

[Jonathan Kew [:jfkthame]]

(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....

Comment 3

[Jonathan Kew [:jfkthame]]

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.

Comment 4

[Jonathan Kew [:jfkthame]]

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.

Comment 5

[Jonathan Kew [:jfkthame]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: patch, v1 - add missing cases to gfxPlatform::GetFontPrefLangFor

Comment 7

[Jonathan Kew [:jfkthame]]

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.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: patch, v1.1 - add missing cases to GetFontLangPrefFor

Cleaned up Windows line-ends accidentally present in the first version of the patch.

Comment 9

[Jonathan Kew [:jfkthame]]

Pushed to cedar:
http://hg.mozilla.org/projects/cedar/rev/51118920ebe1

Comment 10

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/51118920ebe1