Open Bug 61883 Opened 24 years ago Updated 1 year ago

Smarter default prefs for the 5 basic CSS fonts

Categories

(Core :: CSS Parsing and Computation, enhancement, P5)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

People

(Reporter: ve3ll, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: intl, testcase, Whiteboard: (py8ieh: extract testcases))

Attachments

(6 files, 7 obsolete files)

testcase for strike-out
1.22 KB, text/html
Details
Fonts prefs dialog of Opera
29.58 KB, image/gif
Details
Set Windows default Cursive to Segoe Script
3.11 KB, patch
Kwan
: review?
jtd
Details | Diff | Splinter Review
Set Windows default Fantasy to Impact
2.94 KB, patch
Kwan
: review?
jtd
Details | Diff | Splinter Review
Before and After (both patches)
37.26 KB, image/png
Details
Add Segoe Script to the talos whitelist
847 bytes, patch
jmaher
: review+
Details | Diff | Splinter Review 
my site uses font-family: cursive on all h1 elements
but mozilla does not show a cursive script fontface...
someone should set pointer to a more appropriate selection
also the fantasy generic fontface is anything but !!!
once again including and pointing at an appropriate face 
is necessary.  These generic fonts are the fallback for
fontstyles not included on a users machine and should 
be reasonably close to the style they say they are ...
confirming this bug.  mpt says it's also a problem on mac, so OS -> all.

This is _not_ a duplicate of bug 28899.

This bug is about having reasonable defaults for the "fantasy" and "cursive"
fonts regardless of whether there is a UI for changing these defaults.
Assignee: asa → pierre
Status: UNCONFIRMED → NEW
Component: Browser-General → Style System
Ever confirmed: true
OS: Windows 98 → All
QA Contact: doronr → chrisd
Summary: generic font not appropriate ones → fantasy and cursive font faces need reasonable defaults
The offending code appears to be at
<http://lxr.mozilla.org/mozilla/source/cmd/xfe/fonts.c#169>, where we define 
one (1) default typeface for each family. If the user doesn't have this 
typeface (or a typeface with a similar name) on their system when they create 
their profile, Mozilla falls back to something completely un-fantasy-like or
un-cursive-like or whatever.

This also means that we can't do things like preferring Courier New over 
Courier, even though Courier New looks nicer, because if we specify "Courier 
New" and the user only has Courier, we won't find anything so we'll end up with 
Times or whatever.

So, what I think we should probably be doing instead is specifying a set of 
typefaces for each family -- so on creation of the profile, if the user doesn't 
have the first in the list for a given family, the default will fall back to 
the next in the list, and so on. This would be more reliable, and would also 
allow for greater precision in specifying nice fonts.

So we'd have something like this:
default == {"Georgia", Times New Roman", "Times", "Roman"}
serif == {"Times New Roman", "Times", "Roman", "New York"}
san-serif == {"Trebuchet", "Verdana", "Arial", "Helvetica", "Sans"}
monospace == {"Courier New", "Courier", "Andale Mono", "Mono"}
cursive == {"Zapf Chancery", "Chancery", "Brush", "Script"}
fantasy == {"Desdemona", "Copperplate", "Blackletter", "Old English", "Gothic"}
Hardware: PC → All
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
The file that <mpt> pointed at has long been outdated ("mozilla/source" contains 
the old 5.0 code base).  The fonts are defined in the different js pref files 
(macprefs.js, unix.js, winpref.js).  On the Mac, we have the following 
declarations for cursive and fantasy.  They seem reasonable to me.

pref("font.name.cursive.x-unicode", "Apple Chancery");
pref("font.name.fantasy.x-unicode", "Gadget");
pref("font.name.cursive.x-western", "Apple Chancery");
pref("font.name.fantasy.x-western", "Gadget");

On Windows, I agree, our fonts don't look good.  IE5 uses "Lucida Handwriting" 
for cursive, which is a good choice, and "Matisse ITC" for fantasy, which I don't 
like.  "Comic Sans MS" would be better, at least it is legible.

Reassigned to erik to make the changes on Windows and check if Unix needs better 
default fonts too.
Assignee: pierre → erik
I don't think Pierre's suggestions are going to help the situation much. The 
basic problem is not that we need *different* defaults, it's that we need
*multiple* defaults for each family. This is probably what IE does; unlike 
Pierre, I can't believe that IE expects every Windows user to have Matisse or 
Lucida Handwriting installed, and I suspect that those fonts are just the first 
ones which IE found from a long list of possible defaults.

This is most important for `cursive' and `fantasy' -- we can't be at all sure 
that the user has Apple Chancery, or Comic Sans MS, or whatever other font we 
choose, installed. For those two families, we need a list of possible defaults, 
in order of preference, to increase the likelihood that the user will have at 
least one of them. (A nice thing about this list is that it wouldn't need to be 
platform-specific.)

But it's also important for the other font families. Mozilla should prefer 
Courier New over Courier, for example, because Courier New has better rendering 
at small sizes. But currently, the default is just `courier', which will match 
Courier rather than Courier New, and that's bad.

As another example, a Linux user might have downloaded and installed the 
Georgia font from Microsoft. If they have done so, Mozilla should certainly 
default to using Georgia instead of Times for the `serif' family, because 
Georgia is more elegant and readable (especially at small sizes) than Times is. 
But because we only have one default per family, we can't do that -- we have to 
specify `times', since that's relatively safe, even though that will result in 
defaulting to Times (which is quite ugly) in preference to Times New Roman 
(which is better).
We don't need to do all that if we fix bug 28899.  Let's just use better fonts as 
defaults in the prefs.js files.

There has been some discussion about having more than one font for each
category. See also bug 72125:

  http://bugzilla.mozilla.org/show_bug.cgi?id=72125
Erik is leaving :-(, I'll take the bug back.
Assignee: erik → pierre
Target Milestone: --- → mozilla0.9.1
As Boris already said, this bug would *not* be fixed by bug 28899. Mozilla 
should have accurate defaults for each family, regardless of whether there is a 
UI for changing the fonts from those defaults. We can't just use `better 
defaults', because we can't be sure that the user has *any* particular single 
default font installed on their system.

As far as I can see, having multiple possible defaults is the only possible 
method of picking sensible defaults for everyone -- short of getting someone to 
create some MPLed fonts and bundling those with Mozilla.
I like the idea.  It would allow us to potentially have the same default fonts on 
all platforms and use the Microsoft fonts if they are installed.  Changed the 
summary line from "fantasy and cursive font faces need reasonable defaults" to 
"Smarter default prefs for the 5 basic CSS fonts".

Matthew, what would be your favorite default fonts on Windows and Unix?
Status: NEW → ASSIGNED
Summary: fantasy and cursive font faces need reasonable defaults → Smarter default prefs for the 5 basic CSS fonts
A mechanism that allows to specify several fonts as possible candidates for the 
default font already existed on Windows.  I reused it on the Mac.  Someone needs 
to implement it on Unix.

Here is what it looks like in the prefs file:
   pref("font.name.cursive.x-unicode",      "Lucida Handwriting");
   pref("font.name.cursive.x-unicode.1",    "Zapf Chancery");
   pref("font.name.cursive.x-unicode.2",    "Chancery");
   pref("font.name.cursive.x-unicode.3",    "Comic Sans MS");

If "Lucida Handwriting" is not installed, we try "Zapf Chancery", then "Chancery" 
etc...

Simon, please review the changes on the Mac.  The new defaults are "Times New 
Roman" and "Courier New" instead of "Times" and "Courier".  Using "Times New 
Roman" revealed a bug with the strike-out.  Note that the strike-out is not 
exactly in the middle of the lower-case characters in "Times New Roman".  IE has 
the same problem: I'm going to attach a testcase.

Franck, please review all the changes, especially in the prefs files. I did not 
really change the non-western scripts except for "zh-CN" where we try "MS Song" 
and "MS Hei" before trying "Song" and "Hei".
Attached patch patch (obsolete) — — Splinter Review 

    
  
Whiteboard: [fix in hand]

    
    

    
  
Why can't the "font.name" prefs contain CSS-style font strings, like:
	pref("font.name.cursive", "Zapf Chancery, Chancery, Brush, Script, serif"); 
?
That avoids the need for these verbose .1, .2, .3 prefs.


    
    

    
  
That's what I wanted to do at first but when I saw the Windows code, I thought 
that we should keep the compatibility with 6.0.  I'm realizing now that these 
prefs files are not in the user prefs folder but inside the application folder, 
so we change the format.  I'll do it.


    
  
Whiteboard: [fix in hand]

    
    

    
  
See also bug #51984. Feel free to mark that as an dependency.

    
    

    
  
Bug 55194 is about font sizes, not font families.  It is related to the screen 
resolution and many other things.  A real can of worms, if you want my opinion.  
Erik and I ate most of them but there are a few left.  Please help yourself :-p


    
    

    
  
> Bug 55194 is about font sizes, not font families.

You mean bug #51984? Bug #51984 is about font sizes *and* the default font 
family.

    
    

    
  
You're right.  I'm going to put a note there.


    
    

    
  
Here is the new patch for Mac, Windows and Unix, with the pref.js files for Mac 
and Windows.

But beware: I did not compile on Windows and Unix!!!

>>> Erik: could you test and review on these 2 platforms, or suggest another reviewer if you are too busy?  If you want, you can change the unix prefs file and add more font choices like on Mac and Windows.

The test that should be done is to feed the code with a font family that contains  
a font name that doesn't exist followed by a font name that you know will no be 
picked up as a hard-coded default.  For instance, try this on Windows:

pref("font.name.serif.x-western",  "foo, Comic Sans MS, Times New Roman, Times");
pref("font.name.serif.x-unicode",  "foo, Comic Sans MS, Times New Roman, Times");

As a result, your default (serif) font should be "Comic Sans MS".

>>> Franck & Simon, please review, especially the i18n part for Franck.

Whiteboard: [fix in hand]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch #2 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Cc'ing Brian for Unix and Shanjian for Windows. Guys, please take a look at
these patches.

    
    

    
  
Yes, as I said to Shanjian earlier, the .1, .2, .3 method is one solution to
this problem. Simon's and Pierre's comma-separated list is another solution
(and is the one I originally had in mind a long time ago).

Again, as I said to Shanjian earlier, it would be nice if we also modified the
font prefs front-end to match the new font back-end. I.e. the font prefs UI
should show whatever font would be chosen by the back-end, even when the user
starts Mozilla for the first time and has not changed any of the fonts yet.
This means that if the back-end is going to parse a comma-separated list and
choose the first one that exists in the user's environment, then the font prefs
UI should also do such parsing/checking.

    
    

    
  
In the Mac code --
What is this change:
-  aOffset = NSToCoordRound(float(mMaxAscent / 2) - dev2app);
+  aOffset = NSToCoordRound(float(mMaxAscent * 0.71f / 2));  // half GetXHeight 
?

+    // strip leading spaces
+    while (isspace(*token)) ++token;

Stripping trailing spaces also would make this more robust to pref strings like
"Times , Times New Roman "

And doesn't this need to be:

    while (*token && isspace(*token)) ++token;

I've always found it odd that we allocate ns[Auto]Strings, rather than just 
keeping nsStrings in the font mapping struct. Allocating nsAutoStrings is 
wasteful of space.
+  nsString *fontname = new nsAutoString(valueInUCS2);
...
+  Self->mGenericFontMapping[script][type] = fontname;

Have you deleted the string by accident here?
+      delete fontname;


Windows code:

The string ownership for the last param here is confusing; it would be nice to 
fix it. It seems that there are code paths inside of LoadGenericFont that can 
lead to tokenDup not being owned or freed, so you should really test it for null 
after this call, and delete it if non-null. But why not just pass a const char* 
to begin with, that LoadGenericFont copies if it needs to?
+          font = LoadGenericFont(aDC, aChar, &tokenDup);


    
    

    
  
Here's some comments on the font suggestion mentioned in bug #51984 (Windows 
fonts):

  serif:       "Times New Roman, Times"

My suggestion: "Minion Web", Georgia, "Times New Roman"

Minion Web is designed to look great on computer monitors, and it does! A very 
nice, easy to read font. It's part of the Adobe Web Fonts pack, which most 
people don't have, but there's no *harm* in including it (first) in the serif 
list (since it looks vastly better than Times NR). Georgia doesn't look to bad, 
but doesn't have enough leading (line height), IMHO.

  sans-serif:  "Arial, Verdana"

"Arial Unicode MS", Arial, "Trebuchet MS", Verdana

'Arial Unicode MS' is an almost complete Unicode font based on 'Arial'. It 
comes with MS Office 2000. Personally, I prefer 'Trebuchet MS' over 'Arial'. 
It's very easy to read, and looks good in most font sizes.

>  monospace:   "Courier New, Courier, Andale Mono"

"Andale Mono", "Courier New", Courier

Courier (New) is old, and doesn't look very good on screen. Andale Mono is much 
better. Also 'Lucida Typewriter' (or something like that, I can't rememember) 
is very nice.

  cursive:     "Lucida Handwriting, Zapf Chancery, Chancery, Comic Sans MS"

'Comic Sans MS' isn't what I would call a cursive font. Can't we just let 
Mozilla search through all fonts for a font marked as cursive if none of the 
other fonts are found?


    
    

    
  
Oh, I forgot -- 'Myriad Web' should be the first choice for 'sans-serif'.

    
    

    
  
> Matthew, what would be your favorite default fonts on Windows and Unix?

The following suggested prefs for Western are based on the suggestions here, 
usability studies (e.g. <http://wsupsy.psy.twsu.edu/surl/usabilitynews/3W/
fontSR.htm>), fonts known to be often installed on Windows, Linux, and Mac OS, 
and informal tests at sizes between 8px and 24px in aliased and anti-aliased 
modes to compare the readability of various fonts. They're also designed to 
gracefully degrade even on a system which doesn't (for example) have a font 
installed with `Times' in its name.

------
/* defaults for "Normal" -- i.e., no font (or an unknown font) is specified */
pref("font.name.default.x-unicode", "Minion Web, Georgia, Times New Roman, 
Times, roman");
/* defaults for "serif" -- and yes, the placement of "Times" is deliberate */
pref("font.name.serif.x-unicode", "Times New Roman, Palatino, Book Antiqua, 
Times, roman");
/* defaults for "sans-serif" */
pref("font.name.sans-serif.x-unicode", "Myriad Web, Lucida Sans Unicode, Lucida 
Sans, Trebuchet MS, Trebuchet, Verdana, Arial Unicode, Arial, Helvetica, 
Geneva, sans");
/* defaults for "monospace" -- serif fixed fonts are generally more readable */
pref("font.name.monospace.x-unicode", "Courier New, Courier, Andale Mono, 
Monotype.com, monospace, console, mono");
/* defaults for "cursive" -- sorted, like the others, in order of legibility */
pref("font.name.cursive.x-unicode", "Lucida Handwriting, Apple Chancery, Zapf 
Chancery, Swing, Mistral, Brush Script, chancery, cursive, script, brush");
/* defaults for "fantasy" -- we assume larger font sizes will be used here */
pref("font.name.fantasy.x-unicode", "Revolution, Arnold Böcklin, Arnold 
Boecklin, Korinna, Benguiat, Kino, Linotext, fraktur, blackletter, copperplate, 
Gadget");
------

(If you're wondering why Lucida Typewriter, Lucida Sans Typewriter, or Lucida 
Console aren't in the list for `monospace', it's because they're actually not 
technically monospace fonts. Narf.)

    
  
Blocks: 73734

    
    

    
  
Pierre: I'm working on the FE for this (bug 28899). could I just ask a couple of
things?

When are you going away?
Are you planning to check in the back end to this before then?
Would it be OK to just check in the back end on its own now and let us sort out
the default font prefs at our leisure later? Or would that break stuff?

Gerv

    
    

    
  
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

    
    

    
  
Brian, Shanjian or someone else: please review the changes on Windows and Unix.  
You need to compile and run with them, and do the test indicated in my comments 
from [2001-04-27 04:55]

Gerv: I'm leaving on sabbatical this Friday (May 4th).  I would very much like to 
checkin the back-end code with the font names issued from the study pointed to by 
Matthew.  If I don't get code-reviews on Windows and Unix, I'll checkin on the 
Mac and reassign.

Simon:
- It is more correct for the height of the strike-out line to use half the height 
of a lower-case character rather than half the height of an upper-case character 
minus one pixel.
- Skipping trailing spaces would be nice, I'll do it.
- We don't need to test for *token because isspace(0) is false.
- |delete fontname| should be there.  When we find a good font name, it is copied 
to the nsUnicodeMappingUtil table and the |break| makes us skip the |delete|.
- It's not in my plans to fix the awkward allocation schemes and ownership models 
we have here.  Not my code, I fix just what I need.  The length of my bug list 
makes me selfish sometimes :-(

Thank you all.


    
    

    
  
Pierre: here are the build errors I got when trying to build on Linux:

*nsFontMetricsGTK::FindGenericFont (short unsigned int)':
nsFontMetricsGTK.cpp:3092: cannot convert `char *' to `char' in
assignment
nsFontMetricsGTK.cpp:3105: cannot convert `char *' to `char' in
assignment
nsFontMetricsGTK.cpp:3108: invalid type argument of `unary *'
nsFontMetricsGTK.cpp:3109: invalid type argument of `unary *'
nsFontMetricsGTK.cpp:3118: cannot convert `char *' to `char' in
assignment
gmake[4]: *** [nsFontMetricsGTK.o] Error 1
gmake[4]: Leaving directory `/usr/src/mozilla/gfx/src/gtk'
gmake[3]: *** [install] Error 2
gmake[3]: Leaving directory `/usr/src/mozilla/gfx/src'
gmake[2]: *** [install] Error 2
gmake[2]: Leaving directory `/usr/src/mozilla/gfx'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/usr/src/mozilla'
gmake: *** [build] Error 2

I am attaching the patch I used; your patch didn't apply cleanly to my tree, so
I may have messed things up. I've also incorporated mpt's font list changes.

Please investigate this :-)

Gerv

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Updated (?) patch (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Pierre: I got this to build. Your problem is that, on line 3087 of
nsFontMetricsGTK.cpp, you say:
    char* newStr, token;

This was causing problems, because this actually means:
   char *newStr, token;
which makes token a char, not a char*.
You need:
    char* newStr;
    char* token;
or
    char *newStr, *token;

However, once I built it, the code doesn't seem to work. I fed it:
pref("font.name.serif.x-western", "foo, adobe-times-iso8859-9,
adobe-times-iso8859-1");
pref("font.name.sans-serif.x-western", "foo, adobe-helvetica-iso8859-1");
pref("font.name.monospace.x-western", "foo, adobe-courier-iso8859-1");

and all my fonts came out as adobe-courier-iso8859-1, which, not coincidentally
I think, is the first thing in my fonts list.

Hope this helps,

Gerv

    
    

    
  
Stealing this bug while pierre is away.
I faced an identical problem when defining a mechanism by which to specify 
multiple default fonts for certain stretchy mathml characters. I am going to 
apply the idea I got for that here. A bit different from pierre's current 
implementation but it is a very effective scheme when you come to think about 
it. And it should ring bells to pierre and erik :-) The idea is this: just 
initialize the comma-separated list of fonts to a dummy nsFont(fontlist,0,0,0,0) 
and use the *existing* font-enumerator callback mechanism that nsFont has. This 
will loop over the fonts for free... and my callback function can check for 
existence of the current font and can then retain or reject it as appropriate.
Assignee: pierre → rbs
Status: ASSIGNED → NEW
Whiteboard: [fix in hand]

    
    

    
  
rbs: it's fantastic that you are taking this bug :-) However, there's another 
thing you should be aware of. I was discussing with MPT the best way to have a 
unified set of default fonts, and we came up with a problem on Linux. If you are 
setting defaults for e.g. Arabic, the fonts on Linux are those with iso8859-9 in 
the name. However, you can't easily specify, using Pierre's current mechanism, 
that a font should have that string *and* times, or helvetica, or whatever, as 
well. 

Do you have any ideas about this problem? 

I don't think that unifying default fonts across platforms is a big deal - if we 
can't do it, we can't do it - but it would be good, in any case, to have a 
solution to the above.

Gerv

    
    

    
  
Implementation-wise, rather than getting the pref value and parsing it at each
FindGenericFont() - which happens quite freqently I might add, and could be a 
perf hit, I would set nsStringArray* gSerif, *gCursive, etc. [As usual, there 
could be some slight variations when actually coding. But that would be the 
general idea.]

Being an array of strings, I could put anything in each entry and do a second
level of filtering in FindGenericFont(), i.e., the font at gSerif[i] would be
retained if it satisfis some other criteria that is/should be relatively
inexpensive to check.

So your problem is that you want to specify:

pref("font.name.serif.x-western", 
     "foo, bar, adobe-times-iso8859-9, adobe-times-iso8859-1");

but selectively ignore or retain all *-iso8859-9 xor (exlusive or)
all *-iso8859-1 ?

    
    

    
  
I don't quite understand what you are saying, but we want to say something like:

"For Arabic (font.default.ar.serif) we are looking for a font which:
a) contains the string iso-8859-9 AND
b) contains one of (in preferential order) "times, homerton, fontfamily1,
fontfamily2"."

Does that answer your question?

Gerv

    
    

    
  
Yes, it can handle that. Let's just agree on a formal specification that is 
suitable for automatic processing. E.g, let's say, 

<spec>
By convention, a list of multiple default fonts in Mozilla should be specified 
as:

font.default.LANGGROUP.GENERIC ::= CHARSET, fontfamily1 [, fontfamily2 ...]

where 
- LANGGROUP is one of the language groups (e.g., 'ar' for Arabic) 
- GENERIC is one of the 5 basic CSS fonts (e.g., serif, cursive, etc...)
- CHARSET is one of the iso charsets (e.g., iso-8859-9). If CHARSET is a 
star '*', then any font on the system that will match the name will be retained. 
Otherwise, a font will be retained only if it matches the name and the charset. 
Note that certain platforms (e.g., Windows) may ignore the CHARSET attribute.
</spec>

Hence for exemple, the list of default fonts for Arabic could be given as:
font.default.ar.serif = iso-8859-9, times, homerton, fontfamily1, fontfamily2

That is, the 'first font' is in fact, by convention, the charset string, and
it is intended to be honored on platforms where it is applicable.

That was a initial go at the specification. Now you could ruminate over it
and iterate to add further changes and make it more complete.

    
    

    
  
Comments:

GENERIC can also be "default", because eventually we will have support for 
setting a font to be used when none is specified. At the moment, you have the 
choice of "The one you set for serif" or "The one you set for sans-serif" but 
this will be expanded to make it an independent choice. 

I think that this _should_ cover it. mpt may have comments, however.

Would it be sensible to produce a "font selection wishlist" - how we'd like it 
to work ideally? It strikes me that, having got that, if you are in the font 
code and see how something could be done easily, then we could kill several 
birds with one stone, but if you don't know about it it will pass you by... For 
example, the aforementioned RFE must just involve a simple rearrangement to the 
font selection logic...

Gerv

    
    

    
  
> must just involve a simple ...
Although I summarized in a way that made things sound easy, it may get trickier 
as details unfold (witness pierre's implementation or the fact that you had 
troubles understanding my earlier explanations. So beware of 'simple'... :-)

Let's say the 'default' GENERIC is given as:

font.default.LANGGROUP.default = default-list

what you mean is that any specific list should be conceptually viewed as if
the default-list was appended to it as a fall-back list, right? That is:

font.default.LANGGROUP.GENERIC ::= specific-list , default-list
(where either list could be empty)

OK, go ahead with your wishlist, sounds interesting but I won't bet on anything.

    
    

    
  
If you look in Mozilla's current font prefs (which I am rewriting over in bug 
28899) you can choose a font for Serif, Sans Serif and Monospace. Then, you can 
choose "Default Type" as either "Serif" or "Sans Serif" - that is to say, when 
no font is specified, Mozilla will either use the font you have set as Serif or 
the one you have set as Sans Serif, as appropriate.

Therefore, somewhere in the code, it says "What font shall I use for this page 
where no font is specified (the common case)?", then looks at the value of that 
radiobutton and picks the relevant font name from either the ".serif" pref or 
the ".sans-serif" pref. 

The change would be to have it pick the fontname directly from a ".default" 
pref - i.e. have an independent list for this purpose.

If you see mpt's comments on 2001-04-29 05:35, you will see what the font prefs 
will hopefully eventually look like. The reason "default" is separate and you 
don't just choose one of the others is that e.g. Minion Web doesn't fit into 
either the serif or sans-serif categories very well, but is an excellent default 
font.

The wishlist basically means being able to implement the following UI (courtest 
of mpt):

    Fonts ::::::::::::::::::::::::::::::::::::::
                                                
    +-Fon_ts for: [default choices         :^]-+
    | :/: _Use dflt. choices for this encoding |
    | _Proportional: [Georgia      :^][  14:^] |
    |    _Monospace: [Courier New  :^][  12:^] |
    |        _Serif: [Times New Rom:^][  14:^] |
    |   Sa_ns-serif: [Trebuchet    :^][  12:^] |
    |      _Cursive: [Zapf Chancery:^][  16:^] |
    |      _Fantasy: [Desdemona    :^][  16:^] |
    | [ ] Minimum font si_ze:         :   8:^: |
    +------------------------------------------+
    [/] Allow documents to use _other fonts     
    For plain te_xt, use: [Monospace         :^]

I.e. the ability to set the font, and the size, for each CSS family and for 
"default" (no family specified) independently, the ability to set a minimum font 
size, and the ability to render plain text in any one of the families.

Gerv

    
    

    
  
> Minion Web doesn't fit into either the serif or
> sans-serif categories very well,

Minion Web is clearly a serif font. See <URL: http://home.no.net/huftis/nynorsk-
programvare/abiword/bilde/eksempel.png >, where the body text is written in 
Minion Web.

> but is an excellent default font.

Yup!

    
    

    
  
To have an idea of what was going on first in this area, I put some printfs in 
FindGenericFont() and related functions. To my surprise, I have noted that the 
current behavior also searches fonts in any language no matter the default.
I.e., if the code is  for example searching for a 'serif' font, not only will
it look in the specified font for 'x-western', but it also expands the search 
amongst the serif fonts listed for other language groups as well. Below is a 
sample output of fonts that are passed to LoadGenericFont (some calls obviously 
resulting in failure) when viewing a page with characters for which I knowingly 
don't have fonts on the system. 

Anyone care to elaborate on the rationale here? (I had no idea that things
were going on like that and could have erroneously broken this behavior at my 
future attempt at fixing this bug)

font.name.serif.x-western : Georgia
font.name.serif.x-western : Times New Roman
font.name.serif.ja : n+¡n+¦ n+¦µÿĵ£¥
font.name.serif.ja : n+¡n+¦ n+¦µÿĵ£¥
font.name.serif.zh-CN.1 : MS Song
font.name.serif.zh-CN.1 : MS Song
font.name.serif.tr : Times New Roman
font.name.serif.tr : Times New Roman
font.name.serif.x-cyrillic : Times New Roman
font.name.serif.x-cyrillic : Times New Roman
font.name.serif.zh-CN : s«ïS+ô
font.name.serif.zh-CN : s«ïS+ô
font.name.serif.ko.1 : Gulim
font.name.serif.ko.1 : Gulim
font.name.serif.zh-TW : t¦¦µÿÄT½ö
font.name.serif.zh-TW : t¦¦µÿÄT½ö
font.name.serif.x-unicode : Times New Roman
font.name.serif.x-unicode : Times New Roman
font.name.serif.zh-TW.1 : MingLiU
font.name.serif.zh-TW.1 : MingLiU
font.name.serif.el : Times New Roman
font.name.serif.el : Times New Roman
font.name.serif.ja.1 : MS PMincho
font.name.serif.ja.1 : MSPMincho
font.name.serif.he : Times New Roman
font.name.serif.he : Times New Roman
font.name.serif.x-central-euro : Times New Roman
font.name.serif.x-central-euro : Times New Roman
font.name.serif.ar : Times New Roman
font.name.serif.ar : Times New Roman
font.name.serif.x-western : Georgia
font.name.serif.x-western : Times New Roman
font.name.serif.x-baltic : TimesNew Roman
font.name.serif.x-baltic : Times New Roman
font.name.serif.ko : O¦¦dª+
font.name.serif.ko : O¦¦dª+

    
    

    
  
Sorry guys, I haven't been able to read the comment of this bug for quite some 
time. I took some responsibility of font related problem after erik left, though 
not officially. 

Respond to rbs's recent post:
The general idea of FindGenericFont is, try the default generic font for that language 
group first. If the font is not found or the font does not contains the glyph for 
our desired character, we enumerate all font in the specified font family, regardless
what language group they are, and return the first font that contains the glyph. 
If that is not found either, we will try other means, such as global font. 



    
    

    
  
If the generic fonts of a langGroup are now given as a list of multiple fonts, 
would that still be necessary to lookup the lists from other langGroups? I would 
think one could just do:
1) try the list of generic fonts specfied for the given langGroup
2) go straight to the global list

as opposed to the current approach which does:
1) try generic fonts specfied for the given langGroup
2) try generic fonts specfied for all other langGroups
3) try the global list  
or maybe there are some valid reasons that I don't know for this approach?


    
    

    
  
There seem to be several threads of information in this bug:

 1) "factory supplied" (default) font lists
    multiple fonts in each list
    a list per CSS font type
    different lists for each language group

 2) user settable font lists
    multiple fonts in each list
    a list per CSS font type
    different lists for each language group

 3) programatic font fallback schemes when the list fails
    

Number 1 (which I like) will grow large when we consider languages; ie:

  default == {"Georgia", Times New Roman", "Times", "Roman"}
  serif == {"Times New Roman", "Times", "Roman", "New York"}
  monospace == {"Courier New", "Courier", "Andale Mono", "Mono"}
  cursive == {"Zapf Chancery", "Chancery", "Brush", "Script"}
  fantasy == {"Desdemona", "Copperplate", "Blackletter", "Old English", 
"Gothic"}

for lang groups:

  ar, el, he, ja, ko, th, tr, x-baltic, x-central-euro, 
  x-cyrillic, x-western, zh-CN, zh-TW

That's 4 fonts for 13 language groups = 52 items. This is
not infinite and will probably produce good results. This
seems doable for a factory supplied (read no UI) list.

I have know idea how one would make a useable UI for #2 if one
considers lang groups and multiple values in each list. 
However, having a single value per CSS font type and different 
settings for each lang group seems possible and would probably 
make most users happy when combined with #1.

Number 3 is fairly tricky because we support many languages. 
Consider the case of a Japanese user displaying a Japanese 
document that contains characters that are not in the font list 
for the document's lang group (Japanese). We need to find good 
looking glyphs. Thus we probably want to look at the other 
preferences the user has set as a way to figure out what to do. 
Just picking any font tends to produce poor results (which is 
the very thing this bug is about).

If the prefs don't help us find the needed glyphs the we should
also look at:

  all fonts in the documents language group
  all fonts in the user's locale's language group


    
    

    
  
1) - exactly right. :-)

For 2), the second thing you suggest is what is going to happen (see bug 28899). 
There seems to be a touch of confusion; I believe the idea here is to have 
multiple feedbacks for the default, chosen at app install time (basically), but 
only a single "current" value. The font for each family in each lang group would 
be selected from a list of all suitable fonts on the system ("suitable" to be 
defined.)

We do not need to do 3) if we can construct the default lists so that they hit 
_something_ in 99.9% of all users' installs. This shouldn't be too hard if the 
last entry in each list matches a system font of some sort.

Gerv


    
    

    
  
Correction:

> That's 4 fonts for 13 language groups = 52 items. 

That should be 6 CSS font types * 4 fonts * 13 language groups = 312
which is still quite doable for a factory supplied list.


    
    

    
  
Some futher implementation notes in the direction where I will be heading.
Here are the data structures that I am thinking of using (not definitive
since the real implementation could introduce variations...)

////////////////////////////////////////////////////////////
// Code to handle the basic CSS generic fonts via a flexible
// pref-controlled interface. See bug 61883 and bug 28899.

// struct to encapsulate the family-list associated to a language group
struct nsPrefFontGroup
{
  // language group associated to this data
  nsCOMPtr<nsIAtom> langGroup;

  // charset of the language group (can be used to filter fonts)
  nsCOMPtr<nsIAtom> charset

  // family-list associated to the language group
  // The first font is the current font selected by the user
  // on the dialog, the others are pre-built (XXX could possibly
  // be determined at application install time).
  nsStringArray fontName;
}

// struct to encapsulate the overall collection of user's preferred fonts
// and some of their attributes (e.g, font-sizes and minimum font-size)
struct nsPrefFonts
{
  enum {
    eGeneric_serif,
    eGeneric_sans_serif,
    eGeneric_monospace,
    eGeneric_cursive,
    eGeneric_fantasy,
    eGeneric_COUNT
  };

  // default fonts to be used for documents with no specified fonts
  nsString defaultVariableFont; // a.k.a. 'Proportional' font
  nsString defaultFixedFont;    // a.k.a. '-moz-fixed' font

  // preferred fonts for each of the generic CSS font groups
  nsPrefFontGroup fontGroup[eGeneric_COUNT];

  // preferred font-sizes for each of the font groups
  nscoord size[eGeneric_COUNT];

  // preferred minimum allowable font-size
  nscoord minSize;
}


    
    

    
  
>   // preferred minimum allowable font-size
>   nscoord minSize;

This needs to be an array - minSize[eGeneric_COUNT] - as it will be 
independently-set for the different families.

So you have an nsPrefFonts for each encoding (e.g. Western, Japanese), right? If 
so, why are langGroup and charset in nsPrefFontGroup?

Why are defaultVariableFont and defaultFixedFont not nsPrefFontGroups? Or why 
are the other font lists not just strings?

Maybe I'm misunderstanding what nsPrefFontGroup does. Could you give a 
conceptual mapping from these data structures to the current UI?

Gerv

    
    

    
  
Good feedback. Here is an update... (nsPrefFontGroup is gone)

1 - There will be only one instance of |nsPrefFonts|, say gPrefFonts, during
the life-time of the application (i.e., it will map to one subset of the
'bigger' factory supplied collection).

2 - gPrefFonts will be kept in sync with the dialog. So if a user switches
from 'Western' to 'Japanese' for example, gPrefFonts will switch from the
Western subset to the Japanese subset.

3 - I have changed defaultVariableFont and defaultFixedFont to be arrays, 
although if they are meant to map to, e.g., 'serif' as in the present menu, 
there could just be a single string. However, if the 'grand' plan is to let them 
map to an arbitrary list of specific fonts, then using the array will ease the 
transition in the future. The usual disclaimer applies ('non definitive for 
now')
==================================

struct nsPrefFonts
{
  enum {
    eGeneric_serif,
    eGeneric_sans_serif,
    eGeneric_monospace,
    eGeneric_cursive,
    eGeneric_fantasy,
    eGeneric_COUNT
  };

  // language group associated to this data
  nsCOMPtr<nsIAtom> langGroup;

  // charset of the language group (can be used to filter fonts)
  nsCOMPtr<nsIAtom> charset

  // default fonts to be used for documents with no specified fonts
  nsStringArray defaultVariableFont; // a.k.a. 'Proportional' fonts
  nsStringArray defaultFixedFont;    // a.k.a. '-moz-fixed' fonts

  // preferred fonts for each of the generic CSS font groups.
  // The first font in each array is the current font selected by
  // the user on the dialog, the others are pre-built (XXX could
  // possibly be determined at application install time).
  nsStringArray defaultFont[eGeneric_COUNT];

  // preferred font-sizes for each of the font groups
  nscoord size[eGeneric_COUNT];

  // preferred minimum allowable font-sizes
  nscoord minSize[eGeneric_COUNT];
}


    
    

    
  
> 2 - gPrefFonts will be kept in sync with the dialog. So if a user switches
> from 'Western' to 'Japanese' for example, gPrefFonts will switch from the
> Western subset to the Japanese subset.

You realise that we need to remember the user's selections for encodings other 
than the current one? Will this be done by writing them out to Prefs and reading 
them back later?

As I see it, the state we have is as follows:

1) Default font lists. These are hard-coded in prefs, perhaps on a 
platform-specific basis, and are compared, in order, to the list of fonts the OS 
gives us, to see which ones get picked by default when Moz first runs, or when a 
new ("Western" / "Japanese" / ...) ( <- what are these things actually called? 
I've been using encoding, but I think that's the wrong word) is chosen. This is 
what's been started in the last patch attached to this bug, with the Unicode 
fonts.

2. Current font lists. These are the lists of fonts available on the system 
which can be selected from a given dropdown. Because the user may add and remove 
fonts, these lists need to be generated at the time the dialog is accessed. 
Don't they? There is one list for each font family for each 
"Western"/"Japanese"/... .

3. Current font selections. 6 font names per "Western"/"Japanese"/... . 

Is that right?

> 3 - I have changed defaultVariableFont and defaultFixedFont to be arrays, 
> although if they are meant to map to, e.g., 'serif' as in the present menu, 
> there could just be a single string. However, if the 'grand' plan is to let > 
them 
> map to an arbitrary list of specific fonts, then using the array will ease the 
> transition in the future. The usual disclaimer applies ('non definitive for 
> now')

Yes, eventually the user will have a list of fonts to choose from. I assume your 
earlier point about the first one in the list being the currently-selected one 
still applies?

Do we need to make a distinction between the default fixed font and the one used 
with CSS Monospace? Can they not be unified? (This may require asking mpt.)

>   // default fonts to be used for documents with no specified fonts
>   nsStringArray defaultVariableFont; // a.k.a. 'Proportional' fonts
>   nsStringArray defaultFixedFont;    // a.k.a. '-moz-fixed' fonts

These also need a size and a minSize. Would it not be easier just to roll them 
into the defaultFont arrays?

Gerv

    
    

    
  
>You realise that we need to remember the user's selections for encodings other 
>than the current one? Will this be done by writing them out to Prefs and 
>reading them back later?

That's how it works now, isn't it? It will be something for you to take care on 
the JS side using hooks provided to persist prefs data, it will be the same on 
all platforms. Whereas if done on the back-end, it will just be a lot of bloat 
on all platforms... So what I will be doing is to make the back-end listen to 
the changes and update itself.

>... I assume your 
>earlier point about the first one in the list being the currently-selected one 
>still applies?

Yes, it does. There are eGeneric_COUNT + 2 arrays. Each array is meant to 
contain the list of font-names, with the first in the list intended to be the 
current selected font.

Having the variable and fixed arrays separate will keep the code more readable
for other persons looking at it later -- premature tricks isn't good on 
something not critical.

    
    

    
  
Updated struct for the time being...

struct nsPrefFonts
{
  enum {
    eGeneric_serif,
    eGeneric_sans_serif,
    eGeneric_monospace,
    eGeneric_cursive,
    eGeneric_fantasy,
    eGeneric_COUNT
  };

  // language group associated to this data
  nsCOMPtr<nsIAtom> langGroup;

  // charset of the language group (can be used to filter fonts)
  nsCOMPtr<nsIAtom> charset

  // default fonts to be used for documents with no specified fonts
  nsStringArray variableFontArray; // a.k.a. 'Proportional' fonts
  nsStringArray fixedFontArray;    // a.k.a. '-moz-fixed' fonts

  // preferred fonts for each of the generic CSS font groups.
  // The first font in each array is the current font selected by
  // the user on the dialog, the others are pre-built (XXX could
  // possibly be determined at application install time).
  nsStringArray genericFontArray[eGeneric_COUNT];

  // preferred font-sizes for each of the font groups
  nscoord genericSize[eGeneric_COUNT];
  nscoord variableSize;
  nscoord fixedSize;

  // preferred minimum allowable font-sizes
  nscoord minGenericSize[eGeneric_COUNT];
  nscoord minVariableSize;
  nscoord minFixedSize;
}

    
    

    
  
Some items in the task list:
============================
1) define the complete nomenclature for the preference system, e.g, 

  font.LANGGROUP1.default.variable.name = fontname1, fontname2, ... [pre-built]
  font.LANGGROUP1.current.variable.name = last-selected-font on the pref dialog
  font.LANGGROUP1.current.variable.size = integer - settable by the user
  font.LANGGROUP1.current.variable.minimum-size = integer - settable by the user

  font.LANGGROUP1.default.fixed.name = [built-in, invisible to the user for now]
  font.LANGGROUP1.current.fixed.name = user's selected-font on the pref dialog
  font.LANGGROUP1.current.fixed.size = ...
  font.LANGGROUP1.current.fixed.minimum-size = ...
 
  font.LANGGROUP1.default.serif.name = ...
  font.LANGGROUP1.current.serif.name = last-selected-font on the pref dialog
  font.LANGGROUP1.current.serif.size = ...
  font.LANGGROUP1.current.serif.minimum-size = ...

 ...etc for all the langGroups and all the generic fonts

2) nsPresContext::GetFontPreferences() needs to recognize the new system

3) double-check to ensure that -moz-fixed is interpreted as a list (not a
single font) in the style system

4) GFX needs a newer FindGenericFont()


    
  
Status: NEW → ASSIGNED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        ongoing patch - in layout (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        ongoing patch - in gfxwin (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Summary: 

in layout 
* Updated nsPresContext::GetFontPreferences() so that it recognizes the new
set of preferences (this is XP).

in gfxwin
* Changed LoadGenericFont() to simplify the ownership model of the font name.
This led to a signature similar to the other LoadXXXFont() and to less code.
* Changed FindGenericFont() so that it can loop over the user's specified list
of fonts.

Up to here, these changes already fix this bug (on Win32 :-) A user can
specify multiple lists per language groups and generic font groups.

====
Re: min-sizes of fonts. This isn't straightfoward. There is a problem because 
the code that I added in FillLogFont() also affects the chrome... For things to 
work as expected, there must be a distinction between the chrome and the content 
window. I think the min-size pref that is currently on Unix (bug 30910) suffers 
from this problem.

The problem is best handled at the style resolution process (when the nsFont 
struct is  created -- maybe some trickery like the one used for -moz-fixed is 
needed, see:
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsRuleNode.cpp


    
    

    
  
Example of dummy prefs that I used for testing purposes:

user_pref("font.current.x-western.fixed.minimum-size", 13);
user_pref("font.current.x-western.fixed.name", "");
user_pref("font.current.x-western.fixed.size", 13);
user_pref("font.default.x-western.fixed.name", "Courrier");

user_pref("font.current.x-western.variable.min-size", 16);
user_pref("font.current.x-western.variable.name", "");
user_pref("font.current.x-western.variable.size", 16);
user_pref("font.default.x-western.variable.name", "Lucida Sans Unicode");


    
    

    
  
I think trying to get the min-size to work properly may jeorpardise this bug.
Trying to do many things at once and end up doing none.
Here is what I propose:
1) leave the min-size issue to the other bug 30910.
2) concentrate on this bug here:

FRONT-END
=========
 * re-work the Prefs -> Fonts dialog to the new convention

 * make the list of default fonts for all supported language groups and
   all platforms in unix.js, etc. That's a big job for you folks.

What is needed is something like this (e.g., for 'x-western' on Win32);

prefs("font.default.x-western.fixed.name", "Courier New, Andale Mono");
prefs("font.default.x-western.variable.name", "Georgia, Times New Roman");
prefs("font.default.x-western.serif.name.name", "Times New Roman, New York");
prefs("font.default.x-western.sans-serif.name", "Trebuchet, Verdana, Arial");
prefs("font.default.x-western.monospace.name", "Courier New, Andale Mono");
prefs("font.default.x-western.cursive.name", "Zapf Chancery, Chancery, Script");
prefs("font.default.x-western.fantasy.name", "Copperplate, Blackletter");

You can also list the '.current.' values, but I wrote the back-end code so
that these can be left empty. Once the user selects other values, make them
persist in '.current.' and they will be used in the back-end.

=========
On unix re:charset, since there are fonts for each langGroup, I will prefer if 
you list the fonts as
 pref(..., "adobe-times-iso8859-1");
 pref(..., "adobe-helvetica-iso8859-1");
i.e., specifically includes the charset string. This will greatly simplify the
back-end code and essentially allow the same skeleton across all platforms.

BACK-END
========
 * finish converting all the platforms to the new system. I can re-use most
of what I did on Win32 (provided the charset is handled as I indicated above).
I now understand a bit more the changes to be made and could progress rapidly 
based on how the front-end is coming along (I will need testers on other 
platforms though).

 * In "Additional Comments From rbs@maths.uq.edu.au 2001-05-07 14:37", I pointed
out that the existing behavior is to search fonts in any language no matter the 
default. I.e., if the code is for example searching for a 'serif' font, not only 
will it look in the specified font for 'x-western', but it also expands the 
search amongst the serif fonts listed for other language groups as well. My 
patch removes this behavior. There is more flexibility in the new system because 
there is a now _list_ of fonts for each generic family. However, bstell 
suggested that it might also be possible to try the user's locale's langGroup. 
Fortunately, this isn't difficult to implement in my scheme, if needed. I 
basically just have to append the locale's list to the search list. If you look 
at the patch, it will give something like:

 nsFontWin*
 nsFontMetricsWin::FindGenericFont(HDC aDC, PRUnichar aChar)
 {
[...] HERE COMPUTE: font.name = .current. + ',' .default. + ',' + LOCALE;
+  // Iterate over the list of names using the callback mechanism of nsFont...
+  GenericFontEnumContext context =  {aDC, aChar, nsnull, this};
+  font.EnumerateFamilies(GenericFontEnumCallback, &context);
+  if (context.mFont) { // a suitable font was found
+    return context.mFont;
+  }
   return nsnull;
}

[Note to myself upon reading the patch: just return context.mFont]

    
    

    
  
Re: [Note to myself upon reading the patch: just return context.mFont]
Not true: need to set mTriedAllGenerics before returning nsnull.

    
  
Depends on: 28899

    
  
Depends on: 74186

    
    

    
  
Note that, if the prefs panel needs reworking again, that's fine, and I can do 
that - but I can't start before the 18th at the earliest. 

Gerv

    
    

    
  
You may perhaps get all what you requested :-) While investigating the bug, I 
found that the variable and fixed fonts in the Style System could be handled 
in a unified way for performance reasons. So this bigger fish led me to hack the 
Style System. And the unification provides a basis for a better integration of 
particular pref-controlled attributes related to each generic font in a XP 
manner while special-casing the chrome. I have opened bug 84398 with preliminary 
patches. The task is much bigger with lots of modules/owners involved. So it can 
take a while anyway.

    
    

    
  
For the record, here is how things work (patches on other platforms are welcome, 
BTW). The key steps are:

1) Required Accessories:
   Define the GenericFontEnumContext struct and the GenericFontEnumCallback()
   function.

2) FindGenericFont:
   * Setup the search list as a comma separated font-family list: 
     font.name = .current. + ',' + .default. + ',' + LOCALE (if possible);

   * Initialize the context and iterate over the font-family list using the
     callback mechanism of nsFont (for free :-)
        GenericFontEnumContext context = {aDC, aChar, NULL, this};
        font.EnumerateFamilies(GenericFontEnumCallback, &context);
     (The GenericFontEnumCallback() function will overwrite the starting NULL
      in context.mFont if a suitable font is found).

3) Elsewhere:
   Since this approach is much cleaner and leaner, some sections in the
   surrounding code become obsolete and have yo be cleaned-up. 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        ongoing patch - in gfxwin (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Mainly a cleanup, with the addition of the convenience macro MAKE_FONT_PREF_KEY.
See bug 84398 for what is going to happen in content & layout.

To recap, the expected prefs are:
font.default.[langGroup].[generic].name = fontname1, fontname2, ... [pre-built]
font.current.[langGroup].[generic].name = settable by the user
font.current.[langGroup].[generic].size = integer - settable by the user
font.current.[langGroup].[generic].min-size = integer - settable by the user

In the existing code, there is also a pref for: font.default = [generic], this 
is used to complete {font-family: fontname1, fontname2}, i,e when no specified 
generic is given in the font-family property. Perhaps, this should be renamed as
font.default.generic, i.e., add the literal string 'generic', since there are 
now so many font prefs that it wouldn't be clear that font.default is supposed 
to be a generic font name.

Re: back-end: having now all these numerous prefs in mind (including this hidden
default.generic stuff), given an author's {font-family: f1, f2}, i.e., with no 
generic, what will you expect, as a user, that the UA should do when hunting for 
a font to represent a character that cannot be represented in the author's font
family list?

[If the author has {font-family: f1, f2, generic}, then that is fine, it is 
covered by what I noted above under FindGenericFont.]

    
    

    
  
> what will you expect, as a user, that the UA should do when hunting for 
> a font to represent a character that cannot be represented in the author's 
> font family list?

Well, it's the author's own silly fault if the user agent gets this wrong :-) I 
would check in my Proportional font first. Then I'd, using some magic heuristic, 
find the list of defaults for the locale from where that character comes, and 
see if I had any of those fonts lying around.

Oh, I don't know. :-) Hixie!

Gerv

    
    

    
  
Once we've tried all the fonts given in 'font-family', then so long as we try
every other font on the system, I don't really care what order we use.

    
    

    
  
Actually, the 'font.default.generic = [generic]' is somewhat redundant and could
be ignored. Indeed I saw that, by design, the Style System always appends the
user's default list to the author's font-family list that is later passed on to
the GFX font-subsystem. So a simplification (to get rid of that pref) could just
be to always set the factory pre-built list as:
font.default.[langGroup].[generic].name = fontname1, fontname2, ..., [generic]

    
  
Target Milestone: mozilla0.9.2 → ---

    
    

    
  
font.default.[langGroup].[generic].name = fontname1, fontname2, ..., [generic]
should be
font.default.[langGroup].-moz-variable.name = fontname1,fontname2,..., [generic]

(I will be changing .fixed. to .-moz-fixed., and .variable. to .-moz-variable.
to avoid the confusion with the "official" generic font names.)

But things are not quite right with my suggested simplification. What if the 
user prefers its default fonts to be sans-serif, for example... As opposed to 
another hard-coded pre-built generic name.

    
    

    
  
About the min-size: 

Normally the font-size is computed hop-by-hop. So if the hierarchy of elements 
is: grand-parent:font-size=12pt -> parent:font-size=50% -> child:font-size=200%, 
then the font-size of 'parent' is 6pt, and the font-size of 'child' is 12pt.

What happens if min-size is set to 7pt?

There are two ways to deal with this min-size:
1) enforce the min-size as soon as the current value goes below the threshold, 
and cascade with the min-size from there.
2) enforce the min-size on the terminal value.

With 1) the font-size of 'parent' will be forced to 7pt, and cascading with that
value will give the size of 'child' as 14pt.

With 2) the font-size of 'parent' will be forced to 7pt, but the cascade will 
continue with its computed size (6pt), yielding 12pt in the 'child'. So this 
approach requires caching all sizes, and knowing which one to return in 
particular situations (e.g., what should be returned getComputedStyle()?) This
is bit tricky to implement, but doable at extra effort :-)

Which of the two would you expect, as an author and/or user?!

    
    

    
  
I think (2) might be better, if it does what I think it does -- only changing 
the font size for display purposes, and not for the purposes of calculating 
other font sizes. Otherwise non-constricted text could become abnormally large. 
E.g. if you had
  body {font-size: 8pt;}
  h1 {font-size: 3em;}
and your minimum size pushed body up to 12pt, then <h1> should still be 3 * 8pt 
= 24pt, rather than ballooning up to 36pt. (The downside, of course, is that 
{font-size: 1.2em or similar would appear to have no effect.)

Other notes:
>...
> eGeneric_monospace,
>...
> nsStringArray defaultFixedFont;    // a.k.a. '-moz-fixed' fonts

From a GUI level at least, these are one and the same. (Opera makes a 
distinction between them, but I can't really see the point; the user shouldn't 
have to care whether the fixed-width-ness was specified by CSS or by another 
method.)

> font.LANGGROUP1.current.fixed.size = ...
> font.LANGGROUP1.current.fixed.minimum-size = ...
>...
> font.LANGGROUP1.current.serif.size = ...
> font.LANGGROUP1.current.serif.minimum-size = ...

Minimum size should be language-group-specific (it needs to be larger for 
Chinese than for Western languages, for example), but I think making it 
font-specific would be a bit excessive.

    
    

    
  
Got option 2 for the minimum font-size working... I will leave -moz-fixed for 
the moment. Many CSS files in the product have come to rely on it. Also, it is 
used for text controls. There could be widespread ramifications associated to 
changing it.

I am in the process of requesting reviews/comments for the back-end. I have
covered what was needed in my implementation. The latest patches are in
bug 84398.
Target Milestone: --- → mozilla0.9.3

    
    

    
  
Gerv, mpt, remember my comment above about a pref for the default generic? 
I stumbed on a link of Todd Fahrner that shows how this could be exposed:
http://style.cleverchimp.com/cssui/

His screenshot shows that in addition to selecting the default font names, there 
could be radio buttons with which to specify the default generic font to be used 
for completion of a font-family with no specified generic.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        final patch in gfxwin (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
I just attached a patch that matches the expected set of prefs. I included 
user's locale's fallback fonts as well. No more issues apart from, perhaps, some 
adjustments of the pref keys if the precise nomenclature of the prefs have to 
change following what is going to happen in the front-end (e.g., the default 
generic).

    
    

    
  
Todd's font prefs UI has the Henry Ford problem which I described in bug 28899. 
It also suffers from a controls-as-labels problem similar to that described in 
the User Interface Hall of Shame <http://iarchitect.com/visual.htm#VISUAL29>.

    
    

    
  
Milestone shift... Need interested folks to try out the branch that has the fix.
It may be too late for changes like this soon. See bug 74186.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
    

    
  
>------- Additional Comments From Matthew Thomas (mpt) 2001-06-14 06:07 -------
[...]
> > Other notes:
> >...
> > eGeneric_monospace,
> >...
> > nsStringArray defaultFixedFont;    // a.k.a. '-moz-fixed' fonts

> From a GUI level at least, these are one and the same. (Opera makes a 
> distinction between them, but I can't really see the point; the user shouldn't 
> have to care whether the fixed-width-ness was specified by CSS or by another 
> method.)

mpt, as I am experimenting things, I am noting that your case over at bug 28899
for having the "proportional" font might apply equally well for -moz-fixed.
"-moz-fixed" could be seen as the fixed-width font that the UA could use
wherever it needs a fixed-width font and none hasn't been specified.
For example, what fonts should the UA uses for:
  <span> <code> ...fixed-width text... </code> ...variable-width text... </span>
If users can decide the 'proportional' (variable) font, they may as well wish to
decide the fixed-width font that will look nice _next_ to their variable-width
font. This means that a distinction might prove useful in the GUI side.

    
    

    
  
Given that the whole point of -moz-fixed was to be able to get a monospace font
that was smaller than the default font, wouldn't a better solution be to get
rid of it altogether and rely on font-size-adjust instead? :-D

    
    

    
  
Technically, that's possible. But as argued in the other bug, there is a value 
in having a default variable-width font that is different from the particular 
default font selected for a generic font. What I have come to realize is that 
the same reasoning applies for the fixed-width font. Hence it seems to me that 
either both are enabled or both are disabled, i.e., either both default fonts 
(variable and fixed) are specific fonts or both are generic fonts. The former 
appears to give more flexibility, though.

    
    

    
  
> [...] there is a value in having a default variable-width font that is 
> different from the particular default font selected for a generic font [...]

There is? Which bug is this discussed in? I'd have thought merely an option to
pick whether the initial value was the serif or sans-serif (or monospace, or 
cursive or fantasy) font would have been enough.

    
    

    
  
That's a point that mpt has been adamant about in bug 28899. I see that you were 
not cc:ed to that bug.


    
    

    
  
To ease transition on all platforms, I am making the nomenclature of the font 
prefs keys a superset of the existing ones. The underlying idea is that all the 
zillion versions of GFX need not be updated at the same time. Hence it is 
desirable to limit the impact of the new features on platforms that may need 
some time to implement them.

'Final' proposed font prefs keys:
=================================

1)  unit
    ----

    font.size.unit = px | pt
         It is assumed to be the same for all language groups
         (XXX could be folded in the size... bug 90440)
    
2)  attributes for generic fonts 
    ----------------------------

    font.default = serif | sans-serif
         On the trunk, this holds the user' selected "Proportional" font from
         the Fonts prefs dialog. It is used as the default generic and also as
         the fallback generic for an author's font-family list without one.
         CHANGE: It becomes only the fallback generic font. The key for the
         user's default font is "font.name.[generic].[langGroup]", see below.

    font.name.[generic].[langGroup] =
         On the trunk, this refers to the font associated to "Proportional"
         (In other words, the final font used, on the trunk, is obtained by the
         indirect reference "font.name.[GenericFrom(font.default)].[langGroup]")
         CHANGE: The key will now hold the default font directly specified by
         the user on the Fonts prefs dialog).

NEW>font.name-list.[generic].[langGroup] = "f1, f2, ..."
         The factory pre-built list of fallback fonts

    font.size.[generic].[langGroup] = integer
         The current user's selected font-size

NEW>font.size-adjust.[generic].[langGroup] = "float"
         The current user's selected font-size-adjust for the generic family

    font.min-size.[langGroup] = integer
         On the trunk, this is only applicable to GfxGTK. 
         CHANGE: It becomes the XP user's selected mimimum allowable font-size
         during CSS computations.

    
    

    
  
Reality check, shifting to next milestone...

gerv, it might be time to kick off some hot action on the GUI part. I suggest to 
aim for something high, with preview and such... (seeing how long the back-end 
is taking, I will feel better if the GUI takes you more than your earlier 
estimation of 5 minutes :-)

1) The exposed prefs:
     font.name.[generic].[langGroup] = selected font
     font.size.[generic].[langGroup] = integer
     font.min-size.[langGroup] = integer

(It will be more robust for the long run to set the size as a string with a unit 
'...[px|pt]'. Doing so will avoid ambiguities and messy situations as explained 
in bug 90440. Such a string could be parsed once for all for 'px' or 'pt'. And 
with this, allowing the user to select the unit to be prefixed can result in a 
competitive edge without attracting further changes to the back-end.)

2) [default generic] I have been wondering how to deal with this. I just thought 
that a possible work-around is to infer it from the default typeface that the 
user will now choose. Hence if the user picks 'Times', set:
    font.name.variable.[langGroup] = 'Times', and 
    font.default = 'serif'.

To know the generic class of a typeface will involve searching all the dropdown 
generic lists. However, the benefit is that no more API changes are needed in 
the zillion versions of GFX and hopefully the search shouldn't been that slow.

3) [different font-size] Seeing what it takes to support |font-size-adjust|,
I think folks will not complain that it wasn't tried hard enough. So go ahead 
and set the font-size the non-spec way. Given that |font.size-adjust| is so far 
only applicable on Win32 and might take a good while to be supported on other 
platforns, it might be kept as a hidden pref:

    font.size-adjust.[generic].[langGroup] = "float"

The back-end will continue to read it but it will be effective only on platforms 
where it is supported. Someday, when it is supported on all platforms, it could 
then be exposed on the UI.
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
    

    
  
Also using "Variable Width Font" (.variable.) and "Fixed Width Font" (.fixed.) 
(like Nav4.x) feel more intuitive than "Proportional" and "-moz-fixed"...

    
    

    
  
I added a finishing touch to nsPresContext::GetFontPreferences(). It is now 
ready to be hooked to the new prefs (the blocker on the whole lot really remains
GetDimensions). 

re:Auto font-size, I switched to using size=0 as the indicator of the 'Auto' 
font-size. When the user selects 'Auto' (size=0), the back-end converts it to 
the current size of the .variable. or .fixed. fonts. Specifically, .monospace. 
takes its size from .fixed., and the others from .variable.. In other words, 
apart from .variable. and .fixed., the other generic fonts can have an 'Auto' 
entry in their drop down list. I am copying the motivation I gave in bug 74186 
for this 'Auto' option here:

"[...] when the support for these generic fonts is complete, with the ability to 
set different font-sizes for each group, it is going to take a lot of gymnastics 
to adjust all these numerous font-sizes. If one is to be changed, then the user 
has to adjust the whole lot for consistency. So this 'Auto' option is going to 
be also useful in that respect. [...]"

    
  
Blocks: 95227

    
    

    
  
mpt: I think you and perhaps some i18n guys need to get together to work out a
new fonts prefs UI based on the new capabilities Mozilla will have.

rbs: Can I just confirm that the old UI will work in the new world, it just
won't expose all the function?

Gerv

    
    

    
  
The simple answer is yes, since I made the keys a superset of the existing ones.
But, I started and did all this hacking because of your wishlist expressed in
"Additional  Comments From Gervase Markham 2001-05-07 06:17". So I have been
building up an expectation for some hot action in return :-)

<quote>
The wishlist basically means being able to implement the following UI (courtest 
of mpt):

    Fonts ::::::::::::::::::::::::::::::::::::::
                                                
    +-Fon_ts for: [default choices         :^]-+
    | :/: _Use dflt. choices for this encoding |
    | _Proportional: [Georgia      :^][  14:^] |
    |    _Monospace: [Courier New  :^][  12:^] |
    |        _Serif: [Times New Rom:^][  14:^] |
    |   Sa_ns-serif: [Trebuchet    :^][  12:^] |
    |      _Cursive: [Zapf Chancery:^][  16:^] |
    |      _Fantasy: [Desdemona    :^][  16:^] |
    | [ ] Minimum font si_ze:         :   8:^: |
    +------------------------------------------+
    [/] Allow documents to use _other fonts     
    For plain te_xt, use: [Monospace         :^]
</quote>

Changing "plain text" to fixed-width on mpt's proposal that has stood the test
of time, a tentative mockup could perhaps be (leaving aside the font samples for
the moment until you folks figure out where it should best go -- it will be
great to have that, BTW):

    Fonts ::::::::::::::::::::::::::::::::::::::::::::

    +-Fon_ts for: [default choices       :^]---------+
    | _Variable With Font: [Georgia      :^][  16:^] |
    |    Fi_xed With Font: [Courrier New :^][  13:^] |
    |                                                |
    |              _Serif: [Times New Rom:^][Auto:^] |
    |         Sa_ns-serif: [Trebuchet    :^][Auto:^] |
    |            _Cursive: [Zapf Chancery:^][Auto:^] |
    |            _Fantasy: [Desdemona    :^][Auto:^] |
    |          _Monospace: [Courier New  :^][Auto:^] |
    |                                                |
    | [ ] Minimum font si_ze:               [   8:^] |
    +------------------------------------------------+
    [/] Allow documents to use _other fonts




    
    

    
  
Yes, of course, I remember :-)

So we're waiting for mpt to review his design and yours, together with your
details of what's now possible on the back end, and get together with some i18n
people to work out the final details. 

Gerv

    
    

    
  
What is now possible (as far as the UI is concerned) is every element in your 
wishlist as quoted above. You got all :-) And bug 95227 is going to be fixed
too -- for free, based on the derivation of the "font.default" generic from the
"font.name.variable.[langGroup]". Indeed, if the user switches the langGroup,
and presses OK, then sync:ing "font.default" at the time of persisting the other 
values as I suggested ealier will also take care of that bug.

As for the prefs keys to persist the values, they are detailed as per 
"Additional Comments From rbs@maths.uq.edu.au 2001-08-22 01:05"

    
    

    
  
Oh, this is going to be extremely cool indeed.

For avoiding the problem of a user having to fiddle with dozens of popup menus 
in order to change the size (or typeface) for all families in all scripts, see
<http://groups.google.com/groups?selm=3B83CD22.652BF353%40mailandnews.com>.

> mpt, as I am experimenting things, I am noting that your case over at bug
> 28899 for having the "proportional" font might apply equally well for
> -moz-fixed.

My guiding principle is not that HTML fonts and CSS fonts should be kept apart 
at all cost. :-) Rather, it is that the user should not have to care what 
technique (HTML, CSS, XML, DSSSL, whatever) is being used to determine a 
particular font. Insisting that HTML proportional be the same as either CSS 
serif or CSS sans-serif is bad, because there is not a one-to-one relationship 
between unadorned HTML text and a W3C CSS family, so the quirks of the current 
back-end implementation (using CSS families for everything) are exposed. Having 
two separate choices for fixed-width/monospace text, one for HTML and one CSS, 
would be bad for exactly the same reason -- given that they have identical 
purpose in the user's eyes, such prefs would make a distinction between
HTML-caused monospace and CSS-caused monospace which the user should not have 
to care about.

> "-moz-fixed" could be seen as the fixed-width font that the UA could use
> wherever it needs a fixed-width font and none hasn't been specified.

-moz-fixed is for use in the user interface (plain-text message composition, 
view source, etc); so it should be an OS setting (like `caption',
`small-caption', `icon' et al. are), not something which appears in Mozilla's 
Fonts prefs. (In Mac OS, -moz-fixed should follow the typeface and size set for 
`Screen Font' setting in the Internet control panel; in GTK, -moz-fixed should 
follow the typeface and size of the font_fixed theme setting.)

> For example, what fonts should the UA uses for: <span> <code> ...fixed-width
> text... </code> ...variable-width text... </span>

The font selected using the `Monospace' popup menu in the Fonts prefs. (With 
the exception of SAMP, which is supposed to imitate sample output from a 
computer, I'd argue that use of `-moz-fixed' in html.css is a bug. Conversely, 
use of `monospace' in forms.css or xul.css would be a bug.)

> If users can decide the 'proportional' (variable) font, they may as well wish
> to decide the fixed-width font that will look nice _next_ to their
> variable-width font. This means that a distinction might prove useful in the
> GUI side.

Not really -- because the same font will be used for CODE et al. whether the 
author has set body {font-family: sans-serif}, or body {font-family: cursive}, 
{font-family: fantasy}, or just left BODY un-CSSized completely. The user's 
choice of fixed-width font needs to look nice next to all the other fonts -- 
not just the CSS ones, and not just the HTML one.

    
    

    
  
So, the bottom line is: I will get to work implementing the UI as soon as:
a) this patch gets checked in, and
b) there is a spec which mpt and some i18n folks have signed off on
Call me when you are ready :-)

Gerv

    
    

    
  
> a) this patch gets checked in, and
Fair enough :-)

> b) there is a spec which mpt and some i18n folks have signed off on
The back-end doesn't have the new "system font" that mpt refers to (in fact, I 
don't know of such a system font for a fixed width font on Win32.) The back-end 
provides -moz-fixed which is the one currently used in the UA CSS for <code>, 
<pre>, viewsource, plaintext composer, plaintext mail compose, etc. Since I 
doubt that anyone will line-up to revamp font handling in the near future to add 
such a new system font, one might be content with what is there. The fact that 
-moz-fixed hasn't been exposed so far has generated some confusion. (Also, I am 
not sure that I agree with all what mpt said because if one uses the same logic 
the "proportional" font would have to be a system font as well.)

> Call me when you are ready :-)
Hope to be done with the back-end in m0.9.5...



    
    

    
  
Something else that I thought worth drawing attention to is that system fonts 
are not mystery fonts or something. Indeed, rather than using "font: caption", 
one could, for example, do "font: 9px Tahoma" to get a similar effect. And 
that's how it works internally, BTW. All these 'caption', 'dialog', etc, get 
converted from their platform specific description into |nsFont| -- the common 
XP data structure that everybody and their friends expect. Thus if the ability 
to select -moz-fixed is exposed, it becomes possible for users to at least match 
what they want. Whereas if this ability isn't even exposed, they are denied from 
the basic ability of doing anything in that respect.

It is also possible to eliminate -moz-fixed altogether (taking for granted the 
jihad necessary to do so :-) But that would amount to hide away from the 
recognized demand for the ability to use a fixed-width font other than the 
default monospace font in certain situations.

On balance, it seems to me that not exposing -moz-fixed takes something out of 
what the back-end currently has to offer, and denies users the ability to alter 
the font being used in places like <pre>, viewsource, <textarea>, plaintext mail 
compose, etc... Remember, these are using -moz-fixed and to my knowledge, there 
is no forthcoming jihad to revamp the various CSS rules in the product, some of 
which may be hard-coded.

    
    

    
  
> ...recognized demand for the ability to use a fixed-width font...

I don't really recognise that demand.

-moz-fixed was originally introduced because Courier New at the same font size
as Times New Roman had a different x-height. This problem has been resolved by
making fonts be able to have different initial sizes (although I still don't
fully understand how that works -- see below). Therefore the need for -moz-fixed
has been removed. Why do we need to monospace fonts?


BTW, I don't quite understand how the font-size-per-family pref works. If I say

   :root { font-size: 10px; }
   a { font-family: serif; }
   b { font-family: sans-serif; }

   <root>
    <a> Hello <b> World </b> </a>
   </root>

...and I set my "serif" font to a font with a size of 20px and my "sans-serif" 
font to a font with a size of 30px, giving them (at those font sizes) equal
x-heights, what size will the text be in the example above? Thanks in advance
for the explanation! :-)

    
    

    
  
So, what is the buttom line for bugs like #95227 ? Is Mozilla going to allow
users select diffrent default font type for each language indipendently?

    
    

    
  
> I don't really recognise that demand.
Not suprising... It is a lost cause from your perspective :-) and even that 
'monospace' should have the same size as the other CSS generic anyway :-) :-)  
Since -moz-fixed is there and there is no forthcoming plan to get rid of it, I 
think users might appreciate to be able configure it. No further action is 
needed in the back-end for that. Whereas other alternatives require further 
revamps that no-one is prepared to undertake at the moment.

>what size will the text be in the example above?

Your settings win. The best way to see things is to simply picture the values 
are just default values -- which is what they are, e.g., the default typefaces 
that the UA picks for a document without explicit typefaces; or the default 
font-sizes for a document without explicit font-sizes.

In approximate CSS terms, what is happening is something like this:

>...and I set my "serif" font to a font with a size of 20px and my "sans-serif" 
>font to a font with a size of 30px

   /* the presentation context holds the default UA initial values */
   :UA:-moz-initial-variable {
     font-size: 16px
     font-size-adjust: none;
     ... and all the other defaults... 
     /* ... and it is technically possible to initialize other 
            attributes to something like "font-weight: bold" ... */
   }
   :UA:-moz-initial-serif { font-size: 20px; }
   :UA:-moz-initial-sans-serif { font-size: 30px; }

   :root { font-size: 10px; } /*will override the initial value in the cascade*/
   a { font-family: serif; }
   b { font-family: sans-serif; }

  <UA>
     <root>
       <a> Hello <b> World </b> </a>
     </root>
  </UA>

Different sizes apply if you remove the rule ":root { font-size: 10px; }".

If you are leaving your computer free for a moment e.g., when taking a coffee 
break or something, you might want to point-n click on the binary drop in
bug 74186 to experiment the example... (I didn't try that particular example 
myself -- I would have been tempted to attach a screenshot :-)

    
    

    
  
> So, what is the buttom line for bugs like #95227 ? Is Mozilla going to allow
> users select diffrent default font type for each language indipendently?

Yes.


    
    

    
  
>> I don't really recognise that demand.
> Not suprising... It is a lost cause from your perspective :-) and even that 
> 'monospace' should have the same size as the other CSS generic anyway :-) :-)  

hehehe. Yes, well! :-)


> Since -moz-fixed is there and there is no forthcoming plan to get rid of it, I 
> think users might appreciate to be able configure it. 

Agreed as far as that goes. Should we file a bug (Futured, maybe) about removing 
it at some point?


>> what size will the text be in the example above?
> Your settings win.

Meaning? (i.e., what's the exact intent of what you want it to do?)


> If you are leaving your computer free for a moment e.g., when taking a coffee 
> break or something, you might want to point-n click on the binary drop in
> bug 74186 to experiment the example... (I didn't try that particular example 
> myself -- I would have been tempted to attach a screenshot :-)

I've got the binary, what prefs would I need to set to set what I describe above?

    
    

    
  
> Should we file a bug (Futured, maybe) about removing it at some point?

Later maybe as it is a controversial issue.

>> Your settings win.
>
>Meaning? (i.e., what's the exact intent of what you want it to do?)

What comes after the fictional 'UA' element wins.

Let me take another shot at explaining. Suppose that there is only one single
default font to start with, and let kick off the style resolution machinery on a 
document. Nothing to see here, what we get here is well understood. 

Suppose you start over again, picking the initial default font as provided by 
'-moz-initial-serif', then kick off the style machinery, this time you get a new 
resolved document which differs from the previous one because of the initial 
value (although most of the final values might end up identical). Then at the 
painting stage, you only paint those elements with the 'serif' font since that 
was your initial value. It could be that there is no such element because a CSS 
rule somewhere has set the font-family to something; or because the document 
didn't have any element with 'font-family: serif' anyway.

Then start over again, picking this time the default font as provided by
'-moz-initial-sans-serif', then at the end, only paint those elements with the 
'sans-serif' font since that was your initial value. It could be that there is 
no such element because a CSS rule somewhere has set the font-family to 
something; or because the document didn't have any element with 'font-family: 
sans-serif' anyway.

When you superimpose your results, you get a multitude of elements where those
elements with 'font-family: serif' where distinctively computed with the 
'-moz-initial-serif' default font, whilst those elements with 'font-family: 
sans-serif' where computed with the '-moz-initial-sans-serif' default font, etc.
So, whatever font-size, or font-size-adjust (or other attributes) that were in 
the initial -moz-initial-[serif|sans-serif|...] fonts end up in each element 
according to the normal CSS cascade.

Using the anology with 'threads', I referred to each of these processes in
bug 84398 as 'monospace thread', 'serif thread', 'sans-serif thread', etc.

Although that's what the implementation achieves, it is coded in a much 
different way from the above explanation. A simple-minded code would be too 
much inefficient. First and foremost, only the font is needed -- not all of
the style machinery... And the particularities are as follow:

In the trunk:
  There is a 'placeholder' for -moz-fixed. Since you cannot tell in advance if
  there will be an element with 'font-family: -moz-fixed', the trunk is doing
  a double style resolution on _both_ the default variable font, and the default
  fixed-font. If an element with 'font-family: -moz-fixed' is later encountered, 
  then no worries, the needed values have been computed and are readily
  available. They are taken. If there is no such element, all that computation
  was done for nothing (that's the overhead here).

In my new code:
  I cannot use additional placehoders for all these 5 CSS generic fonts. That
  will be a waste. So I am using a lazy approach as follow. Do the style
  resolution with the default variable font, if no generic is encountered, no
  worries. I am done. But if a 'font-family: serif' is encountered, I backtrack
  to the the last previous element with 'font-family: serif' and carry a few
  more steps of the style resolution needed for the current element. Hence, if
  a descendant with 'font-family: serif' is later encountered, it will
  backtrack up the current element, and that's how the process feeds upon
  itself. If no descendants is encountered, then no worries, I have not done any
  useless work (the overhead here is in the backtracking). This way of doing so
  allowed removing the placeholder for -moz-fixed as well, and folding its logic
  with the other generic fonts.

>I've got the binary, what prefs would I need to set to set what I describe 
>above?

The current keys are as per my comments of "2001-08-17 18:05" :

prefs("font.size.[variable | fixed | serif | sans-serif | ...].x-western", 16);  
prefs("font.min-size.x-western", 0);
 

    
    

    
  
> Hence, if
>  a descendant with 'font-family: serif' is later encountered, it will
>  backtrack up the current element

No necessarily -- to be more precise. There is no effective backtracking if
the current thread is already the 'serif thread'... Backtracking only happen 
when appropriate.

    
    

    
  
BTW Hixie, since you got the binary drop ready, it is MathML-enabled, and 
another place to see the weirdness of not using nsDimensions is:
http://www.mozilla.org/projects/mathml/fonts/encoding/cmex-ttf-encoding.html

The trunk (when MathML-enabled, that is) renders that page with ugly overlaps.
There is a link to a screenshot of the expected layout of the character map at:
http://www.mozilla.org/projects/mathml/fonts/encoding/cmex.html

    
    

    
  
I've been playing with some REALLY wacky settings:

  user_pref("font.size.variable.x-western", 50);
  user_pref("font.size.fixed.x-western", 100);
  user_pref("font.size.serif.x-western", 150);
  user_pref("font.size.sans-serif.x-western", 200);
  user_pref("font.min-size.x-western", 0);

...and the zoom at 22%.

The first thing I noticed is that:

   :root { font-size: 2em; font-size-adjust: none; }
   a { font: 1em Verdana; }
   b { font-weight: normal; font-style: normal; font-variant: normal;
       font-size: 1em; line-height: normal; font-family: Verdana; 
       font-stretch: normal; /* font-size-adjust is inherited */ }

   <?xml-stylesheet href="test.css"?>
   <root xmlns="http://foo.example.com/">
     <a>This should have an iden</a><b>tical font-size to this.</b>
   </root>

...fails. Explicitly adding font-size-adjust actually fixes this. IMHO THIS IS A
BUG.

The second thing I noticed was that things like the example I gave a few comments 
above act really weird. For example, with the following:

   * { font-size-adjust: none; }
   a { font-family: serif; }
   b { font-family: sans-serif; }

   <root> <a> Hello </a> <b> World </b> </root>

...adding the following rule:

  :root { font-size: 15px; }

...will result in different results than any of:

  :root { font-size: x-medium; }
  :root { font-size: larger; }
  :root { font-size: 1em; }
  :root { font-size: 1.5ex; }

...just as you describe above... but this has terrible implications on CSS:

   * { font-size-adjust: none; font-size: 1em; }
   lh { font-family: sans-serif; }
   li { font-family: serif; }
   :root > * { margin-left: 1em; border-left: 0.5em solid; 
               padding-left: 1em; display: block; }

   <list xmlns="http://lists.example.com/with/headers">
    <lh>Fruit</lh>
    <li>Apple</li>
    <li>Pear</li>
    <li>Kiwi</li>
    <lh>Vegetables</lh>
    <li>Avocado</li>
    <li>Aubergine</li>
    <li>Cucumber</li>
   </list>

...should *always* have a solid left line, and with my user settings given
above, this
would not happen. Per spec, you can't "redo" the cascade for each value of
font-family
like this...

HOWEVER, I don't think this second issue is a problem. In practice, I don't expect
users will be giving font sizes quite as different as I have.

I will now do some more tests with more sensible values. However, I recommend
playing
with the testcases above with the font sizes I give above to get a feel for the 
extremes that this patch implies.
Whiteboard: (py8ieh: extract testcases)

    
    

    
  
OK, I will play around with your tests. The first case is weird. I wonder if it 
works on a 2001 09 04 trunk build? In principle, there is no generic font, and 
the code-path being executed is expected to be the same as on the trunk.

    
    

    
  
Yep, tested and saw that the problem goes away with:
-      font-stretch: normal; /* font-size-adjust is inherited */ }
+      font-stretch: normal; font-size-adjust: none; }

So it is another rule problem then? There must be somewhere else where I need to 
further hook |font-size-adjust| in the Style System. Any clue, style people?

As for the other implications, they seem in line with what the code is supposed 
to be doing (the technical side, anyway. The philosophical side is something 
else :-). The purpose is really just to allow users to slightly tune font 
metrics, so that a tiny looking cursive font can be slightly bumped next to a 
serif font, or a strange and weird looking -moz-fixed font can be slightly 
reduced next to a variable font, so that on aggregate, the overall rendering is 
much more visually appealing. And users can always get back to the default mode 
where they can see the default rendering. In a perfect world, the web-designer 
would attach the webfonts to its page and do-the-right-thing (tm) with an 
homogeneous set of well-designed font-size-adjust(s) on the elements, etc. But 
we are not yet there.


    
    

    
  
hixie, that's great testing. With all that meticulous testing that you have been 
doing, I am more and more under the impression that there will be little fix-up 
afterwards and perhaps no regression at all for existing ASCII documents :-)

I found the bug... If you look at the trunk's nsRuleNode::ComputeFontData(), 
there are many places with this:
    if (parentContext && !inherited) {
      inherited = PR_TRUE;
      parentFont = (nsStyleFont*)parentContext->GetStyleData(eStyleStruct_Font);
    }

When moving the bulk of the computation from nsRuleNode::ComputeFontData() to a 
re-usable helper function called SetFont(), I factored this repeated block out. 
In the process however, I omitted a fix-up somewhere which was exposed with your 
test case with the short-hand 'font' (this fully specifies all properties...).
I now have this corrected in my tree. 

[For completeness to those who have been looking at my patch, the fix is in the
newer nsRuleNode::ComputeFontData() as follows:
-   font = parentFont = new (mPresContext) nsStyleFont(defaultFont);
+   font = new (mPresContext) nsStyleFont(defaultFont);
]

    
    

    
  
gerv: deal done. Back-end landed. Re-assigning this little gem to you for the 
front-end.
Assignee: rbs → gerv
Status: ASSIGNED → NEW

    
    

    
  
rbs: was this "Back-end landed" part of checkin of bug 99010?

    
    

    
  
Yes. The presentation context can now handle the various prefs associated to 
these different generic fonts.

There is a missing bit regarding platform-specific code. All the Gfx flavors 
neeed to support the fallback factory pre-built list:
font.name-list.[generic].[langGroup] = "f1, f2, ..."

I added this support to the GfxWin code (LXR:winpref.js). Other platforms will 
continue to have a single default font per generic family as before -- until 
platform gurus step in and do something about it. So it can be the subject of 
separate bugs.

    
    

    
  
rbs:

This is my understanding of the new prefs for the fonts system. Some of it is
undoubtedly incorrect. Please enlighten me :-)

Preliminaries
-------------
The [generic] set is:
variable | monospace | serif | sans-serif | cursive | fantasy

Is it "monospace" or "fixed" ? As I understand it, part of your work was to
eliminate the difference between the two, so that the fonts prefs UI only had to
set one monospaced font, which was used for both CSS and <pre> etc. Is that correct?

The [langGroup] set is:
x-western, x-central-euro, ja (Japanese), zh-TW (Trad. Chinese), zh-CN (Simple
Chinese), ko (Korean), x-cyrillic, x-baltic, el (Greek), tr (Turkish),
x-unicode, x-user-def, th (Thai), he (Hebrew), ar (Arabic). Is there also a
"default" option here? If so, what does it do?

Prefs
-----
* font.name-list.[generic].[langGroup] = font list

This is a list of suitable fonts, in order, for the given family and language
group. The strings given are checked against the available fonts using a
substring search, so e.g. "mono" is a valid entry near the end of the monospace
name-list. These are used only at Mozilla initialisation, or perhaps if a
currently-selected font goes away, to find the most suitable font.

The lists here need to be decided in the newsgroups by people who use Mozilla in
the different language groups. We need (15 langGroups x 6 families =) 90 lists,
unless some are platform-specific.

* font.name.[generic].[langGroup] = selected font
     
The defaults for these are set by the back end from what it finds in the
font.name-list. In use, this pref holds the currently selected value in the UI
for that font family and language group.
   
* font.size.[generic].[langGroup] = integer

The defaults for these are set in the prefs file; we are assuming that one
default is fine for all fonts in the name-list for that family and language
group - i.e. whichever gets selected on the back end, this value will be
suitable. The defaults need to be decided in the newsgroups.

* font.size-adjust.[generic].[langGroup] = "float"

Question: what does this property do? What are the possible values? Does it need
a default? Does it need UI?

* font.min-size.[langGroup] = integer

The defaults for these are set in the prefs file; we are assuming that one
default is fine for all fonts in a given language group. The defaults need to be
decided in the newsgroups.
Question: is the pref font.min-size or font.minimum-size?

* font.size.unit = px | pt

This gives the unit for font.size and font.min(imum?)-size. 
Question: if there was UI for changing it, how would one translate the old set
of values into the new set? Using the DPI setting?

* font.default = serif | sans-serif

Question: what does this pref now do? Is it merely for backwards compatibility
with un-updated versions of gfx?

In your mockup, several of the font size dropdowns say "Auto". Does this mean
"Use the value for Variable if you are Serif, Sans Serif, Cursive or Fantasy,
and use the value for Fixed Width if you are Monospace?" If so, this comes back
to the difference between Fixed Width and Monospace in your mockup.

I'm sure when you've answered these I'll have a bunch more for you :-)

Gerv




Status: NEW → ASSIGNED

    
    

    
  
> This is my understanding of the new prefs for the fonts system. Some of it is
> undoubtedly incorrect. Please enlighten me :-)

I am feeling a bit sick at the moment and could only provide brief hints. Hope 
they help.

> Preliminaries
> -------------
> The [generic] set is:
- variable | monospace | serif | sans-serif | cursive | fantasy
+ variable | -moz-fixed | monospace | serif | sans-serif | cursive | fantasy

> Is it "monospace" or "fixed" ? As I understand it, part of your work was to
> eliminate the difference between the two, so that the fonts prefs UI only had 
> to set one monospaced font, which was used for both CSS and <pre> etc. Is that 
> correct?

Nope. Both need to be exposed to reap the full potential of the back-end as 
I advocated earlier. It appears that people have been using "-moz-fixed" for
ages as the default fixed-width font for browser elements (viewsouce, plaintext,
etc). The elimination of "-moz-fixed" is a controversial issue and even if
there was consensus to eliminate it, and somebody was to come along and sign
for it -- which is unlikely, it will take a jihad to do so. And the time that
such a long-winded process might take will be enormous. All these make it
improbable that it will go away soon. So my take is to go ahead and expose
"-moz-fixed" as per my mockup above so that users can at least customize it.

> The [langGroup] set is:
> x-western, x-central-euro, ja (Japanese), zh-TW (Trad. Chinese), zh-CN (Simple
> Chinese), ko (Korean), x-cyrillic, x-baltic, el (Greek), tr (Turkish),
> x-unicode, x-user-def, th (Thai), he (Hebrew), ar (Arabic). Is there also a
> "default" option here? If so, what does it do?

Note that the UI works in the same way as you have been doing w.r.t. the current 
one.
 
> Prefs
> -----
> * font.name-list.[generic].[langGroup] = font list
> 
> This is a list of suitable fonts, in order, for the given family and language
> group.

Yep.

> The strings given are checked against the available fonts using a substring 
> search, so e.g. "mono" is a valid entry near the end of the monospace
> name-list.

Nope. Each list follows the standard nomenclature for the comma-separated CSS
font-family list (there are no substring trickeries in the CSS font-family
property -- only an "existence" search when hunting for fonts).

> These are used only at Mozilla initialisation, or perhaps if a
> currently-selected font goes away, to find the most suitable font.

Nope. They are not used at init time. Each is a fallback list that is looked
at only when other fonts don't have the needed glyphs.

> The lists here need to be decided in the newsgroups by people who use Mozilla 
> in the different language groups. We need (15 langGroups x 6 families =) 90
> lists, unless some are platform-specific.

The lists are platform-specific, LXR: winpref.js, to see an example. (Only 
the windows versions are needed at the moment since the other platforms don't
understand them yet. You can forget about them for a start since you can hook
the UI without them, their absence is not a fatal. In fact, they are not even 
meant to be configurable by the UI.)

> * font.name.[generic].[langGroup] = selected font
> 
> The defaults for these are set by the back end from what it finds in the
> font.name-list.

Not quite. (No need to concentrate that much on this name-list :-)

> In use, this pref holds the currently selected value in the UI
> for that font family and language group.

Yep.

And since you have been speaking a lot about the name-list, let me add that
in the back-end the fonts associated to a font family and language group
are made up as:

font.name.[generic].[langGroup] + "," + font.name-list.[generic].[langGroup]

So the UI decides the first choice, and even if the name-list is empty
or is not supported by some platforms, it is not fatal. (Since the
name-list is already comma-separated, the whole composition makes sense).
 
> * font.size.[generic].[langGroup] = integer
> 
> The defaults for these are set in the prefs file; we are assuming that one
> default is fine for all fonts in the name-list for that family and language
> group - i.e. whichever gets selected on the back end, this value will be
> suitable. The defaults need to be decided in the newsgroups.

This works in the same way as the one you have now for Proportional/Monospace.
You can just re-use that code for the other entries, and persists the value
that the user selects. The back-end is wired up with the 'Auto' mode as the 
default, hence there is no need for additional newsgroups defaults.

> * font.size-adjust.[generic].[langGroup] = "float"
> 
> Question: what does this property do? What are the possible values? Does it
> need a default? Does it need UI?

UI is not needed. Forget about it.
 
> * font.min-size.[langGroup] = integer
> 
> The defaults for these are set in the prefs file; we are assuming that one
> default is fine for all fonts in a given language group. The defaults need to
> be decided in the newsgroups.
> Question: is the pref font.min-size or font.minimum-size?

The pref is now: font.minimum-size.[langGroup] = integer

> * font.size.unit = px | pt
> 
> This gives the unit for font.size and font.min(imum?)-size.
> Question: if there was UI for changing it, how would one translate the old set
> of values into the new set? Using the DPI setting?

There are functions for doing the conversion. No need to bother now since
you don't plan to expose it in your first iteration.

> * font.default = serif | sans-serif
> 
> Question: what does this pref now do? Is it merely for backwards compatibility
> with un-updated versions of gfx?

The pref does two things now:
1. backwards compatibility, yes, and
2. generic default... if someone says, "font-family: font1, font2", see? there
is no generic font in this list. In this case, the pref will serve as the
default generic. (See my earlier post about how to compute it from the
default variable font.)

> In your mockup, several of the font size dropdowns say "Auto". Does this mean
> "Use the value for Variable if you are Serif, Sans Serif, Cursive or Fantasy,
> and use the value for Fixed Width if you are Monospace?" If so, this comes
> back to the difference between Fixed Width and Monospace in your mockup.

It means either that
- the UI persits the size as '0', or
- the UI removes the pref entry altogether

These two actions are equivalent. If the pref doesn't exist or has the
special '0' value, the back-end will do the rest as appropriate. (Actually,
the back-end will do what you quoted but the UI doesn't need to worry
about that).

    
    

    
  
This
+ variable | -moz-fixed | monospace | serif | sans-serif | cursive | fantasy
should instead read:
+ variable | fixed | monospace | serif | sans-serif | cursive | fantasy
(the pref key for "-moz-fixed" is "fixed".)

    
    

    
  
> [moz-fixed vs. monospace]

So, which is used when? Which corresponds to which dropdown in your mockup? Why
would I not want to always set both to the same font and size?

> font.name-list.[generic].[langGroup]

So when the user starts the browser for the first time ever and goes to the
Fonts prefs panel, what fonts do they see? The factory-set value of
font.name.[g].[lG]? The first found font in font.name-list.[g].[lG]? If it's the
former, how do we decide what to set it as? I was under the impression that the
point of the name-list was so that we could list cool but rare fonts first, and
that when you initialised Mozilla it used as the initial default the first one
that it matched from the list. This way people with good fonts get good fonts,
and people with only bad fonts get bad ones.

How, in fact, does it work?

A related question: why does font.name.[g].[lG] exist at all? Why is it not just
the first font in font.name-list.[g].[lG]?

Gerv










    
    

    
  
> > [moz-fixed vs. monospace]
>
> So, which is used when? Which corresponds to which dropdown in your mockup?

font.size.fixed.[lG] corresponds to the drop down of "Fixed width font".
font.monospace.[lG] corresponds to the drop down of "Monospace".

> Why would I not want to always set both to the same font and size?

You can -- i.e., the user can (in fact that's what 'Auto' does for the size). 
Conversely, the user can set different choices (Of note: Opera goes as far as 
allowing different settings between <pre>, <textarea>, etc. but it looks 
overkill... see the screenshot to be attached).

> > font.name-list.[generic].[langGroup]
>
> So when the user starts the browser for the first time ever and goes to the
> Fonts prefs panel, what fonts do they see? The factory-set value of
> font.name.[g].[lG]?

Yes, the user sees font.name.[g].[lG].

> The first found font in font.name-list.[g].[lG]? If it's the
> former, how do we decide what to set it as? 

Most of factory-set values already exist (e.g., in winpref.js or unix,js). These 
defaults are legacy of Nav4.x I think. Since they have been set over time and 
are known to be reasonable in various configurations, it makes sense to build 
upon these defaults.

>I was under the impression that the
>point of the name-list was so that we could list cool but rare fonts first, and
>that when you initialised Mozilla it used as the initial default the first one
>that it matched from the list. This way people with good fonts get good fonts,
>and people with only bad fonts get bad ones.

Exactly. But the user can still interact and can decide its first choice, by
overriding font.name.[g].[lG]. Maybe such a font can be a font that the user
has just installed for browsing purposes and which we cannot know. Whereas the 
name-list isn't exposed. But it is an arbitrary factory list where cool fonts 
can be listed, knowing that the font subsystem will only bother with the sublist 
of fonts that are installed on a particular user's system.

There was the issue of backward compatibility, and the need to cater for Gfx 
flavors that lag behind. font.name.[g].[lG] is the pref that has always been 
there, and the nomenclature builds on the existing prefs. For example, I didn't 
have to change unix.js, etc... Yet, their prefs still work. Now that  
font.name.[g].[lG] is going to be settable by the user, it means they can 
override with their preferred font. On the other hand, the name-list allows to 
set the cool factory fonts, some of which may not exist on a particular user's 
system.

> How, in fact, does it work?

Suppose Mozilla is released with:
font.name.cursive.x-western = "Zapf Chancery"
font.name-list.cursive.x-western = "Comic Sans MS, Flemish Script BT, etc..."

And a document with <span style="font-family: cursive"> ... </span>

If  "Zapf Chancery" is installed on a particular user's system, it will be used.
If not, the existing font in the name-list will be used, in order. Since not all 
fonts may be installed on all systems, it is not strictly possible to say in 
advance which font is going to be used. From the Nav4.x legacy, the current 
factory default for font.name.cursive.x-western is likely to be installed. But 
in any case, as soon as the user visits the Fonts dialog, they can now override 
with something else which is guaranteed to exist on their system (and they could 
pick a brand new font that they just installed.)

>A related question: why does font.name.[g].[lG] exist at all? Why is it not 
>just the first font in font.name-list.[g].[lG]?

Backward compatibility. And a side-benefit... it makes things simpler, no need
to parse font.name-list.[g].[lG] in a special manner. And furthermore, it allows
to gracefully cater for Gfx flavors that lag behing.

    
    

    
  


  

    
    

    
  
My worry is that if there are two different monospace prefs, users will be
confused as to which applies when. Could you tell me exactly when we use
moz-fixed, and when we use the monospace font-family?

> Most of factory-set values already exist (e.g, in unix,js). These 
> defaults are legacy of Nav4.x I think. Since they have been set over time and 
> are known to be reasonable in various configurations, it makes sense to build 
> upon these defaults.

As I see it, this misses a rather large chunk of the point of having the list at
all. If you read mpt's comment of 2000-12-12 (second from the top of this bug)
it makes the point that users can have much better fonts installed, but we are
stuck with setting ugly, common fonts as the defaults. The font-list was
supposed to cure that problem by having Mozilla choose the first font present
from the list as its initial default. The key point here is that Mozilla would
use the decent fonts without the user having to _do_anything_.

So, what we really want is for, at e.g. profile creation time, the
font.name.[g].[lG] prefs to be filled with the results of your font-discovery
process (that you use when the initial font is not found) applied to the
font-lists. Is this equivalent to shipping with the values of font.name.[g].[lG]
set to ""?

Gerv


    
    

    
  
You might want to take the time to re-read the bug again. I think you will find
additional details scattered here and there, as most of what is needed has been
commented about. On the client's side, nearly all CSS are defined in terms of
"-moz-fixed" whilst on author's pages, it is "monospace", that's the reality to
deal with. 

For the default fonts, notice that they can really be anything, including being
empty/unspecified -- although caution suggests otherwise since people who can
install cool fonts and precisely those who can visit the Fonts prefs and tweak
them. The GFX font subsystem will filter the lot and pick the ones that exist,
in order. (Discovery is a possible iteration at some stage -- an item for
another bug, perhaps.)

    
    

    
  
s/and precisely/are precisely/
("Discovery" in my comments refers to the programmatic construction of the lists 
at install time as noted in btsell's comments of "2001-05-09 19:35" -- not a 
simple task.)

    
    

    
  
A solution that consists in making separate menus for -moz-fixed and monospace 
seems wrong to me.  It's going to be confusing for users.  The two settings don't 
have to be separate anyhow.  The Opera font prefs dialog is for geeks, let's not 
take that route.


    
    

    
  
Sorry, people. Clearing the decks for the Links toolbar. I'll try and get to
this before the next milestone.

Gerv
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
  
Blocks: 71539

    
    

    
  
I am a bit lost...  Were any of the attached patches checked in yet?  Do the 
prefs files on all 3 platforms support the specification of default fonts 
similarly to a CSS font-family (eg "Verdana, Arial, Geneva, Helvetica")? 


    
  

        Attachment #32417 -
        Attachment is obsolete: true

    
  

        Attachment #33044 -
        Attachment is obsolete: true

    
  

        Attachment #37161 -
        Attachment is obsolete: true

        Attachment #37161 -
        Attachment is patch: true

    
  

        Attachment #37162 -
        Attachment is obsolete: true

        Attachment #37162 -
        Attachment is patch: true

    
  

        Attachment #37602 -
        Attachment is obsolete: true

        Attachment #37602 -
        Attachment is patch: true

    
  

        Attachment #39114 -
        Attachment is obsolete: true

        Attachment #39114 -
        Attachment is patch: true

    
  

        Attachment #32399 -
        Attachment is obsolete: true

    
    

    
  
Only GfxWin, see my comments of "2001-09-28 13:00" -- so backward-compatibility
with other platform prefs is indeed important.

The support code for GfxWin can be found here:
http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp#2815

The bug may be confusing with the way design ideas & etc evolved, but it makes
interesting reading to see how things came along (and to see how some points are
still unclear even after all this time...)

Regarding the name-list code, if you want to hook the Mac, some comments about
how it works can be found in "2001-06-05 15:10" and "2001-06-07 02:19".

    
    

    
  
pierre:
just want to let you know on window "Times New Roman", "Courier New" and "Arial"
all implmenet WGL4 (Window Glyph List 4), which include glyph for Western, East
European (Latin base), Cyrillic, Turkish, Baltic and Greek glyph. Therefore, it
is ok to still use them as the default font name. 

    
    

    
  
I feel really bad that I still haven't found time for this; I started on it, but
got rebuffed by the horrible complexity of the JS backing up the Preferences
Panel, for which there is no documentation. Appeals for help to ben and blake
were ignored. Also, there's a potential clash with the guy doing previewing of
fonts.

<sigh>

Gerv


Target Milestone: mozilla0.9.6 → mozilla0.9.8

    
    

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

    
    

    
  
>by the horrible complexity of the JS backing up the Preferences Panel

Gerv - I had the honor before and might have the cycles to help. I'm planning 
on visiting friends and family in Germany, but I do intend to follow this bug.

    
    

    
  
Er, this wins the award for most bloated bug I've seen yet. Wow.

It it worth reopening bug 110342 just to get the minimum font size in, or wait for this?

If this bug isn't going to be resolved in the next two months, I'd say reopen the dup and work on that as a short term measure.


    
    

    
  
There's a load of stuff which needs doing to this panel; but the JS is such a
mess that I doubt there's much advantage in just doing a few bits - it'd take
the same time as the required rewrite.

But this still isn't really on my radar :-(

(BTW, check bug 2800 for more bloat ;-)

Gerv

    
    

    
  
I don't see a UI spec mentioned in this discussion, but one issue I hope is part
of any upcoming rewrite: currently prefs/fonts brings up a pane which says  
"Fonts for: [         ]" where the value of the dropdown is blank, and the fonts
all default to Times (or was it Courier?) at 8pt.  It's not clear whether these
values actually apply to anything.  I can select Western in the dropdown, change
values, and when I click OK the changes do affect pages I'm viewing.  After
selecting Western, I can't get back to that blank menu unless I make a new
profile.  I've seen users get frustrated trying to change them and wondering why
they obviously don't relate to what's being shown on the screen (and I can't
help, since I don't know what the "blank language" prefs mean either).  I hope
that the font pref ui work for this bug will also solve this issue and make the
pref panel show the font settings for the default language.

Meanwhile, I'll go ahead and detach the minimum font size ui bug.

    
    

    
  
This bug indirectly blocks #84271 which is an nsbeta1+ bug so it needs some
lovin'.  Setting TFV: to match #84271.
Keywords: nsbeta1
Target Milestone: mozilla0.9.8 → mozilla1.0
No longer blocks: 73734

    
    

    
  
I'm not going to get to this :-(

Gerv
Assignee: gerv → nobody
Status: ASSIGNED → NEW

    
    

    
  
testcase provided in comment 5.
adding keyword 'testcase'.

I suppose this bug needs some immediate attention due to the reason mentioned in
comment 133
Keywords: testcase

    
    

    
  
What really remains is to finish off the elements indicated in the mockup of the UI:

    Fonts :::::::::::::::::::::::::::::::::::::::::::::

    +-Fon_ts for: [default choices        :^]---------+
    | _Variable Width Font: [Georgia      :^][  16:^] |
    |    Fi_xed Width Font: [Courrier New :^][  13:^] |
    |                                                 |
    |               _Serif: [Times New Rom:^][Auto:^] |
    |          Sa_ns-serif: [Trebuchet    :^][Auto:^] |
    |             _Cursive: [Zapf Chancery:^][Auto:^] |
    |             _Fantasy: [Desdemona    :^][Auto:^] |
    |           _Monospace: [Courier New  :^][Auto:^] |
    |                                                 |
    |                    Minimum font si_ze: [None:^] |
    +-------------------------------------------------+
    [/] Allow documents to use _other fonts

with the following prefs used to persist the choices that the user has done:
pref(font.name.GENERIC.LANGGROUP, "name-of-the-selected-font");
pref(font.size.GENERIC.LANGGROUP, "integer");

(the whole column to set the individual font.size per generic family can be
omitted -- thus getting an appearance close to the current dialog).

LANGGROUP is to be substituted with the current language in the drop down list
of "Fonts For".

GENERIC is either: variable | fixed | serif | sans-serif | cursive | fantasy |
monospace (in accordance with the mockup).

Hooking such an UI doesn't seem like rocket science. For example, bug 110342
added the UI to control the minimum font size relatively quickly. Default values
that ship with the product are currently kept in winpref.js, unix.js.

    
    

    
  
I'd be very interested in either helping out with this or even owning this bug. 
I'll have to check with my new manager at Netscape, but I might be able to 
spend some cycles on this. 

Could anyone comment on the timeline estimates? Going back to Gerv's comments: 
I'd not recommend rewriting the whole pref panel from scratch, that would put 
this out of my scope as well.

    
    

    
  
*** Bug 155993 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → ---

    
    

    
  
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
  
Keywords: intl

    
  
Blocks: thai-unix.js

    
  
Blocks: thai

    
    

    
  
*** Bug 326293 has been marked as a duplicate of this bug. ***
QA Contact: ian → style-system

    
    

    
  
I support the mockup in comment #136


    
    

    
  
BugAThon Bangkok:

remove Thai support dependency.
No longer blocks: thai
Keywords: uiwanted

    
    

    
  


  
As of Windows Vista, a nice cursive font is finally included by default, Segoe Script
http://www.microsoft.com/typography/fonts/font.aspx?FMID=1633
We should use that for latin characters.
Assignee: nobody → moz-ian
Status: NEW → ASSIGNED

        Attachment #8559770 -
        Flags: review?(jdaggett)

    
    

    
  


  
Here's a quick before and after of the effect the patches have, on Windows 7. Should be the same on everything Vista and up.  XP will still use Comic Sans MS for the Cursive due to it lacking Segoe and my setting of cursive.name-list

    
    

    
  


  
So judging by bug 1096800 comment 12, this will need a talos change

        Attachment #8562122 -
        Flags: review?(jmaher)

    
    

    
  
Comment on attachment 8562122 [details] [diff] [review]
Add Segoe Script to the talos whitelist

Review of attachment 8562122 [details] [diff] [review]:
-----------------------------------------------------------------

font changes are fine!  Thanks for doing this.  Remember we will need to update talos.json in-tree after this lands.

        Attachment #8562122 -
        Flags: review?(jmaher) → review+

    
    

    
  
Change to P5 because P4 is used for Bot.


Priority: P4 → P5

    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 13 votes.

:Kwan, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(moz-ian)
Severity: S3 → --
Type: defect → enhancement
Flags: needinfo?(moz-ian)

    
    

    
  
The bug assignee is inactive on Bugzilla, so the assignee is being reset.


Assignee: moz-ian → nobody
Status: ASSIGNED → NEW

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: