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

That should really have been a comment, rather than a new bug, Matt :)

Sorry -- I found bug 103507 after starting this report, and it seemed
to be a rant / demand for a particular solution, while I just wanted
to report the symptoms and let someone else decide how to fix them. 
I'll be less bug-happy next time.  :)

Note for testers:  To reproduce some of the effects described here,
start your X server with the "-dpi 75" option.  If you use gdm, you
can add this option to the "command=" line for the Standard server in
gdm.conf, and then restart gdm.

Another solution is to tweak DisplaySize in the Monitor section of
XF86config. This will overide the physical monitor size XFree86 can
detect via DDC (and if DDC is broken in the graphic card driver and
the system can not detect the screen size, this is where you can tell
XFree86 what your screen size is).

Once XFree86 knows the monitor physical size it can compute the real
dpi given the resolution it's asked to output. One can consult it via
the xdpyinfo program.

Note that horizontal and vertical dpi can differ (especially since
screens are typicaly 4/3, but standard high resolutions are not). Plus
on a xinerama system all monitors may someday not share the same dpi.
(and when you add nfs-homes to the picture, you quickly realise why
using a single fixed user-defined value is overly simplistic)

gimp is able to get this info ; in fact the first time it is launched
it asks if people want to use a fixed dpi value or get the one X has
detected. In fact these are quite older X features than fontconfig.

Hence my astonishment when I discovered the way Gnome choose to get
this value (and the rantesque bug, I fear I wasn't as restrained as I
tried to be. Sorry).

Note that using real dpi insures the same font will have the same 
physical size on all screens, regardless of the pixel resolution.

Since some people are near-sighted and people are not usually as 
close to their screen as they are to paper medium, one may need to 
add a subjective correction factor.

*This* is what should be saved in user preferences. A user can tell " 
I want fonts displayed 4% bigger than the real size because I have 
bad eyes ". And this will translate into different fontconfig 
parameters depending on the real screen resolution. 96 dpi on the 
other hand will translate into big fonts on some screens and very 
small on others.

Its not quite as simple as all that.

1) the xserver dpi settings are frequently wrong
2) even in newer servers with newer monitors where the values is
actually potentially correct it is often not what you want.

The goal is for the _perceived_ size to be the same.  That is
controlled by the distance of the monitor from the user.  Users will
often end up just adjsuting their screen position to get the desired size.

Have several different copies of dpi is clearly not optimal.
So having Gimp with one notion, Xft with another, the X server with a
3rd, and several others in gconf is not good.  We'll need to decide
how many of these we want, and what their precedence should be.

I'll ignore the issues of multiple displays and multiple logins for
now because lots of other things are already screwed up in those contexts.

1. is not relevant - XFree86 provides ways to fix automated detection
if it's wrong so there is no need of a gnome bandaid that makes things
worse for people who actually have their core system working

For 2. - except for rare cases (like projecting on a wall, tv-out,
etc) the monitor distance is always fairly the same (if only because
there's only so much space one can afford on a desk). So by using the
exact dpi value one gets a fairly stable baseline across monitors.

What changes a *lot* is user individual preferred UI sizes. And this
is a zoom factor - dpi isn't it's a baseline. Lying about dpi has
zooming effects right buts it's an unclean hack that produces
distortion on screens with different H/V res and breaks horribly with
nfs homes (the mozilla people are running in the same problem btw -
they've begun to realise one can not mix units that happen to produce
the same results in some circumstances but not others)

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

This is an open, high-proiority bug and has been for over a year. This post
represents an ongoing Mandrake Cooker ML discussion. We would also like to see
this fixed, mainly because it messes with multiple-environment systems. There is
no supportable reason for GNOME/GTK+ to have its own dpi setting. Since it does,
Mandrake users who run KDE often report that commonly used GTK+ and GNOME apps,
like the Mandrake control centre, Firefox and others, have completely different
font sizes to their KDE apps. KDE - correctly, in our opinion - reads the X dpi
setting, and KDE's font control app sets it. If GNOME were to behave in the same
way, all current functionality would be maintained, and users mixing GNOME and
KDE apps would see consistent font sizes. Please, someone, fix this bug - nuke
the gconf key for dpi and make GNOME read and set the X setting.

If the problem persists please raise the version number.

Nothing changed to fix this, yes

This represents a request from a Gentoo user who is also having horrible
problems getting both KDE apps and Gnome apps to look nice and play nicely together.

For anyone interested, there are screen shots and and a writeup of this problem
available here:

http://bugs.gentoo.org/show_bug.cgi?id=87040

Please fix this.  Please.

There's a discussion on kde-devel (and kde-core-devel) too, see here:
http://lists.kde.org/?l=kde-devel&m=112095768230539&w=2

Please fix it.

patches are welcome

I'd strongly suggest *NOT* welcoming patches here. Jody's comments in #27
are completely accurate. Using the value from the monitor is not appropriate
in almost any environment.

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

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

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

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

To comment a little more here, I do think that there is a use case that
isn't handled very well currently: that use case is where with a single
home directory, people use different monitors with very different
properties. This could be:

 - Switching a laptop between desktop and laptop
 - Remote display of an entire X session onto a different computer
 - A shared NFS mounted home directory used from different computers

There is also the very-difficult to handle case of:

 - Xinerama (single screen dual head) on multiple monitors with
   different properties.

However, using the DPI from the monitor is not a good way to handle
these situations: to expand a little on what Jody said

 - The desired DPI is more based on angular size than physical size,
   and people sit at different distances from different monitors.

 - People want font sizes that fit their information on the display;
   if you have a 1024x768 display, you want fairly small fonts, even 
   if your display is 200dpi.... you'll just move your head close 
   enough so you can see the display.

 - Monitors with incorrect or no DDC information are still quite common.

 - Using the physical DPI of the device leads to pathological situations;
   GTK+ does use the physical DPI as a fallback; when we first ran
   a GTK+-2.0 based version of the Red Hat installer at 640x480 on
   a 21" monitor, we got 5 pixel high fonts. (Then changed the installer
   to set the Xft.dpi X resource...)

It's quite possible that you have a situation where using the physical
DPI of the device would give reasonable results on all the display 
systems that you use. There are all sorts of possibilities for what
the right logical DPI is for each device for a collection of display 
devices:

 - Same for all devices
 - Physical DPI for all devices

Are two of a gigantic space of possibilities. The reason that GNOME 
emphasizes "same DPI everywhere" is that it is both extremely common 
for it to be the right thing, and it is robust: while it may give
slightly wrong results, it won't give *horribly* wrong results.
(Unless you have a 300dpi display, in which case GNOME has a lot of
other scaling problems as well.)

How could we handle the multiple display case? I don't have a really
good situation, but what I might suggest is that we could make the
DPI setting store multiple values indexed on:

 screen size + lcd vs. crt

gnome-font-properties would then use and allow editing the one for
the current setup. (The user sees only one at a time, so they
have to separately set a value for each display they use, but only
once.)

This would have to be done with a new GConf key for compatibility
with old versions of GNOME, of course.

thanks for the explanations

>There is also the very-difficult to handle case of:
>
> - Xinerama (single screen dual head) on multiple monitors with
>   different properties.

Multiple monitors with multiple screens without Xinerama also causes problems.

> - Using the physical DPI of the device leads to pathological situations;

True, but why work around such situations in Gnome? They should be handled on
the root, meaning the X11 configuration. In almost all cases providing a
different value for DisplaySize solves the problem for *all* applications, not
just the Gnome ones.

The current situation is a complete mess. If the monitor DPI setting is fine, I
still have to change the gconf key and Xinerama etc. is broken. If, on the other
hand, the monitor DPI looks bad, I have to fiddle with X11 *and* Gnome config to
fix it. 

Without the setting, working systems wouldn't require intervention; Xinerama
etc. would work fine out of the box. Even if the monitor DPI looks bad, a single
tweak in the X11 configuration would fix it.

This means that the current behaviour breaks working X11 configurations while
not improving the situation for broken configurations.

1. I totally agree with comment #23 : it's a mess, it breaks as many settings as
it solves, and generally speaking this bandaid only justified not looking at the
problems these past years

2. even if some setting was needed at the Gnome level (which I seriously doubt)
hijacking dpi is the wrong thing to do - just because it has a zooming
side-effect should not legitimate lying to apps that could use physical
resolution for other things (for example drawing programs). To make "good"
decisions an app need as much info as possible and we're hiding some from it.

3. angular and monitor size are directly related, because monitors are placed so
they fill the user field of vision. Even if they're not exactly the same, I
doubt a size-base euristic would be much worse than the "everyone uses 96dpi"
thing. (that is, is wouldn't work for very big and very small displays, but
these are definitely not 96dpi displays anyway)

4. if there is a special case that's anaconda - you don't tailor your system
around install phase limitations (thanksfully)

To respond only to 2 - what GNOME does is it *DOES NOT* hijack the 
physical DPI. The physical DPI of the screen is left untouched as
it always is for apps to make any use of they see fit. The GNOME 
setting is a separate number, a scale factor between font size in 
points and font size in pixels, defined by:

 pixel_size = point_size * logical_dpi / 72.
 
The name "DPI" is used for this since it is the normal convention.

Well if it's not dpi in the X sense shouldn't there be a tool in gnome to adjust
X dpi if it's somehow misdetected ? (probablY just a window to enter the screen
size)

A lot of the problems come from the fact the gnome dpi setting is used to change
the X dpi setting, and when the X dpi setting is wrong you overcompensate. So
moving to a workstation that correctly detects it and/or launching an app that
uses the raw X value produces terrible results.

If there was an app to fix physical (hardware-dependent) dpi value when
misdetected, the gnome dpi value (user-dependent and hardware agnostic) would
only be used for light zooming and wouldn't be such a problem.

My comment may have been technically wrong but I'm sure most users and half the
Gnome developpers at least are as confused as me. Using this name is a terrible
 UI choice.

Having thought about the matter for a while, I propose the following solution:

Rename the gconf key in question to font_scale_factor and render all fonts with
physical dpi * font_scale_factor.

People with good X11 dpi values can then just keep the setting at 100% and won't
be bothered with the current side effects.
 
People who needed a different DPI setting before, can reach the same effects by
setting font_scale_factor to a higher or lower percentage.

I believe this stops all the confusion about the current handling, improves the
situation for people who don't need it at all and preserves the right for manual
correction for those who need it.

Comments?

+1 That's one big part of the solution.

The other is a way to set the physical sceen size at the system/hardware level
if X misdetects it

That's already possible using the DisplaySize option.

I know it's possible at the X level, but is there a Gnome GUI to do it ?

One big reason for the current problem is someone at one time decided building a
GUI to change X DisplaySize was too hard and the Gnome DPI bandaid was good
enough. Well it isn't good enough, this bug proves it.

(which doesn't mean a user-level zoom factor is not a good idea, it is a useful
thing, but it has not been used just as a user-level zoom factor so far)

Lots of stuff changed since, we have a resolution GUI control now, so setting
physical screen size must be more doable than before (maybe it's even done
today, I didn't look at this part lately)

I understand what you mean. It would, in fact, be a gnome utility for X11
configuration. I won't elaborate on wheter this is a good idea or not, but it's
certainly beyound the scope of the bug we are discussing here.

Right. I was thinking about Red Hat system-config-display which as you note is
another thing entirely. Sigh. Will have to open another RFE in Fedora bugzilla

In regards to comment #27, fontconfig already has a "scale" attribute available,
wich may be exactly what we're looking for.  Instead of GNOME setting the
Xft.dpi X resource, it can set the Xft.scale X resource.

1.  Leaving Xft.dpi alone, X server DPI is in effect, as fontconfig (xft) dpi
defaults to it.

2.  When fontconfig (xft) scale is set via GNOME setting the Xft.scale X
resource, GTK+ (and other xft rendered fonts) are scaled as the user likes.

3.  The X server AND fontconfig (xft) DPI is left alone and still useful for
those apps that use it.  They just ensure glyphs are drawn with a "scale" of 1.0
(local to their needs).

*** This bug has been marked as a duplicate of 378338 ***