how to disable gathering Display dimensions in xorg 7.3

[Magnus Kessler]

On Monday 10 March 2008, Nicolas Mailhot wrote:
> Le lundi 10 mars 2008 à 11:09 -0400, Alek Uritsky a écrit :
> > I can manually change the font size on a specific display and make it
> > look good.
> >
> > My problem is this:
> >
> > my application is running on many linux boxes with displays of
> > different sizes used.
> >
> > I cannot know in advance what display size is used and I cannot come to
> > every location and adjust it manually. I understand that new Xorg is
> > doing a better job in adjusting fonts to the actual display size. Here
> > is my question: how would the creators of the new Xorg approach the
> > problem that I face, which is making fonts looking proper without
> > knowing the display size in advance?
>
> The new xorg is not making fonts look less proper than the previous one.
> The new xorg actually does what you ask it, that is to display a font at
> foo pt if you ask it a foo pt size. Since pt is a physical unit it needs
> the displaysize variable to convert sizes in pt to sizes in pixels (this
> is what old xorg got wrong it assumed a fixed conversion ratio which is
> obviously not the case given hardware variability)
>
> If for whatever reason you want your fonts to have a fixed pixel size
> the solution is not to try to wedge the pt>px conversion factor to
> reproduce the old xorg misbehaviour the solution is to request font
> sizes in pixels in your app.
>
> This also makes plain the shortcomings of that approach: if your app
> thinks in pixels any hardware with pixels of a size significantly
> different from what you assumed will break your app.
>
> In contrast the new xorg will let you use hardware with high pixel
> density without the text degenerating in fly droppings.
>
> If for whatever reason you want your fonts to be sized a fixed % of the
> total screen size you need to ask X for the current resolution in
> pixels, convert your % to a pixel value and use this pixel value in font
> sizes.
>
> You complain that the new xorg produces small fonts on a big display,
> but you should be aware than the old xorg would have produced small or
> big fonts depending on how far the user hardware was from your
> assumptions. That it didn't on the few displays you tested only proved
> your hardware sample was overly homogeneous.
>
> Barring bugs the new xorg will always produce text of the same physical
> size regardless of the hardware the user is using.

Maybe we should first define what a "big display" is. I believe Alek has the 
no longer uncommon case in mind where you try to display on a HDTV screen. 
Typically these screens export their size in the EDID, and the X-server 
will use these values by default.

A plasma TV could have e.g. 1920x1080 pixels on a 42 inch screen. This would 
correspond to approximately 52 dpi. With this resolution, a 10pt font would 
be displayed about 7 pixels high, which is close to the limit of 
readability.

Contrast this with a 1900x1200 laptop screen at 17 inches. This comes in at 
132 dpi, despite having a similar amount of pixels. A 10pt font would be 18 
pixels high and look quite smooth with lots of detail.

Of course, the typical distance at which those two monitors are going to be 
used are vastly different. A laptop monitor is usuall between 25 and 40 cm 
away from the user's eyes, whereas the TV would probably be at 90-120 cm 
viewing distance if used as a computer monitor.

I believe that for most use cases the user will be interested in the 
apparent (angular) size rather than the absolute size in the plane of the 
monitor. In order to calculate this angular size one has to know both the 
physical size of a pixel as well as the viewing distance. Maybe we should 
allow to provide the viewing distance for an automatic calculation of the 
angular size. Could this be done through randr 1.3?

Until we have this capability it is probably a good compromise for most 
setups to use a dpi setting of around 96 dpi (which happens to be the new 
default setting). In this case we want to avoid using the size obtained 
from EDID for dpi calculations.

Best regards,

Magnus Kessler

PS: Using the angular size calculator (http://www.1728.com/angsize.htm) one 
can show that 96 dpi is a good value for the setups mentioned above.

A square pixel at 96 dpi has a physical size of 0.264 mm. At a viewing 
distance of 450 mm this corresponds to an angle of 2.0 minutes. This is the 
de-facto standard with many of today's desktop monitors. 450 mm is also a 
good reading distance for most users.

A square pixel at 132 dpi has a physical size of 0.192 mm. At a distance of 
330 mm this corresponds equally to an angle of 2.0 minutes. A user of a 
high-res laptop monitor may very well use it a smaller distance, especially 
on a plane or train, giving them the same apparent size as on the desktop 
monitor.

A square pixel at 50 dpi has a physical size of 0.508 mm. At a distance of 
860 mm this corresponds to an angle of 2.0 minutes. At this distance, the 
user would again see each dot as if it was displayed on the desktop monitor 
at the closer distance.

We can therefore use the 96 dpi monitor as the reference and use this dpi 
setting for higher or lower resolution monitors, provided they are at an 
appropriate distance to the viewer.

Moving a monitor away from the viewer has the effect of reducing the angle 
per dot (thereby increasing the effective resolution), and vice-versa for 
moving the monitor closer. If we could pass the distance information to the 
X-server we would be able to automatically calculate the correct apparent 
dpi.