eScriptorium and Kraken: A No-Training Alternative

eScriptorium is an open-source platform that does not read a page until you load a Kraken recognition model, either one someone has published or one you train. If a published model reads your hand well, or if building models is part of your project, eScriptorium is an excellent choice. If you need to read Latin-script pages now, across many hands, without training anything, a ready zero-shot model such as Leo's is the faster path.

eScriptorium is a capable, open-source platform for transcribing historical manuscripts. It ships without a general-purpose recognition model, so it does not transcribe until one is loaded. To get text off a page you either obtain a trained Kraken model that suits your language and hand, or build one from ground truth yourself. Public models are better than they were: medieval Latin and French have strong ones, and a generalist model for the early-modern and modern periods, McCATMuS, now gives English, German, Spanish and Italian material a starting point. How well any of them reads your hand is something you find out by testing, and often improve by fine-tuning. Leo is the alternative for researchers who need to read Latin-script hands now, without that step: a ready, zero-shot transcription model wrapped in a document workspace.

That is the whole decision. The rest of this article works through it honestly, because "no training" is a claim worth testing carefully, and eScriptorium is a serious tool that deserves an accurate description rather than a straw man.

What eScriptorium Is, and How It Works with Kraken

The most common misconception about eScriptorium is that it is a transcription engine. It is not. eScriptorium is a web platform for manual and automated segmentation and text recognition: a Django application that acts as a graphical interface and orchestration layer over a separate recognition engine called Kraken. Kraken does the reading. eScriptorium is where you manage images, correct output, and organize training data.

This matters because of what Kraken is: a turn-key OCR/HTR library "optimized for historical and non-Latin script material," and, crucially, script- and language-agnostic by design. That agnosticism is a genuine strength. Kraken will learn Greek, Hebrew, Arabic, or a Carolingian minuscule with equal willingness. But agnosticism has a cost: the system knows nothing until you teach it, or until you load a model someone else has taught. eScriptorium ships Kraken's default segmentation model, which finds text lines on a page, but no general-purpose recognition model comes with the install. Recognition (turning those lines into characters) requires a model you supply. Kraken can list and download published models from a public model repository, which makes that step easier than it once was.

It also helps to know that eScriptorium is software rather than a service. There is no single eScriptorium website. Many universities and research projects run their own instance and give accounts to their members, so "using eScriptorium online" usually means asking your institution, or a project you work with, for access.

So the real eScriptorium workflow has two forks. Either you find a public model that matches your material, load it, pair it with a segmentation model, and validate it on a small in-domain sample, or you train your own.

The Two Paths, and Where Each One Stalls

Path One: Find a Public eScriptorium Model

The open ecosystem for Kraken models, chiefly HTR-United and Zenodo deposits, is real and growing. If your manuscripts fall inside its coverage, you can reach usable transcription without training anything. That is the "no-training" case, and it is worth taking seriously.

The question is coverage, and how close it gets to your hand. The most mature and most-cited open deposit is CREMMA-Medieval, covering medieval Latin (11th–16th century) and Old French (13th–15th century) across 2,828 folders and 86,832 transcription lines. French and medieval Latin, in other words, are well served. For later material, the most useful development is McCATMuS (Chagué and colleagues, 2024). It is a generic Kraken model for handwritten, printed and typewritten documents from the early sixteenth century to the present, in French, Latin, Spanish, English, German, Italian and Occitan. It is the natural first model to try on early-modern and modern material. Beyond it, coverage is uneven: language- and hand-specific models for English, Dutch, Italian and Spanish are thinner and patchier, and German Kurrent and Sütterlin remain thinly covered by open models.

Note carefully that this is a question of hand as well as script and language, and that is where the "no-training" promise gets specific. Kraken can read the Latin alphabet in principle, and a generalist model gives you a reading. Whether that reading is good enough on a seventeenth-century English will in secretary hand, or a nineteenth-century Dutch parish register, is a separate question, and you answer it by validating on your own pages. For a fuller treatment of why script, language and hand are three different constraints, see our guide to which languages and scripts HTR can read.

And even when a public model fits, deployment is not one click. The model must be loaded, matched to a segmentation model, validated against your own sample, and often fine-tuned before it performs well on your specific hand. A public model is a head start, not a finished job.

Path Two: Train Your Own

If no public model reads your material well enough, you build or fine-tune one. This is where eScriptorium's design shows its real character: it is, at heart, an excellent environment for producing ground truth, the per-line pairs of image and correct transcription (in ALTO or PAGE XML) that a model learns from.

The volumes involved are well documented. Kraken's own training guidance notes that most western texts run 25–40 lines per page, so "upward of 30 pages" must be preprocessed and transcribed to start: roughly 750 to 1,200 lines. The current training tutorial works through an example built on 876 lines. Accuracy seldom improves after 50 epochs, which take between 8 and 24 hours on a normal desktop; characters appearing fewer than ten times in your ground truth will most likely not be recognized well. Fine-tuning the segmentation model for a book-specific layout wants 30–50 labelled pages, with stronger results around 1,000.

None of this is a criticism of eScriptorium. It is simply what training a model is. For a research group with a large, homogeneous corpus in a single hand (the exact case eScriptorium and Kraken were built to serve), that investment amortizes well across thousands of pages. The trouble is that a great deal of archival research does not look like that. It looks like forty pages here in one clerk's hand, sixty there in another, a bundle of letters in a third. Every distinct hand potentially restarts the ground-truth clock, and the payoff per model shrinks. The trade-offs of training a model to read handwriting are the same whichever platform you train on.

The Cost That "Free" Hides

eScriptorium is free of licence fee, and open-source software genuinely lowers a real barrier. But "free" describes the licence, not the total cost of ownership. The recommended deployment is via Docker containers. Running it in earnest means Linux, 8–16 GB of RAM, and, for training at any speed, an NVIDIA GPU. Installation is not always smooth: a long-standing GitLab issue documents the migration pain from the obsolete nvidia-docker2 to the current container toolkit for GPU support. If your institution already runs a shared instance, most of that is someone else's job. If not, add IT time to stand it up and maintain it, plus the researcher-weeks spent building ground truth, and the true cost is measured in infrastructure and hours, not dollars.

For a well-resourced digital-humanities lab with technical staff, this is entirely manageable and often the right choice: the control and reproducibility of a self-hosted, open pipeline are real scholarly goods. For an individual historian or a small team whose bottleneck is reading the documents, not building infrastructure, the calculus is different.

Where Leo Fits: A Ready Model, No Training Step

This is the specific gap Leo is built to close. Where eScriptorium needs a recognition model found, validated or trained before you transcribe, Leo's own model, ATR-1, reads Latin-script material out of the box. It is a Transformer specially tuned for historical documents: manuscript hands including secretary, cursive and court hands, and printed matter, especially the early-modern typography that conventional OCR struggles with. It reads the image at high resolution, where general AI models downsample it, and it is trained to transcribe what is on the page rather than normalise it: archaic spelling, the long s and the scribe's abbreviations survive. There is no ground truth to assemble, no segmentation model to pair, no GPU to provision and no epochs to wait through. You upload page images, including straight from a phone camera in the reading room, and transcribe.

The scope is defined by the writing system, not the language. Any language written in the Latin alphabet is in scope, with performance strongest in English and strong across French, German, Spanish, Italian, Dutch and Latin among others; non-Latin scripts are not. That speaks directly to the coverage question above: English wills, Dutch registers and other vernacular material where you would otherwise be validating a generalist model or training a specific one. Transcription is not translation. Leo transcribes what is on the page; rendering it into modern English is a separate, one-click Translate Transformation that writes to a new tab, leaving the base transcription untouched.

Like any machine transcription, ATR-1's output is a first draft to check against the image, and the honest test is a sample of your own pages. What Leo adds is a guard on the failure that matters most. Any text-generating model can break down on material unlike its training data; the classic sign is a line repeated over and over. ATR-1 checks its own output for failure patterns like that. Suspect output is hidden, retried automatically, and if it still cannot succeed the job stops and the credit is refunded. The errors that get through tend to be the recoverable kind: a wrong letter or word you catch against the image displayed beside the text, not fluent invented text. And as users correct transcriptions, those corrections feed back into ATR-1's training, so the model improves across releases without anyone training a model of their own.

Leo also replaces the "find a model" step with a menu. In the transcription window you choose the model for the document: ATR-1 is the default, and the major OpenAI, Gemini and Claude models sit alongside it. You can run one of them as a second reading into its own tab and compare it with ATR-1's, or use a small model for clean, legible print (a 19th-century book, a typescript) for a fraction of a credit an image. None of them needs training, and switching costs a click rather than a validation run.

There is a second difference, and for daily work it may matter more than the reading itself. eScriptorium is a recognition-and-annotation platform; organizing a collection, describing it and analyzing it happen elsewhere. Leo folds the surrounding workflow into one place: upload, organize into folders, attach structured metadata, search across everything with fuzzy matching, edit in a rich-text editor that preserves strikethroughs, insertions and marginalia, and export to TEI XML, Word, PDF or HTML. On top of a faithful base transcription, Transformations can summarize, classify, extract named entities or translate, each result landing in its own tab, so interpretation is layered on the source rather than baked into it.

What Leo does not do is worth stating plainly, because it marks the honest boundary of this comparison. Leo offers no user model-training or fine-tuning: there is no path to teach it your specific idiosyncratic hand the way Kraken lets you. It is a hosted service, not open software you can run on your own server. It exports TEI, not ALTO or PAGE XML, so it is not a drop-in producer of the line-level ground-truth files an eScriptorium pipeline consumes. If your project genuinely requires a custom-trained, reproducible, open-source model over a homogeneous corpus, eScriptorium is the right tool, and Leo is not pretending otherwise.

How to Choose

Reduced to essentials, the decision turns on three questions.

Does a Public Kraken Model Already Read Your Material Well Enough?

If you work in medieval Latin or Old French, quite possibly yes, and the "no-training" case for eScriptorium is real. For early-modern and modern material, McCATMuS is the obvious first model to try. Load it, validate it on a sample, and you may need little or no custom training. If the sample shows it struggling with your particular hand, which is more likely with English, German, Dutch, Spanish or Italian vernacular hands than with the medieval sets, you are looking at fine-tuning or building ground truth.

Do You Have the Infrastructure and the Corpus to Justify Training?

A technical team with a large, homogeneous body of material in a consistent hand will get excellent, reproducible results from a self-hosted eScriptorium/Kraken pipeline, and full control over it. An individual researcher moving across many hands, whose bottleneck is reading rather than engineering, will spend that same effort on setup instead of scholarship.

Where Is Your Time Better Spent?

This is the real question underneath the other two. Every hour building ground truth or wrestling a Docker GPU install is an hour not spent reading, analyzing and writing. If model-building is itself part of your project (a methods contribution, a shared resource for a field), that time is well spent. If transcription is merely the wall between you and your sources, a ready zero-shot model removes the wall without asking you to become a machine-learning practitioner first.

Neither answer is universally right. The open-source, trainable path and the ready-model path solve different problems, and a researcher who understands the difference will choose well. The fairest way to decide is the same for both: run a few of your own hardest pages through each, as our guide on how to test AI transcription on your own documents describes. For a broader map of how these tools sit against general OCR, large language models, other open workflows such as OCR4all and collection managers, our comparison of HTR software and alternatives lays out the full picture.

Whatever model reads your first draft, the transcription is not finished when the machine stops. It is finished when you have checked it against the image, attending first to the names, dates and figures where a single wrong character does the most damage, and made the editorial decisions no model can make for you. The tool that gets you to a verifiable draft fastest, without demanding weeks of setup you did not come to the archive to do, is the one that returns the most hours to the work only a historian can do: reading these sources closely, and understanding what they say.

Frequently Asked Questions

What is a good eScriptorium alternative that doesn't require training a model?

Leo is an eScriptorium alternative built for researchers who need to read Latin-script hands now, without training a model first. eScriptorium does not transcribe until you load a Kraken recognition model, either a public one validated on your material or one built from ground truth. Leo's own model, ATR-1, is a zero-shot model specially tuned for historical documents. It reads Latin-script material out of the box, including secretary, cursive and court hands as well as printed matter, and transcribes what is on the page without modernising it. The same menu offers the major OpenAI, Gemini and Claude models for a second reading in its own tab. You upload page images, even straight from a phone camera, and transcribe: no ground truth, no segmentation model to pair, no GPU, no training epochs.

Does eScriptorium come with a transcription model built in?

No general-purpose recognition model is installed with eScriptorium, so it does not transcribe until one is loaded. It is a web platform for manual and automated segmentation and text recognition: a graphical interface and orchestration layer over a separate engine called Kraken, which does the actual reading. eScriptorium does include Kraken's default segmentation model, which finds text lines on a page. Turning those lines into characters requires a recognition model. You can download a published one (Kraken can fetch models from a public repository, and McCATMuS is a generalist starting point for early-modern and modern material), validate it on your pages, and fine-tune it if needed, or train your own from ground truth in ALTO or PAGE XML.

How much ground truth do you need to train a Kraken model in eScriptorium?

Kraken's own training guidance suggests starting with upward of 30 pages of transcribed material, roughly 750 to 1,200 lines, since most western texts run 25–40 lines per page. The current training tutorial works through an example built on 876 lines. Accuracy seldom improves after 50 epochs, which take between 8 and 24 hours on a normal desktop, and characters appearing fewer than ten times in your ground truth will most likely not be recognized well. Fine-tuning the segmentation model for a book-specific layout wants 30–50 labelled pages, with stronger results around 1,000.

Which languages does the open Kraken model ecosystem cover well?

Medieval Latin and Old French are covered best. The most mature and most-cited deposit, CREMMA-Medieval, covers medieval Latin from the 11th–16th century and Old French from the 13th–15th century across tens of thousands of transcription lines. For later material, McCATMuS (2024) is a generic model for handwritten, printed and typewritten documents from the early sixteenth century to the present, in French, Latin, Spanish, English, German, Italian and Occitan. Hand-specific models for English, Dutch, Italian and Spanish are thinner, and German Kurrent and Sütterlin remain thinly covered by open models. Coverage of a language is not the same as a good reading of your hand: validate any public model on a sample of your own pages.

Is eScriptorium really free to use?

eScriptorium is free of licence fee and open-source, but "free" describes the licence, not the total cost of ownership. It is software rather than a service, and many universities and projects run a shared instance for their members, which is the easiest way in. Running it yourself is recommended via Docker containers, and in earnest means Linux, 8–16 GB of RAM and, for training at any speed, an NVIDIA GPU. GPU setup has documented migration pain around the container toolkit. Add IT time to stand it up and maintain it, plus the researcher-weeks spent building ground truth, and the true cost is measured in infrastructure and hours, not dollars. For a well-resourced lab this is manageable; for an individual researcher it may not be.

How do eScriptorium and Kraken work together?

Kraken is the recognition engine; eScriptorium is the web interface around it. Kraken does the machine work: segmenting a page into lines and recognising the characters in each line, using models trained for particular scripts, languages or hands. eScriptorium is where people do the human work: uploading images, running Kraken's segmentation and recognition models, correcting the output line by line, and turning those corrections into ground truth to train or fine-tune new Kraken models. You can use Kraken on its own from the command line, but most humanities projects meet it through eScriptorium. If you would rather not choose, validate or train a model at all, a ready zero-shot model such as Leo's ATR-1 is the alternative.