The default font for the console on Windows is some basic raster font without much support for more exotic Unicode code points. Which kind of sucks for command line programs, if they are dealing with Unicode data and foreign languages. It is possible to change the console font to “Lucida Console”, which supports a lot more code points, or, if it is installed, to “Consolas”, which supports even more code points, by clicking on the icon in the upper left corner of the console and choosing to change the properties. But we can’t seriously expect the user of a script to go through the trouble of changing the font of the console manually.
Is it possible to change the font of the console inside a Python script running on said console? Usually, the most natural thing to do would be to look at the module win32console, but unfortunately, it doesn’t implement the needed call to SetCurrentConsoleFontEx. Too bad, but basically just a mere inconvenience, since we can always do stuff like this using the ctypes module (with the additional bonus that since Python 2.5, ctypes is part of the Standard Library, so we don’t have to rely on the availability of an external library). The following code shows how it is done:
Once upon a time, ornaments, dingbats, flourishes, symbols and other embellishments were put in special pi fonts, with the symbols mapped to ordinary letters. For example, in Zapfino Extra Ornaments, you could type a capital letter X and get a nice flourish, which had nothing at all to do with the letter X.
With the advent of Open Type and Unicode, some symbols where put in the Private Use Area of Unicode. For example, Adobe Garamond Pro has three flourishes at the code points U+E09D, U+E09E and U+E09F. That’s a lot betters, since it avoids semantic clashes (don’t confuse search engines and other bots by typing an “X” if you don’t mean “X”), and it also degrades more gracefully if the intended font isn’t available (in which a “can’t print this” symbol is a better choice than the rather misleading letter “X”).
Still, it is far from perfect, since it turns the Private Use Area into some kind of font-vendor-specific swamp devoid of any interoperability and meaning. After all, any information about what U+E09D means is lost, since it could be an ornament, a symbol (with a rather specific meaning), some rare ligature or some other typographical feature like a subscript or a small capital. So an even better approach would be to interpret ornaments as some kind of stylistic variation of a default ornament, like the bullet point U+2022. A search engine or any other kind of bot would see the letter U+2022 and would know (more or less) what it is supposed to mean, and the different ornaments could be accessed as an Open Type feature.
With a framework like Three.js, it is pretty easy to display the faces of simple polyhedrons using WebGL. But a polyhedron, considered less as a physical and more as a topological object, consists not only of its faces. Instead often its vertices and edges are equaly interesting, and it would be nice to have an easy way to display them, perhaps assigning them different colors, to distinguish different kinds of vertices or different kinds of edges. Within the program Stella, vertices can be displayed as small balls and edges as thin tubes, and I wrote a function to be used in conjunction with Three.js which makes it a bit easier to construct similar graphical objects, following a similar visual style, within WebGL.
In the following examples, I’ll assume that we have set up all the usual Three.js stuff with renderers and virtual cameras and mouse controls and lights and that we have defined a Scene-object. Furthermore, I’ll assume that we imported my helper file JAN3D.js which contains the function JAN3D.stella() (among other stuff; I also included JAN3D.TinyTrackballControls). I’ll show, using four examples, how to use this function.
The WebGL-framework Three.js I mentioned in the previous entry has a nice variation of its renderer which renders scenes as red-cyan anaglyphs. So using Three.js, you basically get anaglyphs for free without any additional work on your part (an anaglyph is an image where you need glasses with red and cyan glasses to get a stereoscopic, three-dimensional view).
I tried to construct a little scene using this ability, but what I disliked was that the scene, as an anaglyph, was too distant and appeared to be positioned behind the screen. I had a scene with several concentric circles of spheres, and I wanted them to appear to intersect the plane of the screen, with the center of the circles coinciding with the screen. And since I found no way of doing it, I plugged two new parameters into AnaglyphWebGLRenderer, called the new version ProtrudingAnaglyphWebGLRenderer and put it in a file ProtrudingAnaglyphWebGLRenderer.js.
WebGL is a technology that allows web browsers to display graphics using the fast routines of the graphics card, and Three.js is a framework which makes working with WebGL a lot easier. Among many other things, Three.js provides “controls”, Javascript objects which handle the interaction between mouse events and the WebGL canvas. One such control is TrackballControls. It maps mouse dragging gestures on an imaginary trackball and rotates the scene accordingly. I have used it to make models of polyhedra rotatable for my viewers: Stubsmütter und Tribanocci (a link to the German section of this blog).
Per default, the imaginary Trackball fills the entire available browser window. This is less than ideal if the actual WebGL canvas is just a tiny illustration within a larger text:
I have written my very own editor with syntax highlighting to write these sketches. This is far less impressive than it might appear on a first glance: wxWidgets, and therefore also wxPython, provide access to the Scintilla library via the StyledTextCtrl element, and this element can display HTML source code and style the different elements in different colors. Scintilla provides “lexers” for different languages, parsers which are able to determine which fragments of a document are keywords, identifiers, string literals, numerical literals, operators, comments and so on, and tokens from different categories can be styled differently. So “writing my own editor” in fact just means “gluing together some standard pieces”. It looks like this:
I’m not completely content with the appearance of the preceding sketch, and so I decided to try to prettify it a bit. I replaced all the equations generated by mimetex as GIF images with texts I pipe through MathJax, so if you have Javascript disabled, you’ll see all equations as \(\LaTeX\) plaintext. Furthermore, I replaced all the screencaps I took from OpenOffice or Excel and replaced them with with pretty matplotlib plots; and I also re-did all the previous matplotlib plots. And I tried to enhance the layout of the page a bit, and added more stills from the series. So this is my second take, the content remains unchanged, but I attempted to make the appearance more fitting for a series about cute girls.
This sketch is devoted to the population dynamics of the fictional world depicted by the Japanese animated TV series “Puella Magi Madoka Magica”. As such, it is inevitable going to reveal at least one major plot point. So if you are planning to watch this show, I suggest that you postpone reading this sketch until you are done watching it. You have been warned: there will be spoilers.
I hesitated updating Firefox to version 4.0, since I feared it might break a lot of extensions I use. Well, it certainly broke my theme Orbit Classic. But now that I made the transition, I decided that I won’t maintain Orbit Classic any longer. With Firefox 4.0, I’m happy with the default theme – all the more since it’s possible to cram all the chrome tightly together, so there isn’t much left to style anyway. It’s the compactness of Google Chrome combined with the awesome extensibility and flexibility of Firefox.
In chapter 4 of “Interferences”, I’m using several layers stacked on top of each other with cumulative drop shadows. Of course I have written a Python extension for Inkscape to generate such cascading shadows automatically.
Let’s start with a simple example: five rounded rectangles stacked upon each other.
In the previous sketch, I presented an Inkscape extension which converted texts to paths, replacing duplicate paths with use elements. This extension did call Inkscape itself, requiring a somewhat dubious hack.
It is possible to avoid this hack, although the alternative version (which I am going to present in this sketch) is slightly more roundabout: the altnernative extension needs to be called two times.
Using fancy fonts with SVG faces some pitfalls. One problem is that font foundries are not fond of seeing their font data exposed for everyone to fetch across the pond. Until recently, using commercial fonts on the web was next to impossible, and the support for fonts is still in its infancy, and usually requires some model where fonts are provided in a heavily encrypted and protected way, incompatible with SVG. It is hard to imagine any font foundry would allow their valuable fonts to be published as font formats compatible with SVG.
It’s possible to circumvent this problem by sticking to free fonts. But we immediately run into the next problem: lacking SVG font support in many browsers.
An obvious solution is to replace all textual data within a SVG file with paths. If a user agent can display SVG at all, it will be able to display path data, so that’s a fallback that will always work (if SVG works at all).
Unfortunately, we loose the textual information. That’s bad for searching, it’s bad for indexing, it’s unfriendly towards disabled users, and it might cause problems down the road if we want to modify files later on. It’s therefore advisable to duplicate text elements and to put one copy into a hidden layer, while the other copy is transformed into path data.
But there is another drawback: replacing text with paths increases the file size considerably. Part of this increase in size in unavoidable: after all, we are storing glyphs as paths, and this glyph data inevitably somehow must be transported to the user, whether it is in the form of an auxiliary OTF file or some additional paths increasing the size of the main SVG file.
But another part of this increase in file size is perfectly avoidable. A font file contains the glyph definition for the letter, say, LATIN SMALL LETTER E, just once. A text converted to a group of paths may contain the corresponding data several times, one copy for each occurrence of the letter “e”. Even if we accept the necessity of the first occurrence of this data, all subsequent occurrences are superfluous. We can substantially compress our file if we replace all later occurrences of this letter with references to the path definition of the first occurrence, by replacing the subsequent path elements with use elements; or, using the terminology of Inkscape: by replacing them with linked clones. I have written an Inkscape extensions which does exactly this.
The capabilities of Inkscape can be extended with user scripts, but in a rather peculiar way: unlike other programs which allow user scripts, Inkscape doesn’t expose an API to a script environment. Instead, it pipes the content of the current SVG file to any arbitrary user program registered with an INX file, and this program is free to do with said file whatever it wants, after which it should spew the file back via stdout to Inkscape.
This means that an Inkscape extension has the most amount of freedom imaginable in what it can do to the SVG file in question: it can do whatever a Turing machine can do, and transform the input in arbitrary and completely outlandish ways. On the other hand, the extension can’t access any of the internals of Inkscape and is completely on its own.
Well, almost. Inkscape at least provides the ids of the currently selected objects as additional input options, and the file itself contains some hints about the current state of Inkscape (for example, which layer is currently active). But an extension can’t use some of Inkscape’s effects. An extension might call other extensions, but otherwise, all effects and methods and tricks and procedures it wants to use, it has to provide itself.
Which is sometimes kind of annoying, since Inkscape ships with a lot of useful tools an extension might want to utilize. For example, an extension might want to split a path into its components as one step within a larger procedure. Such a splitting of a path into components isn’t too complicated: take the path data, scan for occurrences of "M" or "m", and split along them. But you also have to take into consideration that in the case of a lower case "m", the relative coordinates of the first vertex must be replaced with absolute coordinates, which means you have to scan the path data backwards until you reach an absolute coordinate, and compute your current position forward from there. Not terribly hard to do, but annoying enough if you know that somebody else already did it before.
Or perhaps you want to transform a text into a path, as the extension does we’ll discuss in the following entry. That requires reading the appropriate font, transforming glyphs to paths, dealing with kerning and a lot of complicated and advanced stuff, and stuff somebody already solved in a completely satisfactory manner, since Inkscape itself already has a command to transform texts to paths. So it is desirable if we somehow could call Inkscape commands from within an Inkscape extension.
I wrote a Python module which extends the Effect class of the standard inkex module in such a way that this is, indeed, possible.
Needing a cursor as a CUR file (since that’s the only format that works cross browser), I opened my cursor PNG file in The Gimp and tried to save it with a CUR extension, only for The Gimp to tell me that it doesn’t know that extension – which came as a nasty surprise to me, since The Gimp has no problem saving files in the ICO format. As it turns out, IrfanView, while being able to display CUR files, can’t save them either. And ImageMagick, while understanding this format, has no option to define a hotspot for the cursor (the hotspot is the one pixel within the cursor that defines where, exactly, you are when pointing with the cursor).
My next idea was to look on the Wikipedia page for the CUR format to see whether there are some open source (or at least free) editors listed. And there I stumbled upon the first good news of my quest: apparently, the ICO format and the CUR format (at least in their classical versions) are extremely similar. Within the main header of the file, I just have to change a single Byte to switch formats, and within an image table, there are two Bytes which either store some ICO-relevant information or the location of the hotspot. And that’s it: if the ICO file contains just a single image, there are but three Bytes at fixed locations I have to change.
So I saved my PNG as an ICO with The Gimp and wrote a little Python script to convert this file to a CUR file. My initial script was only three lines long (read the bytes into memory, change three of them, write them back to disk), but I added a bit of the usual command line options boilerplate plus error handling, and the result is the following:
For page 52 of my Interferences Comic, I wanted to use a Penrose tiling, namely, the P3 version of the Penrose tiling. A quick search on the web for Penrose tilings as SVG files unearthed a file that used an L-system to draw a P3 Penrose tiling, but that was not what I wanted: not only did I want a finished tiling, I also wanted the tiles to have two colors: one color for the “fat” rhombs and one color for the “thin” rhombs. So I wrote my own code in Python. Here is what the result looks like: