More Letter Quality
You don't see too much sign of it on his weblog, but Robb Beal is going
absolutely wild researching issues around letter quality displays, and
what it'll take to get free software to adequately support them. If
you care about these things (which, from the response I typically get
from my LQ blog entries, is rather improbable), he'd be a great person
to get in touch with.
The near-letter quality and letter-quality devices continue to roll
out. In the former camp is the Sony EBR-1000
book reader, which has an exotic monochrome 170 dpi e-ink display.
The software is a mixed bag - apparently it has really crippling DRM,
but on the other hand it's Linux based, so presumably people will be
able to run good software on it. Hey, send me one and I'll see that
Ghostscript gets ported.
One of the newest letter quality devices is the Archos AV500,
sporting an approximately 200dpi 706x480 screen. The main app for this
thing is playing movies stored on its internal hard drive. As far as I
know, it's the first such device play at near-DVD resolution (and, in
the 4" form factor, DVD resolution and letter quality are pretty much
synonymous). The main competition in this field
would appear to be the Portable Media Center platform from Microsoft,
which as far as I can tell specs a 320x240 LCD.
LQ: What is to be done?
The issue of how to best support LQ displays is among the many things
tor and I discussed. He disagrees with my proposal
to have a global "pixels per px" (pppx) ratio for the entire display,
and do pixel-doubling at a low level for applications which are not
I see his point. Presumably, new LQ-aware apps are going to do the
right thing, so having extra machinery for automatic pixel-doubling is
just more cruft. Pixel-doubling is only relevant for older, legacy
apps. I tend to use xv as
something of a canonical example, given it's very old-school handcoded
X interface (clearly, toolkits are for weenies), a website more than
three years stale, a questionable license, and, last but not least,
the fact that it's still my image viewer of choice.
Obviously, if you run xv on a letter quality screen, the 5 point fonts
won't be very appealing. There are several ways to fix, or at least
partially fix, the problem. Probably the way most consistent with the
free software philosophy is to build an old-school, yet 2 pppx UI for
xv, and patch it in. Of all the approaches, this one probably gives
the best overall results.
Alternatively, you could do automatic pixel doubling, somehow
recognizing that xv is not LQ-aware. You could do pixel doubling
manually (this would, of course, be the most Unix-like way of doing
things - provide an incredibly powerful array of tools for solving
problems, but don't go 1/200th of an inch towards making them do the
right thing by default). In the latter case, you'd have any number of
different choices for implementing the pixel-doubling, including an
Xnest-like application, running everything through VNC, and I'm sure
others will think of more.
Other possibilities include ditching xv and upgrading to an image
viewer which is LQ aware, or treating the entire dot matrix resolution
X desktop as a retrocomputing target (it's worth noting that many
emulators already do pixel-doubling, to adequately display
really low res UI's on modern dot-matrix displays).
I still think that automatic pixel-doubling is the most user-friendly
thing to do, but perhaps not implementing it is exactly the sort
of mosquito bite necessary to motivate the army of Linux developers to
fix their favorite apps to be properly LQ aware.
The pppx ratio should be a global configuration parameter
So, while I'm not going to make a strong argument about a
pixel-doubling policy, I would like to make a strong argument in
favor of explicitly promoting pppx to the status of global
configuration parameter. After all, pixel-doubling is merely a stopgap
along the road of true LQ support, while fucking up the pppx ratio
will continue to make life difficult until my grandkids get sick of
the situation and decide to do something about it. (and hopefully,
while they're at it, will they please fix the last vestige of the backspace
problem? That's generally ok in a Linux-only world, but still
bites people when mixing with Mac OS X)
Unless people actually start listening to me, we most likely
won't see a global pppx parameter, and so here are my
predictions of the bad things that will happen.
Without an explicit pppx ratio, application writers will invariably
attempt to guess it on their own, based on information such as monitor
resolution information reported through the EDID channel. Inevitably,
different apps will come to different conclusions, depending on the
exact parameters, so the relative visual size of interface units will
be even more inconsistent than today (however, inconsistent UI
appearance is very much the X/Unix way, so maybe that doesn't bother
people - perhaps I've simply been spoiled by the time I've spent using
Mac OS X).
What are the different ways to derive a pppx ratio? I'm sure the most
common will be to try to dictate the physical size of a px. If you
read the literature on scalable user interfaces, you'll see many
people advocating the "point" as the unit of user interfaces, which
would effectively nail the pppx ratio to the monitor dpi divided by
seventy-two. Other reasonable approaches would be to set pppx to 1 for
dot-matrix displays, 2 for letter-quality, and flip a coin for
intermediate values of resolution.
Worse, when people are unsatisfied with the pppx ratio guessed on
their behalf, they will resort to even uglier hacks to work around
it. If the pppx is derived from the monitor dpi, then people will
figure out ways to lie about that, which will of course break other
apps that actually depend on a correct value.
What's wrong with nailing a px to a definite physical size unit (for
example, equating px with point)? In short, because not everybody has
the same visual acuity. Software developers, who tend to be uniformly
young and virile, easily lose sight of that fact. Currently, on almost
all systems, the pppx ratio is fixed at 1, so users have a very handy
way to configure the physical size of a px - simply choose a monitor
resolution. On CRT's, this is easily done with modelines, but for
LCD's, you pretty much have to choose that when you buy the panel.
Even so, for most people the choice of an LCD is a fairly intimate,
personal decision, and I imagine people consider the size of the px
carefully, whether they're consciously aware of it or not. For me,
low-res panels display blocky-looking text, and images are not crisp
enough. For many others, on higher-res panels, text is too small. I wrote
about this over three years ago; Apple was actually touting the low
resolution of their expensive displays as a feature, which of
course it is if your preference is a fairly large px value, and the
only way to achieve that preference is through hardware choice.
Of course, the whole point of high resolution displays is to not
have to make the tradeoff between desired px value and display
sharpness (the third prong of the tradeoff, of course, is the added
cost of generating all those extra pixels in the CPU and turning them
into light, but Moore's Law should take care of that, in time).
If, as a software developer, you are tempted to fix the px to a
definite physical size, then I suggest you go to your local bookstore,
library, or church, and suggest banning all large print books and
small print bibles. After all, readability studies have proven that
10-12 point text has optimum readability (for the average reader,
A bit of bitterness
Based on my experience in the world of free software, I feel
reasonably confident predicting that we won't get the pppx
configuration parameter right. If I were dictator of the universe,
there wouldn't be any such problem, but of course that's not the way
free software works, and for the most part that's a good thing. (the
primary exception, of course, being the chain of keycode mappings
applied to the backspace key - if it were up to me, I'd say that
everybody should use the mappings that happened to correspond to the
keyboard config I'm typing on now, and then of course the problem
would be solved for everybody)
The world of proprietary software has been very good to me lately. I
don't get to make the big architectural decisions (those are up to
space aliens holed up near Redmond), but I do tend to get a lot of
appreciation for my ability to solve problems. Money too, which is
nice, but here I'm talking about appreciation.
Lately, I've been making gorgeous prints
on inkjet devices (most of my work is on an Epson 2200). I love
experiencing people's reactions when they see those prints, and the
obvious impact that they have on people's decision to license our
technology. It's a rush, a high, and I haven't felt anything like that
from the free software world in some time.
I do, however, get emails like this one:
To whom it may concern,
I have installed the ghost..garbage, and the gsvu garbage software, and it's
a bunch of crap.
It doesn't work nor does it convert ps to text. Go-on publishing your
version after version-it's useless.
Moreover, nearly everything you guys have published about it is a bunch of
gobledee-gook that says nothing, and
is repititious and loops back to nothingness.
Why can't you do or say something useful that normal people can understand
Another one that stung, perhaps more than it should have, was a recent
of Libart as having been written by a "monkey with a PHD in low level
programming." When I started Libart, I had very warm, fuzzy feelings
about solving problems of 2D graphics rendering for the benefit of the
free software world. Now, while I'm pleased that some of the
ideas of Libart seem to have made an impact, every time I see an
app develop their own new graphics library, it bugs me a bit (xpdf's
splash, sodipodi/inkscape's libnr, mozilla's gfx, qt's "arthur"), not to
mention the fact that fontforge still doesn't do aa rendering, roughly
five years after my gfonted prototype.
I'm not just trying to whine at the world here. I know I'm not great
at coordinating distributed projects, especially with volunteers. What
I am saying is that the free software community has a pretty serious
process bug in that it's not very good at making use of my knowledge
and skill at 2D graphics, nor at giving me back much in the way of
"goodies" in return for my contributions.
So, looking forward at the professional work I contemplate, I find
myself getting excited about the prospect of building a top-notch
printer controller, to be sold as a part of real products. I do not
find myself getting excited at all about solving, say, the printing
problems of Linux.
That said, my feelings toward free software and the free sofware
community are decidedly bittersweet rather than purely bitter. While I
don't especially enjoy having my work NIH'd, I do
appreciate and respect the culture of learning that so often leads
people to code up their own solution to a problem rather than taking
an existing solution off the shelf. Hell, I've been guilty of that
enough times myself. Further, in the above I'm talking about my
professional work. For other things, such as pure speculative
research (including, most definitely, Ghilbert), it's impossible to
imagine doing things in any other way than free software. Finally, as
long as my professional work is Ghostscript, all of my code gets
released under the GPL after a year in any case, so I could get as
bitter and negative as I wanted, and everybody would still get the
benefit of my work.
Apologies for whining. But I did want to get some of these thoughts
off my chest, and I do think that writing about these issues is
preferable to not writing at all, which is mostly what I've been