All Posts in “processing”

Geomerative Sketch

geomerative-01

In my previous post I talked about my attempts on Processing + Typography, but I didn’t post any interactive example. Not because I didn’t want to, but because my sketch is using the OPENGL renderer and it is tricky to publish applets with it. Last night I received a notification about a reply to a post at the processing forum with some instructions to do just that. Now the applet is published.

geomerative-02

Works fine for me. I asked a few friends to test it and it didn’t work for everyone. If it will work for you or not depends on platform and JRE version – and probably the lunar phase and many other things. Please give it try. Source code is also available.

Launch the sketch.

Processing + Typography

When I first got my hands on the Form + Code book what impressed me the most was the artwork with typography on the titles and opening pages. It reminded me how much I like typography and how focusing on the shape of letters and text can produce beautiful visuals. Then of course it got me trying to reproduce those visuals using Processing. There is no code in the book to help with that. All we get are some short descriptions at the bottom of each title page, like this one:

form-code-04
Form+Code page 9

That is a good hint. I knew I had to start with Python, which didn’t take long to lead me to TTX. It is a great piece of software that describes TrueType and OpenType fonts in an XML-based format. XML is much easier to read than bytecode and I guess the authors of Form+Code used TTX at some point. But having the fonts described in a text format is not enough, it is necessary to write Processing software to parse all that and create the points and curves and shapes. TTX to Processing: that would be an interesting library. Before I started to write one myself (like it would be easy), I went on a search for other contributed libraries to handle typography.

Which lead me to Geomerative. A fantastic library to work with TrueType fonts and SVG shapes in Processing. I was very happy when I found it. It was not Python or Postscript, but it would let me achieve similar visuals in a much quicker way.

form-code-01
Form+Code page 26
typography-01
similar visuals made with geomerative

form-code-02
Form+Code page 42
typography-02
similar visuals made with geomerative

form-code-03
Form+Code page 92
typography-03
similar visuals made with geomerative

 
Why it doesn’t look the same
I’ve put some effort to copy the exact look of the titles in the book, but it still looks different. Why?
It all comes down to the differences between TrueType and Postscript.

The external contours are drawn in opposite directions, counter-clockwise on Postscript and clockwise on TrueType. This also affects the starting points of each glyph: Postscript starts where TrueType ends and vice-versa. This difference becomes evident on the “Computers” example.

ttf-01
Postscript vs TrueType: start point and direction

There is also a big difference in the way curves are drawn in the two formats. Postscript use cubic Bézier splines while TrueType uses quadratic Bézier splines. Which means TrueType needs more anchor points than Postscript to draw similar curves. The difference becomes evident on the “Working” example.

ttf-02
Postscript vs TrueType: curves

 
Geomerative and OpenType
The OpenType file format can describe both TrueType and Postscript outlines. Is it possible to use OpenType fonts (Postscript flavored) with Geomerative? No. At least not with the current version (rev 34). Geomerative uses a Java library called Batik to parse the TrueType format and convert it to SVG instructions. The Batik library (release 1.7) ignores the CFF table used to describe Postscript outlines. I searched for updates to the Batik library to see if there are plans to support CFF, but it doesn’t look like that is going to happen.

One interesting thing I found was that the Adobe Flex SDK also uses Batik to handle TrueType fonts. Actually, there are four font managers: Batik and JRE to manage TrueType and AFE and CFF to manage TrueType and OpenType.

This post is coming to an end but there aren’t many conclusions to make. Except that, as I read somewhere, OpenType file format is a hard nut to crack. The next steps could be: find a parser for the CFF table and adapt it to Geomerative; or write a parser for the TTX format as I mentioned at the beginning; or accept the formats differences and focus on the visuals of the other titles in Form+Code book. For now, I’ll probably go for the latest option. I’m enjoying the ride and I hope I can post some updates here soon.