HugeFonts

Revision 3 as of 2009-01-30 08:40:39

Clear message

Crazy huge (or insanely tiny) system font sizes can be caused by incorrect DPI detection, often caused by incorrect monitor EDID information.

Symptoms:

  • On the GDM login screen and possibly in seemingly random places in the desktop UI, text is displayed in font sizes that are abnormally large - like ten times what you expect. (Probably, the monitor is lying about its size)
  • Throughout the desktop, fonts are about the right size and shape, but they're just slightly off. You may simply need to tune off of the default 96 dpi.

Non-Symptoms:

  • If the font is the right size, but the wrong typeface, you don't have this problem. More likely you installed some extra font that is overriding the usual default; try uninstalling some fonts.

How It Works

Your monitor has certain data encoded in its firmware. This data is called the EDID, and it includes the physical dimensions of the monitor. Knowing that, and the current resolution, X is able to calculate the effective Dots-Per-Inch (DPI), which GNOME and other applications use for font sizing.

In theory that should be that. In reality, many monitors lie about their capabilities. Long ago, many monitors didn't give this info at all so we had to make guesses based on the video card (which were almost always wrong.) All of this was so problematic when we first switched to it in Gutsy, that for GNOME we decided to just force everyone to 96 dpi! We'll probably revisit that decision at some point and revert that once we trust monitors a bit more. I think the 96 dpi forcing only applies to the logged in session, so you might still see the issue on the GDM login screen.

Problem: Monitor is lying

The most common cause for crazy huge fonts is that the monitor is miscommunicating its EDID. This issue is more commonly seen on KDE than GNOME.

Usually your /var/log/Xorg.0.log has a section that describes the parsed EDID (search on 'EDID'). For example, here's mine:

(II) RADEON(0): I2C device "DVI-1:E-EDID segment register" registered at address 0x60.
(II) RADEON(0): I2C device "DVI-1:ddc2" registered at address 0xA0.
(II) RADEON(0): EDID vendor "BNQ", prod id 30427
(II) RADEON(0): Using EDID range info for horizontal sync
(II) RADEON(0): Using EDID range info for vertical refresh
(II) RADEON(0): Printing DDC gathered Modelines:
(II) RADEON(0): Modeline "1920x1200"x0.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 +hsync +vsync (74.0 kHz)
...
(II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3
(II) RADEON(0): Panel infos found from DDC detailed: 1920x1200
(II) RADEON(0): EDID data from the display on output: DVI-1 ----------------------
(II) RADEON(0): Manufacturer: BNQ  Model: 76db  Serial#: 7709
(II) RADEON(0): Year: 2007  Week: 37
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max Image Size [cm]: horiz.: 52  vert.: 33
(II) RADEON(0): Gamma: 2.20

Notice the 'Max Image Size', which shows the (correct) physical dimensions. Check to see what it says for yours, and if it is at all correct. Problems that have been seen in the past include incorrect units (mm instead of cm), 0's, and more.

Here's an example of one where the monitor lies:

(II) VESA(0): Max H-Image Size [cm]: horiz.: 33  vert.: 21
...
(II) VESA(0): Supported additional Video Mode:
(II) VESA(0): clock: 71.2 MHz   Image Size:  289 x 21 mm
(II) VESA(0): h_active: 1280  h_sync: 1328  h_sync_end 1360 h_blank_end 1440 h_border: 0
(II) VESA(0): v_active: 800  v_sync: 802  v_sync_end 808 v_blanking: 823 v_border: 0
(II) VESA(0):  LGPhilipsLCD
(II) VESA(0):  LP154W01-TLA1
(II) VESA(0): EDID (in hex):
...
(II) VESA(0): EDID vendor "LPL", prod id 0
(II) VESA(0):     EDID quirk: Detailed timings give horizontal size in cm.
(II) VESA(0):     EDID quirk: Detailed timings give sizes in cm.

Notice the 289 x 21 mm dimensions -- clearly wrong! But in this case the X server has caught it via a couple quirks.

Two other tools provide EDID dumps:

xrandr --verbose

get-edid | parse-edid  # From the read-edid package

The first command uses the same code for parsing EDID as the X server, while the second uses somewhat different code. So it's helpful to look at both; if they both show the same, then your monitor is probably giving bad EDID; otherwise, it could be a problem with the parser.

In the case that your monitor is giving bad EDID, the X.org team can put in a quirk (workaround) specific to your monitor model. Please see X/Quirks for details on how to file a bug requesting this, the info to include, etc.

Problem: 96 dpi looks ugly

While using 96 dpi gives a nice generic default, it's not the right dpi for all situations, and on certain screens it will look downright yucky.

You can determine what X *thinks* the dpi should be via this command:

$ xdpyinfo | grep dots
  resolution:    94x94 dots per inch

You can then adjust the fonts in GNOME via System > Preferences > Appearance > Fonts > Details... and then changing the Resolution spinner to that dpi.