Forem: Chris

Why does stylized “cursive text” even render on Instagram?

Chris — Sat, 02 May 2026 04:26:45 +0000

Scrolling through Unicode‑styled bios always raises the same question for me: we’re not uploading fonts, so how are those ornate characters surviving across every app and device? I spent some time poking at Cursive Generator to see what kind of engineering makes that happen, and it’s surprisingly old‑school — closer to a Unicode hack than a graphics pipeline.

Unicode as poor man’s font system

When you type something there and pick “Script” or “Bold Gothic,” the site isn’t drawing custom glyphs; it’s remapping code points. Most of those styles live in the “Mathematical Script,” “Fraktur,” and “Double‑Struck” blocks (U+1D4xx, U+1D5xx, U+1D50x). The generator likely has a static lookup table: ASCII a–z → corresponding decorative characters. When a letter doesn’t exist in that range, it probably falls back to the base Latin, which is why punctuation stays plain.

That interpretation means the whole text field output is still ordinary strings, not rendered images — hence copy/paste works in Instagram or Discord without fonts installed. The key trick is selecting code points that the major OS fonts happen to ship with glyphs for, like Cascadia, SegoeUIEmoji, or Apple Color Emoji. “Generates across platforms” is less magic, more exploitation of those built‑in fonts.

PNG generation hints

The landing page mentions downloadable PNGs for “wedding” or “Etsy designs.” That points to a canvas‑based renderer separate from the Unicode mapping path. My guess is an <canvas> or <svg> layer that uses Google Fonts under OFL — probably dynamically loaded via the Google Fonts CSS API once the user clicks “Image.” The PNG export could be canvas.toDataURL() or a Blob converted for download.

The absence of server latency (images appear instantly) implies client‑side rendering only; no headless Chrome round‑trip. Cloudflare presence in headers suggests purely for CDN + DDoS protection, not computation.

Astro front‑end observations

The DOM fingerprints show Astro v6 and TailwindCSS. That fits the static‑site profile: layout generated at build time, minimal JS hydration except for the generator input logic. Given Astro’s islands model, the state machine for style selection is probably a reactive miniature component — maybe written in Svelte or React nested inside the Astro page. It doesn’t look like any heavy framework is present; just small hydration islands and a single script handling copy/download actions.

One subtle optimization I noticed: loading “10 more styles” doesn’t re‑render the whole layout. That points to pre‑fetched fragments or data attributes toggled via DOM mutation instead of network fetches. Very low overhead, typical of Astro partial hydration.

Speculative internals

Two small engineering guesses:

Lookup compression — with 42 styles × ~60 supported characters, a naïve map would be thousands of entries. They might autogenerate this from Unicode ranges, not hardcode. Could be a JSON slice pre‑compiled during Astro build and embedded in the bundle.
PNG font rasterization — likely using OffscreenCanvas plus FontFace API. It would allow asynchronous font loading while keeping main‑thread responsive, explaining the lack of flicker when changing script styles.

What I'm still curious about

PNG exports seem crisp even at large sizes — possibly vectorized before rasterization. Is the download actually a rendered canvas bitmap, or are they producing SVG and then rasterizing via a hidden <img> to get transparency? I couldn’t confirm from the client code alone. If it’s the latter, that’s a neat hybrid I’d like to see more of.

The bellows move, but the CPU stays quiet — what’s powering this browser based harmonium?

Chris — Sun, 19 Apr 2026 12:11:48 +0000

The bellows move, but the CPU stays quiet — what’s powering this browser web harmonium?

Clicking into this harmonium-in-a-tab feels a bit surreal: a little bellow handle animates, reeds respond to keypresses, and the sound is surprisingly organic for something coming out of AudioContext. I'm less interested in how musical it feels than in how they pulled off that “real instrument in a browser” illusion with so little lag.

Probably sample playback, not synthesis

The page claims “nine sampling points across three octaves,” which suggests pre‑recorded WAVs pitched via resampling rather than additive synthesis. My guess is each note name maps to an AudioBuffer loaded once and stretched by playbackRate. Because harmonium reeds are relatively static timbrally, a few samples per octave are enough if you interpolate pitch carefully — maybe detune in 25‑cent steps.

What’s impressive is the lack of audible pops between bellows volume changes; that implies they’re smoothing gain adjustments through a shared GainNode envelope, not tweaking volume directly on AudioBufferSourceNode. The “pump handle” UI probably just changes a target amplitude, and a short exponential ramp handles the fade so the CPU doesn’t glitch.

MIDI velocity and the mystery of expression

The velocity‑sensitive response hints at simple amplitude mapping, but the harmonium doesn’t actually respond to velocity in the acoustic sense — it’s air pressure. Maybe they map velocity onto the global bellows gain, making harder hits simulate stronger pressure. Without polyphonic aftertouch, that would still feel static if you hold notes. I’d bet they’re smoothing gain.value over time to fake air compression.

The navigator.requestMIDIAccess API can be finicky in Safari, so I’d love to see what polyfill (if any) they use. The low latency suggests they rely on Chrome’s direct MIDI path and accept best‑effort elsewhere.

The “drone” is a separate audio graph

Switching between the reed drone and tanpura loop is instant, no browser re‑buffering pause. That implies pre‑decoded looping buffers. The tanpura’s periodicity sounds about five seconds, so they likely run a looping AudioBufferSourceNode with a small crossfade fade‑out/fade‑in at the seam. The harmonium drone could simply be the same sample layered under a low‑pass filter.

Given that it keeps playing while you record, the recorder must be grabbing from a mix MediaStreamDestination feeding into a MediaRecorder — straightforward but clever for an all‑client setup.

Recording and share links

Recordings save as WebM up to two minutes, which lines up neatly with Chrome’s default MediaRecorder memory limits; beyond that, latency spikes. The “one‑hour share link” that supposedly stores the state is probably a compressed JSON blob passed via base64 — about forty characters on my short test, so likely LZ‑compressed settings encoded into the query string. Interesting that playback settings, not audio, travel in that link; the recipient just rebuilds the same instrument state client‑side.

PWA and caching puzzle

The thing installs offline, so they’ve gone the serviceWorker route. But harmonium samples are big — three octaves × nine notes ≈ 27 files at maybe 300–500 KB each. That’s bandwidth‑heavy. Either Cloudflare is edge‑caching aggressively, or they lazy‑cache samples on first touch. Watching the network panel shows delayed fetches per note, supporting the lazy hypothesis. Makes sense: cache only notes actually played rather than forcing a multi‑megabyte warm‑up.

What I still wonder

The bellows animation tracks volume with almost zero frame lag on mid‑range phones. Are they syncing that via an AudioWorkletProcessor thread posting back amplitude RMS values, or just deducing handle position purely from UI state? If anyone has dug through its JavaScript bundle, I’m curious how tightly (or loosely) the visual and audio loops are coupled.