Sådan vælger du det rigtige filformat til håndskrevet tekstgenkendelse (HTR)

Sidst opdateret: 20 Aug, 2026

OCR-filformater til historiske og håndskrevne dokumenter

Bevaring af kulturarv gennem digitalisering er gået ind i en renæssance. Mens de tidlige optiske tegngenkendelsessystemer (OCR) blev udviklet til at læse uberørte, maskintrykede papirer fra det tyvende århundrede, står moderne kulturarvsinstitutioner over for en langt mere rodet og rig udfordring: middelalderlige manuskripter, 1800‑tals kursiv korrespondance, skrøbelige oplyste folier og århundredegamle registre.

At transskribere historiske dokumenter handler ikke længere kun om at udtrække ren ASCII-tekst. Det kræver at fange kontekst—den fysiske geometri af siden, grundlinjekurver, korrigeringer af gennemblødning, marginalia, forkortelser og paleografisk usikkerhed. Dette specialiserede område, ofte kategoriseret under Handwritten Text Recognition (HTR), er stærkt afhængig af det filformat, der bruges til at gemme og udveksle både billedkoordinater og tekstlag.

At vælge det forkerte skema kan fjerne vigtige grundlinjedata, bryde justeringen med IIIF (International Image Interoperability Framework) manifest, eller forhindre langsigtet digital bevaring. Her er en definitiv guide til de førende OCR- og HTR-filformater for historiske dokumenter, deres strukturelle styrker, og hvordan du bestemmer det rette valg til din arkiveringspipeline.

Det Historiske Dilemma: Hvorfor Alm. Tekst og Standard PDF’er Mislykkes

Maskinprintet OCR leverer ofte simple .txt-filer eller “sandwich”-PDF’er med skjulte tekstlag under scanningen. For historiske manuskripter og kursiv håndskrift fejler disse output af tre grundlæggende årsager:

1. Ikke-lineær tekst og komplekse layout: Historiske skrivere fulgte ikke pæne rektangulære gitter. Teksten flyder ind i marginerne, vikles omkring oplyste initialer, væver sig mellem indsatte interlineære rettelser, eller løber lodret langs ryggen.
2. Kurvede og skrå basislinjer: Kursive skrifter følger sjældent en stiv horisontal akse. HTR-motorer som Transkribus, Kraken og eScriptorium baserer sig på polylinje-basislinjer i stedet for afgrænsningsbokse for at fortolke ligatur-tunge skrifttyper.
3. Paleografisk kompleksitet og metadata: Arkivforskning kræver sporing af forkortelser, historiske stavemålsvariationer, beskadigede læsninger og linjeniveau tillidsværdier. Standarddokumentformater kasserer denne granularitet.

For at bevare troværdigheden over for den oprindelige genstand, stoler arkivfællesskabet på strukturerede XML-skemaer designet til at bevare layouttopologi sammen med transskriberet tekst.

1. PAGE XML: Guldstandarden for håndskrevet tekstgenkendelse (HTR)

Udviklet af PRImA (Pattern Recognition & Image Analysis) Research Lab, PAGE XML (Page Analysis and Groundtruth Elements) betragtes bredt som det mest avancerede format til håndskrevet tekstgenkendelse og avanceret layoutanalyse.

Kernearkitektur

PAGE XML behandler det fysiske dokument som en hierarkisk struktur:

• PcGts (Rod)
  • Page (Billeddimensioner og overordnet læserækkefølge)
    • TextRegion (Afsnit, overskrifter, marginalnoter, opsamlingsord)
      • TextLine
        • Coords (Polygonkoordinater omkring linjen)
        • Baseline (En række punkter, der følger den sande grundlinje for skriften)
        • TextEquiv (Den genkendte tekst, med valgfrie tillidsmålinger)

Hvorfor den udmærker sig for historiske manuskripter

• Polygon- og polylinjepræcision: I stedet for at tvinge tegn ind i rektangulære afgrænsningsbokse, bruger PAGE XML polygongrænser med flere punkter og kontinuerlige grundlinjer. Dette forhindrer overlappende kursiv hævede og sænkede dele i at forstyrre segmenteringen.
• Granulære strukturelle typer: Regioner kan klassificeres præcist (f.eks. marginalia, drop-capital, signature-mark, header, editorial-note).
• Broad Software Ecosystem: Den fungerer som det primære interne og eksportskema for flagskibs HTR-platforme som Transkribus, eScriptorium, og Kraken.

2. ALTO XML: Bibliotekets og arkivets kraftcenter

ALTO (Analyzed Layout and Text Object) er en åben XML-standard vedligeholdt af Library of Congress og bredt adopteret af nationale biblioteker, herunder Bibliothèque nationale de France (BnF) og British Library.

Kernearkitektur

ALTO strukturerer layout hierarkisk fra Page til PrintSpace, ned til TextBlock, TextLine og String (individuelle ord eller tokens). Det pakkes ofte ind i en METS (Metadata Encoding and Transmission Standard) wrapper for at knytte strukturelle metadata til højopløselige masterbilleder.

Vigtige styrker og anvendelsestilfælde

• Mass Digitization Workflows: ALTO blev designet med industriel skala nyheds- og bogdigitalisering i tankerne. Det koder tydeligt skrifttypeattributter, ordniveau-koordinater, tegnsikkerhed og mellemrum.
• Moderne HTR-understøttelse (ALTO 4): Tidligere versioner af ALTO var stærkt afhængige af rektangulære koordinater (HPOS, VPOS, WIDTH, HEIGHT). Men fra og med ALTO version 4 introducerede skemaet <Shape>-polygoner og polylinje-baselines, hvilket lukker det funktionelle hul med PAGE XML for håndskrevne materialer.
• Langtidsholdbar bevaring: Da det er en officiel standard støttet af internationale biblioteks-konsortier, garanterer ALTO langsigtet stabilitet og arkivkvalitets bagudkompatibilitet.

3. hOCR: Den web‑første, letvægtsstandard

Oprettet af Thomas Breuel, hOCR tager en pragmatisk tilgang: i stedet for at skabe et helt nyt XML-skema, indlejrer den layout- og transskriptionsmetadata direkte i semantisk HTML/XHTML ved hjælp af mikroformater og klasseattributter.

Typisk syntakseksempel

<div class="ocr_page" id="page_1" title="bbox 0 0 2480 3508">
  <div class="ocr_carea" id="block_1_1">
    <p class="ocr_par" id="par_1_1">
      <span class="ocr_line" id="line_1_1" title="bbox 150 320 2200 410; baseline 0 -5">
        <span class="ocrx_word" id="word_1_1" title="bbox 150 325 380 405; x_wconf 92">Incipit</span>
      </span>
    </p>
  </div>
</div>

Fordele og ulemper ved historiske materialer

• Fordele: Browsere kan gengive det nativt. Det kan nemt transformeres ved hjælp af ren CSS og JavaScript, og det er standardformatet for struktureret eksport for motorer som Tesseract.
• Ulemper: Indbygget understøttelse af komplekse, friformede flerpunkt-basiskurver er begrænset. Selvom det er praktisk for tidlige trykte værker (incunabula eller rene bredsider), har hOCR svært ved uregelmæssige manuskriptlayout og lagdelte marginalia.

4. TEI-XML: Det akademiske og digitale humanistiske benchmark

Formatet Text Encoding Initiative (TEI) er ikke strengt et OCR-motor outputformat; snarere er det den førende standard for kritiske digitale udgaver og videnskabelig repræsentation af litterære og historiske tekster.

Forbindelse af OCR/HTR til TEI

Moderne pipelines stopper sjældent ved rå tegngenkendelse. Forskere bruger værktøjer som Transkribus TEI Exporter eller automatiserede XSLT-pipelines til at oversætte PAGE XML eller ALTO-filer til TEI-kompatibel XML:

• Forkortelser udvides (<choice><abbr>...</abbr><expan>...</expan></choice>).
• Sletninger, tilføjelser og skribenthåndter klassificeres formelt (<add>, <del>, <handShift>).
• Layoutdata bevares sammen med litterær analyse via <facsimile>- og <surface>-elementerne.

Hvis dit historiske projekt har til formål at skabe en interaktiv kritisk udgave eller semantisk søgbar videnskabelig arkiv, er konvertering af dine OCR/HTR-data til TEI-XML ofte det nødvendige afsluttende trin.

Sammenligningsmatrix: OCR/HTR-formater på et overblik

Praktiske anbefalinger: Vælg din arkivpipeline

For at etablere en effektiv, fremtidssikret digitaliseringspipeline:

1. For rene håndskrevne manuskripter & arkiver: Standardiser din transskription og layoutudtræk på PAGE XML. Dens baseline-beregning og polygonkonturering håndterer ikke-standardiserede håndskrifter med minimal datatab.
2. For store biblioteker & blandede samlinger: Vælg ALTO XML (v4.2 eller højere) sammen med METS. Dette garanterer problemfri integration i standardarkitekturer for digitale arkiver og systemer til digital asset management (DAMS).
3. For webpræsentation & fuldtekstsøgeindekser: Brug hOCR eller udled letvægts GeoJSON/Web Annotation-strukturer fra PAGE XML for at drive interaktive IIIF‑visere (såsom Mirador eller Universal Viewer) med live tekstoverlejringer i browseren.
4. For videnskabelige udgaver & paleografisk forskning: Generér din ground truth i PAGE XML, udfør genkendelse, og send outputtet gennem en automatiseret konverter for at generere TEI-XML til redaktionel markup.

Ved at matche de strukturelle muligheder i disse formater med de paleografiske krav i dit kilde materiale, sikrer du, at hvert strøg, hver forkortelse og hver historisk nuance forbliver læselig i århundreder fremover.

Ofte stillede spørgsmål (FAQ)

Q1. Hvad er den grundlæggende forskel mellem standard OCR og HTR? OCR genkender ensartet maskintryk typografi, mens HTR (Handwritten Text Recognition) bruger dybe neurale netværk til at afkode kontinuerlig, variabel håndskrift og buede grundlinjer.

Q2. Kan Tesseract OCR producere PAGE XML eller ALTO-output for historiske dokumenter? Ja, Tesseract kan generere native ALTO XML og hOCR-output, og tredjeparts wrappers kan konvertere disse resultater til PAGE XML.

Q3. Hvorfor er grundlinjer vigtigere end afgrænsningsbokse i transskription af håndskrevet tekst? Grundlinjer sporer den naturlige, bølgende linje i menneskelig håndskrift, hvilket gør det muligt for software at adskille overlappende hæve- og sænkelementer, der kolliderer inden for stive afgrænsningsbokse.

Q4. Hvordan interagerer IIIF-standarden med disse OCR-filformater? IIIF leverer højopløselige billeder via åbne web-API’er, mens formater som ALTO eller PAGE XML leverer koordinatdata, der kan konverteres til IIIF Content Search-annotationer.

Q5. Hvilket filformat er lettest at konvertere direkte til en søgbar PDF? Både hOCR og ALTO XML kan kombineres med de originale sidebilleder for at konstruere søgbare PDF-filer med to lag ved hjælp af værktøjer som OCRmyPDF.

Se også

• PDF/A-3 - Det hybride monster? Indlejring af originale data i din OCR
• Forståelse af OCR-filformater - HOCR vs ALTO vs PDF/A forklaret
• Hvad er forskellen mellem PDF og FDF?
• Hvad bruges FDF til? Forstå formålet med Forms Data Format
• PDF vs Word: Hvilken skal du bruge, og hvornår?