September 2, 2014
Fonts are great. Seriously. They occupy precious real-estate on that narrow overlap between the magistera of Art and Geekdom. Most fonts are defined as closed outlines, the interior of which is what you see. It’s this interior which gets assigned different pixel values on screens or which gets filled with ink on paper. By and large this works really well. The outline approach gives font designers full control over every single geometric aspect of their creations, thus making it possible to design fonts that are a pleasure to read.
But not all text is meant for leisurely consumption, quite often text is engraved or printed onto objects merely as an identifier; ‘Part #576′, ‘Assembly A2′, ‘This side up’. Especially with the advent of computational/algorithmic design and programmable manufacturing, it’s not uncommon to have an assembly featuring hundreds or even thousands of slightly different shapes, which have to be screwed together in the right order. In this case you probably want to include some sort of identifier on each part, and you’ll want to add them without the intervention of a human being who will undoubtedly c*ck it up. Regular fonts that were designed to define the outlines of symbols are not ideal if you’re using a milling machine or a laser cutter to engrave them.
The total length of all symbol outlines is nearly 590 units. Thus the ratio of horizontal text length to text outline length is almost 1:6. Not only is a font like Times New Roman difficult to read when rendered as outlines instead of fills, it also takes a long time to steer the laser or milling bit over all the curves.
There do of course exist single line fonts that describe their geometry in terms of central splines instead of outlines. A quick Google image search yields a large number of potentially halfway decent fonts.
So why don’t we just install one or more of these and select them as the font of choice when generating tags for automated manufacturing? Well, the answer of course is that we do, because it is the single best option available at the moment. But this solutions suffers from and even causes new problems. First of all, fonts were not meant to be single lines, and installing such fonts as system resources may confuse (and sometimes even crash) other programs that attempt to interpret them as outline fonts. Since single-line fonts have a very narrow purpose, it seems like overkill to install them at the OS level. Secondly these fonts often lack characters such as Æ, Ñ, ð, Þ and ß, which may be non-standard in English but are nevertheless commonplace in Iceland, Germany, Turkey, Greece, Russia, France, Estonia, Denmark, Albania, Hungary, Romania, Spain, … enfin, you get the point. Lastly, this geometry is still stored inside TrueType or OpenType font formats, which makes them hard to get at. It’s difficult for programmers to access the clean geometry without referencing 3rd party dlls, and it’s difficult for users to modify or extend a font. First you need to find a font editor that is affordable and modern enough. Then you need to get accustomed to a workflow which can most likely be picked on a scale somewhere between arcane and atrocious.
So in this light I’d like to propose an alternative. I’m not a professional typographer so I may well be underestimating the difficulty of the task ahead, but on the other hand all the worlds professional typographers haven’t managed to solve my problems after trying really hard for 50 years so I’m not convinced we should be listening to them. Instead of making yet another single line font, or writing some software which is really good at interpreting existing single-line font definitions, let us take a step back and re-evaluate what sort of solution would actually solve the problem.
We need to:
- etch, burn, mill or engrave small amounts of symbols onto a wide range of materials which come in a wide range of shapes,
- automatically generate and place these symbols using algorithms.
We’d like to:
- have a good grasp on the geometry of the symbols,
- be able to modify, extend or replace the pool of symbols ourselves, using graphics software we know well,
- not spend too much time etching the symbols, time is money.
We don’t care about:
- performance much. We’re not typesetting books here, just putting a few scratches on a piece of wood.
- Pleasingness to the eye. Fine-tuned kerning, ligatures, good italic and bold styles are not sought after properties.
It is reasonably easy to use Rhino (or any other drafting software you may be familiar with) to design a single line font. The plethora of drawing tools Rhino provides (snaps, accurate transformations, measuring tools, etc) make the design portion of the problem very tractable. But where to go from here? How does one convert hand-drawn curves into a usable font? I spend the last two days writing a small plugin for Rhino which consumes curves and points (more on points later) and generates very easy to access font data from them. Instead of putting the entire font into a single file, I decided to store each character in its own textfile:
The name of the folder which contains them all equals the font name, and each filename represents the unicode identifier of the character in question. Hashes can be used for comments and in the example above the first two lines are auto-generated comments. The body of the file contains one Codepoint line which identifies the file content. It should be the same as the file name. The geometry of the symbol is a collection of lines, circles and arcs (no bezier/nurbs curves allowed yet), each represented by a sequence of numbers, [center.x, center.y, radius] for circles, [start.x, start.y, end.x, end.y] for lines and [start.x, start.y, end.x, end.y, tangent.x, tangent.y] for arcs.
To ease the process of writing these files, the plugin I’m working on overlays a bunch of unicode pages onto the Rhino model space, so all you have to do is make sure your curves are inside the correct square:
Any lines, arcs, circles and points found inside the appropriate square will automatically be combined into a single symbol file. Each symbol cell shows common font metrics (adjustable using commands) as well as a character preview and the unicode codepoint. Since the unicode space is huge, I also draw a small grid inside each cell as the Rhino grid tends to peter out pretty quick once you’re away from the origin:
The above image shows not just the symbol cells, but also the font preview. After exporting the Rhino curves to a collection of *.char files, those files can be read back in and displayed in the correct cells. This makes it easy to visually check the correctness of the symbol files. Different types of symbol fragments are drawn in different colours (lines in magenta, arcs in red, circles in orange and points in teal).
Incidentally this font definition does not (yet) allow for customized kerning offsets, so the plan is to write an automatic kerning engine for the font interpreter. This work hasn’t been done yet but since I’m not aiming to write the worlds best kerning algorithm it shouldn’t be too difficult. The aforementioned point geometry which can be part of symbol files is never included as part of the visible font, but it allows the designer to increase the ‘size’ of the symbol visible to the kerning engine.
This project is only two days old at this point in time and there’s a lot of work left to do, most notably combining the symbols to make actual text. You can see a YouTube video of what’s working so far here:
August 22, 2014
The 16th International Conference on Geometry and Graphics has come and gone. I had a lot of fun, it was certainly very different from the usual software gigs I attend. This was a congregation of mathematicians and educators from all over the world (though mostly Central and Eastern Europe and the Far East) where most attendees were also presenting a paper or poster. The conferences I usually attend have at least a 1:20 ratio of speakers to audience. That hierarchy was entirely absent at ICGG, which was probably at least in part responsible for extreme levels of conviviality. At the conference dinner a lot of national groups sang songs from the homeland, and we even had the pleasure of hearing the Russian and Ukrainian delegates perform Moscow Nights together.
As promised and agreed with the conference organisers, I’m now making my paper available for download here. The paper is much more technical than the plenary lecture, dealing with the mathematical and algorithmic characteristics of generic solvers and fitness landscapes. During the talk I focused mostly on the graphical aspect of landscapes and how specific problem definitions result in specific landscape geometries/topologies. The Prezi for the lecture is of course also available, as are the files I used for the live demonstrations.
February 17, 2014
I’ve written a paper for the ICGG2014 conference to go with my talk. It mostly talks about the theoretical side of things, whereas the talk is going to focus on the pragmatic. In case they won’t accept it I’ll post it here soon, but if they do then it will be available online sometime after the conference.
Over the past few years I’ve grown increasingly tired of slick computer generated graphics. They all too often fail to draw attention to salient details and convey meaning. It’s rare these days that I get to make large illustrations, most of my graphic work is for icons, so I do try and savour it when I get the chance. I’ve put the 10 images I drew for this publication below the fold (with LaTeX overlays and captions).
February 6, 2014
Donald Knuth is one of the people who got a Grasshopper banner animation (january 10th), but until last week I’d never seriously looked into(La)TeX, probably his most famous contribution to humanity. I’ve been invited to give a lecture at ICGG2014 come August and the abstracts and papers are to be submitted in either tex or doc format. Since I don’t own and can’t stand Word® and pretty much every other word processing software I’ve ever seen*, it seemed like a good opportunity to dive into TeX. It’s a curious mixture of pure awesomeness and horrific muck. One the one hand it’s extremely liberating to be able to program a document rather than write one. It seems that no matter what you want to do, there’s always a way to get there. I’m also very pleased about being able to write in pure text and compiling the final document, as opposed to trying to tell a GUI what it is I want and never quite knowing what monstrously nested makeup and layout tags are silently ganging up on me in the background.
But the implementations of TeX seem to suffer badly from softwareforprogrammersitis. TexWorks (which comes installed with MikTex for Windows) was clearly made by someone who has heard about that thing called UX but wants no truck with it. Once I have some time to do some more research I’ll definitely be looking at a lot of alternative editors, but the dozen or so I’ve seen so far do not fill me with hope. With a bit of luck the LaTeX for Sublime Text will work better.
Anyone has any suggestions?
* TechWriter for RiscOs was ok, but I no longer own an Acorn machine and this was 20 years ago.
January 7, 2014
I can’t quite remember where and when, but a long time ago I heard about or read about an ethical dilemma regarding responsibility and guilt. I think it was in the wake of a Dutch trial in ’94 where a man was charged[dutch newspaper article] with murder and assault by injecting his ex-girlfriend with HIV tainted blood. Although undoubtedly a heinous act, does it qualify as murder before the victim dies? And does it qualify as murder right away if the victim will not die for several years from AIDS complications? At any rate, the ethical dilemma is happily fictional and goes like this:
Three students share a dorm apartment in Albequerque. Alec, Basil and Callum. Alec is a bit of a health-nut and goes hiking —alone— in the desert every weekend. He packs his bag on Friday evening, making sure to include two bottles of water. Basil and Callum both hate Alec to the point of murder and they’ve both decided to try and kill him. However they are not aware of each others feelings and plans. At 11pm Basil sneaks into Alec’s room and pours a small amount of lethal poison into the second water bottle, lest Alec drink it while he’s still close to civilisation. Half an hour later Callum sneaks into Alec’s room, takes the second bottle and empties it before putting it back.
Alec’s mortal remains were found by hikers 3 months later about half a day’s hike from the nearest water source. Who killed him?
The reason this is a dilemma of course is that it’s not obvious who’s ultimately to blame for Alec’s death. It’s clear that both Basil and Callum tried to kill him, so they can at least be charged for attempted murder, but the ultimate responsibility is vague.
We can’t say that Basil killed Alec as the poison was never ingested. It never even came close to Alec as it was poured down the sink while he slept. If Basil had done nothing, the outcome would have been exactly the same.
However it’s also not clear that Callum killed Alec. If Callum hadn’t emptied the bottle then Alec would have died much sooner through poisoning rather than dehydration, a far more definitive death. In fact, one could make the point that Callum’s actions postponed death for several hours, not only —briefly— saving Alec’s life but also giving him a real chance of survival.
If Basil wasn’t involved at all, this would be a clear-cut case. However by doing something which ultimately had no physical effect Basil effectively removed a large portion of responsibility from Callum, and I’m not at all sure where it went. Is there such a thing as conservation of responsibility?
December 23, 2013
At the end of the 1957 classic Witness for the Prosecution there’s a brief message to the audience:
The management of this theatre suggests that for the greater entertainment of your friends who have not yet seen the picture, you will not divulge to anyone the secret of the ending of ‘Witness for the Prosecution’.
It was truly a more innocent age…
December 10, 2013
For reasons which need not concern you dear reader, I’ve been thinking about numbers as of late. There’s a common trope out there which states that since π is infinite and never repeats, every finite string of numbers you care to come up with occurs somewhere in π, simply because it is infinite and never repeats itself. I should point out right at the start that this is believed to be true by the majority of mathematicians, but it hasn’t been proven. It is certainly possible to create an irrational number which lacks this property. A favourite example is:
which is written in base-10, yet only uses zeroes and ones. Every subsequent group of zeroes and ones is one digit longer than the previous group, hence it never repeats and it is infinitely long. But no matter how far you search, you’ll never be able to find the string ‘492’ in this number. Similarly, we could take π and replace all the nines with zeroes:
Actual π: 3.1415926535897932384626433832795028841971693993751058209... Modified π: 3.1415026535807032384626433832705028841071603003751058200...
No matter how far you search this new irrational, the string ‘492’ will never occur, yet the number is still just as infinite now as it was before we started dicking around with it.
I don’t think this logic is a shocking revelation, this stuff has been dealt with and is reasonably well understood in a post-Cantor world. The reason I bring it up is because —to me— it sounds like this argument is often trotted out by the multi-verse or infinite-universe crowd as proof of our non-uniqueness. If the universe goes on forever, then there must be infinitely many exact duplicates of Earth (where I am right now writing this exact same blog post) out there because you can only arrange a bunch of particles in so many ways. Is that really true, or is it only as inevitable as being able to find any finite string of symbols in an irrational number?