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.

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"}

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

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.

The fonts can be tested at http://www.w3.org/Style/CSS/Test/current/sec522.htm

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.

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?

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

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.

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.

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

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

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

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.

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()

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.

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.

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]

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.

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.

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.

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

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. [...]"

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.

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.

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

> 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

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")?

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

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

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

testcase provided in comment 5. adding keyword 'testcase'. I suppose this bug needs some immediate attention due to the reason mentioned in comment 133

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

adt: nsbeta1-

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

I support the mockup in comment #136

BugAThon Bangkok: remove Thai support dependency.

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.

Impact chosen based on http://www.w3.org/Style/Examples/007/fonts available since XP http://www.microsoft.com/typography/fonts/font.aspx?FMID=1845

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

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.