Open fonts at Libre Graphics Meeting 2009 [LWN.net]

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 19:44 UTC (Thu) by oak (subscriber, #2786)
In reply to: Open fonts at Libre Graphics Meeting 2009 by nim-nim
Parent article: Open fonts at Libre Graphics Meeting 2009

> (People will raise the "angle of view" argument.

Yes, I was just thinking about this. :-)

(Others: viewing angle = relation between DPI and viewing distance.
There's a large difference whether you look at your PDA screen from dozen
cm distance or your projector canvas from 4m distance.)

> Since no one can measure "angle of view" automatically this is just a
way to refuse fixing the problems. Physical sizes can be autodetected and
they're good enough for many cases)

For projectors not so...

What kind of API you were thinking for physical sizes (hmm. does xinerama
complicate this)? And which one is more appropriate; the application
window size or screen size? Former would be easier for apps to get right.
Unless you're using a compositing manager that uses large zooming
factor...

(Log in to post comments)

Open fonts at Libre Graphics Meeting 2009

Posted May 15, 2009 8:08 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

>> Since no one can measure "angle of view" automatically this is just a
>> way to refuse fixing the problems. Physical sizes can be autodetected and
>> they're good enough for many cases)

> For projectors not so...

Since the vast majority of screens are not projectors and any browser page sucks when projected anyway that is not a good argument.

Basically you have three kinds of devices :

1. desktop and laptop screens where distance to eyes is pretty much fixed (for laptops, human arms are trivially not extensible). Using raw physical size to adjust text will just work here.

2. embedded stuff where the pixel size and eye distance can vary wildly so the actual behaviour is terminally broken, and you can not get by at all without a device-specific adjustment (since remote sessions and shared homes exist this adjustment must really be tied to the device not the user general preferences). This device-specific adjustment can be sourced from a device db.

3. TV and projectors : viewed at a distance, and this distance is not device specific but installation-specific. Handling those requires asking the user for the viewing distance at first plug-in time.

So here you are, to handle all the kinds of devices on the market you need:

1. To autodetect the physical pixel size. This is sufficient for laptops and desktops and already done by X for years (except the "but projectors" people refused to use this measure and made a mess doing other stuff). In the case of broken devices that do not expose their physical size, allow manual overrides. This could have been automated yesterday.

2. Factor in a device-specific adjustment for embedded stuff (from a device db, as we already do for input devices, printers, etc).

3. Factor in a user-inputed installation-specific adjustment for TVs and projectors (which remain the minority case, and can be trivially detected because they use video not computer resolutions or old low-density computer resolutions)

Also some users like small text, other users like big text, so once you have adjusted everything so your pt size is meaningful and device/installation independant, you need to let the user declare if he likes 8pt or 12pt text (totally useless before making sure 1pt is something meaningful).

Thus a working API would be:

1. raw physical pixel size (today's X DPI) => totally autocomputed, system-wide/system-specific

2. perceptual pixel size (raw physical size * a where a = 1 for laptops and desktops, a is db-sourced for embedded stuff and a is user-sourced for TV/projectors), system-wide, needs manual (deferred via a db or not) settings

3. user text size preferences : user-session specific, in pt, with the pixel value of pt computed using the perceptual pixel size. Can be broadcasted to gtk/qt/choose-yout-toolkit via XSettings