Closed Bug 37365 Opened 25 years ago Closed 24 years ago

Combine Fixed/Variable font option with Mail/News Default View Font option

Categories

(MailNews Core :: Backend, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: momoi, Assigned: BenB)

References

Details

(Whiteboard: Fixed. Patch in bug 31906.)

In Bug 26182, the following backend work was implemented: ----------------------------------------- I checked in the backend support. Please try following prefs (everything is disabled as default). "mailnews.language_sensitive_font" - if set to "true" then browser's font setting is used for mail/news If above pref is "false" then you can apply mail/news specific font setting by following prefs. "mailnews.font.name.html" "mailnews.font.size.html" "mailnews.font.name.plain" "mailnews.font.size.plain" ----------------------------------------- Ben (mozilla@bucksch.org) noted that: ----------------------------------------- > If above pref is "false" then you can apply mail/news specific font setting by > following prefs. > "mailnews.font.name.plain" > "mailnews.font.size.plain" Note, that this propably collides with the "mail.fixed_width_messages" (sat in "Prefs|Mail and Newsgroups") pref, logically and in the code. As for the code side, I set "font-family: -moz-fixed" (not yet checked in), if true, and depend on HTMLish defaults (i.e. set nothing), if false. ----------------------------------------- Given the Mozilla font architecture, one way to resolve the difference is to apply "mail.fixed_width_messages" ONLY IF "mailnews.language_sensitive_font" is true. This is actually the way Fixed/variable option worked in 4.x. The settings using the following prefs "mailnews.font.name.html" "mailnews.font.size.html" "mailnews.font.name.plain" "mailnews.font.size.plain" are effective only as the default view fonts for the languages which the fonts can cover. If you set Times New Roman and Courier as the fonts by these new prefs, they are not going to be used for Japanese messages. If your main viewing is done is in Japanese, then you should set Japanese fonts instead of Times or Courier. So something like the following UI may be one way to combine these backend prefs: === Viewing Messages ===== (Two radio buttons) o Set Mail/News default fonts HTML Mail {Font List} {Size List} Plain Text Mail {Font List} {Size List} o Use Browser Font Settings instead (Language Sensitive) View Plain Text Messages with: o Fixed-width Font o Variable-width Font Does this sound like something we can use to resolve the 2 prefs?
QA Contact: lchiang → momoi
Status: NEW → ASSIGNED
Sounds reasonable. However, I don't (yet) fully understand nhotta's feature, so I cannot say for sure. ACCEPTing for now.
The default font feature is very simple. Since libmime sends UTF-8 output to layout, unicode font setting is used for message display by default. Default font is specified to avoid that by putting a tag like <pre style="font-family: xxxxxxx">...</pre>. There are two ways to get the font name. It is automatically selected based on the message charset or the user can explicitly specify it by pref. The second option needs UI which is currently not available. I think this bug is about combine that with the current plain text font option pref UI. There is also a backend issue. The default font setting for the plain text view is overridden by the plain text view setting which specifies a style but does not specify a font name. The back end code can be changed to use the default font name (I can provide a function to get that).
nhotta, I'll be working on this (together with 31906) in the coming days.
Target Milestone: --- → M16
Ben. the UI specs I wrote above is a suggestion. While combining these features, if you come across a better way, please don't hesitate to raise issues. I read your mail comment a few days ago and there seems to be some doubt in your mind about the exct specs.
The default font can be taken by calling GetMailNewsFont(). For testing, "mailnews.language_sensitive_font" to false otherwise browser's font setting will be returned.
momoi, the problem was time for the most part. I read everything again and the issues are mostly clear to me now. Apart from the fact, that I don't like new pref UI for formatting, it looks good. However, I'm not the one to implement the UI (I know neither XUL nor JS well), I'll just try to resolve the backend problems.
OK, with the fixes for bug 31906, the prefs shouldn't collide anymore. I.e. assuming GetMailnewsFont does the right thing (honors mail.language_sensitive_font, mailnews.font.* etc.), I will use it and won't get into its way. So, my part is done. Remaining work: - Resolve bug 28274 completely. - Pref UI as proposed by momoi. Who should own this? New UI proposal, incorporating bug 39402: o Set Mail/News default fonts HTML Mail {Font List} {Size List} Plain Text Mail {Font List} {Size List} o Use Browser Font Settings instead (Language Sensitive) o Unicode o Language-sensitive o Fixed-width Font o Variable-width Font
Whiteboard: Looking for new owner
Do we really need UI for Mailnews-specific fonts? All those formatting prefs are bloating (including bugs) our code more and more. It gives headache together with user stylesheets (see below). Generally, they are a hack. However, once we have UI, it's hard to get rid of them. After bug 31906 is fixed, you can do all of this (and much more) cleanly and easily via CSS. Given, currently you need to hack user.css, i.e. have to know CSS. I hope, this will be fixed in the long term with a GUI CSS editor. If we decide not to create UI for Mailnews-specific fonts, we could get rid of the (not yet fully implemented, as it seems) backend prefs mailnews.font.* as well, because changing prefs.js is not harder (I think even easier) than changing user.css. So, this bug and bug 28274 wouldn't have to be fixed. Comments?
Whiteboard: Looking for new owner → Waiting for decision
> All those formatting prefs are bloating (including bugs) our code more and > more. OK, I admit, I'm in part guilty of this as well :).
Target Milestone: M16 → M17
This bug is about the backend (at least it sound that way to me). It is fixed with bug 31906 (which is waiting for review and checkin). Adding dependency. I'll maybe post to .mailnews, if we should file a bug for UI for Mailnews-specific fonts.
Depends on: 31906
Whiteboard: Waiting for decision → Fixed. Patch in bug 31906.
I just posted to n.p.m.mailnews, thread "Mailnews-specific fonts?", <news://news.mozilla.org/39345E4F.9170FFF6@bucksch.org>.
Fix checked in by rhp.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This could be somewhat comlicated to verify well. If marina or ji wants to take it, please go ahead. I won't have time to work on it until shortly before RTM.
Xianglan, can you take care of verifying this one? Naoki, can you help?
QA Contact: momoi → ji
Checked with win32 2000092009 build. With "mailnews.language_sensitive_font" set to false, this is working well.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.