LWN: Comments on "Open fonts at Libre Graphics Meeting 2009"

Open fonts at Libre Graphics Meeting 2009

jwalden — Sat, 27 Jun 2009 11:48:11 +0000

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.

Open fonts at Libre Graphics Meeting 2009

foom — Tue, 26 May 2009 15:45:50 +0000

> should be marked deprecated and eventually forbidden to use

Actually "pixels" have a very useful meaning in HTML -- and it's nothing to do with the resolution of
your screen. The size "1pixel" == the size of a 1x1 image element without size overrides.

As screens get higher res, browsers will *need* to scale up "pixels", not just because of CSS px size
specifications, but because of images.

Open fonts at Libre Graphics Meeting 2009

muwlgr — Tue, 26 May 2009 10:40:25 +0000

Yeah, as DPI for modern displays is getting bigger and bigger, we are gradually entering the DPI hell. Pixels are becoming useless and meaningless measures of whatever. Use angular measures, use linear sizes in inches/cm/mm, adjust display of your content for certain viewing distance. But never more use pixels. When I read someone's blog with centered column width specified in pixels, with huge blank fields on the sides, I am losing the last respects for the web designer who did it. And my screen is only 1280x800 14", 107 DPI. And yeah, font sizes are sometmes given in points, sometimes in pixels.

I think that any size specifications in pixels in HTML CSS should be marked deprecated and eventually forbidden to use. You could not assume any certain pixel size and density any more.

Open fonts at Libre Graphics Meeting 2009

jpetso — Mon, 18 May 2009 13:14:50 +0000

Actually, there have been commits for Konqueror/KHTML to support web fonts
too, I believe the KDE 4.3 release will already ship with that.

Open fonts at Libre Graphics Meeting 2009

nim-nim — Fri, 15 May 2009 08:12:29 +0000

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

nim-nim — Fri, 15 May 2009 08:08:08 +0000

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

oak — Thu, 14 May 2009 19:44:47 +0000

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

rgmoore — Thu, 14 May 2009 16:10:02 +0000

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

ajb — Thu, 14 May 2009 13:07:43 +0000

Actually I think web fonts may help with accessibility, in many circumstances: it means that at least the actual text is there somewhere, as opposed to in an image with no Alt text.

Open fonts at Libre Graphics Meeting 2009

nye — Thu, 14 May 2009 11:47:21 +0000

Interestingly, I hate reading blocks of serif text on a screen (I usually force the use of Tahoma, with antialiasing disabled between 8pt and 13pt), though I've never used one with a DPI above 100 so perhaps that's the difference between us.

Open fonts at Libre Graphics Meeting 2009

nim-nim — Thu, 14 May 2009 08:47:33 +0000

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

Velmont — Thu, 14 May 2009 08:42:27 +0000

Yay! I look *so* forward to this :D

I've not joined the band wagon with sFIR and other font replacement techniques (well, I use image replacement sometimes, but feel really dirty doing it).

Of coure that other browser won't support it, -- but Firefox is pretty darn big, so it's OK.

Open fonts at Libre Graphics Meeting 2009

riddochc — Thu, 14 May 2009 07:26:27 +0000

While I can certainly understand the appeal of having more control over the fine presentational details of one's website, I'm concerned about what this could mean for web accessibility.

To give some context: the screen I normally use is 14" diagonally at roughly the golden ratio (unlike a lot of screens these days), with 1400x1050. I just looked it up, it comes to 124x124 dots per inch. My X.org log, as configured by YaST (running OpenSuSE 11.1), reports:

(**) RADEON(0): Display dimensions: (287, 215) mm
(**) RADEON(0): DPI set to (123, 124)

So, that sounds about right. Since a point is 1/72nd of an inch these days, 12 points should be 4.23 millimeters. I'd consider that comfortably readable.

But in order for text to be actually readable, I have to tell Firefox to use no less than a 26-point font. In reality, this puts my x-height at about... 3 millimeters, as I imprecisely measure with a ruler on my screen. When a website assumes it's acceptable to insist on using a font at 12 points, the x-height is a smidge under a millimeter and a half. I'm sorry, but my copy of the compact Oxford English Dictionary is more readable than that. $DEITY forbid I ever get so nearsighted I can't pick out individual pixels.

Is Firefox not querying X right? Is X not presenting DPI information to applications right? Is it XFCE's fault? I don't know. Not sure where this bug should be filed, but it's beside my main point...

I tell Firefox to ignore whatever fonts the website wants to use, for several reasons. (1) The already mentioned size problem. (2) Sans serif is for headers and large text, Serif is for blocks of text. That's a basic readability rule that's been thrown out the window by web designers. (3) Mucking around with kerning for the sake of being "interesting" never actually is. (4) Does anybody remember how many different dashes or spaces Unicode offers, and what they mean for their use in language and/or the effect on the typography? Neither do I. (5) Most importantly, accessibility.

It's the content that matters most - it's the content that will keep people coming back to some sites, and avoid others. Until the majority of web developers actually learn something about typography and readability, I'll make my own font choices, thanks. I strenuously object to any attempt at letting website developers make the web less accessible than it already is.