For The Record

I may think that the OWS protestors are on shaky ground from a theoretical standpoint, but this morning's raids on various and sundry "Occupy" encampments are something else entirely. To paraphrase that guy: I may not agree with what they're saying, but they damn well have a right to say it. And the possibility that crackdowns were part of a coordinated effort is just frickin' scary.

An Experiment In HTML Typesetting, Part I

Observation: Typesetting in HTML is painful.

HTML is not TeX; it's cumbersome to do anything more than generate blocks of (relatively) uniform text. Those of you who read my martial arts blog are aware that I've been developing, in conjunction with another blogger by the name of Scav, notation for recording martial arts forms/techniques. One of our secondary goals has been to restrict the notation is so that it's capable of being rendered using HTML. That has, so far, been mostly successful; I've been able to typeset some fairly complicated material using HTML. That process, however, has been a labor of love... there's a lot of hand-tweaking necessary to make things look good. I, personally, would benefit from some sort of lightweight, meta-HTML framework which allowed me to focus more on transcription and less on abusing CSS until it cries "uncle". Additionally, there's a lot to be said for separating meaning from representation; it would be great if the same underlying source could be used to produce both bottom-to-top and left-to-right variants. Right now the two are tightly coupled; I take a .csv file and run it through a small script that does some simple substitution and outputs the result as an HTML table. Not fancy and, as I said, I usually have to do a lot of tweaking afterwards.

So... having made that observeration, where to now? The first thing I want to do is see if I can come up with a generic input format that allows me to produce transcriptions quickly without worrying so much about the nuts and bolts of how its going to be displayed in HTML.

Reviewing the material I've produced to date I find that it typically has the following structure:

1. Some introductory commentary
2. A list of blocks/kicks/strikes
3. A list of targets
4. One or more blocks consisting of the following:
   1. A heading
   2. Some commentary
   3. A notation block
   4. Some numbered notes.

What format to use to encapsulate the above? XML is a natural candidate, but recall that I want to be able to produce transcriptions quickly. XML is a pain the butt to type by hand and is also "chatty"; the ratio of markup to actual information can be pretty high relative to alternatives (such as my .csv files). Right now I'm leaning towards a bastard amalgan of XML and CSV; make use of XML for describing the gross structure, but keep the notation blocks in CSV.

There's also the question of simplifying the typesetting of the notation itself. I've a computer science background, so when I think about separating meaning from representation the first thing that comes to mind are abstract syntax trees. What I'm really looking for is a system that will take a concise, easily-typed input file and turn it into an AST which can then be fed to rendering engine which will produce the desired HTML. This, in turn, implies the existence of a parser and a well-defined, though perhaps simple, language for describing the desired notation.

So I'm going to go off into a corner now and see what I can come up with; updates as events warrant.

Ya Gotta Wonder What Intuit Was Thinking

Update: What precipitated this whole post was my failure to find any way to get a portfolio summary out of Quicken Essentials. After reading the article I linked to below I went and downloaded the trial of iBank, exported a QIF from Quicken 2007, and imported it into iBank. Not only did the import go smoothly but, imagine that, they have a canned report called "Portfolio Summary"! So now I'm going to give iBank a try; I suspect that I'll be asking for my money back from Inuit before too awful long.

---

I recently retired my 2003-vintage, PowerPC-based iMac for one of the sparkly, new, Intel-based ones. Which also meant upgrading various bits of software including, of necessity, Quicken. Big mistake...

Intuit's latest offering for Mac, Quicken Essentials, is a braindead piece of crap. I thought I could deal with the lack of investment-tracking support, but they've gone and removed a bunch of other, subtle stuff as well. The product as it currently stands is only slightly better than a toy.

Now, here's the puzzling thing: It's not like Intuit isn't capable of producing good personal finance software for OS X; I've been happily using Quickbooks 2007 for a number of years now. They've just decided, for no discernable reason, to limit Mac users to this dumbed-down version of their software. If you want decent features they suggest that you should buy the Windows version instead. Hey, Intuit... I'm not going to switch platforms just for your lousy software. If it gets unbearable I'll just switch to iBank instead of sending you any more of my money.