Closed Bug 33313 Opened 25 years ago Closed 23 years ago

GTK-GFX: need support for css2/css3 system fonts

Categories

(Core :: CSS Parsing and Computation, defect, P2)

Other
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: pierre, Assigned: dbaron)

References

()

Details

(4 keywords, Whiteboard: [nsbeta3-])

Attachments

(5 files)

I implemented the css system fonts in XP code and on the Mac (that was bug 3371). 
We need to complete the job in nsDeviceContextGTK::GetSystemAttribute(). It 
should be easy... and appreciated by some users who complained that the font 
sizes in the chromes are a bit small on Unix (bug 18135).

The testcase from bug 3371 is copied in the URL above.
Blocks: 18135
Blocks: 16729
Target Milestone: --- → M17
Status: NEW → ASSIGNED
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Blocks: 44806
Nominate for nsbeta3 since this is required for the Classic skin to work correctly
Keywords: nsbeta3
Keywords: correctness
Keywords: pp
nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: M21 → M18
erik....  I need to go from a GdkFont to an nsFont... any suggestions on how to
do this?  :)
Classic skin seems to work okay with the Mozilla fonts, except for the FG/BG
contrast. Only open blocker for this says 'default skin ought to use CSS2
systemfonts'.  Ben says that this 'isn't really' a requirement for Classic.
Lowering priority to P5.
Priority: P3 → P5
...which means we are no longer committing to fixing it for N6.
Since the priority of this bug has moved to P5, is it still considered nsbeta3+?
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
If I bring up a gtk application (I use kde, but can still run gtk apps and they
look fine), the menu fonts are a reasonable size and easily readable.  If I turn
on Classic skin in mozilla, the menu fonts are something like half the size of
the menu fonts in gtk apps, and they're just tiny unreadable blobs (even smaller
than the hardwired font sizes in Modern!)  I don't think this is working right. 
Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
cc ben 
Mass-moving P4/P5 bugs to Future milestone.  We just don't have any time left
for these, although we could still consider taking a good patch.  Adding
Helpwanted keyword.
Keywords: helpwanted
Target Milestone: M18 → Future
nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
Blocks: 51748
For those following this bug: 48907 also covers the same issue and may be a
better bug to track.
pav. Have a look at bug 48907. Is this bug really a duplicate (and fixed?).
sure looks like it to me. Anyone object, please reopen

*** This bug has been marked as a duplicate of 48907 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
Bug 48907 has been fixed, but this still isn't working (see test case).
Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Keywords: css2, css3
From braden@endoframe.com 2000-10-07 23:17 in bug 33312:

Actually, I can't see that CSS2 system fonts are working at all on Linux. The
attached test case gives me 12pt Helvetica for all fonts, regardless of the font
used in my GTK theme.
Braden, how do you change the font in your GTK theme?
OK, I figured out that you can change the GTK font in GNOME's Control Center.

I also figured out that you can pick up that font by calling

  GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_widget_ensure_style(window);
  GtkStyle* style = window->style;

instead of gtk_style_new() in mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp. We
might be able to implement CSS3's system fonts by instantiating several
different GTK widget classes and then getting their styles as above.
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Taking this bug from Pavlov, since it's futured/P5 on his list, and I think I
can find time to try to do this in the next few milestones.  (I think it will
improve our UI on GTK a good bit.)  Adding dependency to bug 96971 -- see my
comments there.
Assignee: pavlov → dbaron
Status: REOPENED → NEW
Depends on: 96971
Status: NEW → ASSIGNED
Priority: P5 → P2
Target Milestone: Future → mozilla0.9.5
Comment on attachment 50273 [details] [diff] [review]
above, cleaned up a bit

r=bryner
Attachment #50273 - Flags: review+
Comment on attachment 50273 [details] [diff] [review]
above, cleaned up a bit

I don't see it in the patch... I know recently there was code checked in to make all nsFont things be lowercase.. I don't think it does it automatically.. this code may need to lowercase the font names when it creates nsFont objects.
Looking at the nsFont objects passed to nsFontMetricsGTK::Init when loading my
homepage, I see (in aFont->name):

Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Tahoma,Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Verdana,sans-serif,sans-serif
Arial,Helvetica,sans-serif,sans-serif
Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Tahoma,Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Tahoma,Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Verdana,"Myriad Web",Syntax,sans-serif,sans-serif
Verdana,sans-serif,sans-serif
Arial,Helvetica,sans-serif,sans-serif
Comment on attachment 50273 [details] [diff] [review]
above, cleaned up a bit

sr=blizzard
Attachment #50273 - Flags: superreview+
I just discovered a problem here: mPixelsToTwips can change when we change
profiles, but that change isn't reflected in the stored nsFont so they appear at
the wrong size if the profile manager is used.

I'll try to come up with a better patch tomorrow.
And, FWIW, the case-sensitivity stuff Pavlov mentioned was bug 97299 and was
backed out.
Attachment #50847 - Flags: review+
Comment on attachment 50847 [details] [diff] [review]
patch fixing pref-change problem

r=bryner
I'm seeing something else funny on another machine.  Ugh.
The problem was that we were preferring XA_FULL_NAME to XA_FAMILY_NAME (the old
code used only the former).  I made the change to prefer XA_FAMILY_NAME to
XA_FULL_NAME, and also left in the debugging code (#if 0) that I've written
three times over and am tired of rewriting every time I need to debug a problem
with this code.
To be more specific, XA_FULL_NAME was "Helvetica Bold", XA_FAMILY_NAME was
"Helvetica", and XA_WEIGHT_NAME was "Bold".  nsFont::name should be set to the
family name rather than the full name.
I've tested that this new version works for bold and non-bold of both true-type
and bitmap fonts (I didn't test a bold bitmap font before).  I'm also going to
run it through the default fonts of a bunch of themes as I did for the previous
patches.
Comment on attachment 50944 [details] [diff] [review]
prefer XA_FAMILY_NAME over XA_FULL_NAME

r=bryner
Attachment #50944 - Flags: review+
Comment on attachment 50944 [details] [diff] [review]
prefer XA_FAMILY_NAME over XA_FULL_NAME

sr=waterson (just sr'ing differences from patch blizzard sr'd)
Attachment #50944 - Flags: superreview+
Could we leave this bug open until I filed a Xlib toolkit version of the patch,
please ? thx!
As far as I know, the notion of system fonts is meaningless on xlib.  That
doesn't mean the current hack couldn't be improved, but that would be a totally
different bug.

Fix checked in 2001-09-27 16:44 PDT.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
*** Bug 85616 has been marked as a duplicate of this bug. ***
*** Bug 92925 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: