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

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.

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.

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

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

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

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

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

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

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

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

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.

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.

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

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.

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.

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!

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)

Rejecting firefox task as it is not a firefox issue.

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.

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.

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.

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!

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.

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

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.

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.

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.

Mike: it's gnome-font-properties.

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.

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.

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

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.

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.

How big is your screen? (Physically)

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.

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 !

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

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.

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

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?

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.

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

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

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

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.

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

Section "Monitor"
  DisplaySize x y
EndSection

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

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

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

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

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

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

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

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

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.

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

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

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.