I have writ­ten my very own ed­i­tor with syn­tax high­light­ing to write these sketch­es. This is far less im­pres­sive than it might ap­pear on a first glance: wxWid­gets, and there­fore also wx­Python, pro­vide ac­cess to the Scin­til­la li­brary via the Styled­TextC­trl el­e­ment, and this el­e­ment can dis­play HTML source code and style the dif­fer­ent el­e­ments in dif­fer­ent col­ors. Scin­til­la pro­vides “lex­ers” for dif­fer­ent lan­guages, parsers which are able to de­ter­mine which frag­ments of a doc­u­ment are key­words, iden­ti­fiers, string lit­er­als, nu­mer­i­cal lit­er­als, op­er­a­tors, com­ments and so on, and to­kens from dif­fer­ent cat­e­gories can be styled dif­fer­ent­ly. So “writ­ing my own ed­i­tor” in fact just means “glu­ing to­geth­er some stan­dard pieces”. It looks like this:

I’m not com­ple­tely con­tent with the ap­pearan­ce of the pre­ce­ding sketch, and so I de­ci­ded to try to pret­ti­fy it a bit. I re­pla­ced all the equa­ti­ons ge­ne­ra­ted by mi­me­tex as GIF images with texts I pipe through Ma­th­Jax, so if you have Ja­va­script disa­bled, you’ll see all equa­ti­ons as \(\LaTeX\) plain­text. Fur­ther­mo­re, I re­pla­ced all the screen­caps I took from Open­Of­fice or Excel and re­pla­ced them with with pret­ty mat­plot­lib plots; and I also re-did all the pre­vious mat­plot­lib plots. And I tried to en­han­ce the lay­out of the page a bit, and added more stills from the se­ries. So this is my se­cond take, the con­tent re­mains un­ch­an­ged, but I at­temp­ted to make the ap­pearan­ce more fit­ting for a se­ries about cute girls.

This sketch is de­vot­ed to the pop­u­la­tion dy­nam­ics of the fic­tion­al world de­pict­ed by the Japanese an­i­mat­ed TV se­ries “Puel­la Magi Mado­ka Mag­i­ca”. As such, it is in­evitable going to re­veal at least one major plot point. So if you are plan­ning to watch this show, I sug­gest that you post­pone read­ing this sketch until you are done watch­ing it. You have been warned: there will be spoil­ers.

I hes­i­tat­ed up­dat­ing Fire­fox to ver­sion 4.0, since I feared it might break a lot of ex­ten­sions I use. Well, it cer­tain­ly broke my theme Orbit Clas­sic. But now that I made the tran­si­tion, I de­cid­ed that I won’t main­tain Orbit Clas­sic any longer. With Fire­fox 4.0, I’m happy with the de­fault theme – all the more since it’s pos­si­ble to cram all the chrome tight­ly to­geth­er, so there isn’t much left to style any­way. It’s the com­pact­ness of Google Chrome com­bined with the awe­some ex­ten­si­bil­i­ty and flex­i­bil­i­ty of Fire­fox.

In chap­ter 4 of “In­ter­fer­ences”, I’m using sev­er­al lay­ers stacked on top of each other with cu­mu­la­tive drop shad­ows. Of course I have writ­ten a Python ex­ten­sion for Inkscape to gen­er­ate such cas­cad­ing shad­ows au­to­mat­i­cal­ly.

Let’s start with a sim­ple ex­am­ple: five round­ed rect­an­gles stacked upon each other.

In the pre­vi­ous sketch, I pre­sent­ed an Inkscape ex­ten­sion which con­vert­ed texts to paths, re­plac­ing du­pli­cate paths with use el­e­ments. This ex­ten­sion did call Inkscape it­self, re­quir­ing a some­what du­bi­ous hack.

It is pos­si­ble to avoid this hack, al­though the al­ter­na­tive ver­sion (which I am going to present in this sketch) is slight­ly more round­about: the al­t­ner­na­tive ex­ten­sion needs to be called two times.

Using fancy fonts with SVG faces some pit­falls. One prob­lem is that font foundries are not fond of see­ing their font data ex­posed for ev­ery­one to fetch across the pond. Until re­cent­ly, using com­mer­cial fonts on the web was next to im­pos­si­ble, and the sup­port for fonts is still in its in­fan­cy, and usu­al­ly re­quires some model where fonts are pro­vid­ed in a heav­i­ly en­crypt­ed and pro­tect­ed way, in­com­pat­i­ble with SVG. It is hard to imag­ine any font foundry would allow their valu­able fonts to be pub­lished as font for­mats com­pat­i­ble with SVG.

It’s pos­si­ble to cir­cum­vent this prob­lem by stick­ing to free fonts. But we im­me­di­ate­ly run into the next prob­lem: lack­ing SVG font sup­port in many browsers.

An ob­vi­ous so­lu­tion is to re­place all tex­tu­al data with­in a SVG file with paths. If a user agent can dis­play SVG at all, it will be able to dis­play path data, so that’s a fall­back that will al­ways work (if SVG works at all).

Un­for­tu­nate­ly, we loose the tex­tu­al in­for­ma­tion. That’s bad for search­ing, it’s bad for in­dex­ing, it’s un­friend­ly to­wards dis­abled users, and it might cause prob­lems down the road if we want to mod­i­fy files later on. It’s there­fore ad­vis­able to du­pli­cate text el­e­ments and to put one copy into a hid­den layer, while the other copy is trans­formed into path data.

But there is an­oth­er draw­back: re­plac­ing text with paths in­creas­es the file size con­sid­er­ably. Part of this in­crease in size in un­avoid­able: after all, we are stor­ing glyphs as paths, and this glyph data in­evitably some­how must be trans­port­ed to the user, whether it is in the form of an aux­il­iary OTF file or some ad­di­tion­al paths in­creas­ing the size of the main SVG file.

But an­oth­er part of this in­crease in file size is per­fect­ly avoid­able. A font file con­tains the glyph def­i­ni­tion for the let­ter, say, LATIN SMALL LETTER E, just once. A text con­vert­ed to a group of paths may con­tain the cor­re­spond­ing data sev­er­al times, one copy for each oc­cur­rence of the let­ter “e”. Even if we ac­cept the ne­ces­si­ty of the first oc­cur­rence of this data, all sub­se­quent oc­cur­rences are su­per­flu­ous. We can sub­stan­tial­ly com­press our file if we re­place all later oc­cur­rences of this let­ter with ref­er­ences to the path def­i­ni­tion of the first oc­cur­rence, by re­plac­ing the sub­se­quent path el­e­ments with use el­e­ments; or, using the ter­mi­nol­o­gy of Inkscape: by re­plac­ing them with linked clones. I have writ­ten an Inkscape ex­ten­sions which does ex­act­ly this.

The ca­pa­bil­i­ties of Inkscape can be ex­tend­ed with user scripts, but in a rather pe­cu­liar way: un­like other pro­grams which allow user scripts, Inkscape doesn’t ex­pose an API to a script en­vi­ron­ment. In­stead, it pipes the con­tent of the cur­rent SVG file to any ar­bi­trary user pro­gram reg­is­tered with an INX file, and this pro­gram is free to do with said file what­ev­er it wants, after which it should spew the file back via std­out to Inkscape.

This means that an Inkscape ex­ten­sion has the most amount of free­dom imag­in­able in what it can do to the SVG file in ques­tion: it can do what­ev­er a Tur­ing ma­chine can do, and trans­form the input in ar­bi­trary and com­plete­ly out­landish ways. On the other hand, the ex­ten­sion can’t ac­cess any of the in­ter­nals of Inkscape and is com­plete­ly on its own.

Well, al­most. Inkscape at least pro­vides the ids of the cur­rent­ly se­lect­ed ob­jects as ad­di­tion­al input op­tions, and the file it­self con­tains some hints about the cur­rent state of Inkscape (for ex­am­ple, which layer is cur­rent­ly ac­tive). But an ex­ten­sion can’t use some of Inkscape’s ef­fects. An ex­ten­sion might call other ex­ten­sions, but oth­er­wise, all ef­fects and meth­ods and tricks and pro­ce­dures it wants to use, it has to pro­vide it­self.

Which is some­times kind of an­noy­ing, since Inkscape ships with a lot of use­ful tools an ex­ten­sion might want to uti­lize. For ex­am­ple, an ex­ten­sion might want to split a path into its com­po­nents as one step with­in a larg­er pro­ce­dure. Such a split­ting of a path into com­po­nents isn’t too com­pli­cat­ed: take the path data, scan for oc­cur­rences of "M" or "m", and split along them. But you also have to take into con­sid­er­a­tion that in the case of a lower case "m", the rel­a­tive co­or­di­nates of the first ver­tex must be re­placed with ab­so­lute co­or­di­nates, which means you have to scan the path data back­wards until you reach an ab­so­lute co­or­di­nate, and com­pute your cur­rent po­si­tion for­ward from there. Not ter­ri­bly hard to do, but an­noy­ing enough if you know that some­body else al­ready did it be­fore.

Or per­haps you want to trans­form a text into a path, as the ex­ten­sion does we’ll dis­cuss in the fol­low­ing entry. That re­quires read­ing the ap­pro­pri­ate font, trans­form­ing glyphs to paths, deal­ing with kern­ing and a lot of com­pli­cat­ed and ad­vanced stuff, and stuff some­body al­ready solved in a com­plete­ly sat­is­fac­to­ry man­ner, since Inkscape it­self al­ready has a com­mand to trans­form texts to paths. So it is de­sir­able if we some­how could call Inkscape com­mands from with­in an Inkscape ex­ten­sion.

I wrote a Python mod­ule which ex­tends the Effect class of the stan­dard inkex mod­ule in such a way that this is, in­deed, pos­si­ble.