Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 8:47 UTC (Thu) by nim-nim (subscriber, #34454)
In reply to: Open fonts at Libre Graphics Meeting 2009 by riddochc
Parent article: Open fonts at Libre Graphics Meeting 2009

Firefox does not use points as font size unit. It uses pixels. This is why you need to specify 16 (px) fonts in Firefox to get roughly the 12 (pt) size on a typical ~ 100 dpi screen (and yet another value on your system, that you need to change for every freaking encoding because someone decided having encoding-specific sizes was smart)

Of course this is a usability disaster. I've always felt exposing pixel sizes this way when the physical size of a pixel can vary greatly from one screen to another was a way to break so utterly text size adjustment no one could tell what dev made the biggest mistake anymore.

(People will raise the "angle of view" argument. 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)

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 16:10 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I assume that the reason people want to specify text size in pixels is that they also use a lot of raster graphics (like JPG and PNG) whose sizes are inherently defined in pixels. If the graphic designer wants a consistent layout behavior, it's easier to define everything in pixels. As long as designers want to do that, the best solution will be to use the scale control built into your web browser, rather than setting a larger default text size.

Open fonts at Libre Graphics Meeting 2009

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

That was not a valid argument when graphic designers wanted to ignore that screens where not equal in resolutions (the infamous "best viewed in 800*600" era), and it's not an argument when they want to ignore pixel sizes are not equal either.

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 19:44 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

> (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...

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

Open fonts at Libre Graphics Meeting 2009

Posted Jun 27, 2009 11:48 UTC (Sat) by jwalden (guest, #41159) [Link]

Odds are you'll never read this response, but for anyone else who does...

Firefox does not use "pixels" that way, and neither does CSS. CSS pixels actually correspond to your angle-of-view suggestion, and the spec defines a precise optical angle for them. Thus far most screens lack sufficiently high resolution to really demonstrate this, but it's my understanding that if you grab a high-res screen and run Firefox (3.5 at least, I believe 3.0 as well) on it, a pixel as selected by CSS does not exactly correspond to what the spec names as a "device pixel".

Frankly, having used for brief times a 30" screen, the bigger problem is that there's so much space that no website or application can fill it, and window maximization is an obsolete concept because seek times across its height and width at a normal distance for a computer screen are so atrocious. That's arguably a window manager problem, but I can imagine individual applications might take various steps to better use that space.