A few common variables we’ll be using throughout:

Basic Text

Let’s start with a simple “Hello World”, except in this case, let’s just say COLDTYPE, because the coldtype repository has a special version of the font Obviously that just has those letters (CDELOPTY).

You might be wondering why the text is blue — that’s the default fill color for any text in coldtype. Let’s mess with the color and set some variable font axis values:

Also let’s track out the letters and rotate them.

What’s interesting (and different) about setting text with Coldtype is that you aren’t telling the computer to draw text, you’re asking for information about the individual glyphs and where they sit, given the parameters you’re passing into StSt function.

Put another way, what you get back from calling (StSt…) is a rich set of data that can be inspected and manipulated.

An aside

Just for fun, here’s a more coldtype-y way to do that last manipulation: rather than declare a variable pens and then manipulate it in a line-wise fashion (pens[0].rotate...), you can use functions built-in to the P class to manipulate the form without leaving the “chain” (that is, the chained expression).

So the keys here are the lines .indices and .index, which target elements of the tree (using standard python-style indexing), and then give you the opportunity to do anything you’d like in a lambda. So in just one line, we can rotate both the C (index 0) and the E (index -1) with a single lambda (i.e. a function that, in this case, is called for each index).

Also we can change the colors since who wants to see the same colors again.

Debugging

To see a tree-like representation of the vector/text data, try something like this:

Less Basic Text

Usually, glyph-wise structured representation of text is not a feature of software or software libraries, because when programmers sit down to implement support for text, they do it with the understanding that if you want text, you probably want a lot of text — great big slabs of it, set in large blocks, like this paragraph that you’re reading now.

But for lots of graphic design (particularly animation), what you actually want is very precise control over only a few glyphs, maybe a line or two. That was some of the magic of technologies like moveable type, or especially Letraset; they gave designers direct control over letterforms. A lot like when you hit “Convert to Outlines” in Illustrator today.

Of course, there’s a big downside to converting-to-outlines: it is excruciatingly slow. And more than that, even when you’re working with just a few letters, you might need to change those letters at the last minute, right before a project is due.

Which is where code really shines. All the manipulations I’ve done so far are not “one-way” or “destructive” (like Convert to Outlines). As far as we’re concerned, the “textbox” (so to speak) is still intact: StSt("COLDTYPE"...

To illustrate that point, let’s change the text:

The last two examples also illustrate something important about Coldtype: (almost) everything is mutable/self-changing by default. So a line like pens[0].rotate(180) changes pens[0] directly, meaning you don’t need to assign it to a new variable. This makes it very easy to directly manipulate nested structures without needing to reassign variables.

This also means that sometimes it is very necessary to copy pens in order to double them, so you can make changes to a copy without modifying the original.

For instance:

I’ll admit the impact of the interesting dropshadow here is lessened somewhat by the appearance of the strange pink lines in the top layer of text. When I added the code stroking the pens (.s(hsl(0.9)).sw(3)), I thought it would look like a standard stroked shape. But if you’re familiar with how variable fonts are constructed, those lines might not seem all that strange to you — they indicate that the letters are constructed in order to interpolate cleanly. That said, we probably don’t want to see them!

How to get rid of them? There are a couple options:

• There’s a special ro=1 flag that you can pass to any StSt function, and that’ll (r)emove (o)verlaps on all the glyphs before they come back to you in their correct positions.

• Or you could call removeOverlap after you do the lockup, which would have the same effect.

Fixed! Also I did some completely unrelated things there.

• Instead of simply offsetting the main text to get a shadow, this example collapses the set of pens to a single pen (via .pen()), and then uses a built-in method called castshadow(<angle>, <distance>) to cast a shadow.

• Instead of copying anything, the example now uses the .layer method, which does the copying for you, and also removes the “original” in favor of the two lambda functions provided. Basically, this is a copy-and-replace operation, where we’ve provided two “replace” operations. So to recap: via StSt, we created a set of pens (aka vectors aka shapes), then we reduced that to a single pen, then we layered that pen, resulting in two new pens (one for the shadow, one for the filled and stroked shape on top). The layer function also allows us to directly return the “chain,” without having to declare intermediate variables.

One additional refinement you may want to make in an example like this is that you’d want to individually cast shadows based on a glyph + a little bit of stroke set around it, in the style of the 19th-century type designers. So let’s do that:

Dang, you know I thought that example would just work, but it looks like there are some tiny little dots present, which I think are artifacts of the castshadow call. I didn’t write the guts of that (Loïc Sander wrote something called a TranslationPen which is used by coldtype internally), so I don’t understand it completely, but it shouldn’t be difficult to devise a way to clean up those tiny specks by testing the bounds of each of the contours created by the TranslationPen. We can do that by iterating over the individual contours by explodeing the path into its constituent contours, then filtering those contours, these implodeing those contours back into a single path again. We can also use the opportunity demonstrate some debugging techniques, like isolating a single letter and blowing it up.

Got it! If you comment out the .explode/.filter/.implode lines, you should see the little speck show up again.

N.B. We pulled the lambda being passed to mapv (map-values) out into its own function, shadow_and_clean. It’s not really a “reusable” function, but it is a little clearer in this instance to have that logic separated from the main chained expression.

Two suggestions to help you better understand code or find weird looks: try commenting out various stuff and using random colors.

Typography, further afield

Multi-line text

Multi-line text, fitted to width

Via the fit= kwarg

Multi-line text, aligned right

Load Fonts directly from Google

Here’s an example of loading a font from Google, using Font.GoogleFont:

Text-on-a-path

If you’d like to align glyphs along an arbitrary path, you can use the DATPens’ distribute_on_path method to set the glyphs returned from a StSt.

What if we want more text on the circle and we want it to fit automatically to the length of the curve on which it’s set — without overlapping? Simple append a fit= keyword argument to fit the text to the length of the curve that we’ll end up setting the pens on.

One thing that’s weird about setting text on a curve is that, depending on the curve, it can exaggerate — or eliminate — spacing between letters. Sometimes that doesn’t really matter — in the case of this circle, because the curve only bends in one manner, the text is always extra spacey, which usually isn’t a problem. But if we set the text on a sine-wave, the issue becomes more apparent, since the spacing is both expanded and compressed on the same curve, and when letters overlap excessively, they can get illegible quickly.

Is there a solution? Probably many but the one I like a lot is the understroke method on the DATPens class, which interleaves a stroked version of each letter in a set (a technique popular in pulp/comic titling & the subsequent graffiti styles they inspired).

Let’s see what that looks like.

Interesting! But there’s one thing to correct if we want better legibility. You’ll notice in that first purple COLDTYPE, the C is unrecognizable, because the O that comes after it is on top of it. This is how text layout engines usually work for LTR languages — the topmost glyph is the right-most glyph. But that’s not what we want — we want to reverse the order of the glyphs. Luckily, that’s easy, just pass a r=1 (or reverse=1), to the Style constructor.

It’s a subtle change, but one that (to me) makes a huge difference. I also lightened the purple in the gradient, I think it looks a little better that way, right?