Closed Bug 44806 Opened 24 years ago Closed 24 years ago

Classic skin should use Windows font, not serif font

Categories

(SeaMonkey :: Themes, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: phil, Assigned: nbhatla)

References

Details

Using 2000-07-07-10 commercial build on NT 1. Switch to Classic skin 2. All chrome uses some serif font like Times New Romain Expected: System font (MS Sans Serif on my system) to be used. For me, the visual effect of using a small serif font makes the Classic skin hard to use.
Nikhil can you check the Windows Classic skin to see if you can fix this one?
Assignee: hangas → nbhatla
I have tried all the CSS fonts that should grab system-wide fonts (menu, message-box, caption, etc.), but none of them actually grabs the proper system-wide menu font. I can either hard code it to MS sans serif, or someone has to fix the underlying code to grab the proper system font. Suggestions?
cc'ing pierre and kmcclusk to see if they can help
Nikhil, I bet if you had a small snippet of code which demonstrates the problem, it would be easier for the Gecko guys to help. You could paste it, or attach it, to this bug report.
This is a dup of bug 16729. The CSS System Fonts have been implemented in the CSS cross-platform code and in MacGFX (bug 3371). There is a proposed fix for WinGFX (bug 33312) which is not checked in yet and the work needs to be done in UnixGFX (bug 33313). Phil: you may want to push the priority of the 3 remaining open bugs otherwise the skins won't work correctly for beta2. *** This bug has been marked as a duplicate of 16729 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Depends on: 33312, 33313
Resolution: --- → DUPLICATE
Although I'm sure pierre is right that this is a dup, I'm reopening this bug since I think it would be better in the short term to work around by hard-coding MS Sans Serif rather than waiting for that ancient CSS bug to get fixed.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
We've got a problem. I cannot hardcode MS Sans Serif into the CSS, because for some reason raster fonts don't display properly in mozilla (see bug #22031). The closest I can get at this point is MS Serif. I will leave it at that for now, until bug #22031 is resolved.
Depends on: 22031
It looks like bug 22031 is going to get resolved today. Maybe just wait a couple hours.
You don't want to hardcode "MS Sans Serif" into the skins unless you do a separate skin for Windows. "MS Sans Serif" doesn't exists on other platforms.
Yes, agreed, but Classic skin is, by definition, a platform-specific skin. The Mac version of the Classic skin looks like Mac native widgets, and the same for Windows and Linux. So it seems ok to hard code platform specific skins. Nikhil, please speak up if I'm mistaken about that.
Phil's right. The windows classic skin is by-definition platform-specific, so it's ok to hardcode ms sans serif because all windows computers come with it as the default menu font. Of course, the user can always change this, and then mozilla will look out of place again. So the ideal solution is to somehow link the CSS-defined system fonts (menu, caption, etc.) to the proper Windows settings, so that classic skin will always match the user's system fonts, whatever they may be.
Bug is fixed. Hard-coded 8pt "ms sans serif" into win/global.css, replacing "dialog" font (which, by the way, is not even a CSS font...I'm surprised/confused on how it displays the right font). Anyone know about this "dialog" style?
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Nikhil: - Linking the CSS-defined system fonts (menu, caption, etc.) to the proper Windows settings is precisely the purpose of bug 33312 (Windows) and bug 33313 (Unix). - The 'dialog' font is a CSS3 addition (for more info, see http://www.w3.org/TR/2000/WD-css3-userint-20000216#font) - I'm going to open a separate bug, with dependency on 33312, to ask you to remove the hard-coded "MS sans serif" font from the skin.
I opened bug 45513 to remove the hard-coded string.
[mid air collision. just resubmitting for the record, since pierre has already cleared my doubts] ======================== >So the ideal solution is to somehow link >the CSS-defined system fonts (menu, caption, etc.) to the proper Windows >settings, so that classic skin will always match the user's system fonts, >whatever they may be. This was already the case, but your hardcoded fix has undone it. (I think the hardcoded fix should be backed out.) Mozilla seems to support several other system fonts that are not in CSS2. (Here is a snippet from a code somewhere in the tree, nsDeviceContextWin :: GetSystemAttribute() ... case eSystemAttr_Font_Caption: case eSystemAttr_Font_Icon: case eSystemAttr_Font_Menu: case eSystemAttr_Font_MessageBox: case eSystemAttr_Font_SmallCaption: case eSystemAttr_Font_StatusBar: case eSystemAttr_Font_Tooltips: case eSystemAttr_Font_Widget: case eSystemAttr_Font_Window: // css3 case eSystemAttr_Font_Document: case eSystemAttr_Font_Workspace: case eSystemAttr_Font_Desktop: case eSystemAttr_Font_Info: case eSystemAttr_Font_Dialog: case eSystemAttr_Font_Button: case eSystemAttr_Font_PullDownMenu: case eSystemAttr_Font_List: case eSystemAttr_Font_Field: ... ) Are all the extras in CSS3? I can't find a reference.
The reference was supplied by pierre. The extras are in the CSS3 WD: font: window | document | workspace | desktop | info | dialog | button | pull-down-menu | list | field
> This was already the case, but your hardcoded fix has undone it. > (I think the hardcoded fix should be backed out.) Hmm. I'm confused now. I'm running today's release build, and seeing the right fonts, which is strange because today's release build does not include Nikhil's hard-coding fix. Is it possible that yesterday's fix of bug 22031 was really the blocker, and bug 33312 isn't blocking Classic skin after all?
Nikhil, what's up? Bonsai doesn't show any checkin from you in the last 24 hours; win/global.css still shows "font: dialog" but it seems to work now: http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/global.css#58
Phil, the thing that happened may be the following... All the CSS2/CSS3 system fonts ('dialog', 'menu', etc...) probably default to the basic 'sans-serif' font, which was translated to "MS Sans Serif" and because of bug 22031, they were display as Times. Bug 22031 was fixed which means that the system fonts now appear as 'sans-serif' but it is still not exactly what we want: if you change the Desktop Theme under Win98, Mozilla continues to show everything in "MS Sans Serif" instead of adopting the current OS theme (bug 33312). In fact, the current bug can be considered as a dup of 22031 and we can close bug 45513 as Invalid if Nikhil or the someone else did not checkin any hardcoded string.
I have not checked in the hard-coded string yet, exactly because the font:dialog that is currently in global.css appears to work fine. I believe that we do not need to hard code in "ms sans serif", should close bug #45513, and instead worry about making sure the CSS2/3 system font styles are dynamically loaded based on the user's Windows font settings
Phil, the real blocker was indeed 22031 - it prevented bitmap fonts ("MS Sans Serif" just happened to be a bitmap font). Pierre, it looks like system fonts are properly mapped to "MS Sans Serif" (not defaulted to a generic "sans-serif") Otherwise rendering could be non uniform. Some users could get a certain font, while others get another font. Bug 33312 is indeed the remaining culprit. One of the problem comes from the fact that several "case ..." are mapped to the same thing (cf. the snippet of code above, and the comments from Michael Lowe 2000-05-07 08:27 on bug 33312).
Got it. Thanks for the explanation.
Updated QA contact
QA Contact: paw → pmac
This bug is fixed in windows (build: 2000-09-05-08-M18).
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.