OCR-tiedostomuodot historiallisille ja käsinkirjoitetuille asiakirjoille

Kulttuuriperinnön säilyttäminen digitalisoinnin avulla on kokenut renessanssin. Vaikka varhaiset optisen merkkien tunnistuksen (OCR) järjestelmät suunniteltiin käsittelemään puhdasta, koneellisesti painettua 1900-luvun paperityötä, nykyaikaiset kulttuuriperintöinstituutiot kohtaavat paljon sotkuisemman ja rikkaamman haasteen: keskiaikaiset käsikirjoitukset, 1800-luvun kursiivikirjeet, hauraat valaistut foliot ja vuosisatoja vanhat rekisterit.

Historiallisten asiakirjojen litterointi ei enää ole pelkästään tavallisen ASCII-tekstin poimimista. Se vaatii kontekstin tallentamista—sivun fyysinen geometria, peruslinjakäyrät, läpikulun korjaukset, marginaalit, lyhenteet ja paleografinen epävarmuus. Tämä erikoistunut ala, joka usein luokitellaan käsinkirjoitetun tekstin tunnistukseen (HTR), on vahvasti riippuvainen tiedostomuodosta, jota käytetään sekä kuvan koordinaattien että tekstikerrosten tallentamiseen ja vaihtamiseen.

Väärän skeeman valinta voi poistaa tärkeät peruslinjatiedot, rikkoa yhteensopivuuden IIIF (International Image Interoperability Framework) -manifestien kanssa tai estää pitkäaikaisen digitaalisen säilyttämisen. Tässä on lopullinen opas historiallisten asiakirjojen johtaviin OCR- ja HTR-tiedostomuotoihin, niiden rakenteellisiin vahvuuksiin sekä siihen, miten määrittää oikea valinta arkistointiputkessasi.

Historiallinen dilemman: Miksi Pelkkä teksti ja standardi PDF:t epäonnistuvat

Koneellisesti painettu OCR tuottaa usein yksinkertaisia .txt-tiedostoja tai “sandwich”-PDF-tiedostoja, joissa on piilotettuja tekstikerroksia skannauksen alla. Historiallisille käsikirjoituksille ja kursiiviselle käsinkirjoitukselle nämä tulosteet epäonnistuvat kolmesta keskeisestä syystä:

1. Ei-lineaarinen teksti ja monimutkaiset asettelut: Historialliset kirjapitäjät eivät noudattaneet siistejä suorakulmaisia ruudukkoja. Teksti virtaa reunoille, kiertää valaistuja alkukirjaimia, punoo sisällytettyjen väliin sijoitettujen korjausten väliin tai kulkee pystysuoraan selkärankaa pitkin.
2. Kaarteiset ja kaltevat peruslinjat: Käsinkirjoitus harvoin noudattaa jäykkää vaakasuoraa akselia. HTR-moottorit kuten Transkribus, Kraken ja eScriptorium luottavat moniviivaisiin peruslinjoihin sen sijaan, että käyttäisivät raja-alueita tulkitakseen liitosmerkkejä runsaasti sisältäviä skriptejä.
3. Paleografinen monimutkaisuus ja metadata: Arkistotutkimus vaatii lyhenteiden, historiallisten oikeinkirjoitusmuunnosten, vaurioituneiden lukemien ja rivitasoisten luottamuslukujen seuraamista. Tavalliset asiakirjamuodot hylkäävät tämän tarkkuuden.

Alkuperäisen esineen uskollisuuden säilyttämiseksi arkistoyhteisö turvautuu rakenteellisiin XML-skeemoihin, jotka on suunniteltu säilyttämään asettelun topologia yhdessä transkriboituun tekstiin.

1. PAGE XML: Kultainen standardi käsinkirjoitetun tekstin tunnistukselle (HTR)

PRImA (Pattern Recognition & Image Analysis) -tutkimuslaboratorion kehittämä PAGE XML (Page Analysis and Groundtruth Elements) katsotaan laajalti huippuluokan formaatiksi käsinkirjoitetun tekstin tunnistukseen ja kehittyneeseen asetteluanalyysiin.

Ydinarkkitehtuuri

PAGE XML käsittelee fyysistä asiakirjaa hierarkkisena rakenteena:

• PcGts (Juuri)
  • Page (Kuvan mitat ja yleinen lukujärjestys)
    • TextRegion (Kappaleet, otsikot, reunamuistiinpanot, avainsanat)
      • TextLine
        • Coords (Polygoni-koordinaatit viivan ympärillä)
        • Baseline (Sarja pisteitä, jotka seuraavat kirjoituksen todellista peruslinjaa)
        • TextEquiv (Tunnistettu teksti, valinnaisten luottamusmittareiden kanssa)

Miksi se loistaa historiallisissa käsikirjoituksissa

• Polygoni- ja polylinja-tarkkuus: Sen sijaan, että pakotettaisiin merkit suorakulmaisiin raja-alueisiin, PAGE XML käyttää monipisteisiä polygoni-rajoja ja jatkuvia peruslinjoja. Tämä estää päällekkäisten kursiivisten ylä- ja alaviivojen häiritsemästä segmentointia.
• Rakenne-tyyppien tarkkuus: Alueet voidaan luokitella tarkasti (esim. marginalia, drop-capital, signature-mark, header, editorial-note).
• Laaja ohjelmistoympäristö: Se toimii ensisijaisena sisäisenä ja vientikaaviona lippulaiva‑HTR-alustoille, kuten Transkribus, eScriptorium ja Kraken.

2. ALTO XML: Kirjastojen ja arkistojen voimavara

ALTO (Analyzed Layout and Text Object) on avoin XML-standardi, jota ylläpitää Library of Congress, ja jota on laajasti omaksuneet kansalliskirjastot, mukaan lukien Bibliothèque nationale de France (BnF) ja British Library.

Ydinarkkitehtuuri

ALTO jäsentää asettelun hierarkkisesti Page‑elementistä PrintSpace‑elementtiin, edelleen TextBlock, TextLine ja String (yksittäiset sanat tai tokenit). Se paketoidaan usein METS (Metadata Encoding and Transmission Standard) -kääreen sisään yhdistämään rakenteellinen metadata korkearesoluutioisiin master-kuviin.

Keskeiset vahvuudet ja käyttötapaukset

• Massadigitaaliset työnkulut: ALTO suunniteltiin teollisen mittakaavan sanomalehtien ja kirjojen digitointia ajatellen. Se koodaa selkeästi fonttien ominaisuudet, sanatasoiset koordinaatit, merkkien luottamusarvot ja välilyönnit.
• Moderni HTR-tuki (ALTO 4): Aikaisemmat ALTO-versiot painottivat vahvasti suorakulmaisia koordinaatteja (HPOS, VPOS, WIDTH, HEIGHT). Kuitenkin alkaen ALTO versio 4, skeema esitteli <Shape>-monikulmiot ja -polyline-pohjaviivat, sulkien toiminnallisen aukon PAGE XML:n kanssa käsinkirjoitettua materiaalia varten.
• Pitkäaikainen säilytys: Koska se on kansainvälisten kirjastokonsortioiden tukema virallinen standardi, ALTO takaa pitkäaikaisen vakauden ja arkistotason taaksepäin yhteensopivuuden.

3. hOCR: Verkko-ensimmäinen, Kevyt standardi

Thomas Breuelin luoma hOCR ottaa pragmaattisen lähestymistavan: sen sijaan, että luotaisiin kokonaan uusi XML-skeema, se upottaa asettelun ja transkription metatiedot suoraan semanttiseen HTML/XHTML:ään käyttäen mikroformaatteja ja luokka-attribuutteja.

Tyypillinen syntaksiesimerkki

<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\">\n        <span class=\"ocrx_word\" id=\"word_1_1\" title=\"bbox 150 325 380 405; x_wconf 92\">Incipit</span>\n      </span>
    </p>
  </div>
</div>

Hyödyt ja haitat historiallisille materiaaleille

• Plussat: Selaimet voivat renderöidä sen natiivisti. Se on helposti muokattavissa tavallisella CSS:llä ja JavaScriptillä, ja se on oletusrakenteinen vientimuoto moottoreille kuten Tesseract.
• Miinukset: Monimutkaisten, vapaamuotoisten monipisteisten pohjaviivakäyrien natiivituki on rajoitettua. Vaikka se on käytännöllinen varhaisille painotuotteille (incunabula tai puhtaat lehtilehdet), hOCR kamppailee epäsäännöllisten käsikirjoitusten asettelujen ja monikerroksisten marginalioiden kanssa.

4. TEI-XML: Akateeminen ja digitaalisen humanistisen tieteen vertailuarvo

The Text Encoding Initiative (TEI) -formaatti ei ole tiukasti OCR-moottorin tulostusformaatti; se on pikemminkin ensisijainen standardi kriittisille digitaalisille julkaisuja ja tieteelliselle kirjallisten ja historiallisten tekstien esittämiselle.

OCR/HTR:n yhdistäminen TEI:hin

Nykyaikaiset putkistot harvoin pysähtyvät pelkkään merkkien tunnistukseen. Tutkijat käyttävät työkaluja kuten Transkribus TEI Exporter tai automatisoituja XSLT-putkistoja kääntääkseen PAGE XML- tai ALTO-tiedostot TEI-yhteensopivaksi XML:ksi:

• Lyhenteet laajennetaan (<choice><abbr>...</abbr><expan>...</expan></choice>).
• Poistot, lisäykset ja käsikirjoittajien kädet luokitellaan muodollisesti (<add>, <del>, <handShift>).
• Asettelu‑data säilytetään kirjallisen analyysin rinnalla <facsimile>- ja <surface>-elementtien avulla.

Jos historiallinen projektisi pyrkii luomaan interaktiivisen kriittisen version tai semanttisesti haettavan tieteellisen arkiston, OCR/HTR-datan muuntaminen TEI-XML:ksi on usein vaadittu viimeinen vaihe.

Vertailumatriisi: OCR/HTR-muodot yhdellä silmäyksellä

Käytännön suositukset: Arkistointiputken valinta

Jotta voidaan luoda tehokas, tulevaisuuteen kestävä digitalisointiputki:

1. Puhtaille käsinkirjoitetuille käsikirjoituksille ja arkistoille: Vakiinnuta transkription ja asettelun poiminta PAGE XML-muodossa. Sen peruslinjan laskenta ja polygonin ääriviivat käsittelevät epäsäännöllisiä käsialoja minimaalisella tietohäviöllä.
2. Suuren mittakaavan kirjastoille ja sekoitetuille kokoelmille: Valitse ALTO XML (v4.2 tai uudempi) yhdessä METS-standardin kanssa. Tämä takaa saumattoman integroinnin tavallisiin digitaalisiin arkistorakenteisiin ja digitaalisten aineistojen hallintajärjestelmiin (DAMS).
3. Verkkoesitystä ja täyden tekstin hakemistoja varten: Käytä hOCR-muotoa tai johda kevyitä GeoJSON-/Web Annotation -rakenteita PAGE XML:stä ohjaamaan interaktiivisia IIIF-katselijoita (kuten Mirador tai Universal Viewer) reaaliaikaisilla selaimen sisäisillä tekstikerroksilla.
4. Tieteellisiä julkaisuja ja paleografista tutkimusta varten: Luo ground truth -tietosi PAGE XML -muodossa, suorita tunnistus ja syötä tulos automatisoidun muuntimen läpi luodaksesi TEI-XML editointimerkintöjä.

Vastaamalla näiden formaattien rakenteellisia mahdollisuuksia lähdeaineistosi paleografisiin vaatimuksiin, varmistat, että jokainen viiva, lyhenne ja historiallinen vivahde pysyy tulkittavissa vuosisatojen ajan.

Usein kysytyt kysymykset (FAQ)

Q1. Mikä on perusero tavallisen OCR:n ja HTR:n välillä? OCR tunnistaa tasaisen koneellisesti painetun typografian, kun taas HTR (käsinkirjoitetun tekstin tunnistus) hyödyntää syviä neuroverkkoja dekoodatakseen jatkuvaa, vaihtelevaa ihmiskirjoitusta ja kaarevia peruslinjoja.

Q2. Voiko Tesseract OCR tuottaa PAGE XML- tai ALTO-tulosteen historiallisille asiakirjoille? Kyllä, Tesseract voi luoda natiivin ALTO XML:n ja hOCR-tulosteen, ja kolmannen osapuolen kääreet voivat muuntaa nämä tulokset PAGE XML:ksi.

Q3. Miksi peruslinjat ovat tärkeämpiä kuin raja-laatikot käsinkirjoitetun tekstin transkriptiossa? Peruslinjat seuraavat ihmisen kirjoituksen luonnollista, aaltoilevaa linjaa, mikä mahdollistaa ohjelmiston erottaa päällekkäiset ylä- ja alaviivat, jotka törmäävät jäykkiin raja-laatikoihin.

K4. Kuinka IIIF-standardi on vuorovaikutuksessa näiden OCR-tiedostomuotojen kanssa? IIIF tarjoaa korkean tarkkuuden kuvia avoimien web-API:en kautta, kun taas muodot kuten ALTO tai PAGE XML tarjoavat koordinaattitietoja, jotka voidaan muuntaa IIIF Content Search -annotaatioiksi.

K5. Mikä tiedostomuoto on helpoin muuntaa suoraan haettavaksi PDF:ksi? Sekä hOCR että ALTO XML voidaan yhdistää alkuperäisiin sivukuvien kanssa hakukelpoisten kaksikerroksisten PDF-tiedostojen luomiseksi työkaluilla kuten OCRmyPDF.

Katso myös

• PDF/A-3 – Hybridihirviö? Alkuperäisen datan upottaminen OCR:si sisään
• OCR-tiedostomuotojen ymmärtäminen – HOCR vs ALTO vs PDF/A selitetty
• Mikä on PDF:n ja FDF:n välinen ero?
• Mihin FDF:ää käytetään? Forms Data Format -muodon tarkoituksen ymmärtäminen
• PDF vs Word: Kumpaa sinun pitäisi käyttää ja milloin?