Disclosure: This article was generated by AI for the team behind Handwriting AI and FontKind AI. The schema below is an illustrative design example, not a description of either product's internal API.
A handwriting workflow can produce two very different artifacts: a reusable font and a finished page. Both may look like handwriting, but they solve different problems. Treating them as one export creates confusing interfaces, misleading descriptions, and brittle integrations.
Start with the artifact
A TTF font describes glyphs and the metrics used to arrange them. It does not contain the final letter, card, worksheet, or PDF. A page combines text, a font, spacing, paper dimensions, and layout. Changing the message should not require rebuilding the font; changing the font should not silently overwrite the page settings.
This distinction suggests two separate records:
type FontAsset = {
id: string;
format: "ttf";
characterSet: string;
source: "handwriting-photo" | "description" | "style-image";
};
type PageDocument = {
text: string;
fontAssetId: string;
paper: "A4" | "Letter";
output: "pdf" | "jpeg";
};
These types deliberately omit authentication, billing, and storage details. Their purpose is to make the boundary visible: the page references a font asset rather than pretending the font is a page.
Record what came from the handwriting sample
A photograph rarely contains every character a reusable font needs. If a missing character is generated in a similar style, it should not be described as a direct restoration of the writer's original letter.
Keep that distinction at character level. A simple provenance value can distinguish a restored character from a style completion. File paths, character counts, and download formats can come from deterministic code. Whether a shape faithfully represents the photographed letter requires comparison with the source. A complete character set alone does not prove visual fidelity.
Test the font and the page separately
For the font, check actual character coverage, legibility, spacing, and the result when unfamiliar words are typed. Include capitals, digits, and punctuation. Compare restored characters with the source at a readable size.
For the page, check wrapping, clipping, margins, paper size, and print output. A glyph that looks good in a large preview can still create an awkward line break. Conversely, a clipped PDF does not necessarily mean the underlying glyph needs regeneration.
Keep these failures separate in bug reports. "The lowercase g differs from the source" points to font creation. "The last line crosses the print margin" points to page layout. That separation makes a fix easier to evaluate.
Make the product boundary visible
In our products, FontKind AI handles font creation from a clear handwriting photo, a text description, or a style reference image. It provides text previews and TTF download. Current output covers 95 ASCII characters: English uppercase and lowercase letters, digits, punctuation, and space. Photo-based results distinguish restored characters from style completions.
Handwriting AI handles handwritten pages and printable handwriting, cursive, tracing, and spelling worksheets. Users adjust paper, ink, spacing, and layout and export page files. FontKind AI has its own credits and subscription. Previewing already linked personal fonts on Handwriting AI is free; exporting or printing pages with them requires Starter or higher.
The practical interface rule is simple: name the artifact before asking someone to export it. Use "Download TTF" for a font and "Export PDF" for a page. Show character coverage beside the font, and paper size beside the document. These details tell users what they are getting and give developers a clear place to investigate when something goes wrong.
Top comments (0)