Re: A proposal for units in GTK+
- From: Keith Packard <keithp keithp com>
- To: gtk-devel-list mail gnome org
- Cc: Keith Packard <keithp keithp com>
- Subject: Re: A proposal for units in GTK+
- Date: Thu, 20 Feb 2003 00:11:22 -0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]