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)
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
Assignee | ||
Comment 2•24 years ago
|
||
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?
Reporter | ||
Comment 3•24 years ago
|
||
cc'ing pierre and kmcclusk to see if they can help
Reporter | ||
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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 ***
Reporter | ||
Comment 6•24 years ago
|
||
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 → ---
Assignee | ||
Comment 7•24 years ago
|
||
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
Reporter | ||
Comment 8•24 years ago
|
||
It looks like bug 22031 is going to get resolved today. Maybe just wait a couple
hours.
Comment 9•24 years ago
|
||
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.
Reporter | ||
Comment 10•24 years ago
|
||
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.
Assignee | ||
Comment 11•24 years ago
|
||
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.
Assignee | ||
Comment 12•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
I opened bug 45513 to remove the hard-coded string.
Comment 15•24 years ago
|
||
[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.
Comment 16•24 years ago
|
||
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
Reporter | ||
Comment 17•24 years ago
|
||
> 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?
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
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.
Assignee | ||
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
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).
Reporter | ||
Comment 22•24 years ago
|
||
Got it. Thanks for the explanation.
Comment 24•24 years ago
|
||
This bug is fixed in windows (build: 2000-09-05-08-M18).
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•