We used to use unicode font setting, because Mailnews emits Unicode. With bug 26182, we either try to manually set the font correctponding to the original charset or set the (exclusively for Mailnews) user specified fonts. So, there is no option to still get the original behaviour. But I liked it. It's OK to be false by default. Not sure, if its worth UI. Add a pref to not set any font (apart from honoring the plain text fixed/variable width font pref), but let NGLayout decide. I think, we just have to query the new pref in GetMailnewsFont and return a failure, if true.

>no option to still get the original behaviour. I think the orginal behavior was a side effect of the data is converted to UTF-8 so not intended. What is a benefit of keeping this? It is not easy for the user to discover to set unicode font for the mailnews view.

- It fits well in my ideal world. Ideally, we wouldn't have to care about charsets/encoding at all and fonts would support all Unicode chars. Maybe, I'm missing something, but we were very close to this in Mailnews. Japanese "just worked" for me on Linux, even with the old behaviour (I still works) and although I never touched the Japanese font settings. - Sorry to say that, but your fix for bug 26182 is a hack (I think, you think the same, since you pushed for using LANG) and caused many bugs. I'm not sure, we found all yet.

>- Sorry to say that, but your fix for bug 26182 is a hack The issue is not the implementation is a hack. Anyway, the pref might be useful for a debugging or a workaround. So, I don't care if this is a backend only pref. >and caused many bugs. some of the bug had existed before my changes (e.g. serif, san-serif font selection), >I'm not sure,we found all yet. that applies to any features recently checked in

Sorry, Ben, the ideal world does not exist yet. On Windows and Mac, if you have other Asian fonts, etc. Mozilla will try to use these non-Japanese fonts sometimes and the results are disastrous. I don't want to see Japanese Chinese characters displayed in Chinese glyphs! I'm sure the Chinese feel the same way about this. On Unix, you claim that you can see consistent use of Japanese fonts for Japanese messages. I have not seen the evidence of this at all. The fact is that we fallback on some akgorithm to pick glyhs when the encoding we use is Unicode for display. The user should have a way to designate the fonts for Japanese messages -- otherwise, they display with wrong glyphs for Japanese! In my opinion, you need to prove conclusively that CJK users get to see their languages displayed with their characters not by glyphs of other languages. This is not a simple matter of displaying characters -- the same character may have different glyphs among Chinese, Japanese and Korean. And we don't want to see Chinese glyphs for the Japanese characters. The onyl way to control this precisely is to allow users to set the fonts for their languages. Also in CJK languages, many subset fonts already exist on operating systems -- they are not a singl;e big Unicode font. That is another reason why font control by language is important. By the way, if you have a big Unicode which includes all the languages we care about, you can the get the effect you'ee tallking about here by setting that Unicode font for Japanese. So we already have a facility to take care of waht you're talking about this in this bug.

nhotta, you are right. I was not speaking about your implementation (code), but the strategy used to solve the bug. Of course, I don't have a better idea.

About the strategy : I think the way to go is the lang attribute. I'm not sure rejecting it for bug 26182 was the good decision. Currently the lang attribute is actually used in WWW pages to help the browser select the correct font according to the language of the page when it's encoded in utf-8 (see http://alkashi.citeweb.net/japchin.htm for an exemple with a word that should be displayed with chinese, corean, japanese font on a compliant browser, that 4 kanji expression is meaningful both in chinese and japanese), so I don't see why it wouldn't be used like that inside mail. Because there is no way to go down to actual language resolution for ISO-88596-1 ? Is it not possible to forge a european or western value ? If a user wants to add LANG=fr as bobj said in bug 26182, can't this value be placed in a block inside the LANG=WE or LANG=EU to override it ? Now that support of the lang attribute exists in html, there is one piece of code that gets the correct font from the language information. There is a clear duplication of effort between that piece of code and what correction bug 26182 does to insert the correct tag according to preferences.

I agree with Jean-Marc Desperrier, but it is not part of this bug. Jean-Marc, please add your comments to bug 26162. FYI: Bug 40547 is caused by that, too, and is [nsbeta3-]. I have a similar problem with a new feature (bug 46993), so I fixed this (workaround) bug. Will attach patch. nhotta, can you review, please?

QA momoi, hope that is OK.

Do we really need this option? There is a font fallback mechanism already built in so we can see multiple languages currently without this option. If the user really wants to use a specific unicode font then that can be specified in the font pref UI. I also have a concern that adding more option causes more complication and confusion to testing.

Is there another workaround for bug 40547? With that new feature (see above), I see bug 40547 for many msgs (including all bugzilla spam).

I think the workaround for 40547 could be removing font size specification but not font family.

And how do I do that? If you are suggesting to modify this patch to just skip the font-size spec, I don't know why we should do that. Other bugs, similar bugs about the font-family are likely to appear, and if we have such a workaround, why not remove both specs at once? Note that this pref is hidden (no UI). We don't even need a default pref. It defaults to the old behaviour (setting the font specs).

If you are fixing bug 40547 then the patch should go to that bug. As I said, font size issue and font familly issue are separate, we should not disable font familly feature to correct the font size problem. I think the change not to specify font size can be done by the caller side. Since 40547 is HTML specific, that's the right place to check the option and disable font size.

No, it is not /exactly/ bug 40547. I am working (in part) on ASCII-Art-recognition in plaintext fonts to make the variable width font work better. So, I am switching from variable width font to a fixed width font (by adding <tt>) in the middle of the msg. Basically the same problem, just that it happens in the plaintext converter. Fixing it on the caller side would be a hack IMO. > As I said, font size issue and font familly issue are separate, we should not > disable font familly feature to correct the font size problem. Well, if you really, really want different prefs for skipping font-size and font-family, I think, I could add that. Do you?

We may need a pref to disable font size, I agree that. But I am not sure if we need a pref to disable font familly if the purpose is just to make plain text art look better.

nhotta, the problem is: Bug 26182 caused a lot of bugs for all users (which is *not* your fault), while only giving an advantage for CJK users (correct me, if I'm wrong). I know, it is very important for these users, but I was just suffering from it. I want a simple, bullet-proof workaround (as a "backend only pref") for those many western users that don't need this stuff. I just realized: If you want to override font-family or font-size specifically, you can do that by adding e.g. ".text-plain, .text-flowed {font-size: inherit;}" to your user-stylesheet. But these rules will be evaluated for all of Mozilla, including the UI, so they mean a speed penality (not sure how large, however). So, we have the following options: 1. Hidden pref to skip the font stuff completely + Already implemented + Very simple code - Unspecific 2. Hidden prefs for both font-size and font-family - Not implemented - More complex code + Allows specific overriding 3. Hidden pref for fone-size only - Not implemented - More complex code - Doesn't allow override of font-family (only by using option 4.) 4. Using UA stylesheet + Generic feature, already implemented - Slight speed penality BTW: > if the purpose is just to make plain text art look better. I used "ASCII-art" as term for ASCII-pictures, tables (as used in bugzilla spam) etc.. This appears *very* often. (Otherwise, I wouldn't spend my time on it, since I don't really like it.)

I vote for 1., but if people stongly disagree, 4. is OK with me, too.

>while only giving an advantage for CJK users (correct me, if I'm wrong). I don't think this is true. It applies to all the users who want to change font name/size for message view. The user has to discover that the unicode font values has to be changed in order to change mail font. The other issue which may apply international users (not just CJK) is that unicode font quality. The user may want to assign unicode font to unicode range to view multilingual pages (to at least see the characters even when the font quality is not good). But that implicitly overrides the user's setting of the font choice of the user's language. So using unicode font does not affect the user if the user is happy about the default unicode font selection as below and do not want to change. winpref.js 86 pref("font.name.serif.x-unicode", "Times New Roman"); 87 pref("font.name.sans-serif.x-unicode", "Arial"); 88 pref("font.name.monospace.x-unicode", "Courier New"); 89 pref("font.name.cursive.x-unicode", "Comic Sans MS"); For option 4, could you tell me more detail? Is there UI which allows the user to select?

> The user has to discover that the unicode font > values has to be changed in order to change mail font. Right. I forgot that. > The user may want to assign unicode font to unicode range > to view multilingual pages OK. But *I* don't need that, do I? I know only western languages anyway. > For option 4, could you tell me more detail? Add .text-plain, .text-flowed { font-size: inherit !important; font-family: inherit !important; } to <profiledir>/chrome/user.css (you might have to create the chrome dir), and the unicode fonts should be used again. Or did you want to know something else? > Is there UI which allows the user to select? No. And it will be hard to create one.

Okay, since no UI for any options, most of the user cannot use it. I would chose number 4, we want to take advantage of this flexible feature. For UI, how about providing pre-defined css files (with descriptions) so the user may choose? The second choice would be number 2 to be flexible, and the two prefs can be combined by UI if desired.

> how about providing pre-defined css files (with descriptions) so the user > may choose? Since the UA stylesheet is pretty generic, the user might already have other, unrelated content there. So, you would have to parse the CSS file -> generic CSS writer.

QA cntact to ji.

-> default owner

ops, the bug had a patch. back to me.

Ben Bucksch, any reason to leave this old bug open?

nope