I've been kinda immersed in fonts for the past week or so, and have some things to share with you font nuts out there.

First, I've picked a font revival to work on: ATF Century Catalogue. I think this may be one of the most underappreciated fonts out there. It's definitely a representative of Beatrice Warde's Crystal Goblet theory of font design, as opposed to all the ego-driven stuff work churned out now.

In particular, I believe an adaptation of Century Catalogue is an excellent candidate for a font to supplant Computer Modern as a font for setting math. In addition to aesthetic beauty, an important consideration is continuity with existing traditions of math typography. A great many math texts in the last century have been set in Monotype Roman No. 8, of which Knuth's Computer Modern fonts are a reasonably accurate digital revival. But this is far from the only font well represented in the literature, nor, arguably, the best.

The model that Knuth acknowledges as the most aesthetically pleasing is Volumes 23 and 24 of the Transactions of the AMS (see p. 20 of his book, Digital Typography). The sample he shows appears to be set in a variant of Monotype Old Style (not exactly No. 2, as the tail of the 'c' in the latter are curved up more). Even so, he doesn't like some aspects, for example the angularity of the italic 'x'.

I agree that the shape of the italic 'x' is important - indeed, to me, it strongly connotes variableness, in much the same way that a copperplate gothic connotes the style of a banker or lawyer, or Old English Gothic connotes an old-style newspaper banner.

So, after looking at dozens of fonts, I've concluded that Century Catalogue is the one. The roman resembles the Monotype Old Style fairly strongly, but is in my opinion better drawn (by master typographer Morris Benton Fuller). In addition, its italic (which is more closely based on ATF's Baskerville Italic than a member of the Century family, but is nonetheless stylistically quite coherent with the Roman) is much closer to what people now expect from math fonts.

Gain

Perhaps the biggest complaint about Computer Modern is that it's too light. Both the weight of vertical stems, and the relative weight of serifs and hairlines compared to the vertical stems are lighter than mainstream text fonts.

When I got my copy of Knuth's Digital Typography, I was struck by how much better it looked than most of the TeX output I'm used to seeing, especially from laser printers. I now believe I know the secret: press gain, probably in this case introduced deliberately to make the body text look good. You can see the effect pretty clearly in my 2400dpi scans.

What is the best primitive for curve design?

Most 2D curve design (including fonts) done today uses cubic Bezier splines. Almost all of the remainder is quadratic Beziers. There are other choices, and I wonder if some might be better.

In particular, I find it tricky to make smooth curves when there are a lot of control points. I'm sure it gets easier with practice, but I'm not sure people should have to adapt to the underlying polynomial nature of the spline, when perhaps smoother, more natural primitives exist.

For example, Ikarus used Hermite splines, in which all the control points lie on the curve. In Beziers, you have to position the off-curve control points so that they "magically" adjust the curve how you want it.

From what I can see, the main reason inexpertly drawn Beziers look unsmooth is large variations in curvature, both discontinuities at the knots and in greater deviation in curves than needed to smoothly connect the endpoints. I'm thinking of building a tool that graphs curvature along the path of an outline. I have little doubt that this tool's output would reveal much less variation and discontinuity in splines drawn by experts than by newbies.

So, to me, the most promising approach is to use a primitive that has smoothness of curvature built-in, so that by default it's easier to draw smooth curves than unsmooth. Of course, it should still be possible to do the latter, but I have no problem with making it require more control points than an equivalent unsmooth Bezier curve.

The most promising primitive I've seen so far is the "circle spline" of Carlo Sequin and students [SIGGRAPH PowerPoint presentation]. Near the end of that presentation, he raises the possibility of using a Cornu Spiral, which is mathematically constructed so that curvature is continuous at endpoints, and linearly interpolated in between.

For those more interested in this issue, John Hobby's paper "Smooth, Easy to Compute Interpolating Splines" is a must-read. My gut feeling is that his work is good, but that replacing his choice of cubic Bezier as a primitive with a circle spline or Cornu Spiral may give better results. He found that making curvature continuous can yield instable results, so he uses a linear approximation which guarantees stability. I wouldn't be surprised if this instability would go away with a better primitive.

Ripoffs

The Wikipedia is fun (and I've been contributing a bit to it), but one of the things that really irritates me is how ripoff sites usually manage to get higher Google rankings than the real thing. Most people don't know better, and often link to the ripoff pages, further strengthening their rank.

It's not just the wikipedia, of course, even though that's a notable and recent case. If you go searching for free fonts, you don't come across many sites of people who've put time and effort into creating, collecting, and critiquing the fonts, but you sure do find the ones that aggregate thousands of fonts (most of which are ripoffs of proprietary versions themselves), then presumably make some money off ads and whatnot.

I'll be releasing the math fonts under some form of free license so that they can be included in Ghilbert, of course, but it would be nice if there were some way to discourage them from being ripped off. If I continue to make fonts, I'm tempted not to release them freely, partly because of the ripoffs, and partly because free fonts are seen as junky.

Back already? Ok, good. I find a lot of what Paul writes to be
resonant. I especially liked his section on "nasty little problems" -
I think the elimination of nasty little problems, as opposed to
genuinely difficult and challenging ones, should be a top priority,
especially for free software developers. Longtime readers will not be
surprised to hear me categorize the auto* suite as a particularly rich
source of such nasty little problems, for all that it does a pretty
good job solving a set of real problems, and is a huge improvement
over what came before.

Paul seems to be addressing the issues at the scale of individuals or
small (startup) companies. I would like to see more attention given to
issues at a much broader scale: the interaction between hackers and
society as a whole.

One way for society to view its great hackers is as a resource,
comparable to a natural resource such as mines for valuable metals, or
fertile fields for agriculture. Most healthy societies try to convert
the potential of those resources into wealth. They plant good seed and
tend the land, rather than salting the fields. Of course, societies
vary in the extent to which they do a good job of this; famine is
much more common in Africa than in the West.

Societies vary even more widely in their ability to get good work out
of hackers. Paul explains fairly well what's needed: mostly, let us do
our thing and get the hell out of the way. I think his section "More
than Money" tells part of the story. I don't think hackers hate money,
but I do think we hate spending time hustling for money. There are
plenty of people who do, and they tend to become investment bankers
and the like. I don't think those people understand us very well.

Fonts

There's a fair amount of emotional turmoil in my marriage right now,
and I've been taking refuge by spending time with a subject very dear
to my heart: font design.

In particular, I've been scanning ATF type specimen books and
carefully studying the designs therein. I now have a great scanner
(Epson 4870), and the scans at 2400 dpi really pick up the
detail, and let you see the quality of the printing.

I was especially surprised to compare the quality across the
decades. I have four books, one each from 1912, 1921, 1934, and 1941
(all collected by my father). The printing quality from 1912 is head
and shoulders above the rest. As a seat-of-the-pants estimate, I'd say
it's roughly equivalent to a 2000dpi digital printer.

I've especially grown to appreciate the work of Morris
Benton, the chief type designer at ATF for many years. I get the
feeling that he was positively obsessed with printing quality. His
father was a very gifted inventor, and worked on many machines used in
type design and typefounding. In particular, his pantographic
"delineating machine" and matrix engraver not only scaled a single
design to many sizes, but could also apply general affine
transformations, just like PostScript today.

One of the secrets revealed by close study of these specimen books is
how type scaled to different sizes. Most fonts today are designed at
one size, then enlarged or reduced using strictly mathematical
scaling. Master printers over the centuries, however, have long
understood that smaller fonts should have more robust features, while
larger ones can be more elegant and refined. Periodically, type
designers working with new technologies try to rediscover this fact,
but it always seems like an uphill battle, probably because of how
much extra work it takes to optically scale a font. Adobe is producing
many fine optically
scaled fonts now, but one gets the impression they're still a
small minority of their entire font catalog. Another important
example, from the world of free software no less, is the Computer
Modern fonts of TeX, which, while technically way ahead of their
time, are not considered especially appealing by serious typographers.

So it's especially interesting to learn that ATF used almost purely
automated techniques to produce different sizes of font from a single
"pattern plate". I came across an excellent article
by Patricia Cost which explains the process in considerable detail.

I'll try to strip out the mechanical and historical stuff and just
describe the underlying "algorithm". The scaling happens when a
matrix (or mold from which the actual metal type with raised letter
is cast) is engraved from a pattern plate.

The pattern plate is a piece of metal about 4 inches high, which
contains a raised outline of the letter. Placed in the matrix
engraving machine, a "follower," or stylus, traces the inside of this
outline. The motion of this follower describes a path.

At the same time, a high-speed drill traces a scaled version
of this path, cutting into the matrix. Through the mechanical
ingenuity of Linn Boyd Benton, the scale factors can be different for
horizontal and vertical movement. Typically, the pattern plate was
designed for a 36pt font size. To cut a matrix for a 6pt letter, the x
scaling would be a factor of 1.19 of the y scaling.

The path traced by the follower, though, isn't exactly the same as the
inner outline on the pattern plate, nor is the outline of the letter
engraved in the matrix exactly the same as the path of the drill. The
follower has a nonzero diameter, so the path it traces
is "shrunk" by half that diameter, so that the width of strokes is
reduced by one diameter. Similarly, the cutting tool has a nonzero
diameter, so the outline engraved into the matrix is "grown" by half
that diameter, so that stroke width is increased by one diameter. When
the ratio between these two diameters is the same as the scaling
factor, the outlines correspond closely (especially if the letter on
the pattern plate has slightly rounded, rather than perfectly square,
corners), and stroke weight should be identical (after scaling, of
course).

However, by using a smaller or larger diameter follower, it's possible
to increase or decrease the stroke weight, respectively. And, after
studying the font books, I see that the typefounders at ATF did consistently apply this technique for scaling fonts. A typical recipe would be to use a grow radius of 100/ptsize - 3 units (on a 1000 unit/em grid), while applying a horizontal scaling of 1.18/ptsize + .967 (both additive factors chosen to normalize for 36pt design). It's worth noting that the Computer Modern fonts use a width scaling of about 1.3/ptsize, so the stretch of smaller sizes is even more exaggerated compared to the ATF example.

I want to write this stuff up, but to do it justice will require quite
a bit of time, especially to produce the illustrations. In the
meantime, this image of two lowercase a's from Lightline should
whet the appetite of you type fiends out there. The two images are
superimposed with a "difference" blend mode, so you can see two
outlines. The sharper image is an 18pt "a", scanned at 2400 dpi, and
scaled in the horizontal direction by a factor of 1.15. The fuzzer
image is a 6pt version of the same character, scanned at 2400 dpi,
then enlarged by a factor of 3x. Thus, 0.001" at that size corresponds
to 7.2 pixels. You should be able to see, then, that the 6pt version
is grown by a little less than a mil with respect to the 18pt version.

The good news is that it wouldn't be that hard to adapt this process
to the present-day practice of digital typography, and that it can be
almost entirely automated, so generating a good family of optically
scaled fonts wouldn't be that much more labor-intensive than drawing a
single good font (which is difficult enough as it is!)

I still haven't re-caught the blogging bug, for whatever reason. So I'll just weigh in with a few bits of personal trivia.

My mom just went back home to Virginia after visiting here for a couple weeks. It was a good visit - she and the kids get along famously.

Both the server hosting Advogato (casper2) and the original casper.ghostscript.com have had various problems as of late - the latter a failing hard drive. rillian has been doing the heavy lifting on recovering these systems, but I helped out some, including a laying-on-of hands to the physical servers (located at transbay.net in Oakland).

Experiencing such server failures, I can't help but think that the future will hold self-configuring high-availability features, especially for content repositories such as CVS and blogs. There's no reason why the data can't be replicated across several servers, and if one fails, for whatever reason, it should be possible to just throw it away and have the others take up the slack.

I think a large part of what makes P2P apps so compelling is the fact that, at heart, they are self-configuring high-availability servers, albeit with limited functionality. I'm most struck by BitTorrent's ability to resume a download (or upload, for that matter) even on a laptop which hops from one WiFi network to another.

I've also been spending some quality time with my collection of type specimen books. I'm enjoying rediscovering the beauty and engineering mastery that Morris Fuller Benton put into his classic ATF fonts from the first quarter of the last century. I'll happily write a blog post about what I've been finding if there is interest.

There are a couple of other things in my blogging queue, including progress on my Ghilbert proof language and applications of formal logic to programming. I may subject my reading audience to further thoughts on the economics of free software, as well. Feedback on which of these topics, if any, you're interested in hearing (or, for that matter, dread), is always appreciated.

Whew, it's been a long time since I've blogged. That's largely because of the site outage here, but also just inclination - after all, if I really wanted to, I could blog at my personal site.

I'm mostly doing well. Among other things, I'm really trying to put some time aside to finish my thesis. I had a great dinner last night (at the Blue Agave in Pleasanton) with Roger Dingledine and Rachel Greenstadt, during which we mostly talked about trust networks, stamp trading in particular, and how to make at least some of that work in the real world.

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.

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.

fxn: I haven't gotten the chance to look at Brian Ford's paper, but it sure is intriguing.

If indeed ZF comes crashing down, that would really validate my decision to make proofs in Ghilbert truly portable with respect to axioms, rather than trying to pick a single axiom system that is both powerful enough for the work at hand, but not so powerful as to raise questions about soundness, or raise problems porting the proofs over to other systems.

That said, the timing could have been a little better for me; as a demonstration of Ghilbert's portability, I picked a construction of HOL logic in ZF[C] set theory, and it's only a few proofs away from being done (of the core HOL axioms, I have only the law of the excluded middle (BOOL_CASES) and a theorem to introduce the iota operator). Oh well.

Busy, busy

It has been a busy month since the last time I blogged. Among other things, we had an Artifex staff meeting, and also tor stayed for a couple of weeks. We had a great time talking serious 2D graphics, color, and so on, plus hanging out with the family.

Kids

I'm proud of a couple photos I took on Alan's 8th birthday; the portrait of him, and another of the brothers posing with a penguin prop. Both were taken with my archaic Rapid Omega 100 on slow B/W film (6x7cm), then scanned on my brand new Epson 4870 scanner (highly recommended, btw).

Alan's photo page has unbelievably high Google-juice - looking at the referer logs, the most popular images are the ones that currently show up as #1 and #2 for a Google image search on happy. Even more exciting, a photo from last year of him playing his guitar is now on the cover of a book recently published by Wesleyan University Press.

Max, who just turned four last week, is developing quite a subtle sense of humor. A few weeks ago, when I was reading him Eating the alphabet, he asked if I would get him a Xigua melon. I answered that I didn't remember ever seeing one in a store, but that if I did see one, I'd get it for him, then we'd be able to tell if it's as good as a watermelon, or better (watermelon is one of Max's absolute favorites right now). Max replied that he knew that Xiguas are way better than watermelon. I asked him how he knew that, and he said: I can see inside people's minds. Even fruit. And that Xigua melon is thinking, "I'm way better than a watermelon".

More later

"More later" is one of Josh Marshall's favorite catchphrases, and people rib him for it. I've been doing quite a bit of deep thinking lately about the place of free software in the world, among other things, and I do want to write about it, but it will have to wait until I have a bit more time.

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.

I think Microsoft is on to something here: find smart people who know
what they're talking about, give them money and toys, and listen to
them. It seems to work well for them, but there's no reason for them,
or even evil proprietary software companies in general, to have a
monopoly on this business method. Who
knows, maybe we ingenious free software types can someday find a way
to adapt it to our universe.

Not that I'm personally complaining, mind you. I really enjoy my job
working on Ghostscript, and get to play with lots of cool graphics
toys - I don't have a 200 dpi monitor in my studio yet, but Miles has offered to pay half for
one, so it's tempting. I have a gut feeling that a letter quality
desktop panel will be available within a few months at consumer
pricing, at which point I'll jump on it.

If some kind benefactor wanted to set the cause of the free
desktop forward a few months or more, one of the most effective things
they could do is spread a few of those panels around to the people
in the free software community who can make the best use of them: X,
Gnome, KDE, Mozilla, etc. (I'd happily accept such a donation but
would be equally happy to see it go to others for whom it's a more
pressing need).

Indeed, the imminent arrival of letter quality displays will present a
very crisp test of the health of the various organizations responsible
for generating the relevant software. It's a pretty safe prediction
that Microsoft will not only get the software mostly right, but also
nearly singlehandedly create the mass market for these displays. Mac
OS faces a choice - Apple can either lead as they did with FireWire,
802.11 and DVD burners, or they can drag behind and let the Wintel
world kick their butt for a while, as they did with raw CPU power up
until their shipment of the IBM 970. Sun will probably manage to screw
up Java support royally - during the transition, I'm sure you'll see
teeny fonts, chunky pixels, and related artifacts for quite some
time. Mozilla won't even start to get its act together until there's
reasonably good support for letter quality on platforms other than
Internet Explorer (although the W3's sensible definition of the px
will help them get to the goal once they really get started). And of
course, it's reasonable to predict that the free software community
will eventually get it right, but that it will take quite some time.

I think there are two other potential winners from the disruption to
be caused by this technology: PDF and Flash. The win for PDF is pretty
obvious; today's dot-matrix screens are just not quite good enough to
display 8.5 x 11 inch pages with reasonable quality, in much the same
way as early-'80s dot matrix printers were not quite good enough to
render such pages on paper. The win for Flash is not quite as obvious,
but I think just about as compelling. Once you get past Flash's
reputation as the blink tag of the dot-com boom times, the underlying
technology is actually pretty impressive. Existing Flash applications
will immediately start looking good on letter quality displays once
the client supports the devices, and Flash will continue to be one of
the most painless ways to deliver such applications. Among other
things, it's pretty darned cross-platform already, and that will
probably just get better.

Interesting times ahead, that's for sure.

Advogato's DNS

I had DNS for advogato.org rather poorly configured. A power outage
here this evening that took out the primary, and none of the
secondaries thought they were authoritative, so oops. I also had the
timeouts set quite short because of the recent server move, so double
oops. Everything should be a lot more robust now.

I've posted the choice
thread on ghilbert.org. For those of you who are slavishly
following the development of Ghilbert, or fans of the Axiom of Choice,
it should offer a glimmer of enlightenment.

The New York Times reaches about 1.5 million people. This posting is
possibly of interest to two dozen. But the difference between my blog
and the NYT is that my post will reach those two dozen :)

Version control

As NTK says, No
self-respecting Thinker Of Hard Thoughts these days is without their
own Deep Theory Of How To Do Version Control. It's not surprising to
see so much activity in this sphere now. CVS has been broken for a
long time, and it's now clear that Subversion only solves some
of the problems of CVS.

I haven't actually played with Codeville yet, but I look forward to
it. When Bram puts his mind to something, it often turns out well. I
was also very interested to see Ken Shalk's CodeCon presentation on
Vesta, a project I've actually been following since its inception
about a decade ago.

The bottom line is that I think Vesta gets a few things very right,
but some of the design decisions are going to hold it back from
hitting the big time. Vesta is a source repository, a configuration
manager, and a build tool. If you buy in to the Vesta way of doing
things, all these pieces interact in a very nice way. For example,
because you keep not only your source files but also the tools needed
for building in the repository, you can always go back to a
specific build, bit for bit. It uses some neat tricks to work - the
files in the repository are exported through NFS, and, not so
coincidentally, that's how the build knows what the dependencies
are. If the file is accessed during the build, it's a depenedency,
otherwise not.

The biggest downside, I think, is that it's quite Unix-specific. It's
not impossible to run NFS on Windows or Mac, but it's not exactly
convenient either.

I think it is possible to take the best ideas from Vesta and put them
in a portable framework. Rather than a build being a script which runs
random commands and litters directories with temporary and result
files, it should be a functional program from input to output. All
intermediate results should be considered a cache. Indeed, I see no
reason why you shouldn't be able to take a source package, run a
simple command, and have it spit out a .deb for Debian, .rpm's of the
various flavors for the Red Hat-based distros (including some
intelligent analysis of how many variants are actually needed), a .pkg
or .dmg or whatever the Mac people decided is the preferred way to
distribute OS X apps, an InstallShield-like installer for Windows, and
a .pdb for Palms. Throw in a couple flags, and the Unix build is
instrumented to support debugging and profiling, or maybe gcc bounds
checking. Better yet, have it run in an interpreter such as eic, so that you can debug
runtime violations at a source level.

What exactly is standing in the way of such a thing? My guess is that
the main thing is inertia.

At least I think I voted. There's no way of knowing for sure, because
it was on one of those fancy new Diebold machines.

The problem is, of course, familiar to those experienced in computer
security. Because it's impossible to see security flaws, and
very difficult, even for experts, to understand them, people get
very complacent.
Judges, for example, are wont to dismiss
knowledge of such vulnerabilities as "speculative", rather than an
"actual threat".

What changes the status quo is invariably an actual exploit. If people
can see a voting machine being hacked, then they'll believe
it. Fortunately, in this case it ought to be relatively easy.

I don't think it's time yet for large-scale civil
disobedience about hackable voting. The most important thing, I
think, is to spread the word about the
dangers. As Avi Rubin
points out, many election judges are elderly folk without a deep
understanding of security flaws. I spoke with my election judges
briefly. I told them that I was a computer scientist, and that maybe I
know the secret to cracking the smart card they gave me. When I gave
it back to them and informed them that I didn't, in fact, mess with
it, they were visibly relieved.

I also liked Avi's idea of volunteering as a judge. That's probably
the single best way to get the word out in a positive way.

In any case, after I voted I got a little sticker that says "I voted -
touchscreen" with an American flag on it. Maybe for the election this
November, we should hand out stickers with the slogan "I think I voted
- touchscreen", and a flag with the 50 stars replaced by a BSOD.

Letter quality LCD's

I think this is going to be the year they go mainstream. They're
showing up in more and more devices. It's also
interesting that Tiger
Direct has the IBM T221 for four
grand, "while supplies last". It's possible, I think, that a
newer model is in the pipeline.

Logic update

I got a very gratifying response from my last post,
resulting in a very enlightening email correspondence with Michael
Norrish, Bob Solovay, and Norm Megill. I'll post it soon, for those
of you out there just dying to find out whether there really is a
closed form expression for HOL's epsilon in ZFC.