Geometry you compute instead of eyeballing

The studio's mark turns on one pun: ODIN337 leetspeaks to 0DIN337 — the O becomes a zero. Odin gave one eye for wisdom, so the zero becomes that eye. One glyph carries the letter, the digit and the myth at once.

Then the engineering starts, because "a zero that reads as an eye" is a specific piece of geometry with specific requirements: it has to work as a digit at 16 pixels and as an eye at two hundred.

Why you cannot get here by dragging handles

The silhouette is a vesica piscis: two circular arcs meeting at a point top and bottom. Drag the handles in an editor and you buy three problems, only the first of which is visible.

The visible one is a kink. Arcs whose radius is not consistent with the chord meet at the vertex with a tiny discontinuity, and at large sizes the eye finds it even when it cannot name it.

The second is irreproducibility. A year later you need the mark on a different proportion, and the construction logic cannot be recovered, because the numbers it was derived from never existed.

The third is copies. Every exported PNG is a copy of the geometry that has lost its link to the original. That is exactly how a favicon stops matching the logo on the page, and why nobody can name the moment it happened.

The arithmetic

Geometry is authored on a 64×64 grid. What is known is the chord (the mark's vertical axis) and the sagitta (how far the arc bulges away from it). The radius follows:

d + h = R                     // the arc centre sits h short of the bulge
d² + (c/2)² = R²              // Pythagoras on the half-chord
(R - h)² + (c/2)² = R²
R² - 2Rh + h² + (c/2)² = R²
R = (h² + (c/2)²) / 2h

c = 56   (y from 4 to 60)
h = 24   (x bulges from 32 out to 8 and 56)
R = (576 + 784) / 48 = 1360 / 48 = 28.333

That value goes straight into the SVG as A28.333 28.333, and the arcs meet at exact tangent points. There is no kink — not because one was corrected, but because one is not expressible.

The result is a 48×56 mark inside a 64 box: 8 units of side margin against 4 top and bottom. The asymmetry is deliberate, and it buys optical centring in the two places where the box genuinely is a frame — the favicon and the monogram. An intermediate version with a sagitta of 20 gave a 40×56 almond that pressed against the top and bottom edges and read as a leaf rather than a zero.

The trade-off, stated out loud

At R = 28.333 the vertex angle works out as:

sin(a) = (c/2) / R = 28 / 28.333 = 0.98824   →   a = 81.2°
vertex angle = 2a = 162.4°

162° is nearly a straight line. The vesica's points are therefore muted and the silhouette is closer to an oval than to a lens. That is worth saying plainly rather than hoping nobody measures it.

A true vesica — the one with 120° vertices — needs a different radius:

a = 60°  →  R = (c/2) / sin 60° = 28 / 0.866 = 32.33
h = R - sqrt(R² - (c/2)²) = 32.33 - 16.16 = 16.17
lens width = 2h = 32.33     (for the classic vesica the width equals the radius)

32 against 56 is a 0.58 width-to-height ratio, versus 0.86 for what shipped. A narrow pointed lens reads as a leaf or a fish, which is historically what a vesica is. But the load-bearing requirement here is different: the mark has to read as the 0 in 337. The eye reading is carried by the pupil, which survives every size, so the eye reading is what could afford to pay for width. The pointed reading did not get discarded — it moved to direction B, where the same silhouette is cut with four straight lines, as a rune would be chiselled into stone.

One source for every raster

The favicon, the apple icon, icon.svg and the press-kit files are all generated by a script from the same constants. Nothing is drawn by hand, which means drift from the logo on the page is impossible by construction rather than by vigilance.

There is one seam that could not be removed, though. The script is plain Node with no TSX loader, so it cannot import the .tsx; the paths and constants are duplicated into it. The right response to duplication you cannot remove is not to pretend it is absent but to make it loud:

const missing = required.filter((needle) => !source.includes(needle));
if (missing.length > 0) throw new Error(...)

assertInSync() reads Eye.tsx and checks for every path string, both iris and pupil definitions, and EYE_VIEWBOX itself. Editing the mark without editing the script fails the build and prints the list of what went missing. The duplication is still there; it has stopped being silent.

ICO without a dependency

sharp cannot write .ico, and pulling in an encoder for forty lines of well-specified format is not worth the dependency:

6 bytes    header:      reserved=0, type=1, count
16 bytes   per entry:   w, h, palette, reserved, planes, bpp, byteLength, offset
then       the PNG payloads back to back
w = h = 0 encodes 256 — the field is a single byte

Each entry holds a complete PNG: the container has allowed them since Vista and every browser in the support matrix reads them. The single trap is that 256 is encoded as zero, which is precisely the detail on which a hand-rolled encoder breaks — on the largest icon, the one you look at least.

The safe area that had to be measured

This is the most portable part. The mark's ink spans y 1.5 to 62.5 of the 64 box: the 56-tall silhouette plus half of the 5-wide stroke at each end. That leaves 2% clearance.

On a page that is correct — a logo should fill its box. In a boxed icon it is wrong, and the only way that became visible was measuring the generated .ico: the ink landed on row 0 and row 15 of the 16px entry. The mark was cut flat top and bottom and pressed into the rounded corners of icon.svg.

ink spans y: 1.5 ... 62.5     (silhouette 4...60 plus half of the 5-wide stroke)
scale 0.84 about y = 32:
  32 + (1.5 - 32)  × 0.84 = 6.38
  32 + (62.5 - 32) × 0.84 = 57.62
at 16px:  6.38 / 64 × 16 = 1.6px of margin
ink height: 51.2 / 64 = 80% of the box

80% happens to be roughly the content ratio Apple's icon guidance asks for, which is a pleasant coincidence and was not the target. The target was the 1.6 pixels that were missing.

What matters is that the inset is applied to icons only. It is off for the press-kit files, because padding baked into a logo asset is a nuisance for whoever has to place it. One geometry, two rules for two contexts — and both rules expressed as a flag rather than as a separate file somebody has to remember to regenerate.

Supersample, do not rasterise to size

density 384 → 384 / 72 = 5.33× → a 341px raster, downscaled to 16
density 720 → 720 / 72 = 10×   → a 640px raster, downscaled to 180

The SVG is rasterised large and reduced, rather than drawn straight at the target size. The difference shows on an arc at 16 pixels: direct rasterisation gives a ragged edge, downscaling gives an antialiased one. It costs nothing, because the script is run by hand, its output is committed, and neither CI nor the image build ever executes it.

Two more decisions of the same kind. The favicon is built simplified, without the iris ring: below roughly 24 pixels the ring closes into a smudge. And it is built on an opaque ground, because a transparent favicon is unreadable against a dark browser theme. Colour is currentColor throughout — one mark, tinted by whatever it sits in, with no light and dark variants to keep in step.

The point

The argument is not that arithmetic is prettier than a curve you nudged into place. It is that a computed value has a reason attached, and the reason outlives the file. In three years someone will ask why the top and bottom margins are half the side ones. There is an answer to that. There is never an answer to "why is this handle here".