GNOME Bugzilla – Bug 113051
Font preferences shouldn't be different to default GNOME settings
Last modified: 2004-12-22 21:47:04 UTC
Is there a *good* reason that epiphany has separate font selection from the rest of GNOME ? The obvious reason (Although I don't call it "good") is that Mozilla expects multiple fonts to be defined for the various "types". However is there a reason that these couldn't map to fonts set up in the GNOME Font preferences (My guess is that we already have 2 out of 3 (It's 50/50 whether to map Application font to Serif or Sans Serif), ie: GNOME - Mozilla Application Font Sans Serif Application Font???? Serif Terminal Font Monospace Would we need to do anything/much more to match these up properly and remove the font selection stuff from epiphany, or are there a11y reasons to keep them there [And if so why is a web browser different to all the other apps that mean that they don't need this - specifically word processors where the document font is under the control of the author, not the reader?)
CSS recommends that web browsers should be able to specify Serif, Sans-Serif, Cursive, Fantasy and Monospace fonts: http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families
Problems to solve are: - Are the very granular mozilla settings necessary for accessibility ? - Is there a satisfying way to map gnome desktop settings to browser settings, or these could be extended so satisfy our needs. For example, is it sane to assume the same font is good for a web page and applications ? It would seem that a system font to display text (web or pdf or text viewer ....) is necessary. Maybe there is one, or it's just fine to use the application one. Unfortunately I cant access gnome and check now. - When we enabled this in galeon 1, a while ago, using a different font then the default was causing several layut problems. This may have changed now. - Encodings
About font families, I ever wondered if these terms (Serif etc...) are understable to vast majority of users. Personally I never understood what they means, and I ever configured all fonts to the same value. It could be a language problem (maybe they make sense to english "readers").
The main thing is Serif vs. Sans Serif. FYI, "serifs" are the short lines or curves projecting from the top or bottom of a mainstroke of a letter. It is important to be able to make the distinction and difficult to simplify. Generally, serif fonts are more traditional looking and are good for printed stuff (because the serif help you to follow lines) and sans-serif fonts are more modern and are good for on-screen stuff because they are clear. Of course for stuff like Cursive and Fantasy, you don't have to use those names - you could label them "Natural Writing" and "Decorative" or something.
Created attachment 16549 [details] Pretty picture, serif vs. sans serif :)
marco, totally unrelated, but those combo boxes in the fonts dialog, I know i told you to make them combo boxes, but uhhh I was wrong they should be option menus :/ /me was young and stupid :)
I think i18n is a non issue. Fontconfig is smart and with default aliases (that are also default fonts in gnome), it can deal with encodings automagically.
I'm not sure if doing this is "good" for a11y. http://www.w3c.org/TR/UAAG10/guidelines.html#tech-configure-text-scale 1. Allow global configuration of the font family of all visually rendered text content. 2. As part of satisfying provision one of this checkpoint, provide a configuration option to override font families specified by the author or by user agent defaults. 3. As part of satisfying provision one of this checkpoint, offer a range of font families to the user that includes at least: * the range offered by the conventional utility available in the operating environment that allows users to choose the font family, or * if no such utility is available, the range of font families supported by the conventional APIs of the operating environment for drawing text. In a way i do agree we should probably have global prefs for these that all html renderers use in their presentation. So maybe a small reduction in the available prefs of epiphany is worth it in the long run, not sure. At the very least we're going to need to continue to provide an overide text size specified pref.
------------- 1. Allow global configuration of the font family of all visually rendered text content. ------------- OK - we have that in the GNOME font preferences. ------------- 2. As part of satisfying provision one of this checkpoint, provide a configuration option to override font families specified by the author or by user agent defaults. ------------- Checkbox - "Always use my fonts" - where "my fonts" is defined as those you set up in the GNOME font preferences. ------------- 3. As part of satisfying provision one of this checkpoint, offer a range of font families to the user that includes at least: * the range offered by the conventional utility available in the operating environment that allows users to choose the font family, or -------------- OK - the language is a little long-winded here - doesn't this just mean that we have to allow specification in the same area as GNOME font preferences - if so then using the GNOME font preferences means we're doing that? -------------- At the very least we're going to need to continue to provide an overide text size specified pref. -------------- Hmm yeah - maybe that should be at the GNOME level as well though? (After wouldn't the same requirement be present in a Word processor?)
>1. Allow global configuration of the font family of all visually >rendered text content. We dont have this in gnome. Families == serif, sans serif etc .. gnome fonts configuration is different.
My opinion is that for epiphany 1.0 we should target to just simplify these prefs. Then we can think to integrate them more with the desktop I think we can default to fontconfig families aliases (which are also gnome defaults), and then remove the encoding thing that is terribly confusing. In fact fontconfig will automatically choose a good i18n font for default families. If someone really want change them, I think in 99% of cases he will not need to configure them per encoding, he will just select a font that works also with his country encoding. (Someone has a clue if the Proportional option menu is useful ?)
*** Bug 113531 has been marked as a duplicate of this bug. ***
marco, since we use font config, can we at least change the ui to use the gtk-font-sel instead of the mix of option menus and combo boxes(what the hell was i thinking when i recommend that, please shoot me). Ist thi s possible? Just using the standard interfaces would make this part of the ui 100% better
I dont think we can do it. There are several problems ... - You cant filter gtk dialog by family - The Proportional size apply both to serif and sans serif and the font dialog has a size field - Not sure if the fonts will ever match what mozilla can use
The Propotional menu defines which font we use when no font is specified in a web page (so it needs to stay).
Created attachment 16736 [details] What we do for each CSS font family
I think we should see that the language-based font setting serve actually two different purposes. First, it lets you choose different sizes for different language. I think that's important. For example, you can have your normal text in 10, but you just might want to display all cjk characters at 24 :) I don't know if fontconfig lets you define that when you have e.g. "Sans 10" and a japanese char is requested, it actually it "Mincho 24" or sth ... ? Second, it lets you define which fonts to choose for which language. E.g. for "Sans" it means that for example for western languages it means Arial while for japanese it's mincho, for trad. chinese sth else etc... In that respect, the font prefs act like a fontconfig alias generator. Fontconfig already has this capability, and if there was a desktop-wide, standalone program which let users modify their fontconfig aliases in that manner, we could drop these prefs.
Same issue, we want to discuss it in one place I guess. *** This bug has been marked as a duplicate of 114228 ***