I built a handwritten notes compiler because AI kept giving me walls of text

I kept running into the same problem when I studied with AI.

Live demo (runs in your browser, no account): https://shyler-web.github.io/scriptforge-handwriting/

I would ask it to explain a concept and get a wall of text. I would ask for a diagram and get a blocky architecture chart. I would ask for anything else and it would reach for SVG — which looked nothing like the page I actually revise from, and burned through tokens fast.

The frustrating part was not just the output. It was the format.

I do not study from walls of text. I study from a page: a derivation, a free-body diagram, a timing waveform, a small note in the margin. Handwriting compresses an idea in a way plain text does not. One page can hold the thing I am trying to understand, the diagram that explains it, and the sentence that makes it click.

That is the page I wanted from AI. It never gave it to me. So I built ScriptForge.

What ScriptForge does

ScriptForge is a browser-native compiler for handwritten notebook pages.

You write plain text, LaTeX-style math and small declarative diagram blocks. It renders a deterministic hand-drawn page, lays the content out across real notebook pages, and exports a multi-page PDF or PNG.

A minimal document looks like this:

# Statics & Calculus [sketch: @layout place=full scale=1.35 title "Free-body diagram" incline at=(0, 0) angle=30 mass="$m$" friction="$f_k$" components=true ] $$ \int_0^1 4x^3\,dx = 1 $$ 

That produces a ruled page with a handwritten heading, an inclined-plane free-body diagram with components, and a hand-set integral.

No drawing tablet. No cloud. No account. No build step.

The idea: handwriting is a compression format

Most note tools treat handwriting as a font. You type, a font repeats the same glyphs, and the result looks like a document wearing a costume.

ScriptForge treats handwriting as geometry with variation. Every character is warped with its own noise, slant and pressure. The same seed reproduces the page exactly; re-roll the seed and the entire page re-inks.

That matters because handwriting is not decoration. It is a compact visual language:

• a derivation can live next to the diagram it describes
• a waveform can sit beside the timing table
• a margin note can point at the exact step it explains
• a page can be scanned as a whole instead of read as a feed

The goal is not to make text look handwritten. The goal is to make a page that is easier to study from.

How it works

The app is intentionally plain: vanilla JavaScript, no framework, no npm dependencies, no build step. Rough.js is vendored for hand-sketched primitives, and the fonts are self-hosted. Everything else is hand-rolled.

1. The allography engine

Each glyph gets a deterministic variation (each letter is drawn slightly differently, like real handwriting): warp, baseline drift, slant, pressure and ligature behavior. The seed controls the page. That gives you reproducible output without cloning the same letter everywhere.

2. The 2D math renderer

The math layer parses a focused LaTeX-style subset and lays it out as hand-drawn 2D math: fractions, roots, matrices, integrals, sums, limits, aligned derivations and piecewise cases. It is not a full TeX engine. It is a deliberately small language for notes.

3. The sketch engine

[sketch: ...] is the part that makes the pages useful. A few lines of geometry become:

• inclined planes, Atwood machines, thin-lens ray traces and fields
• timing waveforms, stack/heap frames, linked lists, B-trees and pipelines
• cyclohexane chairs, Newman projections and skeletal chains
• Venn diagrams, Hasse lattices and mappings
• 3D surfaces, Riemann sums, matrix transforms and slope fields

The engine handles placement, text wrapping and collision avoidance, so diagrams can share a page with prose instead of living in separate images.

4. Pagination and layout

A document can flow across A4, two-column A4, three-column A3 landscape and four-column wall charts. Content wraps around floating figures, and page breaks avoid splitting equations or diagrams.

5. The PDF writer

This is the part I am most stubborn about: the PDF writer is hand-rolled. No PDF library. It builds a real PDF 1.4 file, embeds each page as a JPEG XObject and writes the cross-reference table itself.

That is not the shortest path. It is the path that keeps the whole thing local, inspectable and dependency-free at runtime.

What I deliberately avoided

• No framework
• No npm dependencies
• No build step
• No cloud renderer
• No account
• No AI model at render time

The note format is AI-native — the local MCP server and CLI let an agent write and validate notes — but rendering is deterministic. The same input produces the same page.

What is still hard

The honest version:

• The LaTeX support is a subset, not a TeX engine.
• Diagram grammar is expressive, but it is still a grammar. Some figures are easier to describe than others.
• Layout collisions are the endless edge case. Text wrapping around floating figures is where most of the visual bugs live.
• Because each PDF page is embedded as a JPEG, the text in exported PDFs is not selectable or searchable, and files are larger than a vector PDF.
• The sketch language has to stay learnable. If it becomes a programming language, it stops being a note format.

Those are the trade-offs I chose. A smaller language that renders reliably is more useful to me than a larger one that constantly breaks.

The agent side

There is a local MCP server and a CLI, so an agent can write notes, validate them and render pages without leaving the machine. The point is not "AI writes your notes." The point is that the same page format works for a human and an agent.

Try it

Live studio: https://shyler-web.github.io/scriptforge-handwriting/

ScriptForge is MIT open source. If you study math, CS, chemistry or engineering, I would love feedback on two things:

1. Does the note language feel learnable?
2. Where does the sketch grammar break for diagrams you actually draw?

I am especially interested in the page you would render first.