48907 - nsDeviceContextGTK.cpp doesn't implement CSS 3 fonts

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[rods (gone)]

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.

Comment 1

[Kevin McCluskey (gone)]

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

Comment 2

[waqar]

working on it now.

Comment 3

[rods (gone)]

Attachment: html.css for testing

Comment 4

[Stuart Parmenter]

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

Comment 5

[Kevin McCluskey (gone)]

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

Comment 6

[waqar]

Fix checked in

Comment 7

[waqar]

Backed out the fix, problem with GTK version  number

Comment 8

[Kevin McCluskey (gone)]

Setting priority to P3 based on new criteria

Comment 9

[waqar]

Fix checked in once again.

Comment 10

[Akkana Peck]

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.

Comment 11

[waqar]

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.

Comment 12

[Peter Trudelle]

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

Comment 13

[rods (gone)]

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....

Comment 14

[Peter Trudelle]

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.

Comment 15

[waqar]

Attachment: Patch to fix the font size problem.

Comment 16

[waqar]

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

Comment 17

[waqar]

Getting fonts by pixel size checked. Thanks Brian.

Comment 18

[Akkana Peck]

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?

Comment 19

[waqar]

Yes, you need to assign it to [e-mail].

Comment 20

[Akkana Peck]

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

Comment 21

[John Morrison]

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?

Comment 22

[rods (gone)]

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.

Comment 23

[John Morrison]

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.

Comment 24

[Alec Flett]

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