Currently, documents that only list Roman font-families in a stylesheet, but contain (mainly) CJK text, Gecko substitutes the Japanese characters to the font-family based on the serif/sans-serif setting in Preferences>Appearance for that particular lang group. Expected: use the font-family based on the generic font-family specified in the stylesheet. In the URL listed, the page specifies only roman serif fonts in the stylesheet, but on my side, Gecko uses 'Hiragino Kaku Gothic Pro' (a sans-serif font), because my preferences for Japanese list 'sans-serif' as the choice. Expected: use 'Hiragino Mincho Pro' in this case. Follow-up on bug 364786 comment 61 and bug 364786 comment 69.

Not quite sure what the bug, if any, is here. mozillazine.jp is somewhat unusual Typical text runs on this page look like this: InitTextRun 3db90200 fontgroup 34fc9de0 (Georgia,"Times New Roman",Times,sans-serif,serif) lang: x-western len 168 TEXTRUN " Linux ユーザにとっては、テーマが改善され、Firefox の見た目をよりネ イティブな GNOME アプリケーションに近づけ、GTK+ のアイコンを使うことが可能になったことを評価するだろう。最終的なリリースの前に、より をそれぞれのオペレーティングシステムでのルック・アンド・フィールと統合するために更なる変更を行う予定である。" ENDTEXTRUN InitTextRun font: Georgia InitTextRun 3db90200 fontgroup 34fc9de0 font 34fca4d0 match Georgia (1-7) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fd7e70 match HiraKakuPro-W3 (8-18) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fca4d0 match Georgia (26-8) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fd7e70 match HiraKakuPro-W3 (34-13) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fca4d0 match Georgia (47-7) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fd7e70 match HiraKakuPro-W3 (54-13) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fca4d0 match Georgia (67-5) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fd7e70 match HiraKakuPro-W3 (72-42) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fca4d0 match Georgia (114-1) InitTextRun 3db90200 fontgroup 34fc9de0 font 34fd7e70 match HiraKakuPro-W3 (115-54) The stylesheet specifies sans-serif so I'm not sure why matching Hiragino Kaku Gothic Pro is problematic: body { font-family: Georgia, "Times New Roman", Times, sans-serif; } If there's a bug here I think we need to set up a testcase that localizes the problem better. Because UTF-8 is used and no lang attribute is set, the language for all text runs on the page defaults to x-western. I would prefer if the lang defaulted to the user's locale lang, that would probably be more appropriate.

They used to specify 'serif'. I'll attach a test case next, which does specify 'font-family: Georgia, serif'. On my side, the test case renders with Hiragino Gothic Pro, because my pref is set to use sans-serif. However, I would expect the test case to use Hiragino Mincho Pro, given that the stylesheet specifies 'serif'.

identical to the previous, but uses shift_jis

With serif specified in the style, we map the serif attribute to a font based on the language. For some reason, the language for both of these pages is set to 'x-western', which completely doesn't make sense, especially for the Shift-JIS encoded page. So serif ==> Times and the font matching code will fall back to pref font matching. With the default pref setting of Japanese ==> sans-serif this will result in a sans-serif face, in this case Hiragino Kaku Gothic Pro instead of a serif face like Hiragino Mincho Pro. Effectively I think there are two bugs here: 1. the mapping of CSS generic families should be a function of the unicode range of the characters for which they are specified, instead of the lang setting for the text run 2. for pages with obvious charset ==> lang mappings, like Shift-JIS ==> ja, the lang group setting should be set to that, not to 'x-western' I definitely think (2) is a bug, I'm not quite convinced that (1) is a bug although I'm sure it's confusing for web authors.

Here is another example url: http://asiangazette.blogspot.com/2008/02/construction-and-political-bribes.html This is the kind of pages that I regularly see on the web. WebKit latest build shows the Japanese textstring using Hiragino Mincho Pro.

John-san, I think that this is a simple bug. gfxFontGroup should cache the specified generic font. And font fallback code should prefer the specified generic font at getting from from font prefs. Of course, if there are no generic fonts, we should prefer the default generic type of the language. I think this bug is also on win. I'm not sure on linux.

@Doug Sherk - why is this WFM ? This is still an issue on a recent Aurora build an the latest nightly trunk build (with default profile e.a.) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111007 Firefox/10.0a1

My mistake, I think I was looking at the wrong window when I resolved it. Now I have to find the one I missed...