This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 127532 - dpi value changes font size in gdm
dpi value changes font size in gdm
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Depends On:
  Show dependency treegraph
Reported: 2004-07-09 11:03 EDT by Carlos Rodrigues
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-13 16:50:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Carlos Rodrigues 2004-07-09 11:03:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

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
logging in.

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):

How reproducible:

Steps to Reproduce:
1.Remove the DisplaySize from xorg.conf
2.telinit 3
3.telinit 5

Actual Results:  The fonts in gdm get smaller.

Expected Results:  The fonts should keep their size.

Additional info:

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
Comment 1 Benjamin S. Scarlet 2004-07-17 10:01:04 EDT
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.
Comment 2 Carlos Rodrigues 2004-07-17 13:05:13 EDT
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).
Comment 3 Jonathan Briggs 2004-08-25 19:02:24 EDT
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.
Comment 4 Stefan Becker 2004-11-19 14:50:26 EST
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
way off:

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.

Some ideas:

 - 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
and measure.
Comment 5 Ray Strode [halfline] 2005-04-13 16:50:41 EDT
This should be fixed in tomorrow's rawhide

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