Red Hat Bugzilla – Bug 127532
dpi value changes font size in gdm
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
When the display resolution is set to 75dpi, such as when there is no
"DisplaySize" line in "xorg.conf", all the fonts in the GDM login
screen get smaller. This doesn't seem to affect any other app after
I don't know if this is the standard behavior (as I actually never
understood in what way is the dpi value used in font rendering, just
seen some weird effects on some fonts if the Xft value is different
from the value that mozilla uses, but this is offtopic) but it doesn't
feel right, so I think it is a bug.
It's not that serious as the FC2 installation puts a DisplaySize line
in xorg.conf, but I think this may mean that the font size also
changes when the monitor size changes (and the screen resolution stays
the same), as the dpi value changes accordingly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Remove the DisplaySize from xorg.conf
Actual Results: The fonts in gdm get smaller.
Expected Results: The fonts should keep their size.
I have a 17" TFT monitor at 1280x1024, which gives it a 96dpi value if
one uses the DisplaySize of 340x270 that the installer puts in
xorg.conf (and the one that the nvidia drivers get from the monitor's
This problem is exaggerated when connected to a physically large display. I'm using a
1280x768, 30" LCD TV. Both gdm and rhgb seem to be trying to choose their fonts to be
an absolute size. The result is that the text is unreadable, because a font the same actual
height as would be readable on a standard computer display is only a very few pixels high
on this large but low-dpi screen.
The right answer seems to me to choose the font size as the larger of a physical size and a
size in pixels. That way, for high dpi screens the pixel size would lose and you'd get a
well-rendered font at a reasonable size, but for low dpi screens you'd get an increasingly
physically large font with enough pixels to be read.
Well, I think it should do neither. The pixel size of a font should
stay the same regardless of dpi or absolute resolution. If one wants
to magnify the text, there sould be other means. Bigger resolution
(YxZ) should always mean a bigger "desktop" but same size (absolute,
in pixels) fonts. DPI should not affect scale.
Rephrasing what I said, either the DPI value stays fixed at 96dpi with
only the user being allowed to change it (like Windows does) or DPI
value should not be used to scale fonts (it can have other purposed,
application specific) and instead provide a "scale" option in
xorg.conf (which could be derived from DPI if the user so desired).
The font system is using the DPI information to make a 12-point font
always be 12 point size. It should be 12 points on screen and the
exact same size on paper. You should be able to hold up a printed
sheet to the screen and have the same size.
That's the right thing, in my opinion.
Now, for applications like GDM, perhaps it should be selecting fonts
as a percentage of screen size instead of by point size.
It seems that FC3 install no longer sets DisplaySize in xorg.conf, at
least on my laptop where I selected "Generic LCD Panel (1400x1050)"
during the installation process.
Unfortunately it's not only rhgb and gdm which are affected by too
small fonts, but also applications started via xinit/startx <client>,
because in this case the default resources from /etc/X11/Xresources
are not merged in and therefore the resource "Xft.dpi: 96" is not set.
I have seen this with xine/gmplayer which I run via xinit on a second
server for the TV connected to the external VGA, and with the Synpatic
package manager which I run with xinit when the system is on runlevel 3.
The problem gets even worse when the TV is connected to the external
VGA port at X server initialization, because now the DDC information
comes from the TV and not the LCD:
(II) SAVAGE(0): VESA VBE DDC read successfully
(II) SAVAGE(0): Manufacturer: SAM Model: 73 Serial#: 808464432
(II) SAVAGE(0): Max H-Image Size [cm]: horiz.: 110 vert.: 62
(--) SAVAGE(0): Virtual size is 1400x1050 (pitch 1408)
(--) SAVAGE(0): Display dimensions: (1100, 620) mm
(--) SAVAGE(0): DPI set to (32, 43)
The resolution is still set from the LCD panel so the DPI values are
1100mm ~ 43" with 1400 pixels -> 32dpi
620mm ~ 24" with 1050 pixels -> 43dpi
and much smaller than the default 75dpi one. Therefore the fonts are
scaled even smaller!
So I guess the installation process should always set DisplaySize.
- Why not add the size information to the Monitor DB? At least for
the specific models the size is known. For the Generic ones
system-config-display could then force the user to enter the size.
- Add aspect ratio/screen diagonal to the DPI setting dialog to make
it easier for users to set the size without having to get out a ruler
This should be fixed in tomorrow's rawhide