Re: A proposal for units in GTK+

[Michael Meeks <michael ximian com>]

Hi Keith,

On Thu, 2003-02-20 at 08:11, Keith Packard wrote:
> I've done some thinking along these lines and thought I'd chime in with my 
> misinformed opinions.

	Ha; so - not as misinformed as mine.

	So - all this stuff about angular eye slicing, virtual inches,
foot-pounds etc. is well beyond me; however in OO.o there are some
people that think when you are at 100% zoom - in the ideal world you
should be able to hold your printout up to the (flat etc.) screen and
see the perfect parity between the printed and on-screen page [ if your
monitor isn't lying about it's DPI ].

	It seems to me with an angular perspective, that instead you have to
press the sheet of paper to some virtual plane between yourself and the
display (or beyond) - is that so ?

	And/or is it a reasonable thing to want this behavior ? and if so -
would it be sensible to have a "believe the monitor really" setting in
the Gnome font settings 'Font rendering details' dialog ?

	Either way - I'm well in favour of the status quo in our OO.o - just
using the XGetDefault and falling back to the DPI, but others are
thinking differently; insight appreciated.

	Thanks,

		Michael.

(rudely quoting lots of noise for Chris (and the OO.o list's sake)):
> 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
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot