These are implemented on Mac and on Windows. In nsDeviceContextGTK::GetSystemAttribute: //--------- // Fonts //--------- case eSystemAttr_Font_Caption: // css2 case eSystemAttr_Font_Icon: case eSystemAttr_Font_Menu: case eSystemAttr_Font_MessageBox: case eSystemAttr_Font_SmallCaption: case eSystemAttr_Font_StatusBar: 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: case eSystemAttr_Font_Tooltips: // moz case eSystemAttr_Font_Widget: status = NS_ERROR_FAILURE; break; } // switch Other bugs are depenedent on this. I have talked to waqar and if you can get some of the other nsbeta3 bugs off his plate he said he could then work on this.

Marking nsbeta3+. It blocks several other nsbeta3+ bugs.

working on it now.

I have this same bug.. 33313... have you made any progress on this one?

Waqar has an implementation which he emailed to Rod to try.

Fix checked in

Backed out the fix, problem with GTK version number

Setting priority to P3 based on new criteria

Fix checked in once again.

Reopening. If I bring up a gnome app, e.g. ghex, I get menu fonts that are readable; if I switch mozilla to the classic skin (which supposedly uses CSS system fonts) with no user.css, I get significantly smaller menu fonts. They should be the same.

I have 09062000 build it shows mozilla menu font 2 points larger than the menu font for ghex. The reason is that the default font for default style for gtk is 12pt. Rod had asked me to make the font smaller for Button, Field, List, Widget and Caption to decrease the default font by 2pts. Akkana what version of linux are you using? I have RH62.

Okay, I'll bite: what reason did Rod have for asking you to decrease the font sizes by 2 points?

Ok, here is the scientific answer: It looks better. The assumption is as follows: The defailt font for any given platform is unique to that platform and the size of the default may or may not be the correct size for buttons or textfields. We also assume that if the default font can chane the difference in size in relation to the text or button will also be the same. The default font on Windows is the font that matches the menu items, which is 2 point sizes smaller than the button or text fields fonts. There is no other definition of other default fonts or anyway to get what a default font may be for buttons/selects/textfields etc. Unless MS has a specific API they aren't telling us about in the secret ninja book of APIs. So on Windows we bump up the point size by 2. On Linux it "appears" that the only default font we can find is defined in the style object and this "appeared" to be a 12 point font on the systems we tested it. So we decreased it by 2 points. If for some reason the style object isn't available we have hard coded a in a propositional font and then as a further back stop we have a fixed font. I am not sure what the point size is for the fixed font (maybe it is 20 or 18). The proportional back stop font is defined to be a 12 point font. One that would hopefully match the style object that we could find in our testing. These are all CSS3 font that are in the working draft, which most everyone hates anyway and will probably go away. (I think one reason is that the granularity of some of the user interface style is far greater than many platforms can support, except for maybe the Mac) BUT, we still need these defined and implemented in order to get the proper fonts defined as a "special" font name, so they can be overriddable by user defined style sheets or inline style. In the past we defined the font and font size in the html.css and this made it so they couldn't be overriden. So with or without CSS3 we still need this "type" of definition. I think dbaron will soon be renaming them to be -moz-button just in case the CSS3 spec changes. I hope this helps....

Okay, I guess that makes sense for Windows, where I can read the fonts. This bug is about Linux though, and I still don't understand why we change the size of the default font there. BTW, the personal toolbar is a bit better today, still tiny but at least the glyphs have all of their strokes.

Akkana does this patch fix your font size problem? Could you give it a try.

Getting fonts by pixel size checked. Thanks Brian.

I see the gfx/src/gtk checkin, but that alone doesn't cure the too-small fonts in the classic skin. Does that mean that the classic skin isn't actually using the CSS system fonts, and I should reopen another bug rather than this one?

Yes, you need to assign it to rods@netscape.com.

Filed bug 52680. There are other bugs covering this issue, but I can't find one that specifically covers only the classic skin.

Ok. There is an implementation for all the CSS2 and CSS3 fonts (i.e., using "font:'somecss3orcss2keyword';" will override the default, inherited value for font:). So, verified fixed linux 2000092512 rh6.1 In a current build, these all map to a serif font of the same size, except for: 1) 'field' which maps to a monospace font of about the same size, and 2) 'button' and 'list' which map to a sans-serif font about 2pt larger than the other fonts. Is that a (different) bug, Waqar?

I have Bug 53744 where I am reducing the font point size by 2 of the List and Button for Windows. If this is the right thing to do i could do it for Linux also.

Rod: yes, 2pt less would bring them in line with the approx. pt size of the other CSS2/3 fonts. I don't know, however, what the intent of the spec. is, so I don't know if that's "correct". I'm still curious why these two font values map to a 'serif' font.

*** Bug 33313 has been marked as a duplicate of this bug. ***