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: Always 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 EDID).
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 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.
This should be fixed in tomorrow's rawhide