13 Jul 2003 raph   » (Master)


Why has it been such a long time since I last wrote a diary entry? I'm not totally sure. I guess I've just been more inwardly focussed lately, especially on family issues (drop me an email if you're curious - I just don't want to write on the family's permanent Google record). But I've also been a bit of a hermit - I like it when there's

no email or phone calls.

Even so, I have stuff to write about.

Sleep apnea

I've been trying to build a home sleep study so I can determine which factors affect the seriousness (I'm especially interested in weight, even though my BMI is right in the middle of the curve). I'm about done, but it's taken more time and energy than I counted on.

Basically, the ingredients are:

  • A pulse oximeter (available from eBay for about $200-$300). I have the Ohmeda 3740, which I can recommend and seems to be very popular for sleep.

  • Strain gauge belts for measuring "respiratory effort". I have two of the Grass Telefactor 6010, at $60 each.

  • A LabJack and the EI-1040 instrumentation amplifier for getting the signals into the laptop.

Basically, you plug the stuff in to the LabJack. The Ohmeda has outputs in the right voltage range, just use 1/8" mono audio cords. The strain gauges need to be amplified - I use a gain of 1000 on the EI-1040. Since the impedance of this amplifier is so high, you'll need some resistors for the input bias current return path.

The Linux driver for the LabJack is still very alpha, so for the time being I'm just using the Windows stuff. All I need is to log the data, and the LJlogger makes a very easy-to-use ASCII file (suitable for gnuplot).

I'll probably make a Web page with a more detailed recipe and the results as I find them.

Font rendering

Really high quality text and font rendering is challenging. It's not just a question of there being a "right way" to follow; there seem to be many ways to improve font rendering. Also, what constitutes "good" text is highly subjective. I personally favor a high fidelity reproduction of print fonts, even with some loss of contrast, while others prefer their fonts highly hinted. If you're in the former camp, OS X pretty much nails it, and if you're in the latter camp, the RH desktop with Vera fonts and TT hinting enabled.

But the ultimate goal, of course, is to combine fine typography aesthetics with high contrast rendering. This is a harder problem when the text metrics have to match the source exactly (as is the case for PostScript and PDF viewing), but is still challenging even when they don't. My favorite so far is Adobe Acrobat 5, but it's still not perfect. The big problem is that spacing errors are typically in the half-pixel range, which is not really pretty (the repeated letters emphasize the spacing errors; it's not as easy to see in body text). Also, in this sample you can see that the 'm' lacks symmetry, which bothers me.

Other attempts, in my opinion, don't work as well. In particular, the screenshots I've seen of Longhorn suggest that it'll distort the stroke weights to integers, but still suffer some loss of contrast in the case of subpixel positioning. Of course, they've still got some time to improve it before they ship.

Longhorn may have an even more significant consequence for us: it promises to support very high resolution displays. So far, there's been a bit of a catch-22 situation. High resolution displays are available but expensive, so very few have been shipped, and almost no software supports them, so there isn't the motivation to figure out how to manufacture and sell them cheaply. But if Microsoft puts their weight behind them, it could easily break this cycle.

I haven't seen any of the technology involved, but I'll take a guess. Since high resolution displays are around 200dpi, it makes sense for non hires-aware apps that do bitmap drawing to just double the pixels. In most cases, text should be able to go at full res without any software changes - the requirements are rather similar to simple low-res antialiased text.

So this is what I think they'll do. The default graphics context will be set up to double all coordinates before drawing, and zoom bitmaps accordingly. Apps that expect to draw to a 96 dpi screen will look about the same as they do now. Then, there'll be a call to get a hi-res graphics context if available, with 1:1 pixel drawing, and correspondingly higher precision for positioning glyphs. It'll be important to take this path for the Web browser, the word processor, and graphics software, but for a lot of other stuff it won't be as important.

The consequences could be dramatic. For one, if Apple isn't working on something similar, they'll face a mass defection of graphic arts types to the MS platform - once high res displays are affordable and really work, people will not want to go back. It'll be like trying to sell a black-and-white only lineup when the rest of the world is moving to color.

Second, I'd expect high res displays to come down to commodity pricing. I'm not an expert on the economics of displays, but I'd expect that the actual cost of manufacturing a high res LCD isn't much higher than a low res. I think that's much less true for CRT's, but they're on their way out anyway.

If the Linux desktop folk have any real vision, they'll start working on support for high res displays now. A lot of what I'm talking about, with the 2x coords and bitmap zooming, could be done at the X level so that legacy apps would work without ridiculous tininess. Then, modern GUI toolkits could grab the higher resolution context and get crisp, accurately positioned text. I'm not holding my breath, though.

If high res displays become widespread, then the need for high-tech font hinting basically goes away, in much the same way that the need for fancy dithering algorithms went away when video cards went from 8 bits to 24. So, long term, I'm not sure it makes sense to invest a lot of work into hinting.

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!