Re: A proposal for units in GTK+

[Keith Packard <keithp keithp com>]

Jg sent me a pointer to this discussion and then jrb and I were chatting on
IRC about it.

I've done some thinking along these lines and thought I'd chime in with my 
misinformed opinions.

There are two separate issues which this discussion has conflated.  The 
first is how wide to make various objects on the screen and the second is 
how big to make the text.  I argue that they should be treated 
as independent configuration options.

The perceived resolution of the screen (it's "dpi") is a factor of the 
physical size of the pixels and the distance between the eye and the 
display surface.  In essence, "inches" on the screen aren't a linear 
measure, but rather an angular one, make an image 10 times bigger and move 
it 10 times further away and objects need to stay the same pixel size 
while getting 10 times larger to be perceived as the same size.

So, distances along the screen should be measured by angle instead of by 
linear dimension.  This makes measurements on billboard displays make some 
sense in relation to how large to present various objects.  The obvious 
question now is what units do we use.  I suggest that we call them 
"inches" and understand that we're talking about the length of an arc with 
radius of 18 inches or so -- the nominal distance from the eye to a 
typical PC screen.  This retains the "dpi" notion of resolution, but 
decouples that from the physical monitor resolution and lets us reason 
about how to compute better dpi values for different environments.

Linus argued persuasively that all PC screens are the "same" angular size;
the size which the user can comfortably fit in their field of view without
undo eye or head movement.  If this was indeed the case, we could actually 
compute dots-per-"inch" by dividing the pixel size of the monitor by a 
constant ("inches" per FOV).  

I argued that this computation would need to be adjusted based on the
context of the display -- a handheld device will occupy less of the
practical FOV than a desktop machine; the screen cannot be brought closer
than arms length because of the need to handle the device for input.
Similarly, projector environments have a wide range of FOV occupancy and
user interfaces for them will have to present information in a way that is
usable at a wide range of apparent sizes.

In any case, I'm getting side tracked by related issues.  Back to the task 
at hand.

Now that the DPI value is not fixed by the physical display device, I 
suggest that we can adjust the scale factor of the entire UI by changing 
this value.  Want to make the whole system twice as tall?  Double the DPI.
I don't think we would present DPI to the user, just a knob that adjusts 
the size of the presentation.  This knob is related to setting the current 
screen size and should probably be presented in that configuration UI.

The separate issue is how large to make text -- this is not connected with 
the above discussion as the desired size of text in dialogs depends on the 
font selected, the language in use and a bunch of other user preferences.  
One obvious example is when using Han characters -- you want a large font 
and yet you don't want the rest of the dialog spacing to increase.  So,
I think we should have a control which sets the base size of font elements 
in the UI and let the user frob the knob to suit as a part of selecting 
the UI fonts.  I suspect that most users would feel comfortable selecting 
font sizes in points.  The above setting gives us a conversion from points 
to pixels which will cause the selected point size to be additionally 
scaled by the preferred value for "dpi".

"dpi" should be configured to a default value automatically.  For PC 
displays, we can use Linus's rule above until we find something better.  
For handheld displays, I suspect we'll have to use a combination of the 
physical and pixel sizes along with a standard arm's length distance to 
compute logical DPI.  We can guess with projectors, but I suspect users 
will need to grab the knob to fix things.

Xinerama has an effect on all of this as well; as Xinerama is really just 
a kludge for "real" multi-screen setups, it's clear we should treat 
Xinerama as a collection of separate screens rather than one large screen. 
This means we should apply Linus's rule to a single physical screen rather 
than the union of them in logical form.

-keith