Out of Cheese

John Gruber’s discussion of the anti-aliasing changes in Panther reminded me of a question I’ve been wondering about for years.

There are two very distinct ways of writing a lowercase ‘a’. There’s the version you see in most fonts with the curly thingy on top (sorry for the terminology; I’m definitely not a typographer) and the one that’s basically just circular. I’ve often wondered why we have two very different glyphs in common usage for the same letter. It just doesn’t seem like the typical path for language evolution.

According to about.com, the variant with the curly thing on top is an “upright” glyph, while the circular one is an italic glyph (even though it’s used in some non-italic typefaces). I can’t find any corroboration of that, though. And even if that’s correct, I wonder why we maintain the two. The only explanation I can think of is that the upright version looks better in type, but the italic version is far easier to write. As writing becomes less common and more people type everything, will the italic version slowly disappear? Do people in some countries prefer one variant over the other? And how did the two distinct glyphs evolve in the first place? Finally, do other scripts have similar examples of a letter that can appear as two (or more) different glyphs with exactly the same meaning in every context?

A while back, Buzz posted some beautiful pictures of Northern California. I hadn’t known him to be particularly into photography, so I asked him what he’d used to take such terrific pictures. He’s a bit more into photography than I am — he knows how to use buttons other than the shutter button, for example — but the camera he was using was both affordable and great for both beginners and somewhat more advanced users. In a fit of insanity, I decided to copy him and bought the model he was using, a Canon PowerShot A70. (I’ll admit that I didn’t buy it entirely on his recommendation alone; I also read the glowing Digital Photography Review review of it first. They really liked it, too.)

I’m not a camera person. I think I own a regular camera; I’m sure it’s around here somewhere. I never liked it, though, because I’d always forget to buy film, the batteries would be dead, developing the pictures took a lot of effort, and they’d invariably look awful in the end. I’d never bought a digital camera because I couldn’t figure out what random set of features would make sense or what price point would be appropriate. The PowerShot A70 review helped convince me that its price point and features were about as close to ideal as I could expect.

Apparently I’m also not much of a gadget person, since I let the PowerShot sit unopened for about a month before tonight. Part of that was because I hadn’t ordered rechargeable batteries and a carrying case when I got it. I still need to get those somehow. But part of it was also that I didn’t really have anything to take pictures of. (No, I wasn’t about to take a picture of my team’s G5 showing up.) I’ll have a variety of things to take pictures of in the next two months, though, so I finally got around to opening the box tonight.

I’ve only read the first five pages or so of the manual, but I’m already very impressed. My test pictures look focused and sharp. If this little silvery thing can make my photographs look good without any contribution of talent on my part, well, I’m just amazed. I’m going to have to try it for real sometime soon. I doubt I’ll get as into photography as Dave, but at least I’ll start having pictures to remember things by for the first time in years.

(On a side note, the Quick Start Guide said in bold type in about six different places “Do not connect the camera to the computer before the software is installed.” Since the guide didn’t mention iPhoto anywhere other than to insist that you quit it if it’s running, I figured they’d want me to use their software instead of iPhoto. Forget that. I plugged the camera into my computer without installing the software — horrors — and not only did the camera not start emitting sparks, iPhoto launched and let me import my pictures. Yay for non-exploding iPhoto-compatible cameras. I bet Canon’s software doesn’t let me build screen savers or publish to my .Mac account….)

After a weekend of hacking, I’ve updated Rotor to run on Panther. Diffs against TOT at sscli.net are here. To patch your Rotor install, cd into the sharedsourcecli directory and run patch -p0 < rotor_panther_diffs.txt.

This has not undergone extensive testing. In other words, it passes the basic tests (perl rrun.pl -b) on one Panther system and one Jaguar system. I haven't tried it on FreeBSD or Windows, since I don't have any of those systems around. It's not perfect, either. Here are the known issues:

• The purchaseorder sample does not run. It appears that XSD translation (is that the right word?) is telling csc to include system libraries. On Panther, that's resulting in duplicate definitions for all system objects; on Jaguar, it isn't. That might just be an issue with my Panther system's configuration. I'm not sure.
• A few PAL tests (perl pvtrun.pl) fail. Quite a few of the networking tests crash. I haven't investigated that at all. Others fail due to some interesting behavior in Panther's poll(3) implementation. Perhaps Rotor should continue to use its internal poll implementation (which is actually Greg Parker's fakepoll) on Panther.
• Precompiled headers are only enabled when building with GCC 3.1 on Jaguar. I haven't found the time to figure out how to merge the concepts of GCC 3.3's PCH with the Rotor build system.

In case you're curious, here's a summary of what I changed:

• Included /usr/lib/crt2.o on Darwin systems when it's present.
• Rearchitected env.{c}sh to use gcc -dumpversion instead of its earlier extremely hacky method of checking GCC's version. (I wrote the original version, so I can hopefully call it extremely hacky without offending anyone.) This let me introduce a mechanism by which Rotor can use GCC-version-specific compiler warnings, which I needed to get -Wno-invalid-offsetof to be used when building with GCC 3.3.
• Added the concept of a post-preprocessing filter for C# files that get sent through the C++ preprocessor. This let me remove the #pragma GCC set_debug_pwd line that Apple's GCC 3.3 adds at the start of every preprocessed file. Shockingly, that line really confuses the C# compiler.
• Improved the differentiation between C and C++ compiler warnings in the build system. GCC 3.3 warns when you use C++-specific warnings when compiling C code, so this had to be fixed to keep Rotor warning-free.
• Removed some checks in the FJIT and a few other spots that could never be triggered due to the limited size of various data types.
• Added a definition of POLLRDNORM in the PAL because Panther's poll.h doesn't define it.
• Fixed a few dozen compiler warnings in the PAL test suite.

Enjoy! And if you have a chance to test it on FreeBSD or Windows, let me know how it goes. I don't want to suggest that it be checked in at sscli.net until I know that it doesn't break either of those builds.

(11/5 Update: Fixed a missing 'esac' statement in env.sh. Thanks, George!)