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.