Font sizes in Gutsy are affected by bad X.org DPI detection

[Martin Pitt]

In Gutsy, Gnome switched to using the X server's screen DPI detection, which means that fonts can easily appear to be too large or too small, depending on your screen setup. The old approach was to use 96 DPI by default, but the new one can result in widely differing DPI values. We need to improve the detection, or give people an easy way to tweak these values so that the result looks good on their system.

Jun 01 14:06:38 <seb128> pitti: in case fonts turn to be too small (which happened to several people after upgrade) you might want to modify libgnome schemas to change Sans
10 to 11
Jun 01 14:07:02 <pitti> seb128: do we have a bug about it?
Jun 01 14:07:06 <seb128> just edit debian/libgnome2-common.gconf-defaults
Jun 01 14:07:29 <seb128> pitti: I think so, let me look
Jun 01 14:08:21 <pitti> seb128: if that affects everyone, we should milestone it
Jun 01 14:08:33 <seb128> well, not easy to know
Jun 01 14:08:49 <pitti> well, but that only affects upgrades anyway, right?
Jun 01 14:08:50 <seb128> gnome-settings-daemon uses the screen DPI now
Jun 01 14:09:12 <pitti> if it affects fresh installs, too, then we should do something about it
Jun 01 14:09:15 <seb128> but I'm not sure if that means we should change the default or if the fonts are only too small when xorg is not correctly configured or something
Jun 01 14:09:28 <pitti> ok, let's look into that during CD testing
Jun 01 14:10:15 <seb128> right, that was my point
Jun 01 14:10:39 <seb128> if that happens on desktop CD and you want to workaround it just modify libgnome debian/libgnome2-common.gconf-defaults to change the default deskto
p font

[Martin Pitt (pitti)]

BTW, for Tribe-1 I uploaded

libgnome (2.18.0-4ubuntu2) gutsy; urgency=low
 .
   * debian/libgnome2-common.gconf-defaults: Increase font size of Sans from 10
     to 11 for the desktop and document default fonts. gnome-settings-daemon
     now uses the screen DPI for font size calculation, the new default
     mitigates the resulting size changes. (LP: #118745)

which already helped a bit, but e. g. the Terminal font is still too small.

[Alexander Jones (alex-weej)]

Er, I don't get this. 10pt is massive enough already.

11pt is just huge. I think anyone who is finding font sizes to be too small must have incorrect DPI settings.

Please consider reverting to 10pt.

[Sebastien Bacher (seb128)]

Alex, for lot of users the fonts are tiny with 10, if you read the bug you will notice that's a workaround and not a fix, your comment is not really bringing anything to it

[Alexander Jones (alex-weej)]

OK, here's a better workaround for now - change /desktop/gnome/font_rendering/dpi to 96, and leave the font sizes as they were.

[Sebastien Bacher (seb128)]

It makes it no respect the dpi, how is that a better workaround?

[Alexander Jones (alex-weej)]

Because most people's panels are 96 dpi. You can unset it when the auto-detected DPI is fixed in Xorg.

[Sebastien Bacher (seb128)]

where did you get your information that most configuration are using 96 dpi? We received other bugs indicating that's not that evident, have clear datas on the subject would be nice

[Alexander Jones (alex-weej)]

Do you have any clear data to suggest that screen DPI is being systematically undercalculated at 91% (10/11) of its real value?

Anyway, as long as leaving the default font size as 11pt is not intended for the final release, then it's really not worth locking horns over this. Let's just agree to disagree. :)

[Martin Pitt (pitti)]

Hi,

Alex Jones [2007-06-17 16:01 -0000]:
> Because most people's panels are 96 dpi. You can unset it when the auto-
> detected DPI is fixed in Xorg.

Please don't ever rely on that value. For many monitors it is simply
not possible to detect the DPI and other settings.

How has the DPI setting been handled before? Was it just fixed to 96
DPI? (or whichever value).

[Sebastien Bacher (seb128)]

Alex, that's ridiculous, nobody claimed the "DPI is being systematically undercalculated at 91% (10/11) of its real value", we did that because 10 was looking tiny for most people and we needed a workaround

[Tim Hull (thully)]

On my system (13 inch MacBook - dual-boot installed w/Boot Camp), this appears to detect the DPI correctly. as being 112 dpi.
However, the resulting fonts, when using my display's native 1280x800 resolution, are huge. I think the issue may not necessarily be the
wrong DPI being detected - it's that the font is a bad size with the right DPI selected! In the meantime, I've reverted to the Feisty settings
(96 dpi, 10 pt font in Gnome), and everything looks normal again.

[Martijn vdS (martijn)]

Tim, you should try to set the font to the right size, while keeping the DPI the same, calculated value. The DPI is getting more and more important as high-pixel-density monitors appear (I have a 150dpi laptop here), as people usually don't want to read 5 pixel high fonts on those screens. If we get more programs to cope with DPI properly, we won't have to solve this problem in the future, when all panels are >150dpi.

[Tim Hull (thully)]

The bug I filed is that if I do this - set the DPI to the calculated size -
the fonts are gigantic.
That is why I don't have it set that way...

On 6/26/07, Martijn van de Streek <email address hidden> wrote:
>
> Tim, you should try to set the font to the right size, while keeping the
> DPI the same, calculated value. The DPI is getting more and more
> important as high-pixel-density monitors appear (I have a 150dpi laptop
> here), as people usually don't want to read 5 pixel high fonts on those
> screens. If we get more programs to cope with DPI properly, we won't
> have to solve this problem in the future, when all panels are >150dpi.
>
> --
> default desktop/panel menu font sizes too small
> https://bugs.launchpad.net/bugs/118745
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Just an update about the current status: DPI is detected correctly on my production system upgraded from feisty to latest gutsy, but when I boot the current live CD, I get an autodetected DPI of 67. It should be 86, that's why fonts are so small.

So this is ultimately an Xorg bug. Bryce, is that known to fail sometimes and going to be fixed? Or can it at least tell us if it was able to detect the DPI? If not, we might need to revert to the hardcoded 96 DPI we had so far.

[Martin Pitt (pitti)]

Hi,

Mark Shuttleworth [2007-06-28 17:33 -0000]:
> - since gutsy, font sizes are too small.
> + In Gutsy, Gnome switched to using the X server's screen DPI detection,
> + which means that fonts can easily appear to be too large or too small,
> + depending on your screen setup. The old approach was to use 96 DPI by
> + default, but the new one can result in widely differing DPI values. We
> + need to improve the detection, or give people an easy way to tweak these
> + values so that the result looks good on their system.

I agree. At the moment, changing the DPI value in the Appearance
dialog doesn't have any effect at least on my installed system.

[Tim Hull (thully)]

In my experience, changing the DPI does have an effect . However, what I'm finding is that even with the *correct* DPI values, the fonts can be way too big.
In my case, using the correct value (112 dpi) causes my MacBook to have fonts that are intolerably large. 96 dpi, on the other hand, results
in fonts that are of a more reasonable size. I have a separate bug open to this effect - though some systems are certainly detecting the wrong DPI, I'm finding the fonts are bad even with the *right* DPI!

[Nick_Hill (nick-nickhill)]

I have a switch box. The switch box doesn't appear to send DDC signals through, whether or not the monitor is live when X starts.

If I start X with the monitor connected directly to the computer, X sets DPI at 95, 96 . If the monitor is not connected, it sets the DPI at 75. At 75dpi, the fonts are usually intolerably small.

The most common screen resolutions/sizes tend to be (appx) :
Diagonal Width Height ResolutionWxH DPI
14.1" 11.28 8.46 1024X768 90.5 90.5
15" 12 9 1024x768 85 85
17" 13.25 10.65 1280x1024 97 96
19" 14.8 11.85 1280x1024 86 86

The most common resolution today is probably 17" 1280x1024. for desktops, and something close to 14.1" 1024x768 for laptops. The weighted average is probably around 92dpi.

We must assume that it is not always possible to determine the monitor's characteristics - any of them. Screen size, H/V sync, max resolution, DPI.

Where no information is available, we need to set sensible defaults so that the user can at least get something on screen to make initial changes..

If the user has not set preferences (ie all fields are on autodetect in the attached example) and we have no DDC information whatsoever, AND no settings have been put in xorg.conf, then 800x600,60Hz75dpi is a sensible default.

However, if a resolution has been set and a DPI has not been set, I suggest we have an automatic DPI mapping based on the highest resolution axis as follows:
<700 56dpi (eg 640x480)
<950 75dpi (eg 800x600)
<1200 85dpi (eg 1024x768)
<1400 95dpi (eg 1280x1024)
>1400 100dpi. (eg 1440x1024)

Whenever display settings changes are made within Gnome, I suggest we also store the mtime for file /etc/X11/xorg.conf. If xorg.conf exists, and the time stamp differs, then all settings in Gnome should be re-set to Autodetect / default. Otherwise, Gnome settings should take precedence.

This way, if the user does dpkg-reconfigure xserver-xorg, the settings will take precedence. If the user then logs into Gnome then changes settings, they then take precedence.

So we have an order of precedence for each parameter Res, Freq, DPI:

Resoution
1) The most recently changed of Gnome or xorg.conf
2) DDC
3) 800x600

Frequency (refresh rate)
1) The most recently changed of Gnome or xorg.conf
2) DDC
3) 60Hz

DPI:
1) The setting in Gnome
2) DDC
3)
<700 56dpi (eg 640x480)
<950 75dpi (eg 800x600)
<1200 85dpi (eg 1024x768)
<1400 95dpi (eg 1280x1024)
>1400 100dpi. (eg 1440x1024)

[John Vivirito (gnomefreak)]

Rejecting firefox task as it is not a firefox issue.

[Nick_Hill (nick-nickhill)]

As an update to my suggestion to have the DPI settable in a Gnome interface,

I suggest replacing the DPI drop-down box that I previously suggested, with a screen size drop-down box. And add two fields for width and height. If anything other than user defined is selected, the width and height boxes are greyed/inactive and display the current auto-detected width and height, or the width and height associated with the option manually selected. If "User Defined" is selected, the width and height boxes are black, activated and editable. User can change those values to any sensible value.

I'd suggest
AutoDetect
12"
14"
14" widescreen
15"
15" widescreen
17"
17" widescreen
19"
19" widescreen
User Defined

How do we handle situations where the user has not selected either a resolution or screen size, and no detection information is available?

Normally, we would want to assume the user is using the most common screen size of the day which is 17”.

We need to consider whether this would work when a user is trying to install a system using a 'fall-back' resolution such as 640x480 or 800x600 whether or not screen size info is available.

We are faced with several competing factors:
1)Will the font sizes be readable with default settings?
2)Will the system be installable with default settings?
3)Will the screen be set to the “correct” size?

I suggest that when we are set to a fall-back resolution, 3 doesn't matter. Readability and installability are the prime factors. The user can set his or her preferences later, once installed.

We also need to ensure the ubiquity installer is usable with fall-back resolutions, at least, 800x600. I therefore suggest that if the screen resolution detected via DDC is 800x600 or less, we should ignore the screen size reported by DDC if less than 14” and assume 14”. (We don't want high DPI values at 800x600 resolution as this will often lead to the ubiquity application window growing too large for the screen, and other applications growing ungainly).

I have made a flowchart which demonstrates logical steps to end up with a resolution, refresh rate and screen size from xorg.conf, gnome settings and DDC as outlined above.

[Tim Hull (thully)]

Well, at least in my case the correct DPI seems to have been detected in Tribe 2. However, 11 pt system font is too big at my actual system DPI - though 10 pt (the original setting) is perfectly fine.

[Patrice Vetsel (vetsel-patrice)]

Hi i confirm this problem on a fresh install of tribe 2.
Fonts are too small. following Nick_Hill post, i set dpi to 85 and all is ok now.
Tell me if you need more specific informations.

[Nick_Hill (nick-nickhill)]

Hello Patrice

How did you sett he DPI for your system?

For my 17" TFT monitor, I set screen size and hence DPI in xorg.conf like:
Section "Monitor"
        Identifier "Generic Monitor"
        Option "DPMS"
        HorizSync 30-65
        VertRefresh 50-75
        DisplaySize 340 270
EndSection

However, Bryce Harrington has been making excellent progress with bullet proof X, which should autodetect all relevant settings, which could ultimately eliminate the need for xorg.conf on most machines.

I installed Ubuntu Gutsy T2 on a 2.5" hard drive, deleted xorg.conf then swapped it between 8 very different laptops. On all systems, I had a screen which was potentially usable to at least install the system and manually configure the resolution etc (once the front end will accommodate higher than fall-back settings in fall-back situations).

I have logged info from these laptops including lspci -v, xorg.0.log, /proc/bus, dmesg, lsmod. If anyone knows how this information can best be used, please let me know!

[Stephan7 (sshsteph007)]

I noticed in this discussion that firefox is removed from this issue,
however "Bug #121738 in firefox (Ubuntu)" is makred a duplicate of this
and it shows a difference between firefox menu font (not its contents)
with the gnome menus.

I have that same problem that the firefox menu font is too small, see attachment.
No matter which DPI I choose (in system->Pref->Appearance->Font->detail) it
won't influence font sizes in my situation: I have a beamer connected and I want
larger than default as I'm watching it from several metres away.
So I prefer the system font at 14pts, but as firefox shows fonts too small I need
to set it up to 18pts.

So don't forget that there are also users with beamers using Ubuntu.

[John Vivirito (gnomefreak)]

Firefox was removed from this issue because firefox isnt causing this problem it is affected by it.

[Andreas Färber (afaerber)]

I would like to point out that this issue touches on personal taste. I liked the "small" menu font size in Tribe 2 whereas I do not like the 11pt at 96dpi setting I suddenly had after today's updates. Please reconsider imposing that on all users without asking.

[Nick_Hill (nick-nickhill)]

Hello Andreas

Presumably your fonts scaled to 75dpi but displayed on your 96dpi screen. They were therefore not displayed as an 11pt font but instead displayed as an 8.5pt font. Now the dpi is presumably detected correctly, it is displayed, as set, at 11pt.

As you rightly say, there is a matter of taste how big you would like to see your fonts on screen. But having the system set up so that it does not "know" the resolution of your screen is not a good way to achieve the desired result. Putting it another way, if your screen were really 75dpi, you would probably again find the fonts too big.

Once screen dpi is correctly detected and set on the majority of systems, if users find the fonts are then too big, bugs can be filed against Gnome/KDE for more appropriate default font sizes.

In the meantime, you can adjust your menu font sizes to your preferred size in the control panel.

[Mike Richards (mrmikerich)]

What is the name of the control panel app that lets you change font sizes? I have a non-standard Ubuntu install, so I need to know the name of the app to launch it from the command line. Thanks.

[Marius Gedminas (mgedmin)]

Mike: it's gnome-font-properties.

[Jean-Pierre Rupp (xenog)]

Now that /usr/share/gconf/defaults/10_libgnome2-common is setting some fonts at 11dpi, my desktop looks like a carnival of big and small fonts.

[Jean-Pierre Rupp (xenog)]

I "fixed" things on my computer this way:

First I changed /etc/gdm/gdm.conf-custom and added this lines to the end:

[server-Standard]
command=/usr/bin/X -br -audit 0 -dpi 96

It's lovely that Gnome is able to change it's font size to suit whatever resolution my system is reporting. But it only makes sense really if EVERYTHING scales accordingly, I mean icons, and panels, toolbars, widgets, etc. if only fonts are scaled, the desktop doesn't look quite right, it gets distorted. So I don't care much about autodetected DPI, and I leave it as 96 dpi which seems to give the least distorted output for the desktop and most applications.

[server-Standard]
command=/usr/bin/X -br -audit 0 -dpi 96

I then changed the two libgnome fonts (document font and inteface font) to be back at 10 dpi, if I leave them as 11 dpi and use a monospace 11dpi, Nautilus 11dpi and a Metacity 11dpi font, then fonts inside Firefox will look too small compared to the rest. This I fixed changing /usr/share/gconf/defaults/10_libgnome2-common so all text reading "Sans 11" would now read "Sans 10". Then I ran update-gconf-defaults.

I also added a value to the end of this same file:
/desktop/gnome/font_rendering/hinting full

And ran update-gconf-defaults again. This last setting fixes the problems with font weight with gnome-terminal and OpenOffice.org.

I hope this serves the developers.

[Paul Dufresne (paulduf)]

Not sure if bug #107320 (that itself have duplicates) is related and or duplicate of this one.

[Jonathan Riddell (jr)]

When X can pick any random DPI there's no right answer as to what the default font size should be. I recommend adopting the guidance-restore script which sets up a sane DPI. Install kde-guidance and restart the X server to test. It can easily be moved to guidance-backends.

[Ned (nedwilliamson)]

I don't know if this is the same problem, but on the latest update, text pretty much everywhere got really small.
I have a screenshot of the problem attached.

[Alexander Jones (alex-weej)]

How big is your screen? (Physically)

[Ned (nedwilliamson)]

It's about 11 1/2 inches horizontally and 8 1/2 inches vertically not including the border around the edges.
It's a Dell Latitude D610 laptop.

[Kristian Rosenvold (kristian-rosenvold)]

I have a 40 inch 1920*1080 display attached (Approximately 55 dpi according to my calculations). Xorg.log says it detects a DPI value of 304, 304.

I get *GIGANTIC* fonts and Icons and am unable to install gutsy tribe 4 or change anything because hardly nothing fits on
my screen !

[Bryce Harrington (bryce)]

Fwiw, bulletproof-x is just a failsafe mode for X, and wouldn't have any bearing on this issue.

It sort of sounds like the issue here is that Gnome is guessing the correct dpi by looking at the refresh rates. Unfortunately, in most cases the refresh rates are themselves just guesses done by the xorg postinstall script when xresprobe fails to detect the card (which happens a lot). If this is indeed the case, then basing a guess on top of a guess is bound to lead to rather unpredictable failures.

In talking with seb128 about this, it sounds like the best option for now is to go back to a hardcoded dpi setting.

Assuming my hypothesis is correct, a couple workarounds to try would be to a) try running with no xorg.conf. b) try fixing the HorizSync and VertRefresh settings in the Monitor section of your xorg.conf (see your monitor for correct settings). No guarantees that this would fix things in all circumstances, but if they fix it in at least some, then that is added evidence that the core issue here is mis-detected refresh rates (which is bug 3731).

[Carroarmato0 (carroarmato0-deactivatedaccount)]

What's this thing about guessing? When the live-cd boot screen appears you can select your screen size from there. How come the boot graphics aren't the same as the normal graphics? Can't X use a default dpi based on the screen size you selected at boot time? Of course there's some abstraction involved but I think this would lead xorg from betting the dpi a little more realistic.

[Alexander Jones (alex-weej)]

We don't have resolution independence yet in GNOME. As such, the only thing that is affected by screen DPI are the fonts. Proportionality between text and other graphical elements, particularly icons, is of primary concern for most users. The only way that proportionality looks "right", is with 13 1/3 pixel text (10pt @ 96dpi) with 24 pixel menu icons.

It is my opinion that we should just set the default DPI to 96 and revert the font sizes for now until:

a) We have a more reliable way of setting/detecting actual screen DPI; and
b) We actually have some level of resolution independence

[Anthony S (aaaantoine)]

Pardon my curiosity, but what is the significance of the OS knowing the PPI of the screen? Consider the following scenarios:

Screen #1 is an independent monitor: a 19" LCD with native 1280x1024 resolution. The PPI is approx. 85. The user sits between 3 and 5 feet away from this screen.

Screen #2 is a laptop panel: a 14.1" LCD with native 1280x800 resolution. The PPI is approx. 105. The user sits between 1 and 2 feet away from this screen.

When the GUI scales everything by the DPI of the monitor, it will scale everything according to what the "real" size of the graphics should be. This means that Screen #1 will display more information on it than Screen #2, regardless of resolution. However, the smaller size of the graphics on Screen #1 causes the user to strain at his usual sitting distance from the monitor, while the relatively large graphics on Screen #2 suffocate him with their sheer size.

I guess what I'm asking is, wouldn't it make more sense to have a GUI scaling tool that lets you resize all graphics (independent of resolution) rather than autosize everything according to the monitor's PPI?

[Alexander Jones (alex-weej)]

Both are necessary, but the only thing we can scale right now is fonts so we should talk about this in a blueprint.

https://blueprints.launchpad.net/ubuntu/+spec/resolution-independence

[Raptor45 (raptor405-deactivatedaccount)]

(Correct me if I'm wrong here, but... this is why to the best of my understanding.)

The reason for knowing the DPI hasn't been too important in the past, but could grow to become a bigger issue in the future. This is because although most current screens are approximately 96 DPI, there is room for improvement in the future in making denser screens for better detail. My 20" monitor has a resolution of 1680x1050; but what if someone has a 20" monitor that is 3360x2100? Everything would appear to be unusably "small" on this monitor, despite them being the same size.

Using DPI properly and sizing based on actual distances, as opposed to via pixels, means that sizes would be standardized. What is an inch on my monitor would also be an inch on the other, just the other would look that much more detailed. This can be important in other ways too: ever try holding up a sheet of paper to your word document? If it doesn't line up quite right at 100% zoom your DPI setting is probably slightly off. As the DPI on monitors increases, this will become a bigger issue.

In your example, the graphics on both screens would be the same size. The menu bar on each would be .25" on both, or what have you. The problem you seem to take with proper DPI settings seems to be caused by your viewing distance from the screen; an issue which DPI isn't meant to correct for.

[Raptor45 (raptor405-deactivatedaccount)]

A possible solution to the bad DPI detection could be to have a simple way of allowing users to input it on install.

This could be done by showing a ruler on the screen and asking users to expand/compress it until it matches up with the markings on a real ruler. (Windows has a similar method, and it works pretty well.)

This would be pretty simple for users to understand, and would give an easy failsafe in case the DPI is incorrectly detected.

[Bryce Harrington (bryce)]

In discussing this with seb and riddell, and judging from comments from Alex Jones and others, we've decided to go back to 96dpi hardcoded for Gnome in Gutsy as a workaround, and leave this bug open to get a truer fix for Gutsy+N. I've dropped the milestone to Ubuntu: later.

Jonathan Riddell pointed out a script in kde-guidance, displayconfig-restore.py, which is what KDE uses to compensate for this issue. It hardcodes to 96dpi or 120dpi if xorg guesses the dpi to be anything under 140dpi, and allows use of the guessed dpi for over 140 dpi. We think that for gnome, while a workaround like this might give better appearing fonts, at least by hardcoding to 96dpi we can eliminate the bug without causing or risking regressions, and leave us wide open for ideas for better solutions in future ubuntu's.

Alex Jones has started a blueprint to collect ideas for a better solution to the display scaling problem in general. It would be great to see this blueprint fleshed out sufficiently in time for UDS Boston at the end of October, so it can be considered for Gutsy+1.

[vidd (vidd)]

Here is a silly suggestion:
why not make an option for the user to "auto-detect DPI settings or use the hard-coded default setting of 96 or 120 (3 options here). This is similar to "auto-detect keyboard" that I have yet to have correctly identify us-english.
Explain on the option selection section what the risks are of auto-detecting (fonts may appear large/small if autodetection fails) and have a splash page with text to show the results BEFORE the setting is saved so the user can say "nope...that wont work", and choose one of the hard coded sections.
If something cant get get done for this release, then by god use the setting in Feisty so I dont need to have my screen resolution set to 800x600 (or less) so i can read a website!

[Dave Morley (davmor2)]

vidd How many people in the really world would know what there monitor was capable of dpi wise. Resolution wise yes but not I fear dpi wise. So everyone would just hit auto detect. Then when it didn't work complain it was crap and use something else. This is just one of those things that needs to work out of the box unfortunately.

[vidd (vidd)]

Exactly
The issue is that the auto detection currently fails miserably.
The issue has nothing to do with the xll config file, and everything with GDM
I have disabled GDM and ran startxfce4 (xubuntu) and the fonts were fine.

davmor2, did you read my post in its entirety? no-one complains that the keyboard detection algorithm is worthless, because they see that it does not work and is going to select the wrong keyboard layout, and gives the user the option to correct this before completing the install.
Thus, as I have suggested, we need to display some kind of splash screen to display the results of the choice. Or, we can use the proven method used in feisty

[Dave Morley (davmor2)]

As a temporary work around.

1. Once the machine has entered the desktop, hit Alt+Ctrl+F1.
2. At the prompt type ubuntu and hit return.
3. Type sudo 'nano /etc/X11/xorg.conf' then return
4. Press the down arrow until you get to the line Driver "intel"
5. Change the word intel to i810
6. Press Ctrl+x, then y, then return to save and exit nano
7. Press Alt+Ctrl+F7
8. Press Atl+Crtl+Backspace (to restart the X server and environment)
9. Temporarily fixed :)

[fhucho (fhucho)]

Hi,
I have tried Gutsy Tribe 5 and in the default install, the fonts are too big. I have 17" LCD monitor, 1280x1024. In Appereance Preferences, the Application font and the Document font are set to 11, although in Feisty they are set to 10. The size 10 fonts look MUCH better.

[Tim Hull (thully)]

Please revert the changes made with respect to font defaults from Feisty to Gutsy. As it stands, I have HUGE fonts in Gutsy, even though my DPI is *technically* set correctly (114 dpi). The 11pt menu font only makes this worse. As it stands, I always have to adjust the fonts after the install - as do many people. A screenshot of the atrocious-appearance-by-default is attached...

Tim

[Alexander Jones (alex-weej)]

Sucks that this actually affects those lucky enough to have working hardware.

[schnollk (schnollk)]

After an upgrade to Gutsy just a few hours ago I have almost the same setup as fhucho does only I have smaller looking fonts as before with Feisty. When I go -> System -> Prefs -> Appearance -> Fonts all font sizes are set to 9. If I put them to 10 or 11 it looks much better. Unfortunatelly I haven't tweaked fonts in Feisty so I cannot remember what sizes Feisty had.

Hope this helps.
Cheers.

[Alexander Jones (alex-weej)]

Default size is 10pt.

[Sebastien Bacher (seb128)]

libgnome (2.20.0-1ubuntu1) gutsy; urgency=low

  * debian/libgnome2-common.gconf-defaults:
    - set dpi to 96 rather than fonts to 11 (LP: #118745)
  * Sync with Debian
  * debian/control.in:
    - package maintained by the Ubuntu Desktop Team
    - updated maintainer information
  * debian/libgnome2-common.gconf-defaults:
    - changes to default configuration for Ubuntu
  * debian/patches/04_gnome-score.c.patch:
    - dropped, it's not required with the new version
  * debian/patches/08_dont_force_a11y_activation.patch:
    - don't force a11y activation
  * debian/patches/10_sounds_event_list.patch:
    - no sound event out of the login one for the default configuration
  * debian/patches/11_aplay_fallback.patch: Change gnome_sound_play() to
    fall back to aplay if esd is not available. This finally allows us to not
    install esound by default any more.

 -- Sebastien Bacher <email address hidden> Mon, 17 Sep 2007 15:55:06 +0200

[Bryce Harrington (bryce)]

Additionally, I've changed the default xserver dpi from 75 to 100 which may help in a few cases. Seb's fix is the one that should take care of it for most people.

[TJ (tj)]

Sebastien, I'm not sure but I think the libgnome changes may be the reason for a massive surge of reports about fonts becoming too small to read and gnome-appearances-properties crashing, summed up by bug #140540 and all its duplicates. I found the problem and a fix and posted the details there, but a patch will need to be released once the root cause is found.

Summary: After the updates (which I thought might be caused by changes in gnome-control-center & capplets-data) gconf is showing /desktop/gnome/font_rendering/dpi = 50 rather than 96.

Could you check on this?

[Olivier Cortès (olive)]

Hi,

just a note about the progress of this bug on my system ; Dell Precision M4300 (Dual 64bits + nVIDIA Quaddro FX360M, Gutsy 32bits installed from tribe5 liveCD then regulars dist-upgrade ; nvidia-glx-new installed and working; compiz enabled)
I didn't encounter any font size problem since installation, except this morning.
Following the upgrade 30min ago, my screen became tinily unreadable after reboot. gnome-terminal was 30pixels heigth with only 2px blinking cursor. I launched "gnome-appearance-preferences", and changed font sizes, but it did not seem to affect gnome-terminal (it affected the rest of the gnome interface). I tried to click on "details" of the "fonts" tab of gnome-appearance-pref and it crashed.
Relaunched gnome-appearance-preferences from gnome-terminal and "details" made it crash too.
Relaunched gnome-appearance-preferences from xterm (which font size was readable though) and "details" worked, but the resulting window was larger than the screen (which is 1920x1200...).
I noticed that the DPI was 50, i put it back to 145 (which is the DPI detected by gimp) and everything went just back fine.

Perhaps GNOME could use the GIMP routine to correctly detect the DPI settings of Xorg ? I never saw it fail on any of my systems, gimp always did detect DPI correctly (even when horiz and vert DPI are not the same (which is the case on my screen, 147x145 or such).

As you can see on the capture, 145 DPI made the fonts bigger (i'm going to put them back to size "6" which fits me best), but the font previews in gnome-appearance-preferences didn't get updated. Closing it and reopening it does the job, and fixes the fonts details beiing too wide.

So, everything is fixed for me, but the upgrade from last night broke something that was OK since tribe5.
Anyway, thanks for all comments in this bug, they helped me find the solution.
Best regards,

[Jonathan Ernst (jonathan.ernst)]

You can fix the problems caused by this "fix" using the instructions here :

https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/140619

[CliveG (cgerada)]

Hi,
how did you fix your terminal Font from being so small,
after the gutsy upgrade of a few hours ago, my screen fonts are all fine on all programs except my terminal program
were the font is tiny i cannot see the text at all.
thanks

[Jonathan Ernst (jonathan.ernst)]

copy paste this command in a terminal as stated in my previous message :

gconftool --type float --set /desktop/gnome/font_rendering/dpi 96

[CliveG (cgerada)]

Thank You.

[Elie De Brauwer (elie)]

I stepped from Feisty to Gutsy today, and I also encountered the same issue, gconftool fixed it as well for me. Thanks

[Sebastien Bacher (seb128)]

could people stop suggesting this workaround and try the official update and let we know if that works for them rather?

[Freebsd (freebsd)]

I am using version 6.7.192 of the Radeon driver. The machine is a Dell Inspiron 8600C laptop running FreeBSD 6-STABLE with a Radeon M10 graphics card serving the internal LCD panel via LVDS. The screen is 15.4" widescreen with a resolution of 1920x1200.

As the screen appears not to report its physical size to the driver, I manually set it via "DisplaySize 325 203" in the "Monitor" section. This worked correctly in X.org 7.2 and resulted in the correct 150 DPI being calculated. The new driver normally ignores the "Monitor" section. After I set the undocumented "Monitor-LVDS" option, the DisplaySize setting does get read and used, but then gets overridden somehow, resulting in a bogus physical screen size and 96 DPI (see attached Xorg.0.log).

The relevant log lines are:
> Line 508: (==) RADEON(0): X server will not keep DPI constant for all screen sizes
----
> Line 537: (II) RADEON(0): Max desktop size set to 2560x2048
----
> Line 559: (II) RADEON(0): Panel Size from BIOS: 1920x1200
----
> Line 637: (II) RADEON(0): Output LVDS using initial mode 1920x1200
----
> Line 639: (**) RADEON(0): Display dimensions: (325, 203) mm
> Line 640: (**) RADEON(0): DPI set to (200, 256)
----
> Line 787: (II) RADEON(0): Setting screen physical size to 508 x 317

My understanding is as follows:
* Line 508: randr will not fudge the physical screen size to keep the DPI constant
* Line 537: The graphics card can handle up to 2560x2048 resolution
* Line 559: The LCD panel will only do 1920x1200 resolution
* Line 637: The chosen resolution is 1920x1200
* Line 639: The correct physical screen size has been read from xorg.conf
* Line 640: Despite knowing that 1920x1200 will be used, the driver calculates DPI based on 2560x2048, which is wrong
* Line 787: The driver for some reason overrides the correct physical screen size, now again using 1920x1200 resolution and fudging the size so that it results in 96 DPI, which is wrong

I have to manually correct the physical screen size via "xrandr --fbmm 325x203" after every login, which is a pain.

[Freebsd (freebsd)]

Created an attachment (id=11619)
xorg.conf

[Freebsd (freebsd)]

Created an attachment (id=11620)
Xorg.0.log

[Freebsd (freebsd)]

Created an attachment (id=11621)
Output of xdpyinfo after starting X

[Freebsd (freebsd)]

Created an attachment (id=11622)
Output of xdpyinfo after manually setting the physical screen size with "xrandr --fbmm 325x203"

[Luka Renko (lure)]

This bug is very similar (same?) as the bug 12117 that I reported some time ago. I have alos workaround the issue by running xrandr -fbmm in Xsession.

[Matt Whiteley (mwhiteley)]

The official update fixed the issue for me. Thanks.

[Freebsd (freebsd)]

Yes, this is a dup of 12117. Feel free to consolidate the two. However, this bug (12474) has additional information and a clearer summary line which should not be lost.

[agd5f (agd5f)]

*** Bug 12117 has been marked as a duplicate of this bug. ***

[agd5f (agd5f)]

I think this is something in the server as the driver does not mess with the dpi anywhere.

[Luka Renko (lure)]

Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is running xserver 1.3, panel size (and consequently DPI) is properly detected with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati driver with xrandr (this was regression identified with my early testing of xrandr branch and is still there in 1:6.7.192-1ubuntu2).
Since it looks like driver is reporting proper size in log file, but later does not use it properly, is it possible that this get somehow mangled in the driver before passing further?

[Saivann Carignan (oxmosys)]

Maybe we should give some attention to bug #119990 which relate to similar problems with QT programs, it's still not fixed and worst ever.

[Jamessp (jamessp)]

I can confirm comment #9 on Debian. Actually, I can confirm this whole report letter for letter down to the solution. :)

[agd5f (agd5f)]

(In reply to comment #9)
> Alex, I am not sure if I can agree with last comment: on Ubuntu Gutsy, which is
> running xserver 1.3, panel size (and consequently DPI) is properly detected
> with ATI driver 1:6.6.193-1ubuntu1, but it does not get detected with ati
> driver with xrandr (this was regression identified with my early testing of
> xrandr branch and is still there in 1:6.7.192-1ubuntu2).
> Since it looks like driver is reporting proper size in log file, but later does
> not use it properly, is it possible that this get somehow mangled in the driver
> before passing further?
>

The old driver implemented it's own dualhead system (mergedfb) right in the driver. The old driver DID mess with the dpi because it handled the randr type functionality itself. With randr all of that moved to the server. The server should be doing the right thing. If it's broken for radeon, it's also broken for intel or mga or whatever other randr driver you are using. The drivers shouldn't be duplicating dpi fixups.

[John Vivirito (gnomefreak)]

The fix failed to fix it here i had to set fonts to 12 this is with libgnome2-common 2.20.0-1ubuntu2
I use 1600X1200 and the fonts are way too small still if i run xdpyinfo i get:

xdpyinfo | less shows dimensions: 1600x1200 pixels
 (323x252 millimeters) resolution: 126x121 dots per inch

shouldnt that be more like 100X100 DPI?
there is no way that i found to change that setting even with DPI set in apperance to 96

[John Vivirito (gnomefreak)]

This was working fine before i reinstalled feisty and upgraded to gutsy without installing packages thani ran into this issue it happened yesterday after upgrading to fixed dpkg

[Matt Zimmerman (mdz)]

I installed a system with Tribe 5, and its fonts were somewhat large. After
further updates, I saw the regression with gnome-terminal that others
reported (fonts too small to see). With the latest updates in Gutsy,
everything is working fine, with appropriate font sizes both in the terminal
and elsewhere.

--
 - mdz

[Alexander Jones (alex-weej)]

On Wed, 2007-09-19 at 23:21 +0000, John Vivirito wrote:
> The fix failed to fix it here i had to set fonts to 12 this is with libgnome2-common 2.20.0-1ubuntu2
> I use 1600X1200 and the fonts are way too small still if i run xdpyinfo i get:
>
> xdpyinfo | less shows dimensions: 1600x1200 pixels
> (323x252 millimeters) resolution: 126x121 dots per inch
>
> shouldnt that be more like 100X100 DPI?
> there is no way that i found to change that setting even with DPI set in apperance to 96

The DPI setting in "appearance" only affects font rendering, not your X
server.

[John Vivirito (gnomefreak)]

Where would i find the dpi setting to change to fix this if not in apperance>fonts?

[Arkadiusz Miśkiewicz (arekm)]

New driver is out but doesn't fix this issue.

Linux 2.6.23git, glibc 2.6.1, i686, Thinkpad Z60m with ATI Mobile X600,
xorg-xserver-server 1.4-3, xorg-driver-video-ati 6.7.193, Mesa 7.0.1.

By default driver calculates very wrong panel size:
  dimensions: 1680x1050 pixels (444x277 millimeters)
  resolution: 96x96 dots per inch

The correct one is DisplaySize 330 210 (mm).

I'm attaching my config, x log and xdpyinfo output.

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11657)
xdpyinfo output

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11658)
Xorg log

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11659)
xorg.conf

[Alexander Jones (alex-weej)]

Section "Monitor"
  DisplaySize x y
EndSection

Where x and y are your actual, real-world screen dimensions in mm.

[Alexander Jones (alex-weej)]

Sorry, I should add that you need to put that DisplaySize bit inside your "Monitor" section in your X configuration file: /etc/X11/xorg.conf

[Arkadiusz Miśkiewicz (arekm)]

Created an attachment (id=11726)
New log, xserver 1.4, ati 6.7.194, linux, thinkpad z60m

[Luka Renko (lure)]

This is fixed for me with recent uprage to 6.7.194-1ubuntu1tv version of ati driver.
SW: Kubuntu Gutsy
HW: HP nw8240 with ATI FireGL V5000 PCIE

[agd5f (agd5f)]

does 6.7.194-1ubuntu1tv carry any patches beyond what's in the stock 6.7.194 or ati git?

[Luka Renko (lure)]

It is vanilla source from git.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

The "tv" package is practically the same as the Debian 6.7.194-1 package, which has no changes to the source files (only packaging and makefiles etc).

OTOH the xorg-server in Ubuntu Gutsy is a bastard 1.3 with lots of 1.4 backports.

[Marcelo Boveto Shima (marceloshima)]

What about this patch?
http://sisyphus.ru/srpm/xorg-x11-server/patches/10

[Arkadiusz Miśkiewicz (arekm)]

Doesn't work with newly released ati driver 6.7.195. Alex Deucher tells that this is probably xserver issue and not ati driver one: http://lists.freedesktop.org/archives/xorg/2007-September/028627.html. Unfortunately xserver devs didn't respond to that so this is still unknown.

If you are xserver dev and could help to track down this I'm ready to test your ideas, debug things and so on. Very nasty issue preventing any few randr 1.2 drivers from being usable :-/

[Arkadiusz Miśkiewicz (arekm)]

In my case resolution is 1680x1050 and this code in hw/xfree86/modes/xf86RandR12.c is executed:
                /*
                 * Otherwise, just set the screen to 96dpi
                 */
                mmWidth = width * 25.4 / 96;
                mmHeight = height * 25.4 / 96;

width is 1680, height 1050 and that ends up as dimensions: 1680x1050 pixels (444x277 millimeters).

I assume that the standard code path that this driver shoud follow is:
if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)

Unfortunately the problem is that mm_width and mm_height are zero so that code path is never executed. Don't know yet where these come from - I assume radeon driver fills these. Digging.

I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6 found" like not found => no ddc query => panel dimensions unknown. Is my guessing correct?

[Arkadiusz Miśkiewicz (arekm)]

"Unknown DDCType 6 found" was the main problem here. Without handling it DDC/EDID didn't work so X didn't know panel dimensions and other stuff. Thanks to airlied git commit 0b03a73b7dcb4aa192c42f2a4c842d324c358122 the isue is solved for me.

Bartosz logs also show the same issue so I guess he will be fine with this patch, too.

[Tim Hull (thully)]

The issue still isn't fully fixed for me. On my MacBook (13.3", 1280x800, intel graphics), the fonts for the user id on the login screen and for application title bars are still gigantic. However, the rest of the fonts are OK, and restarting X once after booting up will resolve the issue with the title bars until the system is rebooted again. Seems like a different DPI is being used when X is started through the init process as opposed to through gdm AFTER the init process. Could someone fix this? It is a tad annoying...

[agd5f (agd5f)]

(In reply to comment #23)

>
> I assume that the standard code path that this driver shoud follow is:
> if (crtc && crtc->mode.HDisplay && output->mm_width && output->mm_height)
>
> Unfortunately the problem is that mm_width and mm_height are zero so that code
> path is never executed. Don't know yet where these come from - I assume radeon
> driver fills these. Digging.

mm_width and mm_height should be filled in either by the edid (xf86OutputSetEDID()), or by hardcoding them in a monitor section in your config. If you hardcode the settings, the server should parse the monitor section of your config assigned to that output and fill in the values, but it does not. That's the bug.

>
> I'm guessing that my problems are related to "(WW) RADEON(0): Unknown DDCType 6
> found" like not found => no ddc query => panel dimensions unknown. Is my
> guessing correct?
>

In your case, yes, but lots of laptops do not provide an edid for the panel. Without an edid, there is no way to know what the physical size of the screen is. We are able to determine the size of the panel in pixels based on the panel bios tables, but not the physical size.

[Felix Miata (mrmazda)]

I'm bothered by seeing this kind of thing in Xorg.0.log using 845G on Mandriva 2008 and OpenSUSE 10.3 (where DPI always comes out to 96 no matter what resolution or screen size is used):

...
(**) intel(0): Display dimensions: (361, 270) mm
(**) intel(0): DPI set to (144, 192)
...

See:
https://bugzilla.novell.com/show_bug.cgi?id=331609
http://qa.mandriva.com/show_bug.cgi?id=33935

[Arkadiusz Miśkiewicz (arekm)]

bug 10304 has fix for xserver (not tested by me but looks fine)

[Tim Hull (thully)]

I have figured out that the current font problem is limited to Compiz, so adding that as a package which this bug occurs in and re-closing the bug in xorg-server...

[Tim Hull (thully)]

Please look at this as it related to Compiz... I have huge title bar fonts after starting X with Compiz enabled (with Compiz disabled, it's fine...).

[Matt Zimmerman (mdz)]

This issue seems to be fixed for everyone else; I suspect that Tim Hull's problem is not related.

[Florian Effenberger (floeff)]

I tried out an in-place upgrade from feisty to gutsy, and it seems to work now! :-)

[Khorne (szczygiel-piotr)]

Well, today I've made a clean install of 7.10. Even on Live CD install ,window title bar fonts were extremely huge. After install I could see the same huge font on login screen and, like on Live CD, on tittle bars. Font on tittle bars has changed after switching to non-default metacity theme but remained the same (huge) on login screen.

I didn't have this problem when I was working on Feisty and even when I updated from Feisty to Gutsy by updating repositories.

[Alexander Jones (alex-weej)]

Is Compiz using the GNOME API for screen DPI? I'd imagine not, hence why this bug is a problem.

[Mhopf-suse (mhopf-suse)]

Fixed in git as of d502521c3669f3f22b94c39a64ab63bfd92c6a97.

[donflint (don-pacific-sailing-deactivatedaccount)]

I've got the same problem as Khorne describes, and many other people. This should be a critical bug and a fix put out pdq because NUBE's are throwing Ubuntu away when they experience their first hassle before even getting to their desktop.....

[Bryce Harrington (bryce)]

The remaining cases I've seen of this have been down to the user having an old xorg.conf from either Feisty or an old tribe release. In at least one case, removing the HorizSync and VertRefresh lines in Monitor and rebooting completely resolved it.

Or just run "sudo dpkg-reconfigure xserver-xorg" and it'll regenerate your xorg.conf. For most people you can just accept the defaults for any prompts it gives.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

I think you meant commit 48ca5961caee62f2980017a6bdc96a1b4c747727