I turned '"' today. I can't think of any particular meaning to that
number. Perhaps it is interesting precisely because it is the first
Letter quality displays
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
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
Not free software related.