Robert Leslie is upset because Vorbis doesn't have a published spec yet.
He definitely has a point. Vorbis needs a spec. But his attitude (echoed by a number of people posting comments) is troublesome to an extreme. Monty and crew have made a tremendous gift to the world by doing Vorbis. This guy seems to believe that somehow obligates xiph.org to hand him a polished spec on a silver platter.
The real problem is that writing specs takes time and energy. For patented technologies, there's plenty of financial incentive for corporations to fund that work. For work done as a pure public good, the incentive disappears.
The xiph people are doing their work as a labor of love. They deserve our moral support back. Robert Leslie should take an active role in the process of writing a Vorbis spec, on an unpaid volunteer basis. If he does, he will be participating in free software the way it is meant to be. If not, he's just whining.
David McCusker's note on dict btrees is entertaining reading, as always. As he suggests, it's not directly relevant to my Fitz needs. But I appreciate him writing it anyway, largely because I'm still fairly ignorant when it comes to known database practice.
The idea of unique, stable node id's is interesting. If the tree is stored on a disk, then you maintain the mapping from id's to file offsets as an additional invariant, for example by using the node id as a btree key to the actual node contents. The big advantage is that clients don't have to worry about a node id ever changing. Also, letting go of a node reference doesn't have to be a significant event. Thus, implementing DOM-compatible semantics is easier.
I don't think I'll use this idea for Fitz, though. In most databases, you're generally willing to make the server a lot more complex in order to make life easier for clients. I'm not dealing with any such asymmetry. Maybe there will be a little more work to keep the keys for the partially rendered fragment cache updated, but it doesn't scare me too much. The Fitz client interface will be subject to reference counting discipline, so I can easily keep track of all "active" node references from the client.
But of course none of this is set in stone yet, and I could easily change my mind. The part that's least well thought through is the mutation event propagation. Anything that makes that easier counts as a compelling argument.
Dave Winer posted a screenshot (from Tim Bray) of Chimera, a Web browser for Mac OS X that uses the native Quartz fonts.
There are few notable things about the font rendering. Obviously, the fonts are antialiased. Less well known is the fact that Quartz font rendering tends to be completely unhinted. This screenshot also demonstrates a fanatical degree of subpixel precision. Obviously, subpixel precision is important for quality, but I'm not convinced that taking it to this extreme is a worthwhile tradeoff. My experiments show that 1/4 pixel horizontal positioning is indistinguishable from "perfect" precision unless you're looking reallyhard. Quantizing to quarter pixels certainly makes glyph caching more effective. So that's almost certainly what I'm going to do for Ghostscript.
I've looked at OS X font rendering on several monitors. The 15" CRT in Alan's iMac is acceptable but far from great. I run it in 1024x768, but the default is 800x600. One of the odd things about CRT's is that cranking up the resolution actually decreases contrast if you don't scale the input signal (and most people don't). The 14" 1024x768 LCD on this ThinkPad 600 is also ok, but not great. Rendering looks a little globby and uneven.
However, on my 15" 1600x1200 ThinkPad A22p, this screenshot looks really, really good. Running OS X on that hardware would be very compelling. Too bad you can't buy an Apple with a screen that good.
Part of the reason the screenshot looks so good is the choice of font - Lucida Grande is very robust for low-res antialiased rendering. In my experience, most fonts in the general ballpark of Frutiger will have this property. I chose antialiased Frutiger for my first GUI about 15 years ago. Hopefully, I'll be able to use it for my main desktop (laptop?) reasonably soon.
Considerable progress on Chapter 7 (the stamp trading network design). Update: the latest thesis snapshot contains a reasonably fleshed-out design for the stamp trading network; the chapter is now 9 pages. Not much in the way of analysis yet, though.
I also found out that the easiest way to get the Bluesky TeX fonts is to use pdflatex instead of dvips. The latter uses bitmap fonts, which are a lose. The main hitch is that pdflatex can't handle included eps files. However, it handles included pdf's just fine. Fortunately, epstopdf (which is part of the tetex-bin package on debian, and is a wrapper around Ghostscript) converted my eps's without difficulty.
So it looks like I'll be abandoning PostScript, and going straight to PDF. It's amusing that it's taken me until now to figure this out.