Introduction
For many years, the Buddhist Digital Resource Center (BDRC) has collected and scanned hundreds of thousands of Tibetan manuscripts, creating an archive containing thousands of volumes. BDRC has also made this archive more accessible by preparing scholarly outlines of the works within it. These outlines identify texts, chapters, tables of contents, and editorial sections by volume and image-level page spans.
Improvements in OCR technology created the next opportunity: converting page images into searchable text. BDRC trained its in-house Tibetan OCR model, Yigdzin 1, based on PaddleOCR-VL, and has applied OCR across the collection at archive scale. The model currently reports a mean character error rate (CER) of 6.28% across its 1,070-page benchmark, with a median page CER of 1.42%.
OCR alone, however, does not carry over the structure recorded in the image-level outlines. To integrate OCR e-texts cleanly into the BDRC library, each volume-and-page span must be translated into a character span over the OCR text. We designed the BDRC Text Extractor package to perform that transfer.
The result is a volume-length OCR string in which every outlined text, table of contents, editorial section, and chapter has precise span_start and span_end coordinates. A reader or application can move directly from an outline entry to its OCR passage, extract one work from a large volume, or build a structured e-text without repeatedly consulting page images.
The gap between an outline and an e-text
A BDRC outline identifies a work by volume and image range, but an image range is not yet a character range. The outlines contain several situations:
- Clean boundary: one work ends on image 20 and the next starts on image 21. The page division gives us the character boundary directly.
- Single overlap: one work ends and another starts on the same image. The boundary must be located inside that page’s OCR.
- Multiple overlaps: several short works start and end on one image, requiring multiple boundaries in reading order.
- Invalid outline: an end page is missing, or one segment’s range improperly overlaps another. These cases must be logged and corrected.
- Multi-volume text: one outlined text crosses a volume boundary and requires a separate workflow.
Overlapping pages are the central challenge: assigning the whole shared page to either work adds text from its neighbor or loses part of the work. OCR variation in spacing, line breaks, punctuation, and recognition makes locating the exact character boundary harder.
Methodology
Bringing the source layers together
The extraction process starts from three sources:
- released BDRC outline data, which supplies titles, part types, volumes, and image ranges;
- image-instance data, which maps a bibliographic volume number to a scanned volume identifier;
- Yigdzin OCR output, which supplies one OCR string for each image.
Some pages were skipped during Yigdzin inference. Before extraction, those gaps were filled with text from the Google Vision OCR that BDRC had previously run across its collection. This keeps the image sequence complete, which is essential because the outline coordinates refer to positions in that sequence.
During preparation, the extractor finds released outlines that contain text, table-of-contents, or editorial sections. It reads the matching image-instance record, resolves the OCR files for each scan volume, and keeps the outline nodes belonging to that reproduction.
The prepared material is grouped by BDRC work identifier so that everything related to one collection or book is available from one folder. For example, outline.trig contains the page-span outline, while the manifest.json beside it records the work identifier, outline identifiers, and one entry per volume with its scan-volume identifier, OCR version, and OCR inference path.
Works containing a text that crosses volume boundaries are separated from non-multi-volume works. The current character-span workflow supports non-multi-volume texts; direct handling of text spans that cross volumes is planned for a later version.
This preparation stage matters because BDRC identifiers describe different layers of the collection. The outline, reproduction, scan volume, image number, and OCR file all need to refer to the same physical sequence before any text boundary can be trusted.
Turning pages into one addressable text
For each volume, OCR pages are joined in image order while their start and end offsets are recorded. Clean page transitions can therefore be converted directly into character boundaries.
For a shared page, a break finder locates the ending work’s terminal marker, using clues such as རྫོགས་སོ, མངྒ་ལཾ, closing punctuation, and the next work’s opening mark. Multiple breaks are returned in reading order, and surrounding context helps map each result back to the original OCR despite whitespace differences.
The output JSON stores the complete OCR string and the span_start and span_end of each segment and chapter.
Three ways to find a shared-page boundary
We implemented three break finders with the same input and output contract. This allows the extraction pipeline to change methods without changing how outlines or character spans are built.
A rule-based finder
The rule-based method searches for clusters of Tibetan closing punctuation and ranks each possible break using nearby evidence. In simple terms, a candidate receives a higher score when:
- it contains a stronger cluster of closing punctuation;
- a known ending or colophon expression appears just before it;
- a likely opening mark or opening phrase for the next work appears soon after it; or
- it occurs near the end of the page.
Candidates that are too close together are treated as duplicates, and only the stronger one is kept. Because the outline tells us how many breaks should occur, the finder then selects that many highest-scoring candidates and returns them in reading order. For example, if three breaks are expected but four candidates are detected, only the three strongest candidates are used. Page numbers and spaces immediately before the next opening marker may be included in the ending span.
This method is deterministic, fast, local, and requires no external service. More importantly, it encodes a focused understanding of the particular task: finding the transition between works, rather than detecting arbitrary changes in a page.
mmBERT
The mmBERT finder uses the local BDRC/Bo-Boundary-mmBert token-classification model. It scores tokens as possible boundaries, combines consecutive boundary tokens, and adjusts a detected start toward a nearby Tibetan opening marker. Long pages are processed in overlapping windows.
This approach avoids an API dependency and can recognize learned patterns that are difficult to express as fixed rules. Its behavior, however, depends on the coverage and calibration of the trained model.
Gemini
The Gemini finder asks gemini-2.5-flash to identify and copy the terminal marker of the ending work, together with ten characters of left context used to relocate that marker in the OCR. We use separate instructions for single- and multi-break pages because one general prompt tended to over-predict on single-break pages and under-predict when several breaks occurred on a page. For multi-break pages, Gemini is told exactly how many boundaries the outline implies and returns them in order.
Gemini results are cached, both to avoid repeating remote calls and to make later processing reproducible from the saved responses. The finder is particularly useful where a boundary depends on broader textual context rather than punctuation alone.
The finders can also be routed by page type. In the combined configuration, Gemini handles pages with one expected break and the rule-based method handles pages with several expected breaks.
Producing and validating the output
Using the prepared outline and manifest, the package writes one JSON file per scan volume. Each file contains the unchanged joined OCR text and the character coordinates of every outline segment. Clean boundaries are calculated directly; overlapping boundaries are resolved by the selected finder.
Invalid outlines, missing pages, and unresolved overlap boundaries are written to a log. This makes it possible to address a problem either by correcting the source TriG file or by improving the relevant rule without stopping the rest of the collection-level run.
Evaluation
Creating a benchmark for overlapping-page navigation
We created a page-level benchmark specifically around the difficult case: real OCR pages on which outlined texts overlap. The source pages came from prepared non-multi-volume work data, keeping the benchmark close to the material the extractor is designed to process.
The dataset contains 96 pages from 77 works and 77 scan volumes. It is deliberately balanced by page type:
- 48 pages contain one work-to-work boundary;
- 48 pages contain multiple boundaries;
- together, the pages contain 149 gold text breaks.
Within the multi-break group, 44 pages contain two boundaries, two contain three, and two contain four. This matters because finding one obvious ending is a different task from navigating several short texts on the same page.
Each benchmark item keeps the OCR page as plain text and records its work identifier, scan-volume identifier, image number, relevant outline segment identifiers, and expected number of breaks. Its gold annotation records every break as a page-local character offset: the exclusive end of the terminal marker belonging to the work that is ending. Context and the marker text are also represented in the same shape used by finder output.
This design tests the decision needed by the production pipeline. It does not ask whether a model can describe the page in general terms; it asks whether it can return a boundary that can be mapped to the correct place in the actual OCR.
How the evaluation works
A prediction counts as a hit when it falls within 15 characters of an unused gold offset. Each gold boundary is matched to the nearest available prediction inside that tolerance. A missed boundary lowers recall, while an extra prediction lowers precision.
We report recall, precision, and F1 for all pages and separately for single- and multi-break pages. We also count exact pages: pages with every expected break matched, no extra prediction, and no finder error. Character error is measured only for matched predictions.
The distinction between break-level and page-level measures is important. A finder may locate most boundaries on a crowded page and still fail to make that page completely navigable. Exact-page accuracy captures this stricter requirement.
Results
The evaluation report contains results for all 96 pages, and none of the methods raised a page-level error.
| Finder | Recall | Precision | Overall F1 | Hits | Exact pages | Single-page F1 | Multi-page F1 | Mean error |
|---|---|---|---|---|---|---|---|---|
| Rule-based | 86.6% | 86.0% | 86.3% | 129/149 | 75/96 | 87.5% | 85.7% | 0.17 chars |
| mmBERT | 53.7% | 87.9% | 66.7% | 80/149 | 46/96 | 87.1% | 55.5% | 0.28 chars |
| Gemini | 75.8% | 86.9% | 81.0% | 113/149 | 72/96 | 92.5% | 75.3% | 1.07 chars |
| Gemini + rule-based | 87.2% | 88.4% | 87.8% | 130/149 | 76/96 | 92.5% | 85.7% | 0.35 chars |
Key insight: The best individual finder depends on the structure of the page. Gemini performed best on pages containing one boundary, while the rule-based finder was more dependable when several texts shared a page. Routing single-break pages to Gemini and multi-break pages to the rule-based finder therefore produced the best overall result. mmBERT was precise when it returned a boundary but often found too few, especially on multi-break pages. All configurations had a median error of zero on matched boundaries, showing that locating a recognized break was generally accurate; the harder problem was finding every break that was present.
Collection-scale run
We then ran the rule-based character-span workflow across all prepared non-multi-volume works. The run produced 14,371 volume-outline JSON files. Its log also identified the cases that still need attention:
- 2,084 volumes were skipped because a later outline segment started before the preceding segment ended;
- 112 volumes were skipped because at least one segment had no end page;
- 1,970 overlap pages had no detected text break, so the full shared page was assigned to the earlier segment as a fallback; and
- 6 overlap pages were absent from the OCR page index, so the page-start fallback was used.
These numbers separate successful volume generation from source-data errors and boundary-detection fallbacks. The log provides the exact work, volume, page, and segment identifiers needed for correction.
Credit
The BDRC Text Extractor was developed by Dharmaduta based on specifications from the Buddhist Digital Resource Center for The BDRC Etext Corpus, a project funded by the Khyentse Foundation.