I turned '"' today. I can't think of any particular meaning to that number. Perhaps it is interesting precisely because it is the first uninteresting number.
Letter quality displays
Robb Beal asked me a couple of weeks ago how to get support for letter quality displays in Linux. It's a good question, and it deserves an in-depth answer.
I want to go over the highlights here, though. There are really three parts to the question. First, what can users do to push things along? Second, what are the "configuration science" problems that need to be solved? Third, what are the imaging problems that need to be solved to get high resolution bitmaps to the display hardware?
As a user, probably the most important thing is to let your friendly local developers know that you're interested in having letter quality displays supported. There are a bunch of ways to do so. If I expand this into a full post, I'll have two sample letters. One says, briefly, "you suck, free software developers are commies, by the way why doesn't your software support LQ?" The other says, "I love your software and would love it even more if it had LQ support. By the way, do you have a paypal address or maybe an Amazon wishlist so I can give you a small token of my appreciation?"
Indeed, funding is a large part of the problem, not least because the prototype displays are still rather expensive. Of course, after Microsoft rolls out their LQ stuff, then the hardware will be available at commodity prices, and then as the gear filters into the hands of free software developers, there will naturally be more motivation to support it. It's a shame that we, as a community, suck so hard at organized fund-raising, or else we'd have already put a few of these displays in the hands of the most important developers, as of course Microsoft did years ago.
Yes, that's a whine. On to the configuration science part of the question. The primary configuration parameter that must be discovered by applications and negotiated between application and display subsystem is the "pixels per px" ratio (which I'll abbreviate here as pppx). The px is the fundamental unit of constructing user interfaces, and has no preset size. On current display hardware, the pppx ratio is locked in at 1. If you like, "LQ support" could well be defined as the support of pppx ratios other than 1.
Many people believe (misguidedly, in my humble opinion), that the "correct" configuration parameter is the display dpi. Indeed, it's fairly easy to come by values for this - the EDID standard provides a way for the display to tell it to the video card, and most OS's now provide at least some support to access the info (in X, DisplayWidth and DisplayWidthMM; in Windows, similar information can be obtained from GetDeviceCaps; in Mac OS X, CGDisplayScreenSize).
UI's are built in units of px units, which, because of currently available display technologies, are identified with pixels. They could have been built out of some physical unit, for example points, so that getting a larger DPI value out of the EDID would cause applications to automatically draw their UI's with more pixels. (indeed, for quite some time a display resolution of 72dpi was so common that many people identified pixel and point, as well). If the technology had evolved that way, then LQ support wouldn't have been espcially difficult. However, technology didn't evolve that way. I don't see this as entirely a bad thing - there are good things about a px-based coordinate system, which I think I'll detail if this becomes a full-length article.
So, the negotiation has to happen something like this. The OS knows that a pppx value of, say, 2, is available. If the app is not LQ-aware, then as it asks for a display surface, the OS knows to give it one with 100 dpi "pixels", so that each pixel that the app draws shows up on the hardware as a 2x2 square of pixels (one can imagine other choices here, for example, drawing text at the full device resolution, but it will be a compromise in any case, and the Real Solution is always to make the app LQ-aware. The chunky pixels might not look that good, but at least they won't break anything or introduce bizarre new artifacts).
But if the app asks for the range of available pppx values, the OS will tell it that 2 is available, and then the app can ask for a drawing surface that matches the physical display resolution.
Once we get to that point, then the app has to actually come up with the higher resolution pixels. But this is a relatively straightforward technical problem, and different applications can solve it each in their own best way. Certainly, having a good 2D graphics library under the hood would be nice, but there are a few around (even if one of the more well-known was written by a "monkey with a PhD in low level coding" :), and if none are satisfactory, you can write your own.
By contrast, configuration science problems have a way of not being readily solved. My favorite running example is what happens when you press the backspace key. After many years, Linux systems have pretty much settled down, but if I login from my MacOS X laptop to my Linux box and open a forwarded X11 terminal, I still find that pressing backspace sometimes prints '^H' rather than deleting the character to the left of the cursor. Let us pray that we can do a better job with LQ configuration.
Update at other blog