Font Settings Design

Rationale

Typically we have two different uses for font selection.

The font used in the "user interface"
The font used in content I'm creating

The first is a configuration option for the system itself and the second is typically offered by a specific application as a way to change the default.

In this page we'll focus on the first case - font settings that apply to the desktop.

This case can theoretically be broken down into a huge number of configuration options but GNOME currently limits this to:

The default font used in applications and most user interfaces
The default font for document display and creation
The font used to label files in the file browser and on the desktop
The font used to label windows in their titlebar
The default font for fixed-width uses

In addition to these options the tool allows the user to configure or tune the rendering mechanism to the settings that she finds most appealing.

There are a few problems with this dialog as it stands. We'll try to capture some of the issues that motivated the various discussions that can be found in the "Previous Discussions and Designs" section.

Some of these problems include:

It is too difficult to quickly increase or decrease text size
The interface for picking a font is clumbsy
- Lists are too small vertically by default
- Horizontal scrollbars ugh!
- The preview doesn't show me the effect on the interface I'm interested in changing
- The Style pane offerings are dependent on the Family selection but don't appear to be
- Doesn't have a good search (only typeahead search)
- Might be good to filter by sans-only etc
- Doesn't seem to distinguish virtual and native variants (Italic vs. Oblique - typography geeks care)
- Have a way to see a full specimen?
- Should not show fonts that make no sense as the default (eg. don't try selecting "wasy" as your default font)
Seems a bit like the picker dialog pops up separately only because that dialog already exists not because it is the best design
Font size numbers don't mean much (technically)
Unclear interaction between font size and screen DPI
Design of rendering system selection doesn't facilitate comparison
Unclear how this relates to Universal Access
Why is the text preview different in the picker dialog and the rendering configuration?

Relevent Art

GNOME 2.26

Mac OS X 10.5

OS X does not allow the user to change the user interface font faces or sizes.

Applications may offer the following dialogs to change fonts:

Windows 7

Font selection is supported in a configuration screen buried beneath an "Advanced appearance settings..." button in the Window Color and Appearance Personalization control panel.

DPI Scaling

http://www.istartedsomething.com/20081029/windows-7-dpi-scaling-my-7-is-bigger-than-your-7/
http://blogs.msdn.com/greg_schechter/archive/2006/08/07/690704.aspx
http://msdn.microsoft.com/en-us/library/dd464646%28VS.85%29.aspx
http://blogs.msdn.com/nickkramer/archive/2006/04/12/574587.aspx
http://blogs.msdn.com/greg_schechter/archive/2006/03/05/544314.aspx
Windows 7 offers DPI scales of 96, 120, 144, 192, and custom

ClearType Tuning

Others

http://www.guidebookgallery.org/screenshots/font

Previous Discussions and Designs

From Owen

<owen> mccann: I think scaling the points-per-pixel ratio as the primary method of zooming is reasonable. But you cannnot, cannot, cannot tie that to the dpi of the screen. it doesn't work. You *can* do an automatic best guess selection based upon the screen resolution, reported dpi, and other factors that you know about (like "is it a laptop" "is it an external display")
<owen> If you make it really easy to change the font size, then it's incumbant to fix other scaling issues - if the fonts get more than 20-30% larger, other things will get out of whack
<owen> If you are goigng to make changing the dpi the primary way of changing the font size, then changing the individual font sizes in gnome-font-properties doesn't make sense. We dont' need multiple interfering font size sliders duplicating the volume control situation
<mccann> owen: 20-30% larger than?
<owen> Making a size-less font selection might require GTK+ API additions
<owen> mccann: the current GNOME defaults.
<mccann> ok
<owen> One thing to be aware of is that fonts look better at 96dpi than at 90dpi or 100dpi
<owen> Using discrete pre-picked dpi values allows optimization of fonts in a way that a slider or picking up whatever the screen happens to be doesn't
<mccann> owen: how do we choose those values where they look best?
<owen> mccann: well, 96 and 120 are the traditional values for windows XP. 72 dpi is a tradititional mac value
<owen> mccann: above 120 - well, if you can reverse engineer what the dpi's are in the windows vista selection, use that

<federico> mccann: I'd say:
<federico> 1. we need a live preview (we can't do instant-apply on the whole desktop right now; it's too slow)
<federico> 2. we don't want "document font" in the capplet (which document?  where is that actually used right now?)
<federico> 3. even the fixed-size font is a stretch there...
<federico> 4. DPI is stupid.  We want a single slider for UI elements; no tweakability of spacing (apps should do good spacing with font-relative-scaling when that lands in gtk)

<ssp> owen: OK, fair enough. I'm not violently opposed to some sort of UI that would scale all fonts on the screen if that's deemed to be a good idea by designers. 
<ssp> Whether it is a good idea, I have my doubts about
<ssp> It shouldn't be tied the dpi as reported by X or EDID - that number should basically be ignored

<ajax> the only good use for [the dpi as reported by X or EDID] is tuning subpixel coverage
<ajax> and as a rough guide for heuristicking what kind of display form factor you're using, _maybe_
<ajax> even then you still lose when you have wildly different DPI on different displays, so it's probably better not to try.
<ajax> oh, and if you're a desktop publishing app and you really do want pixel presentation to match physical size.

Use Cases

Primary

Regina has received a new computer at work. She works long hours and her eyes are strained by small fonts. She would like to increase the size of all the fonts on the computer by a moderate amount.
Bob has connected his laptop to a screen that is across the room and is controlling it using a bluetooth keyboard and mouse. The fonts that were appropriate when shown on his internal laptop screen are now far too small to be visible at the new distance.
Celia is an author. She recently found out that all her article submissions must be made using a specific font. She would like to set this font as the default for all new documents she creates.

Secondary

Thorsten is a web designer and he is very particular about how fonts look on his screen. He uses both Windows and Mac computers regularly. He changes fonts frequently and likes to customize the way fonts are rendered.
Kylie is 11 years old and she loves Hannah Montana. Her mom is a computer programmer and has given her an account on their shared computer. Kylie likes to switch between a funky wild pink and light blue design with a fancy script when she is searching the web before bedtime and a theme with earth tones and a standard script when doing research for school.

Design

Notes

If we want to have all the fonts rendered on the family font below the family name the default treeview/liststore implementations make this operation really slow. For the sake of usability we should look into ways to lazyload the cells, here's some example from the file chooser code by Company: http://git.gnome.org/cgit/gtk+/commit/?h=filesystemmodel&id=04b7b41b75dd769433a0594b5e5d0347d858f00c