DEV Community: Zerrin Arslan

I generated a pixel font in pure Python with fonttools (no font editor)

Zerrin Arslan — Thu, 25 Jun 2026 19:32:28 +0000

I needed a font last week — not to use one, to ship one. Long story short, the cleanest way to get listed on the big font directories is to publish your own typeface, and I'm not a type designer. No FontForge, no Glyphs, no years of Bézier practice. So I did the programmer thing: I generated one in pure Python with fonttools. No GUI, no GPU, a few seconds of CPU. Here's how.

The trick: a pixel font is just rectangles

A pixel/bitmap typeface is the easiest kind to generate by code, because every glyph is a grid of filled cells. Define each letter as a 5×7 bitmap, draw a square for every "on" cell, and you have an outline. No curves to hand-tune.

G = {
  "A": ["01110","10001","10001","11111","10001","10001","10001"],
  "B": ["11110","10001","10001","11110","10001","10001","11110"],
  # ... A–Z, 0–9, punctuation
}

Drawing a glyph with a pen

fonttools gives you a TTGlyphPen. For each filled cell, draw a square contour:

from fontTools.pens.ttGlyphPen import TTGlyphPen

PX = 120  # cell size in font units
def make_glyph(rows):
    pen = TTGlyphPen(None)
    for ry, row in enumerate(rows):
        for cx, ch in enumerate(row):
            if ch == "1":
                x, y = cx * PX, (6 - ry) * PX  # flip: row 0 is top
                pen.moveTo((x, y)); pen.lineTo((x + PX, y))
                pen.lineTo((x + PX, y + PX)); pen.lineTo((x, y + PX))
                pen.closePath()
    return pen.glyph()

Assembling the font with FontBuilder

FontBuilder wires the glyphs, character map, metrics and metadata into a real .ttf:

from fontTools.fontBuilder import FontBuilder

fb = FontBuilder(1000, isTTF=True)   # 1000 units per em
fb.setupGlyphOrder([".notdef", "space"] + list(G))
fb.setupCharacterMap({ord(c): c for c in G} | {32: "space"})
fb.setupGlyf({"space": TTGlyphPen(None).glyph(),
              **{c: make_glyph(rows) for c, rows in G.items()}})
fb.setupHorizontalMetrics({g: (820, 60) for g in fb.font.getGlyphOrder()})
fb.setupHorizontalHeader(ascent=900, descent=-150)
fb.setupNameTable({"familyName": "Boxel", "styleName": "Regular", ...})
fb.setupOS2(); fb.setupPost()
fb.save("Boxel-Regular.ttf")

That's a working, installable font.

Three things that bit me

Lowercase. I only defined A–Z, so typing "hello" rendered as tofu (□□□□□). Fix for a caps-only design: map a-z to the same glyph as A-Z in the cmap, so lowercase shows the uppercase shape instead of blanks:

  for c in G:
      cmap[ord(c)] = c
      if "A" <= c <= "Z":
          cmap[ord(c.lower())] = c

The viewBox flip. Font Y goes up, your bitmap rows go down. (6 - ry) flips it. Forget this and your letters are upside down.
Name table completeness. Some validators want license URL (name ID 14) alongside the license text (ID 13). Cheap to add, saves a rejection.

Verify it before you trust it

Don't eyeball it — render every character:

from PIL import ImageFont
f = ImageFont.truetype("Boxel-Regular.ttf", 64)
# draw "HELLO hello 12345 Test!" and check: any boxes = missing glyph

If a cell comes out blank, the glyph or cmap entry is missing.

Result

I made three styles this way — square, dot-matrix, and stencil — by swapping the cell-drawing function (square vs circle vs notched). It's a family called Boxel, free for personal use. The whole thing is a single script; no design tool ever opened.

fonttools is one of those libraries that turns "I can't do that" into "oh, it's 80 lines." If you've ever wanted a custom display font and bounced off the editors, generating a pixel one in code is a fun afternoon. (And if you just want fonts to download, that's literally what I build.)

What would you generate — a bitmap font, an icon font, something weirder?

Render any font to a crisp SVG path in the browser with opentype.js

Zerrin Arslan — Tue, 23 Jun 2026 19:54:49 +0000

A designer asked me for a logo word as an SVG path — not a PNG, not "the font file," an actual <path> they could drop into Figma and a cutting machine. My first instinct was to screenshot it and trace it. Don't do that. If you have the font file, the outlines are already vectors — you just have to ask for them. Here's how I do it client-side with opentype.js.

The idea

A font glyph is a set of Bézier curves. opentype.js parses a .ttf/.otf and hands you those curves as an SVG path string. No tracing, no quality loss, no server.

Load the font and get a path

import opentype from "opentype.js";

const font = await opentype.load("/fonts/MyFont.ttf");

// getPath(text, x, y, fontSize) → a Path object
const path = font.getPath("Hello", 0, 150, 120);

// .toSVG() gives you the <path d="..."/> markup
const pathMarkup = path.toSVG(2); // 2 = decimal precision

That pathMarkup is a real vector outline of your text in that font. Wrap it in an <svg> and you're done.

Size the viewBox correctly

The gotcha is the canvas/viewBox. getPath draws from a baseline, so you need the bounding box to avoid clipping:

const bb = path.getBoundingBox(); // {x1, y1, x2, y2}
const pad = 16;
const w = (bb.x2 - bb.x1) + pad * 2;
const h = (bb.y2 - bb.y1) + pad * 2;

const svg = `<svg xmlns="http://www.w3.org/2000/svg" viewBox="${bb.x1 - pad} ${bb.y1 - pad} ${w} ${h}">
  ${path.toSVG(2)}
</svg>`;

Now the SVG is tightly cropped to the glyphs, whatever the text.

Download it from the browser

No backend needed — make a Blob and click a link:

const blob = new Blob([svg], { type: "image/svg+xml" });
const a = document.createElement("a");
a.href = URL.createObjectURL(blob);
a.download = "text.svg";
a.click();
URL.revokeObjectURL(a.href);

Things that bit me

CORS on the font fetch. opentype.load does an XHR/fetch under the hood; the font has to be same-origin or CORS-enabled or it silently fails. Self-host the file.
Licensing. Converting a glyph to a path is still using the font. Check the license allows it before you ship outlines of a commercial font.
Right-to-left / complex shaping. getPath does basic layout, not full HarfBuzz shaping. For Latin display text it's perfect; for Arabic/Indic you'll want a shaping engine.
Precision vs file size. toSVG(2) is plenty for cutting/printing. Higher precision just bloats the path string.

Why client-side is nice here

The whole thing runs in the browser: the user picks a font, types text, and gets an SVG without a single byte hitting a server. That's exactly how I wired up the font-to-SVG tool on FontBoxDL — handy if you want to see it in action or grab a quick cut file (it pulls from a library of 60k+ free fonts you can use as the source).

opentype.js is one of those libraries that makes a "hard" task almost embarrassingly short. If you're doing anything with fonts in JS — metrics, kerning, glyph inspection — it's worth an afternoon.

Anyone else using it in production? Curious what you've built.

Adding custom fonts to a Next.js app without the layout shift

Zerrin Arslan — Mon, 15 Jun 2026 17:38:38 +0000

If you've used Next.js in the last couple of years you've probably reached for next/font. It's genuinely great — but I still see custom fonts done in ways that tank the Lighthouse score or make the page jump around on load. Here's how I actually wire up fonts in a Next.js app now, and the one thing that quietly fixes most of the layout shift.

Google fonts: `next/font/google` already self-hosts

First, a thing a lot of people miss: next/font/google doesn't load anything from Google's servers at runtime. At build time Next downloads the font files and serves them from your own origin. So you get the self-hosting win (no third-party request on the critical path) for free:

import { Inter } from "next/font/google";

const inter = Inter({ subsets: ["latin"], display: "swap" });

export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

That subsets: ["latin"] line matters — it subsets the file so you're not shipping glyphs for languages you don't use.

Custom / paid fonts: `next/font/local`

For a font that isn't on Google Fonts — a brand font, a freebie you downloaded, whatever — use next/font/local and point it at a WOFF2 in your project:

import localFont from "next/font/local";

const display = localFont({
  src: [
    { path: "./fonts/MyFont-Regular.woff2", weight: "400", style: "normal" },
    { path: "./fonts/MyFont-Bold.woff2",    weight: "700", style: "normal" },
  ],
  display: "swap",
  variable: "--font-display",
});

Then expose it as a CSS variable and use it wherever:

<html className={display.variable}>

.heading { font-family: var(--font-display), sans-serif; }

If your font is a .ttf/.otf, convert it to WOFF2 first — smaller and supported everywhere. I usually just drop it into FontBoxDL's webfont generator (browser-based, no install) and grab the WOFF2 back. And if you're still hunting for the font itself, the free library has a pile of them.

The thing that actually fixes layout shift

Here's the part people skip. Even with display: swap, when the real font swaps in it usually has different metrics than the fallback — so text reflows and your CLS spikes. next/font can fix this automatically if you give it a fallback to match against:

const display = localFont({
  src: "./fonts/MyFont-Regular.woff2",
  display: "swap",
  fallback: ["system-ui", "arial"],
  adjustFontFallback: "Arial", // generates a size-adjusted @font-face for the fallback
});

adjustFontFallback makes Next emit a fallback @font-face with size-adjust/ascent-override tuned so the fallback occupies almost exactly the same space as your real font. The swap becomes nearly invisible. This one prop has done more for my CLS numbers than anything else.

Quick gotchas

Don't import a font inside a component that re-renders. Declare it at module scope (top of the file), once. Importing it in the render path defeats the optimization.
variable vs className: use className if it's your single global font; use variable when you want multiple fonts available as CSS custom properties.
Preload is automatic for fonts used on the route — you don't need a manual <link rel="preload"> like you would in a plain HTML setup.

TL... actually, no TL;DR

Use next/font/google for Google fonts (it self-hosts), next/font/local for everything else, ship WOFF2, and set adjustFontFallback so the swap doesn't shove your layout around. Takes ten minutes and your Core Web Vitals will thank you.

What's your go-to for custom fonts in Next — next/font/local, or do you still hand-roll the @font-face?

I stopped loading fonts from Google's CDN — here's the self-hosting setup that stuck

Zerrin Arslan — Mon, 15 Jun 2026 16:42:33 +0000

For years I just dropped the Google Fonts <link> in my <head> and moved on. One line, done, who cares. Right?

Then I was staring at a Lighthouse report for a landing page that felt sluggish, and there it was in the waterfall: a render-blocking hop to fonts.googleapis.com, then a second one to fonts.gstatic.com for the actual file. Two extra connections — DNS lookup, TLS handshake, the whole dance — before a single character painted. On my laptop? Invisible. On a mid-range Android over flaky mobile data? Very visible.

So I bit the bullet and self-hosted. Took an afternoon, and I've done it on every project since. Here's the setup I've landed on after a bunch of trial and error.

Get a WOFF2 (and only WOFF2)

WOFF2 is supported literally everywhere now and it's ~30% smaller than the old WOFF. You don't need the .ttf, .eot, .svg fallback zoo from 2014 anymore. Just ship WOFF2.

If you've got a .ttf/.otf, convert it with fonttools:

pip install fonttools brotli
fonttools ttLib.woff2 compress MyFont.ttf   # -> MyFont.woff2

Honestly I got tired of doing the CLI thing for one-off fonts, so I ended up building a little browser tool for it — FontBoxDL's webfont generator — drop a TTF/OTF in, get WOFF2 + a @font-face block back, no install. Use whatever's less friction for you.

The @font-face block

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

The line that matters most here is font-display: swap. It tells the browser "show the fallback text immediately, swap in the real font when it arrives." Without it you get FOIT — invisible text while the font loads — which is a worse experience than a quick font flash, basically every time.

Preload the one font that matters

Drop this in your <head>:

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

Two things people get wrong here, me included:

Don't preload everything. Preload only the font(s) you actually use above the fold. If you preload six weights, you've just created a different bottleneck.
Don't forget crossorigin. I once left it off and spent a solid 20 minutes confused about why the font was being downloaded twice. Fonts are always fetched in CORS mode, so the preload has to match or the browser throws your preloaded copy away.

Subset if you care about bytes

A full font ships thousands of glyphs you will never render. If your site is English/Latin, subsetting can knock off 70%+:

pyftsubset MyFont.ttf \
  --unicodes="U+0000-00FF" \
  --flavor=woff2 \
  --output-file=myfont.subset.woff2

I don't always bother for a single light body font, but for display/heading fonts it's an easy win.

Cache it like it'll never change (because it won't)

Fingerprint the filename, then cache forever:

Cache-Control: public, max-age=31536000, immutable

Don't skip the fallback stack

Even with swap, give it a real fallback so the first paint looks intentional and the layout doesn't lurch when the swap happens:

body {
  font-family: "MyFont", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
}

That's the whole thing. Convert → @font-face with swap → preload the critical one (with crossorigin!) → cache hard. It's maybe an hour of work and you get a real LCP/CLS improvement plus one fewer third party in your critical path.

Anyone still on the Google CDN <link> for production — what's keeping you there? Genuinely curious if there's a case I'm missing.