pyBlazon announced
It's been about a year and a half since Mark Shoulson and I started trying to make a program that could compile blazons into graphics. This is not a new concept — Robert Billard wrote a quite powerful blazonry program for Windows called BLAZONS! (which no longer seems to be supported, alas). As early as 1994, Daniel V. Klein suggested blazonry as a forerunner of graphic definition languages in his USENIX talk From Blazons to Postscript.
Finally, the blazonry compiler, which we have called pyBlazon, has gotten to a state where it is not directly embarrassing to show to people. Last Sunday, Mark posted an announcement to the sca_heralds LiveJournal community, with a link to the project's makeshift homepage and online demonstrator.
Currently we are hashing out which free licence we are going to release it under, and Mark is preparing to host the project on Google Code.
Some points of note:
- Blazonry as a formal jargon may at first glance seem completely rigid and well-defined, but in fact it is large and open-ended. None of us are artists, so a rule of thumb is: if it can be made with just a few SVG primitives, we have it; if you have to draw it in a vector drawing program, we don't. So don't expect the compiler to know what bears, reindeer or horses are. Also, there is no ISO or W3C of heraldry that tells you which charges you can or cannot use, and people invent their own freely. To make a drawing of a “winged sea centaur” (as in the arms of Stephen Coombs) without ever having seen one, you basically have to be a human or have super duper body-part exchange algorithms.
- Also because of impatience, we are using the somewhat underpowered PLY library for parsing (a yacc/lex clone for Python) rather than doing the right thing from the beginning and using something like ANTLR. This means that some perfectly-valid blazons will not work, and have to be reworded. More details under Known Issues on the project page.
- Some arms still look horrible, either because they are basically a special case, or because they are plain old bugs. An example of the former is ermine fretty gules; an example of the latter is azure within a bordure invected argent.
- The SVG is very hairy. Basically, we are wrapping stuff into many layers of
transforms rather than rewriting the SVG in memory, simply because that's easier and makes for rapid prototyping. The upshot of this is that not every program that claims to be able to display SVG can render the output of the blazonry compiler properly. Currently, only rsvg is guaranteed to work in all cases. Batik and Opera also does a favourable job. Mozilla Firefox? Forget it.
[Friday, Mar 07, 2008 @ 20:03] | [language] | # | G
