Same thing, this time from the Powerbook.
Here I am fiddling with another way to post to the blog. This time, it’s a Dashboard widget.
Or you’ll find out why it’s called Firewire.
That’s the chip inside a former Firewire hub.
That’s a closeup of the destroyed pin. These images were taken with the QX5 toy microscope.
You’re lucky the web doesn’t have smell-o-vision yet.
I may need to develop a program that generates nice-looking printed output. Specifically, exam booklets from a database of existing multiple-choice questions.
Ideally, the resulting program:
- runs on Windows, Mac OS X, and Linux, at a minimum
- can be distributed at zero cost, under an open-source license
- is self-contained and doesn’t require any unusual setup to run
- is relatively idiot-proof for the operator
- doesn’t require any expensive development tools to create
- isn’t too obscure for future developers to deal with
- works smoothly with the native printing scheme on each platform
And, of course, it should be EASY to create, because this is a volunteer effort and I’m lazy.
I need control over page breaks, so I can avoid page breaks in the middle of an exam question. I can see two ways to approach that. The easiest thing would be if the procedural code just generated some sort of markup language and passed the marked-up exam to an off-the-shelf formatter. The markup language would have to be rich enough to include the notion of a region that excludes page breaks. The alternative would be to have sufficient integration between the procedural code and the printing system to permit the code to ask about the printed height of a chunk of text. It could then force a page break where needed.
In some cases I also need to include a small graphic with the question.
The problem is almost solved by generating LaTeX code. That would certainly be powerful enough to handle formatting the page exactly as desired. Unfortunately, LaTeX printing is not natively supported on any of the target platforms, and the existing LaTeX packages are somewhat unwieldy. I suspect it would be a lot of work to hide a LaTeX implementation inside my program. A LaTeX-based solution would be great for savvy users, but it wouldn’t be nearly idiot-proof enough for the target audience.
HTML is better supported, but isn’t quite powerful enough. To capture the needed page headers and footers, I’d need CSS3’s Paged Media Module, and these features are not widely supported. Sigh.
It would almost be good enough to format plain text as if for a TTY. I could get all the control I needed by using a fixed-pitch font and formatting for 80 columns and 60 lines (which usually fits on a letter-sized page). Two problems: there would be no obvious way to include the graphics, and the results would be unavoidably hideous. Good enough for 1985, but not good enough for 2006.
If I could output RTF or PDF, that would be close to a solution. However, either of these languages would be a huge pain in the neck to generate, and the user would have to use a separate application to print the resulting file.
On any single platform, it would be easy enough, if tedious, to code for the native page layout system. But these systems are platform-specific. The truly mandatory platform is, of course, Windows (heavy sigh), and I don’t want to code for Windows only.
What to do?
Ethan had me set up WordPress for him to use on his band blog, and it was so easy and nice that I decided to switch my own blog to WordPress too.
In the man bites dog department, I had a case where Windows 2000 did a better job than Mac OS X. A volume on an external Firewire hard disk had become corrupted. OS X couldn’t even see the other volumes on the drive, much less fix the problem. What’s worse, it pretended to see the broken volume, but accessing files on that volume crashed the program — even when the program was the Finder. Bad news. I bought a third-party disk repair program (DiskWarrior 3.02) and it couldn’t see the drive at all. But when I connected the same drive to a Windows 2000 machine, Windows noticed it was broken on boot, and automatically repaired it before booting up. Score one for Windows.
Of course, this was only possible because the drive had originally been formatted in such a way that both Windows and Mac OS X could use it. That meant partitioning the drive into four FAT32 volumes, since smallish FAT32 volumes are the only reasonably large disk format shared by the two systems. And FAT32 is a Windows native format.