Bug 377651 - gnome needs limit on font DPI deduction
Summary: gnome needs limit on font DPI deduction
Alias: None
Product: Fedora
Classification: Fedora
Component: control-center
Version: 9
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Control Center Maintainer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-12 12:33 UTC by Tom Horsley
Modified: 2009-05-08 12:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-05-08 11:43:06 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 546711 0 None None None Never

Description Tom Horsley 2007-11-12 12:33:50 UTC
Description of problem:

I use a 42" 1920x1080 HD monitor for my primary computer monitor (as well as
for a TV). Gnome or X or someone (not sure what to report this bug against)
is far too literal minded when it comes to accepting the EDID info. It
computes 53 dots per inch for the monitor (which is literally correct),
and that results in microscopic letters in all the buttons and menus and
wot-not that are very close to impossible to read. After much fumbling
around I finally found the font settings panel and explicitly changed the
DPI to 96 and things got much better.

Version-Release number of selected component (if applicable):

whatever shipped with the Fedora 8 install DVD (I'm not on that computer
now, so I can't check).

How reproducible:

Anytime you login to a freshly installed system with this monitor.

Steps to Reproduce:
1. see above
Actual results:

Tiny little unreadable fonts.

Expected results:

Either put a reasonable limit on the minimum pixel height of fonts, or
at least have a one-time popup box when microscopic pixel heights are
detected that asks "Hey! Do you want to set a larger DPI value?" :-).

Additional info:

Comment 1 Tom Horsley 2008-05-15 02:00:29 UTC
In fedora 9, this got even worse. The GDM login screen now uses
the same 52 DPI, and there isn't any place to force it to use 96
(that I know of).

Comment 2 Bastien Nocera 2009-05-08 03:15:52 UTC
You can set the DPI in gconf-editor, look for /desktop/gnome/font_rendering/dpi

I'm afraid that your problem isn't an easy one, and that work is on-going in GTK+ upstream to get nearer resolution independence (so your desktop would look good on your 42" telly).

If the work-around works, I'll point you to the upstream GTK+ bug.

Comment 3 Tom Horsley 2009-05-08 10:00:57 UTC
Actually there are a number of work-arounds I've come up with, but the best
one so far is to switch to using KDM instead of GDM and use KDM's kdmrc file
to set the -dpi 96 option in the X server startup arguments. That gets the DPI
set to an acceptable value in every toolkit for every user and in a driver
independent fashion. Using gconf, you have to get user gdm's preferences set
to influence the login screen (which I have done by copying my .gconf directory
to user gdm's .gconf directory.

Comment 4 Bastien Nocera 2009-05-08 11:43:06 UTC
Glad you found a work-around.

As for the GTK+ patches, details below.


Comment 5 Tom Horsley 2009-05-08 12:40:49 UTC
Those gtk patches are all very well, but they seem to be based on the utterly
false premise that display devices actually report reasonable DPI values,
they won't help anything on a display that doesn't have reasonable DPI, though
it is certainly a worthy goal to remove all hard coded pixel widths and
replace them with point size units that will scale with changing dpi.

Perhaps when they finish with that, they'll realize how futile it was
and finally restore the gdmsetup tool to make it easy to lie about DPI
(or even tell the truth about DPI to work around a display device which
lies - my new samsung HDTV reports 160mm x 90mm as the size in EDID,
which means it claims to have 305 DPI resolution on a 46" display, leading
to dialog boxes which won't fit on the screen :-).

Maybe something will come of my upstream Xorg bug someday:


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