Ansuz

Still reading through the documentation for Tsukurimashou 0.2, but this is definitely the first typeface I've seen whose construction involved the development of a Prolog interpreter.

In the upper-left quadrant of the lowercase "t" glyph, there's a diagonal line connecting the stem and bar, and then the area defined by that line + stem + bar is filled in. It looks like a drawing error, but I'm not sure if it is indeed an error or if that's the way you want it.

The kerning between many characters and punctuation marks (" , : ; especially) feels too tight to me, but I probably need to understand the kerning algorithm before looking further into that. trythil (URL) - 07-04-’11 14:49

If you're describing what I think you're describing on the lowercase t, that's deliberate. It's inspired by a similar feature in Gill Sans. Took some doing to get it looking the way I wanted it (because it's an exception to the spine+stroke method used for most other letters) but that work proved to be valuable later, when I re-used the code in the implementation of accents. This is special-cased in the Tenshi no Kami font, too.

The kerning algorithm has a bunch of tweakable parameters that maybe need further tweaking. My guess is that what you're seeing is associated with characters that have a lot of vertical white space - in such cases it's bringing the rows that have black closer together in order to compensate for all the rows that don't have black at all, and maybe it's doing that too much. If you're building the faces yourself you could try reducing the values of "hullslope" and "hullslope_beyond" (currently 10 and 3 respectively) in line 82 of kerner.c.

On reading that code I realize I misdocumented it - the description in the document describes the run-over-rise slope set by hullslope_beyond as "half a pixel" when it's actually 3/10ths of a pixel at the moment. Matt - 07-04-’11 15:48

One thing with that triangle on the t - it occurs to me that when I first designed it I had been intending that the fonts would be used primarily in monospace, and I was designing the "wide" version which would then be squashed horizontally to become the "narrow" version. Now, you're probably looking at the "proportional" version, which is basically the unsquashed "wide" one with less space between the letters. As a result, the triangle now looks a lot bigger and heavier than it did when I was first designing it (and it's a lot bigger and heavier than Gill's); it's almost a parody of what I'd initially envisioned. Maybe I should reduce it somewhat for the purposes of the proportional version; I might do that by shortening the crossbar of the t. I don't want to remove the triangle entirely, though.

This points to one of the difficulties of designing parametric type: you can't change just *one* thing and have it still look right. All the parameters are linked in complicated ways. Matt - 07-04-’11 16:22