5 May 2004 raph   » (Master)

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 LQ-aware.

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, anyway).

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 and use.

Leon Stambler

Another one that stung, perhaps more than it should have, was a recent description 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 doing.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!