Gradu04243.Pdf

Paperilomakkeesta tietomalliin

Kalle Malin

Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Pro gradu -tutkielma Ohjaaja: Erkki Mäkinen Toukokuu 2010 i

Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Kalle Malin: Paperilomakkeesta tietomalliin Pro gradu -tutkielma, 61 sivua, 3 liitesivua Toukokuu 2010

Tässä tutkimuksessa käsitellään paperilomakkeiden digitalisointiin liittyvää kokonaisprosessia yleisellä tasolla. Prosessiin tutustutaan tarkastelemalla eri osa-alueiden toimintoja ja laitteita kokonaisjärjestelmän vaatimusten näkökul- masta. Tarkastelu aloitetaan paperilomakkeiden skannaamisesta ja lopetetaan kerättyjen tietojen tallentamiseen tietomalliin. Lisäksi luodaan silmäys markkinoilla oleviin valmisratkaisuihin, jotka sisältävät prosessin kannalta oleelliset toiminnot.

Avainsanat ja -sanonnat: lomake, skannaus, lomakerakenne, lomakemalli, OCR, OFR, tietomalli. ii

Lyhenteet ADRT = Adaptive Document Recoginition Technology API = Application Programming Interface BAG = Block Adjacency Graph DIR = Document Image Recognition dpi= Dots Per Inch ICR = Intelligent Character Recognition IFPS = Intelligent Forms Processing System IR = Information Retrieval IRM = Image and Records Management IWR = Intelligent Word Recognition NAS = Network Attached Storage OCR = Optical Character Recognition OFR = Optical Form Recognition OHR = Optical Handwriting Recognition OMR = Optical Mark Recognition PDF = Portable Document Format SAN = Storage Area Networks SDK = Software Development Kit SLM = Statistical Language Model SOAP = Simple Object Access Protocol iii

Sisällys 1. Johdanto ...... 1 2. Yleiskuvaus paperilomakkeiden digitalisointiprosessista ...... 4 2.1. Prosessin toteuttaminen ...... 5 2.2. Varmistus ...... 6 3. Paperilomakkeiden skannaus digitaalisiksi ...... 8 3.1. Kuvanlukija ...... 8 3.2. Kuvan korjaus ...... 10 3.2.1. Suoristus ...... 10 3.2.2. Artefaktien poisto kuvasta ...... 12 3.3. Tehokkuus ...... 13 4. Lomakerakenteen tunnistaminen ...... 16 4.1. Automatisoitu tunnistaminen ...... 17 4.2. Dokumenttitietämys ...... 18 4.3. Taulukoiden tunnistaminen...... 18 4.4. Solujen tunnistaminen ...... 19 4.5. Värien käyttäminen ...... 20 4.6. Editointi...... 20 5. Lomakemallilla tarkennusta lomakerakenteeseen ...... 21 6. Tekstintunnistaminen lomakkeen sisällöstä ...... 23 6.1. Historiaa ...... 24 6.2. Esikäsittely ...... 24 6.3. Oikeellisuuden varmistus ...... 25 6.4. Jälkikäsittely ...... 26 6.4.1. Tunnistus- ja kirjoitusvirheet ...... 27 6.4.2. Manuaalinen korjaus ...... 28 6.5. Käsinkirjoitettu teksti ...... 29 6.6. Rajapinnat ...... 30 6.6.1. ABBYY FineReader ...... 30 6.6.2. Asprise OCR...... 31 6.6.3. GOCR ...... 32 6.6.4. OCR .Net ...... 32 6.6.5. Tesseract OCR ...... 33 6.6.6. TOCR ...... 34 6.7. Verkkopalvelut ...... 35 6.7.1. OCR Terminal ...... 36 6.7.2. Online OCR ...... 37 6.7.3. Muut verkkopalvelut ...... 38 iv

6.7.4. Integraatio tiedostonhallintaan ...... 38 6.8. Tiedostoformaateista ...... 39 7. Tiedot tietomalliin ...... 41 7.1. Tunnettu tietomalli ...... 41 7.2. Tuntematon tietomalli ...... 42 8. Diagnostiikka ja etähallinta prosessissa ...... 43 9. Markkinakatsaus valmisratkaisuihin ...... 45 9.1. ABBYY Finereader ...... 45 9.2. FormSuite ...... 47 9.3. OCRopus ...... 48 9.4. SimpleIndex ...... 48 9.5. WindFORM ...... 49 10. Yhteenveto ...... 51

Viiteluettelo ...... 53 Liite 1 ...... 62 Liite 2 ...... 64 1

1. Johdanto Kotona ja toimistoissa on pyöritelty ja käsitelty paperisia lomakkeita jo iät ja ajat. Teknologisen kehityksen myötä paperilomakkeiden käyttötarve on vain kasvanut, vaikka voisi toisin olettaa. Omalta osaltaan lain säädöksetkin vaikuttavat tarpeeseen, koska tietyissä tapauksissa lomakkeet on arkistoitava määrä- tyksi ajaksi. Suuntauksen kääntämiseksi turhien tulostusten osalta nykypäivänä suositaan paperittoman toimiston konseptia sekä ekologisista syistä että kus- tannustehokkuuden takia. Täydellistä paperittomuutta ei ole kuitenkaan helppo saavuttaa, sillä suuri osa ihmisistä on tottunut käyttämään sekä täyttämään paperilomakkeita. Lisäksi on tilanteita, joissa sähköinen lomake ei myöskään toimi riittävän tehokkaasti tai käyttäminen voi olla mahdotonta. Unohtaa ei myöskään sovi sitä, että paperittomuuden tavoittelun on lähdettävä liikkeelle lomaketta käyttävästä tahosta. Käyttötapauksia, joihin sähköinen lomake ei sovellu kovinkaan hyvin, ovat esim. erilaiset paikan päällä täytettävät kyselyt, esitäytettävät asiointi-, hakemus- ja arvontalomakkeet. Lomakkeiden sähköinen täyttäminen paikan päällä olisi mahdollista toteuttaa, mutta se vaatisi huomattavia henkilöstö- ja laitteis- toresursseja. Paperilomakkeella saavutetaan myös parempi hyötysuhde, koska paperi on halpaa ja lomake voidaan jakaa useammalle ihmiselle täytettäväksi yhtä aikaa. Lisäksi paperilomake voidaan jakaa “anna ja unohda”-periaatteella: lomake annetaan ihmiselle, ja samalla häntä pyydetään palauttamaan se täyt- tämisen jälkeen palautuslaatikkoon tms. paikkaan. Erillisen laitteen vaativaa sähköistä lomaketta ei voida laitteen hinnan takia käsitellä näin vapaasti, koska laite on kuitenkin saatava takaisin. Täyttämätön paperilomake sen sijaan on hukattavissa. Toimistot toimivat nykyään pitkälti sähköisesti, ja tästä johtuen lomakkeet on saatava digitaaliseen muotoon, jotta niiden jatkokäsittely on mahdollista. Perinteinen tapa digitalisointiin on lomakkeiden manuaalinen käsittely. Tämä sitoo henkilöstöresursseja ja vie kaiken lisäksi paljon aikaa. On arvioitu, että amerikkalaisille operaattoreille paperilomakkeen syöttäminen tietokoneelle maksaa 2,5$ per lomake [Casey et al., 1992]. Keskikokoinen yritys voi ottaa vas- taan jopa 15000 lomaketta päivässä, joten kokonaiskustannus on valtava. Pro- sessi on myös altis virheille, koska työn monotonisuus saattaa johtaa lopulta tarkkaavaisuuden herpaantumisesta johtuviin virheisiin etenkin, jos lomakkeita käsitellään kuin liukuhihnalla. Työn mielekkyydestä voidaan olla myös montaa mieltä.

Tässä tutkimuksessa tarkastellaan paperilomakkeiden digitalisointiproses- sin automatisointia käytännöllisestä näkökulmasta. Tarkoituksena on löytää vastaus kysymyksiin: ”Miten ja kuinka pitkälle paperilomakkeiden digitalisointi voidaan automatisoida?” ja ”Miten tutkimustuloksia on realisoitu käytän- töön?”. Lisäksi tavoitteena on antaa lukijalle riittävä tietämys prosessin eri osa- alueista sekä seikoista, jotka on hyvä huomioida tarkoitusta varten soveltuvaa järjestelmää suunniteltaessa. Esillä ovat niin tarvittavat laitteet kuin käytetyt menetelmät. Lisäksi tarkastellaan järjestelmään sopivia ohjelmistokirjastoja ja valmisratkaisuja. Paperilomakkeiden digitalisointiprosessi on mahdollista automatisoida osittain tai jopa kokonaan [Shirari et al., 1994]. Tietotekniikka on kehittynyt ja kehittyy edelleen päätä huimaavaa vauhtia sekä laitteiden että ohjelmistojen osalta, ja tämä antaa aina vain paremmat mahdollisuudet prosessin automatisoin- tiin. Skannereiden tekniikka on kehittynyt, tarkkuus on parantunut ja nopeus on kasvanut, tekstin tunnistamisessa tarkkuus sekä virheherkkyys ovat parantuneet ja lomakkeiden tunnistaminen on kehittynyt. Automatisoitaessa prosessia todelliset tarpeet on huomioitava erikseen, koska ne voivat olla hyvin erilaisia. Tarve voi olla rajattu, kuten esimerkiksi matemaattisten kaavojen tunnistaminen, joka vaatii omaa erityishuomiotaan [Lavirotte and Pottier, 1998] tai pelkkä lomakkeen sisältäminen nimien tunnistaminen [Likforman-Sulem et al., 2006]. Osittaisen avun paperilomakkeiden käsittelyyn tarjoaa jo pelkkä materiaalin digitalisointi skannerin avulla. Skannaamisen jälkeen materiaali on tallessa sähköisesti ja materiaalin jakaminen muille sitä tarvitseville henkilöille ja tahoille helpottuu sekä nopeutuu. Lisäksi materiaaliin voidaan tarvittaessa tehdä erilaisia merkintöjä, jotka ovat kaikkien materiaaliin käsiksi pääsevien henki- löiden saatavilla, ja mikä tärkeintä, aina ajan tasalla. Tämä vähentää esim. pääl- lekkäisen työn vaaraa. Materiaalin tarkistaminen alkuperäiseen vertaamalla on helppo suorittaa, jos skannattuun materiaaliin kytketään tieto, missä alkupe- räistä paperilomaketta säilytetään [Tang and Liu, 1997]. Tarve voi olla myös ohjeellinen tai lain säädösten mukainen. Optinen tekstintunnistus [Mori et al., 1999] on järjestelmän kannalta oleellinen palvelu, jotta kuvien sisältämä teksti saadaan muunnettua merkkijonoiksi. Tämä mahdollistaa tiedon suodattamisen ja lisäksi vähentää tarvittavan tallen- nustilan määrää. Käyttäjää tarvitaan prosessissa korjaamaan tunnistuksen jäljel- le jättämät virheet sekä tarvittaessa myös ohjaamaan kerätyt tiedot oikeaan paikkaan tietomallissa. Tietojen kohdistamisen automatisoimiseksi järjestel-

3 mään voidaan sisällyttää lomakemalli, joka täsmentää lomakkeeseen kuuluvien kenttien tarkoitusta käyttäjän valitsemilla avaimilla. Näin käyttäjän vastuulle jää vain prosessin toiminnan valvominen sekä virheiden korjaaminen. Johdannon jälkeen luvussa 2 luodaan yleissilmäys prosessin eri vaiheisiin. Esiin otetaan myös tekijät, joita järjestelmää suunniteltaessa on syytä ottaa huomioon. Prosessin esittelyn jälkeen vuorossa on tarkempi perehtyminen prosessin eri vaiheisiin. Luvussa 3 keskitytään prosessin ensimmäiseen vaiheeseen eli skannauk- seen. Lisäksi tutustutaan kuvanlukijoihin liittyvään tekniikkaan ja niiden sisäl- tämiin ominaisuuksiin. Lomakkeiden fyysisen ja loogisen rakenteen määrittelyä selvitetään luvussa 4. Tärkeässä osassa ovat rakenteen automaattisesti tunnistavat menetelmät, jotka tehostavat prosessin suoritusta. Lomakkeeseen sisältyy tavallisesti jonkin verran semantiikkaa, joka ei vält- tämättä suoraan selviä itse lomakkeesta. Tätä auttamaan voidaan lomakerakenteen päälle luoda lomakemalli, joka tarkentaa rakenteen sisältöä, ja tähän pe- rehdytään luvussa 5. Prosessin kannalta haastavin osa-alue tekstintunnistus käsitellään luvussa 6. Tarkasteltavana ovat erilaiset tekstintunnistuksessa käytössä olevat mene- telmät, sekä järjestelmän kehityksessä hyödynnettävissä olevat kirjastot. Luvussa 7 käsitellään prosessin viimeistä vaihetta eli tietojen tallentamista käytettävään tietomalliin. Esillä on vaihtoehtoisia tapoja tietomallin kytkemi- seksi järjestelmään. Luvussa 8 käsitellään diagnostiikkaan ja etähallintaan liittyviä näkökohtia järjestelmän kannalta, sekä mitä hyötyä niillä voidaan saavuttaa käyttäjän ja ylläpidon kannalta. Vielä ennen tutkimuksen yhteenvetoa luvussa 10 luodaan silmäys kaupalli- sille markkinoille luvussa 9. Markkinakatsauksessa on mukana ohjelmia, joilla käyttäjä voi suoriutua digitalisointiprosessista alusta loppuun.

2. Yleiskuvaus paperilomakkeiden digitalisointiprosessista Seuraavaksi luodaan yleissilmäys paperilomakkeiden digitalisointiprosessiin. Tarkasteltavaksi otetaan prosessin kokonaisrakenne sekä erilaiset prosessin toteutuksessa tarvittavat osa-alueet. Lisäksi selvitään, millä tavoin prosessi toiminta on toteutettavissa, ja lopuksi kuvataan varmistusmekanismeja, joilla va- raudutaan prosessin aikana ilmeneviin ongelmiin. Paperilomakkeiden digitalisointiprosessi koostuu seuraavista vaiheista: paperilomakkeiden skannaaminen, lomakerakenteen määrittely, lomakemallin määrittely, tekstintunnistus ja tietojen syöttäminen tietomalliin [Lam et al., 1993]. Nämä ovat prosessin kannalta selkeät päävaiheet, joista jokainen sisältää vähäisempiä alavaiheita kuten esim. kuvien esikäsittely skannauksen yhteydes- sä. Kuvassa 1 on nähtävissä yleiskuva järjestelmän rakenteesta. Prosessi on hyvin pitkälle automatisoitavissa, mutta käyttäjää tarvitaan kuitenkin aina vähintään syöttämään lomakkeita kuvanlukijaan. Tämä voi kuitenkin olla kertaluontoinen toimenpide, jos käytettävässä kuvanlukijassa on riittä- vän iso arkinsyöttölaite. Lomakerakenne on kuvaus lomakkeen fyysisestä rakenteesta sisältäen li- säksi loogisen jaottelun kuten ylä- ja alatunnisteet [Klink et al., 2000]. Tunnis- tamiseen voidaan käyttää apuna lomakkeen sisältämää visuaalista sekä symbo- lista informaatiota [Faure, 2000]. Rakenteessa tulisi olla kenttien osalta mukana vähintään kenttäkoodaus ja paikkainformaatio jokaisesta lomakkeen kentästä. Käyttäjä on yleensä hyvä ottaa mukaan lomakerakenteen määrittelyyn, ainakin oikeellisuuden tarkistamista varten, vaikka toimenpide muutoin automatisoi- taisiin täysin. Tarkistustoimenpiteellä varmistetaan luodun lomakerakenteen oikeellisuus suhteessa todelliseen lomakkeeseen ennen varsinaista tiedon työs- tämistä. Lisäksi käyttäjälle on hyvä antaa mahdollisuus ottaa kantaa rakenteeseen myös manuaalisesti [Antonacopoulos and Karatzas, 2004]. Lomakeraken- teen luominen voi tapahtua manuaalisesti, puoliautomaattisesti tai automaattisesti [Sherkat et al., 2005]. Lomakerakenne ei sisällä semantiikkaa liittyen kenttien kuvaamaan infor- maatioon. Tätä varten järjestelmä voi sisältää lomakemallin, joka tarkentaa lomakerakenteen sisältämien kenttien tarkoitusta erilaisten attribuuttien avulla. Lomakemalli on käytännössä looginen lisäkerros lomakerakenteen päälle.

Kuva 1. Yleiskuva järjestelmästä.

2.1. Prosessin toteuttaminen Prosessi voidaan toteuttaa kahdella tavalla: jokainen paperilomake voidaan kä- sitellä alusta loppuun kerralla tai käsittely voidaan tehdä vaiheittain. Vaiheit- taisessa toteutuksessa kaikki lomakkeet käsitellään aina ennen siirtymistä seu- raavaan vaiheeseen. Liukuhihnan kaltainen paperilomakkeen digitalisointiprosessi on yksinkertainen toteuttaa. Käsiteltävä paperilomake skannataan, tunnistetaan, analysoidaan ja tallennetaan tietomalliin ennen kuin seuraava paperilomake otetaan kä-

6 siteltäväksi. Näin toteutettuna prosessissa ei kuitenkaan voida hyödyntää aiemmin kerättyä informaatiota kovinkaan tehokkaasti. Jokainen paperilomake joudutaan käsittelemään erikseen eikä ryhmittelystä ole hyötyä. Prosessin etuna on tiedon jatkuva kertyminen tietomalliin. Käsiteltävän lomakkeen tiedot ovat saatavilla tietomallista heti, kun lomake on saatu käsiteltyä kokonaisuudessaan loppuun asti. Liukuhihnan vastakohta on vaiheittain toteutettu prosessi. Erona liukuhih- naan on, että jokaisessa vaiheessa kerätään kaikki tiedot ennen etenemistä seu- raavaan vaiheeseen. Prosessi alkaa siten, että kaikki paperilomakkeet skannataan kuviksi ennen analysointia ja vasta tämän jälkeen siirrytään lomakepohji- en tunnistukseen. Vaiheittaisella etenemisellä saavutetaan hyötyä, kun prosessin edetessä samanlaiset lomakkeet voidaan käsitellä erissä. Esimerkiksi loma- kepohjia valittaessa etu on huomattava, koska jokaista lomaketta ei tarvitse tunnistaa erikseen, vaan jaottelua voidaan hyödyntää. Kääntöpuolena on se, että tietojen kertyminen tietomalliin vie aikaa, jos paperilomakkeita on paljon. Olipa prosessi sitten toteutettu liukuhihnana tai hajautetusti voidaan toiminta jakaa useammalle palvelimelle [ABBYY]. Prosessin vaiheet ovat selkeitä ja siksi helposti eriytettävissä. Hajauttamisella vähennetään yhdelle palvelimelle aiheutettua kuormitusta ja samalla helpotetaan prosessin valvontaa. Lisäksi prosessin vaiheiden testaus helpottuu, kun vaiheet ovat erillään toisistaan. Ha- jautetussa järjestelmässä vaiheiden välinen tiedonsiirto vaatii abstraktiota, ja tämä antaa mahdollisuuden vaihtoehtoisten toteutusten käyttämiseen eri vaiheissa. Hajauttamista mietittäessä on tiedonsiirtokapasiteetti otettava huomioon. Etenkin skannatessa tuotetaan iso määrä informaatiota, koska kuvat vievät paljon tallennustilaa [Tang and Liu, 1997]. Arvokasta prosessointiaikaa hukataan ja prosessi venyy, jos kaista seuraavaa vaihetta suorittavaan palvelimeen on liian kapea. Muissa vaiheissa käsiteltävät tietomäärät ovat tilantarpeeltaan huomattavasti vähäisempiä, koska tietoa on saatu jalostettua.

2.2. Varmistus Tiedon muuntaminen paperilomakkeelta digitaaliseksi vie aina aikaa, koska digitalisointiprosessi sisältää monta vaihetta. Järjestelmää suunniteltaessa kannattaa varautua prosessi pysähtymiseen sekä järjestelmä kaatumiseen. Varau- tumalla saadaan minimoitua sekä ajallisia että rahallisia menetyksiä [Traeger et al., 2006]. Ainakin seuraavien vaiheiden yhteydessä kerätty informaatio on hy- vä varmistaa:

 skannaaminen  tietomalliin tallennus. Skannaus on prosessin aikaa vievin vaihe, joka lisäksi sitoo käyttäjän laitteen ääreen, jos ei täysin, niin ainakin osittain. Skannauksen edistyessä skanna- tuista kuvista kannattaa tehdä varmuuskopiot ennalta määritettyyn paikkaan [Casey et al., 1992]. Tällöin tallennettu materiaali on käytettävissä prosessin keskeytyessä esimerkiksi järjestelmän kaatumisen takia, eikä uudelleenaloitus aivan alusta ole välttämätöntä. Prosessia voidaan jatkaa viimeiseksi tallennetus- ta paperilomakkeesta. Tietomalliin tallennus on järjestelmän kriittisin vaihe. Jos tieto ei tallennu tai se tallentuu väärin ja ongelma huomataan vasta prosessin valmistuttua, työ joudutaan aloittamaan alusta. Tämä on silkkaa ajan ja resurssien tuhlaamista. Ongelmaan voidaan varautua tekemällä kerätystä informaatiosta varmuuskopio alkuperäisessä formaatissa. Tarvittaessa varmuuskopio voidaan ottaa käyt- töön ja ajaa sen sisältämät tiedot uudestaan tietomalliin, siten että tiedot ovat siinä muodossa, kuin tietomallin kannalta on oleellista. Tietojen varmistaminen voidaan toteuttaa sisäisesti järjestelmän kiinteänä osana tai vaihtoehtoisesti ulkoistamalla. Ulkoistettua varmistusta käytettäessä tiedot voidaan tallentaa fyysisesti eri paikkaan kuin missä järjestelmä sijaitsee, jos käytettävissä on verkkoyhteys. Verkon ylitse toimivia varmistusmenetelmiä ovat esimerkiksi SAN- (Storage Area Networks) ja NAS- (Network Attached Storage) järjestelmät [Gibson and Rodney, 2000]. Fyysisesti eri paikassa sijaitseva varmistus on samalla tärkeä osa riskienhallintaa, koska varsinaisen järjes- telmän kärsiessä fyysisen vaurion, tiedot ovat kuitenkin tallessa ja palautetta- vissa. Varmistukseen voidaan käyttää myös saatavilla olevia ilmaisia verkko- palveluja, joita löytyy nykyään useita [Traeger et al., 2006]. Ilmaispalveluissa käytettävissä oleva tila voi kuitenkin olla hyvin rajallinen ja tietoturvaan on myös syytä kiinnittää erityistä huomiota. Varmistus voi toisinaan tuntua turhalta ja järjestelmää tarpeettomasti ras- kauttavalta, unohtamatta datan tarvitsemaa tallennustilaa. Digitalisoitavia lomakkeita ollessa vain muutamia ei työn aloittaminen alusta prosessin keskey- tymisen jälkeen ole ajallisesti iso asia. Toisin kuitenkin on, jos paperilomakkeita on satoja tai jopa tuhansia, jolloin prosessi kokonaisuudessaan vie paljon aikaa. Ongelmat ja uudelleen aloitus ovat tällöin omiaan lisäämään käyttäjän turhau- tumista etenkin, jos ongelmat ovat toistuvia.

3. Paperilomakkeiden skannaus digitaalisiksi Paperilomakkeiden digitalisointiprosessi alkaa työstettävien paperilomakkeiden muuntamisella digitaalisiksi kuviksi. Seuraavaksi tarkastellaan lähemmin muuntamisessa oleellisesti apuna tarvittavia kuvalukijoita. Lisäksi perehdytään erilaisiin jälkikäsittelymenetelmiin, joilla kuvissa mahdollisesti esiintyviä vir- heitä voidaan korjata. Skannaaminen on prosessin kaikista työvaiheista mekaanisin ja ainoa, jossa tarvitaan erillinen ulkoinen apulaite eli kuvanlukija. Kuvanlukijalle syötetään haluttu materiaali, jonka jälkeen laite lukee materiaalin ja luo siitä digitaalisen kuvan jatkokäsittelyä varten. Kuva ei ole digitaalisen lomakkeen lopullinen muoto, koska siinä ei ole semantiikkaa liittyen lomakkeen sisältämiin kuva- ja tekstikenttiin.

3.1. Kuvanlukija Kuvanlukijoita on olemassa kahdenlaisia: taso- ja käsikuvanlukijoita [Fulton, 2010]. Yhteistä laitteille on lukupää, joka lukee annetun materiaalin ja muodostaa siitä digitaalisen kuvan. Toimintaperiaatteiden ero erityyppisten laitteiden välillä on suuri. Tasokuvanlukijassa lukupää on vaakatasossa lukupinnan alla, ja se liikkuu automaattisesti kuva-alueen läpi muodostaen materiaalista digitaalisen kuvan. Käsikuvanlukija puolestaan on pienikokoisempi laite, joka sisäl- tää vain lukupään, mutta ei mitään mekaniikkaa lukupään liikuttamiseen. Käyttäjän on liikutettava laite materiaalin ylitse, jotta lukupää saa luettua materiaalin. Kuvanlukijaa hankittaessa on hyvä miettiä tarkoin käyttötarkoitusta ja - tarvetta. Onko tarpeen skannata vain satunnaisesti vai päivittäin? Onko lomakkeita vain muutamia vai useita satoja? Markkinoilla on kuvanlukijoita eri tarpeisiin: yksinkertaisista kodin kuvanlukijoista aina tehokkaisiin toimiston asiakirjakuvanlukijoihin. Ei sovi myöskään unohtaa toimiston monitoimilaitteita, jotka sisältävät tulostimen lisäksi kuvanlukijan. Monta toimintoa pakattuna kompaktiin pakettiin on etu pienessä toimistossa, jossa on vähän tilaa. Yksinkertaisimmillaan tasokuvanlukija on laite, johon syötetään yksi arkki kerrallaan. Tämä on kuitenkin hidasta ja käyttäjiä sitovaa, koska jonkun on suo- ritettava lomakkeen vaihtaminen kuvanlukijaan manuaalisesti. Tämä myös li- sää lomakkeiden käsittelyyn kuluvaa aikaa. Toiminta tehostuu, kun kuvanlukijassa on arkinsyöttölaite, johon lomakkeet voidaan jättää laitteen käsiteltäväksi.

Arkinsyöttölaitteiden kapasiteetit vaihtelevat muutamasta kymmenestä useisiin satoihin. Laitteen skannausnopeuden tärkeys korostuu skannattavien lomakkeiden määrään ollessa suuri. Kotikäyttöön tarkoitetut laitteet ovat yleensä varsin hitaita ja tyypillinen skannausnopeus on 1-5 sivua minuutissa. Ero on huomattava, kun sitä verrataan asiakirjakuvanlukijoihin, jotka yltävät jopa sadan sivun käsittelynopeuksiin minuutissa. Taulukkoon 1 on laskettu skannattujen sivujen määrä eri aikajaksoilla. Taulukossa ei ole huomioitu arkin vaihtamiseen tai ar- kinsyöttölaitteen täyttämiseen kuluvaa aikaa. Taulukossa 2 on oletettu, että ar- kinvaihtamiseen tai arkinsyöttölaitteen täyttämiseen kuluu aikaa 5 sekuntia. Arkinsyöttölaitteen käyttäminen on käytännössä tehokkaampaa kuin yksittäi- sen arkin vaihtaminen kuvanlukijan lukija-alustalle, koska arkinsyöttölaite on aina skannauksen valmistuttua tyhjä.

Skannattuja sivuja Sivua/min 1h 3h 8h 1 60 180 480 10 600 1800 4800 30 1800 5400 14400 60 3600 10800 28800 100 6000 18000 48000 Taulukko 1. Jatkuva skannausnopeus.

Skannattuja sivuja Sivua / min Arkinsyöttö 1h 3h 8h 1 1 55 166 443 10 1 327 982 2618 30 10 1440 4320 11520 30 50 1714 5143 13714 60 10 2400 7200 19200 60 100 3429 10286 27429 100 50 5143 15429 41143 100 250 5806 17419 46452 Taulukko 2. Skannausnopeus, jos arkinvaihto vie 5s. Tasokuvanlukijoiden hinnoissa on huomattavia eroja. Kotikäyttöön tarkoitettu kuvanlukija saattaa maksaa vain muutaman kymmenen euroa, kun taas järeä toimiston asiakirjakuvanlukija maksaa muutamasta sadasta aina tuhansiin euroihin.

Kuvanlukijoille ilmoitetaan aina laitteen tarkkuus, joka voi olla esim. 300 dpi, 600 dpi tai 9600 dpi. Yli 600 dpi:n menevä tarkkuus ei enää paranna kuvan laatua, koska tällöin ylitetään kuvan reaalitarkkuus ja skanneri joutuu määrit- tämään ylimääräisten pikseleiden väriarvot ympäristön perusteella [Fulton, 2010]. Merkille pantavaa on, että tyypillisesti halvoille skannereille ilmoitetaan suuria tarkkuusarvoja (4800-9600 dpi), kun taas ammattikäyttöön tarkoitetut asiakirjakuvanlukijat eivät yleensä ylitä 600 dpi:n tarkkuutta.

3.2. Kuvan korjaus Paperilomake ei ole aina suorassa skannattaessa ja tämä näkyy vinoutuneena kuvana. Lisäksi skannattava materiaali voi sisältää ylimääräisiä kynänjälkiä yms. artefakteja, jotka ovat syntyneet lomaketta täytettäessä. Myös skannauksen aikana voi kuvaan tulla artefakteja, jotka johtuvat vaikkapa valottumisesta tai kuvanlukupinnalla olevasta liasta. Jotkut kuvanlukijat sisältävät korjausautomatiikkaa ja parhaimmillaan osaavat suoristaa vinoutumat sekä poistaa skannauksen aikana syntyneet tai paperilomakkeessa alun perin olleet tummentumat [Fujitsu, 2010]. Koska kai- kissa kuvanlukijoissa ei kuitenkaan ole automatiikkaa, voidaan järjestelmään sisällyttää erillisiä korjaustoimenpiteitä. Tämä ei ole kuitenkaan välttämätöntä, jos tiedetään, että skanneri kykenee suoriutumaan korjaustoimenpiteistä riittä- vän hyvin.

3.2.1. Suoristus Vinoutuneesta kuvasta on haittaa lomakerakenteen tunnistamisen, koska alueiden tunnistamista ei voi rajoittaa vaaka- ja pystylinjoihin, sekä tekstintunnistuksen yhteydessä. Kuvassa 2 on nähtävissä esimerkki kuvanlukijaan vinossa syötetystä kuvasta, sekä vastaavasti suorassa syötetystä kuvasta. Vinous on tavallisesti 1-3% [Kwag et al., 2002] onpa sitten käytetty käsisyöt- töä tai arkinsyöttölaitetta, mutta joskus se voi olla jopa 10%. Jo 2-3%:n vinous heikentää tekstin tunnistustarkkuutta ja yli 5%:n vinous tekee tuloksista epä- luotettavia. Jotkut kuvanlukijat sisältävät valmiiksi kuvansuoritukseen liittyvää korjaustoiminnallisuutta, mutta näin ei välttämättä aina ole tai sitten toiminnal- lisuus ei ole riittävän hyvä. Sen takia kuvan riittävä suoruus on syytä varmistaa ennen jatkokäsittelyä.

Kuva 2. Esimerkki vinosta ja suorasta skannauksesta. Skannattu kuva olisi mahdollista suoristaa manuaalisesti käyttämällä apuna piirto-ohjelmaa, mutta se olisi prosessin kannalta liian hidasta. Ihminen voi joskus olla tunnollisuudessaan liiankin tarkka, kun taas kone suorittaa toimenpiteen valmiiksi ja sillä hyvä. Ihmiselle työ olisi myös varsin monotonista, jos kä- siteltäviä kuvia on paljon. Automaattisesti vinouden tunnistavat menetelmät voidaan jakaa karkeasti kolmeen kategoriaan:

 Projektion profilointi  Houghin siirtymä  Lähin naapuri [Kwag et al., 2002]. Näistä Houghin siirtymä on ehkä eniten käytetty menetelmä. Se on yksi- nään kuitenkin laskennallisesti kallis operaatio suhteessa haluttuun tarkkuu- teen, kuten on myös projektion profilointiin perustuvien menetelmien laita. Tu- lokset kummankin osalta ovat hyviä ja siksi etenkin Houghin siirtymään poh- jautuvia menetelmiä on tutkittu paljon. Lähin naapuri -menetelmä voi olla myös kallis, jos naapurisuhteita on paljon. Kahden ensimmäisen menetelmän laskennallisesti järkevän tunnistustarkkuuden raja on +/- 15%, kun taas viimeinen menetelmä kykenee käsittelemään jopa +/- 45% vinoutumia. Houghin siirtymää nopeuttamaan on esimerkiksi ehdotettu menetelmää, jossa kuva jaetaan tunnistusta varten alueisiin. Jokaisesta alueesta otetaan yksi tunnistuspiste, joka on alueen vasenta yläkulmaa lähinnä oleva musta pikseli. Saatujen tunnistuspisteiden avulla lasketaan suuntaa antava vinouma. Kol-

12 mannessa ja viimeisessä vaiheessa hyödynnetään Houghin siirtymää ja lasketaan aiemmin saatujen tulosten perusteella tarkempi arvo vinoutumalle [Jiang et al., 1997]. Toisessa Houghin siirtymää käyttävässä menetelmässä kuva jaotellaan aluksi toisiinsa yhteydessä oleviin alueisiin. Jaottelun jälkeen alueet ryhmitel- lään kokonaisuuksiksi koon ja sisällön perusteella. Jokaiselle ryhmällä arvioi- daan seuraavaksi vinouma käyttäen Houghin siirtymää vain alueen osajouk- koon. Arvioinnin jälkeen lasketaan tarkempi vinouma ja viimeiseksi lasketaan koko kuvan vinouma käyttäen painotettuja ryhmien vinoumia. Menetelmä ke- ventää laskentaa, koska laskennalliset alueet ovat rajattuja [Amin and Fischer, 2000]. Edellä esitetyn Aminin ja Ficsherin ehdottaman lähestymistavan kaltaista menetelmää on sovellettu myös eräässä BAG-esitystä käyttävässä menetelmäs- sä. Erottava tekijä on kuitenkin lähtöalueiden määrittely, joka tapahtuu kerää- mällä kuvasta vain rajattu määrä alueita tunnistamista varten. Alueiden ke- räämisen jälkeen lasketaan summittainen vinouma kuvalla ennen viimeistä vaihetta, jossa valittuun alueeseen sovelletaan Houghin siirtymää. Laskennal- lista raskautta saadaan jälleen vähennettyä, koska alueen koko on rajattu [Kwag et al., 2002]. Poikkeavia lähestymistapoja ongelman ratkaisemiseksi on myös tutkittu. Näistä voidaan ottaa esimerkkinä menetelmä, jossa vinouma lasketaan tekstiri- veille kuuluvien vertikaalisten pikseleiden avulla [Gatos et al., 1997]. Menetel- män ensimmäisessä vaiheessa kuva käsitellään siten, että kirjaimia ja sanoja si- sältävät rivit mustataan. Pikseleiden mustaamisen jälkeen kuvasta valitaan vä- hintään kaksi saraketta, joista kerätään jokaisen rivin vertikaalinen aloituspik- seli. Kerättyjä pikseleitä käyttäen muodostetaan korrelaatiomatriisi, jolla saadaan laskettua kuvan vinouma.

3.2.2. Artefaktien poisto kuvasta Skannatussa kuvassa voi esiintyä erilaisia virheitä kuten taustan tummuutta, heikkolaatuista tekstiä tai roskia (ks. kuva 3). Todellisten artefaktien poistaminen kuvasta ei ole yksinkertaista. Poistaminen voi jopa sotkea dokumentin si- sältöä ja aiheuttaa näin odottamattomia vaikutuksia esim. tekstin tunnistukseen. Mitään täydellistä ratkaisua ongelmaan ei ole, mutta esimerkiksi tii- viysanalysointia on tutkittu yhtenä ratkaisuna. Tässä menetelmässä kuva- alueille lasketaan tiiviysarvo, jonka perusteella tehdään päätelmä onko kysees-

13 sä artefakti vai ei. Tiiviysarvo lasketaan valitun alueen sisältämien täytettyjen eli värillisten pikseleiden perusteella siten, että kaikki em. pikselit huomioidaan laskennassa. Raja-arvon 1.4 alle jäävä tiiviysarvo on merkki artefaktista [Neves et al., 2008].

Kuva 3. Esimerkki tummuus- ja laatuvirheistä. Hiilikopiopaperit ovat hyvä esimerkki paljon artefakteja sisältävistä lomakkeista. Niissä esiintyy sekä väriongelmia että heikkolaatuista tekstiä. Tekstiä voi olla myös hankala erottaa taustasta, koska väriero voi olla hyvin vähäinen. Tunnistamistarkkuutta voidaan parantaa muuntamalla kuva täysin mustavalkoiseksi, jolloin sisällön kannalta oleelliset pikselit on helpompi erottaa taustasta. Tätä menetelmää kutsutaan binäärisaatioksi. Testeissä on saavutettu 9- 21% kokonaisparannuksia tunnistettaessa tekstiä hiilikopiopaperista [Milewski and Govindaraju, 2006]. Artefaktien poistaminen ei aina ole mahdollista ennen dokumentin rakenteen tunnistamista, koska toimenpide voi vaatia ymmärrystä rakenteesta [Abad et al., 2006].

3.3. Tehokkuus Kuten jo aiemmin on todettu, nykypäivän kuvanlukijat kykenevät käsittele- mään parhaimmillaan n. 100 sivua minuutissa. Jos käsiteltäviä paperilomakkei-

14 ta on tuhansia tai päivittäinen tarve ylipäätään on suuri, on syytä miettiä erilaisia keinoja skannauksen tehostamiseksi. Yksinkertaisin tapa on kuvanlukijoiden sijoittelu. Laitteen tulee olla lähellä käyttäjää, jotta uusia paperilomakkeita voidaan lisätä heti, kun laite on käsitel- lyt sille syötetyt paperilomakkeet. Jos laite on sijoitettu pois näkyvistä, tulee prosessiin väkisinkin tyhjäkäyntiaikoja, kun paperilomakkeiden lisääminen unohtuu. Kuvanlukija ei ole kuitenkaan täysin äänetön laite, joten sen sijoittaminen käyttäjän työpisteen ääreen voi olla käyttäjää häiritsevää, jos laite on toiminnassa koko ajan. Parempi tapa on sijoittaa kuvanlukija erilliseen paikkaan ja käyt- tää järjestelmän sisäistä diagnostiikkaa (ks. luku 8) pitämään käyttäjä ajan tasalla prosessin tilanteesta. Järjestelmän havaitessa, että uutta skannattua kuvaa ei ole tullut oletusajan sisällä, käyttäjälle lähetetään tiedote joko sähköpostilla tai teks- tiviestillä. Lisäksi voidaan käyttää muita reaaliaikaista viestinpalvelua, jos sel- lainen on saatavilla.

Kuva 4. Esimerkki organisaatiosta, jossa käytetään useampaa kuvanlukijaa.

Järjestelmän lähtökapasiteettia voidaan myös tarvittaessa nostaa ottamalla yhden kuvanlukijan sijasta käyttöön useampia kuvanlukijoita. Tämä on huo-

15 mioitava jo järjestelmän suunnitteluvaiheessa, jotta skaalautuvuus on mahdollista. Käytettäessä useampaa kuvanlukijaa voi yksittäisen kuvanlukijan kapasiteetti olla huomattavasti pienempi kuin vain yhtä kuvanlukijaa käytettäessä. Käytössä olevien kuvanlukijoiden kokonaiskapasiteetti on kuitenkin toiminnan kannalta ratkaiseva tekijä. Lisäksi toimintaa voidaan tehostaa harkitulla kuvanlukijoiden sijoittelulla. Kuvanlukijoiden ei siis tarvitse eikä tule olla yhdessä ja samassa paikassa, vaan ne voivat olla fyysisesti täysin eri paikoissa. Isossa or- ganisaatiossa (ks. kuva 4) järjestelmä itsessään on keskitetty päätoimipaikkaan, mutta sisältöä voidaan tuottaa kuvanlukijoiden välityksellä kaikista alatoimi- paikoista. Tällöin on syytä huomioida käytettävissä oleva verkkokapasiteetti.

4. Lomakerakenteen tunnistaminen Seuraavaksi tarkastellaan paperilomakkeen rakennetta kuvaavan lomakerakenteen muodostamista. Käsiteltävänä ovat sekä manuaalinen luominen että automaattinen tunnistaminen. Kummassakin tapauksessa perehdytään siihen, miten skannattua kuvaa voidaan käyttää apuna. Lisäksi selvitään dokumenttitie- tämyksen muodostamista sekä rakenteen luokittelua ja tunnistamista muotojen perusteella. Värien käyttö lomakkeessa otetaan myös esille ja viimeisenä pe- rehdytään editoinnin kannalta oleellisiin seikkoihin. Digitalisoitavan lomakkeen rakenteen määrittely on ensiarvoisen merkityk- sellistä sisällön tulkitsemisen kannalta. Lomakerakenne on lomakkeen virtuaa- linen kuvaus, joka sisältää lomakkeen loogisen rakenteen lisäksi fyysisen rakenteen [Klink et al., 2000]. Tyypiltään lomakerakenne on useimmiten puu, mutta se voi olla myös verkko. Lomakerakenteen määrittely voidaan tehdä täysin manuaalisesti tai jättää automatiikan vastuulle osittain tai kokonaan [Staelin et al., 2007]. Määritettäes- sä lomakerakenne manuaalisesti editorilla voidaan lomaketta käyttää silmä- määräisesti apuna tai skannattua lomaketta voidaan käyttää ohjelman taustalla apuna, jolloin käyttäjä saa konkreettista apua määrittelyyn. Manuaalista lomakerakenteen määrittelyä käsitellään lomakerakenteen editoinnin yhteydessä (ks. alakohta 4.6). Käytettävän järjestelmän luonne vaikuttaa omalta osaltaan lomakerakenteen määrittelyyn. Jos järjestelmä on tarkoitettu vain tietyn tyyppisille lomak- keille, voidaan lomakerakenne määritellä muuttumattomaksi osaksi järjestel- mää, koska tiedetään, että käsiteltävät lomakkeet ovat aina samankaltaisia. Tunnistamistarvetta ei siis tällöin ole. Oikeellisiksi varmistetut lomakerakenteet tallennetaan järjestelmän tunte- maan tietosäiliöön tulevaa käyttöä varten. Prosessoitaessa uusia lomakkeita voidaan tunnistettua lomakerakennetta vertailla tallennettuihin lomakeraken- teisiin ja hakea vastaavuuksia [Kebairi et al., 1999; Zhilan et al., 2007]. Jos löytyy annettujen toleranssien sisällä oleva lomakerakenne, voidaan se ottaa käyttöön uuden lomakerakenteen luomisen sijasta. Näin vältetään tarpeetonta vuorovai- kutus käyttäjän kanssa ja tehostetaan prosessin etenemistä. Vertailu voidaan tehdä esimerkiksi vertaamalla rakenteesta muodostettua soluprojektiota käsi- teltävään lomakkeeseen [Peng et al., 2003]. Soluprojektio muodostetaan jakamalla kuva alueisiin sisällön perusteella ja muodostamalla tämän jälkeen alueille vektorit, joita voidaan käyttää vertailuun.

Prosessoitaessa samankaltaisia lomakkeita voidaan lomakerakennetta hyö- dyntää tekstin tunnistuksen yhteydessä antamalla tunnistettavaksi vain ne alueet, joista todella ollaan kiinnostuneita [Wu et al., 2008]. Skannatusta kuvan si- sältämistä alueista voidaan luoda erilliset pienkuvat, jotka syötetään tekstin tunnistukselle, tai vaihtoehtoisesti kuva annetaan tunnistettavaksi rajausten ke- ra. Tehokkuutta tarkasteltaessa etu on huomattava, koska koko lomaketta ei tarvitse käydä läpi.

4.1. Automatisoitu tunnistaminen Automatisoidun lomakerakenteen tunnistamisen tarkoituksena on vähentää käyttäjän tarvetta puuttua itse prosessiin. Järjestelmä prosessoi lomakkeen itse- näisesti ja luo sitä vastaavaan virtuaalisen lomakerakenteen [Liang, 1999]. Alu- eet, kuten sivumarginaalit, jotka eivät ole sisällön kannalta merkityksellisiä voidaan jättää huomioimatta [Shafait et al., 2007]. Tunnistettu lomakerakenne on silti syytä hyväksyttää käyttäjällä, jotta tiedetään sen vastaavan todellisuutta. Lomakerakenteen sisältäessä virheitä voi käyttäjä korjata ne ennen lopullista hyväksymistä. Automaattiseen tunnistamiseen on olemassa useita erilaisia me- netelmiä ja niitä on tutkittu paljon [Mao et al., 2003]. Menetelmät rakenteen tunnistamiseksi eroavat suuresti: jotkut perustuvat lomakkeen sisältämien viivojen tunnistamiseen [Zheng et al., 2005] ja lomakkeen jaotteluun niiden perusteella [Couasnon, 2001], kun taas toiset tunnistavat rakenteen tekstin perusteella. Kuten jo aiemmin todettu on lomakkeiden järjestäminen toisinaan kannattavaa, jos tiedetään niiden olevan samankaltaisia. Tällöin voidaan aiemmin luo- tua lomakerakennetta käyttää koko sarjan kanssa. Lomakkeiden ollessa epäjär- jestyksessä joudutaan jokaisen lomakkeen lomakerakenne selvittämään erikseen, jotta lomake saadaan tunnistettua. Lomakerakenteen automaattinen tunnistaminen on useimmiten parasta tehdä erillistoimintona prosessin aloittamisen yhteydessä. Tämä tapahtuu siten, että järjestelmälle annetaan tunnistettavaksi käytettävä täyttämätön lomake yhden tai useamman kerran. Annettaessa lomake useamman kerran on syytä käyttää useampaa kuin yhtä lomaketta, jotta yhdellä lomakkeella olevat virheet eivät korostu tunnistuksessa. Useamman lomakkeen käyttäminen minimoi lomakkeella ja prosessin aikana esiintyvien virheiden vaikutusta tunnistettuun lomakerakenteeseen, koska lomakerakenne muodostetaan useamman lomakkeen tunnistustiedoista. Vaihtoehtoisesti lomakerakenne voidaan luoda sarjan ensimmäisen tai ensimmäisten täytettyjen lomakkeiden perusteella.

4.2. Dokumenttitietämys Tunnistamisen kannalta ei ole pelkästään oleellista erottaa lomakkeen eri osioi- ta toisistaan, vaan myös muodostaa tietämys dokumentin rakenteesta [Klink et al., 2000]. Tämä sisältää yleisesti käytettyjen dokumenttirakenteiden kuten ylä- ja alaotsikon, listojen ja taulukoiden tunnistamisen. Varsinaisten tekstikompo- nenttien osalta pyritään luomaan tietämys, jossa otsikot ja teksti ovat eroteltui- na. Saaduille tekstikomponenteille voidaan antaa painoarvo, joka määrittää, mitä tyyppiä se on. Muodostetusta tietämyksestä voidaan luoda rakennepuu, jota voidaan käyt- tää haettaessa käsiteltävään lomakkeeseen sopivaa lomakemallia. Vertailussa voidaan käyttää esimerkiksi yksiulotteisia vertikaalisia ja horisontaalisia avaimia [Lin et al., 1996]. Rakenteesta muodostetaan erikseen sekä vertikaalinen että horisontaalinen rakennepuu, jonka perusteella luodaan avain vertailua varten.

A1 A2 A3 A3 A1 A2 A4 A5 A4 A5

A6 A7 A8 A8 A6 A7

Kuva 5. Dokumentin rakenne ja vastaavat vertikaaliset 1D avaimet [Lin et al., 1996].

Kuvassa 5 on tunnistettuna dokumentin rakenne sekä sitä vastaavat vertikaaliset polut. Dokumentin vertikaalinen avain on A1A5A8A2A3A4A6A7. Vas- taavalla tavalla muodostetaan rakennetta vastaava horisontaalinen avain.

4.3. Taulukoiden tunnistaminen Laskut, tilaukset yms. lomakkeet ovat useimmiten rakenteeltaan taulukon kal- taisia ja ne on jopa saatettu tehdä taulukkolaskentaohjelman avulla. Tunnista- minen voidaan tehdä etsimällä lomakkeesta solut toisistaan erottavia tekijöitä, kuten viivoja. Yhtenä vaihtoehtona on esitetty menetelmää, jossa muodostetaan

19 sanoista verkko, jossa sanaan linkitetään sen ylä- ja alapuolella sijaitsevat sanat. Menetelmä tunnetaan nimellä T-Recs [Kieninger and Dengel, 1999]. Verkon muodostamisen jälkeen vuorossa on varsinainen taulukointi. Tau- lukointi toteutetaan asettamalla sanaverkon päälle hienojakoinen taulukko. Taulukon solu voi olla tyhjä, sisältää sanan tai sisältää osan sanasta. Tarkaste- lemalla sanojen välisiä riippuvuuksia ja sijaintia taulukossa saadaan kerätty tie- to taulukoitua. Menetelmän tarkkuus on riippuvainen käytettävän jakotaulu- kon solukoosta.

4.4. Solujen tunnistaminen Taulukko ei ole mitään muuta kuin kasa soluja, joiden sisällöllä on merkitystä lomakkeen tekijälle. Tunnistaminen voidaan toteuttaa etsimällä lomakkeessa olevat solut ja muodostamalla niistä solurakenne [Belaïd and Belaïd, 1999]. Kaikkia soluja ei kuitenkaan tarvita jatkossa, joten solut voidaan luokitella niiden sisällön perusteella. Tämä ei kuitenkaan vielä kerro mitään solun varsinai- sesta käyttötarkoituksesta. Solujen luokittelusta on hyötyä, koska tekstin tunnistuksen yhteydessä voidaan ohittaa epäoleelliset solut sekä solut, joiden sisältö lomakkeella on kiinteä, esim. otsikkosolut. Soluille voidaan myös antaa manuaalinen avain, mikä helpottaa informaation vientiä tietomalliin. Avain kertoo tietomallille tiedon käyt- tötarkoituksen tallentamisen yhteydessä. Periaatteessa avaimena voitaisiin käyttää solun otsikkoa, mutta sijainnin tunnistaminen ei ole aivan yksiselitteis- tä. Erilaisia solutyyppejä voivat olla esimerkiksi:

 DIGI: numeeriset kentät, joissa voi myös esiintyä +/-  GRAY: ei syötettä  HLET: horisontaalinen teksti  VLET: vertikaalinen teksti  HHCL: horisontaaliset isot kirjaimet  VHCL: vertikaaliset isot kirjaimet  BLAC: käänteisvärjätyt solut  EMPT: tyhjät solut [Belaïd and Belaïd, 1999].

Avaimen liittäminen soluun ei onnistu automaattisesti, vaan se vaatii vuo- rovaikutusta käyttäjän kanssa. Tämä liittyy osaltaan lomakemalliin, mitä käsi- tellään luvussa 5.

4.5. Värien käyttäminen Lomakkeen tunnistusta voidaan helpottaa käyttämällä lomakkeessa värejä [Sherkat et al., 2005]. Väritietämys on myöhemmin hyödynnettävissä, kun ollaan erottelemassa sisällön kannalta epäoleellista tietoa todellisesta tiedosta. Tämä myös nopeuttaa kokonaisprosessia. Väreissä skannattu kuva vie paljon tallennustilaa, jos käytetään täyttä tarkkuutta. Värien vähentäminen on siksi useimmiten tarpeen ja jopa suotavaa. Lomakkeissa harvoin kuitenkaan käytetään useita eri värejä, joten vähentämi- nen ei heikennä laatua. Periaatteessa jo yksibittiset värikomponentit, eli kahdeksan väriä, on riittävä tarkkuus. Värien vähentäminen helpottaa myös kuvan käsittelyä, koska sisällön vertailu on helpompaa. Värien käytön todellinen hyöty saavutetaan kuitenkin vasta lomakkeen si- sältöä käsiteltäessä. Tiedettäessä lomakkeen ns. kuolleet eli tarpeettomat värit voidaan ne pudottaa heti prosessoinnin alussa pois. Näin jäljelle jää vain prosessin kannalta oleellinen informaatio. Testeissä on todettu, että värien käyttäminen nopeuttaa prosessia ja parantaa tarkkuutta matalaresoluutioisten lomakkeiden yhteydessä [Sherkat et al., 2005].

4.6. Editointi Lomakerakenteen automaattiseen tunnistamiseen ei voida koskaan täysin var- masti luottaa. Siksi käyttäjälle on annettava mahdollisuus korjata lomakerakennetta. Tähän tarkoitukseen soveltuu parhaiten WYSIWYG-pohjainen käyt- töliittymä, joka antaa käyttäjälle riittävän visuaalisen palautteen muokkaustoi- menpiteistä [Kochi and Saitoh, 1999]. Käyttöliittymästä tulee selkeästi erottaa tunnistetut alueet. Ne voidaan esit- tää käyttäjälle suorakulmioina, jotka voivat olla värjättyjä erottamisen helpottamiseksi. Käyttäjän on pystyttävä muokkaamaan näitä alueita ja tarvittaessa myös lisäämään uusia [Taylor et al., 1992]. Siirtäminen voi tapahtua ottamalla alueesta esim. hiirellä kiinni ja raahaamalla se uuteen paikkaan. Koon muok- kaaminen puolestaan voi tapahtua ottamalla alueen kulmasta kiinni ja raahaamalla joko venyttäen tai kutistaen aluetta. Fyysisen rakenteen lisäksi lomakkeella on myös looginen rakenne, joten käyttäjän on myös pystyttävä vaikuttamaan siihen. Looginen rakenne voidaan esittää osin värikoodauksella, mutta se ei anna välttämättä täydellistä koko- naiskuvaa. Selkeintä on, jos looginen rakenne on esitetty myös puuna, josta rakenteen eri osat ovat nähtävissä omilla tasoillaan.

5. Lomakemallilla tarkennusta lomakerakenteeseen Seuraavaksi on vuorossa perehtyminen lomakerakenteen sisältöä tarkentavaan ja kuvaavaan lomakemallin käsitteeseen. Tässä yhteydessä tarkastellaan mitä lomakemalli kuvaa ja mitä hyötyä lomakemallia käyttämällä saavutetaan. Lomakemalli on lomakerakennetta tarkentava kuvaus ja viittaa aina pohjal- la olevaan lomakerakenteeseen [Kochi and Saitoh, 1999]. Siinä missä lomakerakenne sisältää fyysisen kuvauksen lomakkeesta, lomakemalliin määritetään lomakkeen dataan liittyviä avaimia ja koodauksia. Lomakerakenteesta löytyvä solu ei yksinään kerro mitään muuta kuin sisältämänsä arvon. Lomakemalli lisää käsittelyyn semanttisuutta antamalla solulle nimen ja tarvittaessa myös muita attribuutteja [Antonacopoulos and Karatzas, 2004]. Vähimmällään tarvitaan ainakin kentän nimi tai avain, mutta lisäksi voidaan antaa esim. käyttöön, formaattiin ja näkyvyyteen liittyviä lisämääreitä. Lisämääreet ovat osin sidoksissa tietomalliin ja sen vaatimuksiin. Lomakemalli tallennetaan järjestelmään odottamaan myöhempää käyttöä. Lomakemalli voidaan luoda jo ennen kuin ensimmäistäkään skannausta on suoritettu. Tällöin käyttäjän on kuitenkin samalla luotava lomakemallia vastaava lomakerakenne (ks. luku 4). Jos lomakerakenne on valmiina, voidaan lomakemallin luominen aloittaa linkittämällä se lomakerakenteeseen. Vasta tämän jälkeen määritetään lomakemallin attribuutit. Lomakemallin tietojen määrittelyä ja muokkaamista varten tarvitaan editori [Kochi and Saitoh, 1999]. Muokattavat tiedot ovat sisällöltään tyypillisesti vain informatiivisia avainkenttiä, joten muokkaamisesta ei kannata tehdä liian han- kalaa. Muokkaamista varten käyttäjän on kohdistettava toiminto johonkin lomakerakenteen kenttään. Tämän jälkeen aktiivisen kentän arvot voivat näkyä jatkuvasti näytöllä. Vaihtoehtoisesti kentän aktivoimisen jälkeen käyttäjälle voidaan näyttää dialogi, josta arvoja voi muuttaa. Editori integroituu parhaiten lomake-editorin yhteyteen, koska kyseessä on kuitenkin samojen elementtien editointi lisämäärittelyjä varten. Käyttäjälle tä- mä on myös selkeämpää, koska editoria ei tarvitse vaihtaa toimenpiteiden välil- lä ja kaikki toiminnot ovat jatkuvasti käytettävissä. Toteutustasolla voi kuitenkin olla järkevää pitää editorien toteutus riittävän erillään toisistaan. Tällä helpotetaan korjausten tekemistä, sekä tulevaisuudessa tarpeellisiksi havaittujen muutosten ja lisäysten toteuttamista. Lisäksi samalla voidaan huomioida järjestelmän dynaamisuus ja jättää ovi auki järjestelmään myöhemmin tuotaville editorilaajennuksille tai editorin kokonaan korvaaville

22 toteutuksille. Lomakerakenteen editorin osalta korvaaminen ei ole niinkään tarpeen, mutta lomakemallin osalta vaatimukset tietomallin suuntaan voivat muuttua ja editorin vaihtamismahdollisuus toimii tässä omalta osaltaan apuna. Lomakemallia tarvitaan varsinaisesti vasta prosessin loppuvaiheessa, kun kerättyä dataa ollaan tallentamassa tietomalliin. Lomakemalli sisältää avaimen lomakkeen lomakerakenteen kautta saatavalle informaatiolle, joka kertoo mihin paikkaan tietomallissa informaatio tallennetaan tai millä avaimella tallennus tapahtuu.

6. Tekstintunnistaminen lomakkeen sisällöstä Tässä luvussa perehdytään prosessin automatisoinnin kannalta haasteelliseen tekstintunnistukseen. Liikkeelle lähdetään tutustumalla aiheen historiaan. Tä- män jälkeen vuorossa ovat tekstintunnistamiseen liittyvät vaiheet materiaalin esikäsittelystä, tunnistetun tekstin oikeellisuuden varmistamiseen ja aina jälki- käsittelyyn virheiden korjauksineen. Käsinkirjoitettu teksti on esillä erikseen, koska siihen liittyy omia haasteita. Lopuksi tarkastellaan erilaisia saatavilla olevia tekstintunnistusrajapintoja. Lomakkeita käytetään pääasiassa tekstimuotoisen tiedon hankkimiseen. Kuvia tms. symboleita voidaan myös kerätä lomakkeilla, mutta tarve on vähäi- sempää ja niiden käsittely tekstiin verrattuna on huomattavasti yksinkertai- sempaa. Kuva on kuitenkin vain kasa pikseleitä, jota voidaan käyttää sellaise- naan. Teksti on alkujaan myös kasa pikseleitä ja se voitaisiin myös tallentaa täs- sä muodossa, mutta jatkokäsittelyn kannalta kuvamuotoinen teksti ei ole käy- tännöllistä, koska se ei sisällä semantiikkaa kirjainten ja sanojen osalta. Kuvalle ei voi suorittaa mitään yleisiä merkkijono-operaatioita tietokoneavusteisesti ja myös tilantarve on merkkijonoja huomattavasti suurempi. Kuvassa oleva teksti on saatava siis muutettua merkkijonoksi ennen kuin se lähetetään tietomallille. Tässä kohtaa avuksi otetaan tekstintunnistus. Tekstintunnistus on prosessi, jossa kuvainformaatiosta pyritään erottamaan kirjaimet [Trier et al., 1996] ja muodostamaan niistä merkkijono. Ihmisen on helppo ymmärtää näkemiään muotoja muodostaen pisteistä kirjaimia, kirjai- mista sanoja ja sanoista lauseista. Tietokoneelle prosessi on huomattavasti han- kalampi. Tietokone ei opi samalla tavalla kuin ihminen ja mukautuminen muuttuviin olosuhteisiin ja tyyleihin on huomattavan vaikeaa [Baird et al., 2004]. Mekaanisella tasolla ja optimiolosuhteissa tietokonekin kykenee kuitenkin nykyään jo vaikuttaviin suorituksiin. Tunnistaminen voi tapahtua vertailemalla annetun kuvan sisältöä suoraan tunnettuihin merkkeihin ja poimimalla sieltä paras vastaavuus. Menetelmä on altis virheille, koska yhteyttä tunnistettujen kirjainten välillä ei ole ja sanojen kokonaismerkitys jää huomioimatta. Tarkkuutta parantamaan voidaan tunnis- tusprosessiin ottaa mukaan sanastoja [Koga et al., 1999]. Sanaston avulla tunnistettavan tekstin suodatus on mahdollista ja sanojen kokonaismerkitys selkiytyy. Sanastolla voidaan kaventaa mahdollisten vaihtoehtojen määrää ja siten pienentää virhemarginaalin todennäköisyyttä. Sanaston haittapuolena on mahdollinen rajoittuneisuus sanojen määrän osalta. Järjestel-

24 mä voi kehittää sanastoa käytön aikana poimimalla tunnistettavasta materiaalista uusia sanoja. Alkusanasto voidaan muodostaa antamalla järjestelmälle aloitusvaiheessa riittävästi sisällöltään sopivaa tekstiä sisältävää materiaalia tunnistettavaksi [Spivak, 2002]. Järjestelmä voi olla myös oppia ja osata mukautua havaittuihin virheisiin käytössä olevan sanaston pohjalta [Rawat et al., 2006]. Älykäs järjestelmä olisi käytön kannalta hieno asia, mutta ei yksinkertainen toteuttaa.

6.1. Historiaa Tekstintunnistuksen, OCR:n (Optical Character Recognition), juuret kulkevat aina vuoteen 1809, jolloin patentoitiin ensimmäiset sokeita tekstin lukemisessa avustavat laitteet. Vuonna 1912 Emmanuel Goldberg patentoi laiteen, jolla lan- koja pitkin lähetettävien viestien kirjaimet muutettiin automaattisesti tuettuun sähkösanoma formaattiin [Lenox and Woratschek, 2002]. OCR:lle löytyi uusi tarve ennen toista maailmansotaa, kun shekkien käsittelyä haluttiin automatisoida [AIM, 2000]. Varsinainen teknologinen lähtösykäys tuli kuitenkin vasta toisen maailmansodan jälkeen pankkikorttien myötä. Ensimmäiset laitteet olivat hitaita ja virhealttiita, mutta suunta oli hyvä. 1960-luvulla laitteet oppivat jo tunnistamaan tekstissä olevia kaarteita mahdol- listaen käsinkirjoitetun tekstin tunnistamisen. Alkuaikojen tekstintunnistus oli pitkälti sidoksissa itse laitteeseen. Nykyään laite voi olla täysin erillään sovel- luksesta, mikä avaa uusia käyttö- ja kehitysmahdollisuuksia. Materiaali voidaan lukea helposti sisään ja siirtää muualle prosessoitavaksi. Vuonna 1968 kehitettiin tekstintunnistusta varten kaksi selkeät symbolit si- sältävää erillistä fonttia OCR-A ja OCR-B. Ensimmäisen fontin kehitti American Type Founders-organisaatio ja se on standardoitu ISO 1073-1:1976 [Baid, 2000; Wikipedia, 2010]. Jälkimmäisen fontin taustalla on Adrian Frugiter ja fontista tuli vuonna 1973 maailmalla hyväksytty standardi. Se seuraa myöhemmin jul- kaistua ISO 1073/II-1976 (E) standardia [Osterer and Stamm, 2008]. Nämä fontit ovat helppolukuisia sekä ihmiselle että tietokoneelle. Tekstintunnistus ei ole vieläkään sataprosenttisen varma menetelmä. Tieto- kone on parhaimmillaan, kun tunnistettava materiaali on laadultaan hyvä: helposti erotettava fontti, hyvä paperilaatu, hyvä skanneri jne.

6.2. Esikäsittely Kuvassa olevat virheet ja vinoumat hankaloittavat tekstintunnistusohjelman toimintaa. Materiaalille voidaan suorittaa erilaisia esikäsittelytoimenpiteitä, jot-

25 ta tunnistustarkkuutta saadaan parannettua ja virheiden määrää pienennettyä. Tavallisia toimenpiteitä ovat seuraavat:

 Binäärisaatio. Binäärisaatiossa kuva muunnetaan mustavalkoiseksi, jotta rajojen yms. erottaminen helpottuu. Yksittäisen kirjaimen tunnistus on myös varmempaa, kun väriliu'ut eivät ole haittana.  Suoristus. Vaikka alkuperäinen kuva on suoristettu, voi tunnistettava tekstialue olla edelleen vinossa. Suoristuksella parannetaan fontin luet- tavuutta.  Vääristymien korjaus. Tunnistettava kuva itsessään voi olla suorassa, mutta sisällössä voi olla vääristymiä ja vinoutumia. Tämä on tyypillistä etenkin lehtien tai kirjojen kohdalla, kun materiaalia ei välttämättä saada täysin tasaiseksi kuvanlukijaan.  Rajojen poisto. Tunnistettavalla alueella olevat rajaviivat voivat tulla tunnistetuiksi kirjaimina, joten poistamalla ne kuvasta parannetaan tunnistustarkkuutta.  Jaottelu. Tunnistettava alue saattaa olla osa laajempaa kokonaisuutta, joka sisältää useita erillisiä tekstialueita. Jaottelemalla voidaan tunnistaa erilliset kokonaisuudet erikseen [Korb, 2008] Edellä esitetyistä esikäsittelytoimenpisteistä suoritus liittyy osaltaan myös skannauksen yhteyteen ja jaottelu sisältyy tavallisesti jo lomakerakenteen luo- miseen.

6.3. Oikeellisuuden varmistus Tekstintunnistuksessa on hyvä huomioida riittävä taso tunnistetun tekstin oikeellisuuden osalta. Virheet tunnistuksessa voivat aiheuttaa myöhemmin vää- riä oletuksia ja johtopäätöksiä, kun kerättyä dataa analysoidaan. Oikeellisuu- den varmistaminen voidaan antaa käyttäjän tehtäväksi tai sitten se voidaan automatisoida tietokoneen prosessiksi. Käyttäjän varmentaman tekstin yhteydes- sä voidaan oikeellisuudesta olla kohtuullisen luottavaisia. Ihmisen kapasiteetti on kuitenkin rajallinen ja vireystila vaikuttaa laatuun. Käyttäjä voi suorittaa tarkistuksen käymällä läpi tunnistetun tekstin digita- lisoiduista paperilomakkeista tai etsimällä poikkeamia tunnistusohjelman lo- keista, jotka kertovat ongelmista tunnistuksessa [Korb, 2008]. Vähäiset loma- kemäärät on helppo tarkastaa täysin, mutta määrän kasvaessa alkaa toimenpide viedä paljon aikaa ja sitoa resursseja tarpeettomasti.

Tietokoneen voi myös ottaa avuksi toimenpiteeseen. Tietokone voi käydä lokeja läpi, aivan kuten ihminen, ja etsiä sieltä ongelmista kertovia poikkeamia. Havaituista poikkeamista välitetään tieto käyttäjälle ja näin lopullinen vastuu varmistuksesta on edelleen käyttäjällä. Jos tarkastettavia tietoja on paljon, voidaan ottaa vain pieni otanta tarkistet- tavaksi, jotta toimenpiteeseen käytettävä aika saadaan hyväksyttävälle tasolle. Otantaa käytettäessä ei oikeellisuudesta voi tehdä varmoja johtopäätöksiä, koska se saattaa vaihdella laajan materiaalin eri osissa hyvinkin paljon. Tilannetta voidaan parantaa ottamalla useita pieniä otantoja, joskaan tämäkään ei vielä kerro koko totuutta. Nykypäivänä vastuu tarkistuksesta on helppo jakaa useammalle käyttäjälle kohtuullisen vähin ponnistuksin. Tunnistuksen edistyessä voidaan materiaalista tehdä satunnaisotantoja ja lähettää otantaan liittyvä tunnistus- ja tunnistettu materiaali jollekin käyttäjistä. Käyttäjä käy materiaalin läpi kirjaten samalla virheet ylös. Käytyään materiaalin kokonaan läpi käyttäjä palauttaa virherapor- tin. Lähetyksen, materiaalin käsittelyn ja raportoinnin lisäksi järjestelmän olisi hyvä tukea myös käyttäjien kirjautumisia, jotta materiaalia välitetään vain ak- tiivisille käyttäjille. Laskettaessa virheiden määrää voidaan keskittyä joko virheisiin kirjaimissa tai virheisiin sanoissa. Tällä hetkellä algoritmit perustuvat pääosin kirjainpoh- jaiseen tunnistukseen, koska kirjainkohtaiset virheet ovat yksiselitteisiä. Kirjain- ten painoarvo on myös selkeämpi, kun lähdetään laskemaan keskimääräistä virhemarginaalia. Sanavirheitä tarkasteltaessa lyhyen ja pitkän sanan painoarvo on sama, mikä ei välttämättä vastaa todellisuutta. Erilaisia menetelmiä sa- navirheiden tunnistamisen parantamiseksi on kehitteillä [Korb, 2008]. Oikeellisuutta tarkastelemalla voidaan haarukoida virheiden olemusta ja luoda virhekantaa. Kannan perusteella tekstintunnistusta voidaan opettaa sel- viämään havaituista tyypillisistä virhetilanteista.

6.4. Jälkikäsittely Kuten edellä on todettu, tekstintunnistus ei ole koskaan täysin varmaa eli virheet ovat tavallisia. Jäljelle jäävät virheet eivät välttämättä ole merkityksellisiä, mutta niiden korjaaminen vaikuttaa vähintään tekstin luettavuuteen. Jos tarkastellaan nykypäivän tekstinkäsittelyohjelmia, löytyy kaikista isoimmista oh- jelmista oikolukutoiminto, joka ainakin merkitsee virheet, jos ei ihan korjaa nii- tä. Vastaavan toiminnallisuuden tuominen mukaan tekstintunnistusprosessiin parantaa laatua. Erillään oleva oikolukumoduuli parantaa järjestelmän skaalau-

27 tuvuutta, koska se voidaan tarvittaessa helposti vaihtaa. Lisäksi eri kielien huomioiminen on helpompaa.

6.4.1. Tunnistus- ja kirjoitusvirheet Oikoluku ei ole kuitenkaan täydellinen ratkaisu, koska tekstiä ei ole suoranai- sesti tuotettu, vaan se on malli olemassa olevasta tekstistä. Näin ollen tekstissä voi esiintyä tunnistuksesta johtuvia virheitä ja oikeita kirjoitusvirheitä [Cavnar and Gillies, 1994]. Tunnistuksesta johtuvien virheiden korjaus oikoluvulla voi johtaa vääriin tulkintoihin, jos järjestelmä ei osaa huomioida, että kaikki virheet eivät ole suoranaisia kirjoitusvirheitä. Automaattisten korjausmenetelmien tär- keys on tiedostettu ja erilaisten menetelmien toimivuutta jälkikäsittelyn yhte- dessä on tutkittu paljon [Beitzel et al., 2003; Kolak and Resnik, 2002]. Tong ja Evans [1996] esittivät virheiden korjaamiseen mallia, joka kykenee korjaamaan kumpiakin esiintyviä virheitä. Heidän esittämänsä menetelmä perustuu tekstin sisältämien kirjain- ja sanajaksojen (n-gram) analysointiin. Lisäk- si se sisältää oppivan lähekkäin olevien ja helposti sekaisin menevien sanojen korjausmekaniikan. Järjestelmä siis kehittyy käytön myötä. Oppiminen vaatii useita materiaalin käsittelykertoja, mutta opettaminen voidaan suorittaa jo ennen varsinaista tunnistusta antamalla riittävän hyvä lähtömateriaali oppi- misalustaksi. Korjausmenetelmän testaukseen käytettiin eräästä verkkouutispalvelusta tulostettuja uutisia. Skannauslaatua heikennettiin valottamalla materiaalia. Il- man korjausta 14,7% (8198) vain kirjaimia sisältävistä sanoista tunnistettiin vir- heellisesti. Sovellettaessa esitettyä korjausmenetelmää virheiden määrä putosi 3270:n, joten parannusta alkuperäiseen tuli 60,8%, Kokonaisvirhemarginaali oli kuitenkin edelleen 5,9%. Konkreettisesti dokumentin sisältöä virheiden korjauksessa on käytetty esim. MANICURE-järjestelmässä, jonka kehitys on aloitettu vuonna 1998. Jär- jestelmä perustuu myös oppivaan ympäristöön, joka luo dynaamisesta tunnistettavasta materiaalista korjauksessa tarvittavia viitteitä. Nartker ja muut [2003] vertasivat MANICURE-järjestelmää SDK2000 OCR:ä järjestelmään. Testissä käytettiin useita eri lähdemateriaaleja, joista jokaisesta luotiin alkuperäismate- riaalin lisäksi viisi generaatiota siten, että seuraava generaatio skannattiin aina edellisestä generaatiosta laadun heikentämiseksi. MANICUREN tarkkuus keskimääräisen sanan tunnistuksen osalta vaihteli alkuperäismateriaalin 99,66-prosentista viimeisen generaation 98,86-prosent- tiin. Parhaimmillaan etua SDK2000:een verrattuna oli neljännen ja viidennen

28 generaation kohdalla, jolloin tarkkuus oli 0,27% parempi. Kummankin järjes- telmän virhemarginaali on kuitenkin huomattavasti pienempi kuin Tongin ja Evansin [1996] suorittamien testien kohdalla. Tähän vaikuttavat kehittyneempi tekniikka, parantuneet ohjelmistoalgoritmit ja laskentakapasiteetin kasvami- nen. On kuitenkin syytä ottaa huomioon, että testimateriaalit eivät ole samat, joten tulokset eivät ole suoraan verrannolliset. Korjaukseen löytyy myös kaupallisia sovelluksia, joista yksi esimerkki on PrimeOCR. Sovelluksen luvataan vähentävän virheiden määrää 65% perintei- seen OCR:n verrattun. Lisäksi saatavilla on optio parannetulla tarkkuudella, jolla virheiden määrän luvataan putoavan peräti 82%. Vertailukohta on kuitenkin nimeämätön, joten tuloksiin on syytä suhtautua varauksella [PrimeRecogni- tion]. Kirjaimissa esiintyvien virheiden määrää voidaan konkretisoida seuraavan laskelman avulla, kun oletetaan keskimääräisen tarkkuuden olevan 98% luok- kaa ja yksittäisten virheiden osalta tunnistuksen olevan 40%:

 2500 merkkiä  50 virhettä  20 virhettä merkitty epäilyttäviksi  30 virhettä tunnistamatta.

Virheiden määrä ei vaikuta kovinkaan suurelta. Edellä mainittu tekstimäärä mahtuu yhdelle A4-arkille, joten siihen nähden virheitä on paljon. Jos arkkeja on sata, on lopullisessa tuotoksessa jo 3000 merkkivirhettä.

6.4.2. Manuaalinen korjaus Automaattisen korjauksen lisäksi järjestelmä voi helpottaa käyttäjää tarjoamalla manuaalista korjausta varten työkaluja. Virheiden korjausta ja tunnistusta helpottaa, jos ne ovat selkeästi tunnistettavissa ja erotettuja [Taghva et al., 1998]. Työkalu voidaan toteuttaa tekstinkäsittelymäisellä lähestymisellä, jossa havaitut virheellisiksi epäillyt merkit ja sanat korostetaan. Visuaalisuus nopeuttaa materiaalin läpikäyntiä, koska silmä havaitsee potentiaaliset virheet helpom- min. Jos läpikäytävää materiaalia on paljon, voi käyttäjä lopulta turtua prosessiin ja korjata vain näytetyt virheet. Tällöin ei-havaitut virheet jäävät osittain tai kokoaan huomioimatta. Havaittujen virheiden yhteydessä voidaan esittää samalla myös mahdolliset korjaukset, jos sellaisia on löytynyt. Käyttäjä voi valita niiden joukosta oikean,

29 mikä nopeuttaa korjausta. Kirjoitusvaihtoehtoa ei voi kuitenkaan unohtaa, koska oikeaa vaihtoehtoa ei ole aina välttämättä automaattisesti saatavilla. Työkalu voi samalla toimia apuna tunnistuksen opettamisessa. Käyttäjän korjatessa virheitä voi järjestelmä samalla opetella tunnistamaan samankaltaisia virheitä ja luoda niistä itselleen oppimiskantaa. Jatkossa samankaltaiset virheet voidaan automaattisesti tunnistaa sekä korjata. Virheet voivat kuitenkin olla tyypillisiä vain tarkistettavalle materiaalille, ja siksi luotu oppimiskanta ei vält- tämättä ole käyttökelpoinen muiden materiaalien kohdalla.

6.5. Käsinkirjoitettu teksti Tietokoneella tulostetun tekstin tunnistaminen on huomattavasti helpompaa kuin käsinkirjoitetun. Tulostettu teksti on laadultaan tasaista ja huonolaatuista jälkeä voi aiheuttaa lähinnä mustevajaus, paperitukos tai huono paperilaatu. Tulostuksessa käytetyt fontit ovat yleisiä ja erot tulostimien välillä käytettäessä samaa fonttia ovat hyvin pieniä. Erilaista käsinkirjoitettua tekstiä esiintyy sen sijaan yhtä paljon kuin on ihmisiäkin. Jokaisella ihmisellä on hieman toisista eroava kirjoitustyyli, joskin toisen ihmisen tyylin imitoiminen on mahdollista. Vaihtoehtoisia menetelmiä käsinkirjoitetun tekstin tunnistamiseen on paljon [Lecun et al., 1998; Roy et al., 2009]. Ensimmäistä kertaa käsinkirjoitettuja dokumentteja tunnistettiin tietokoneella vuonna 1962 [AIM, 2000], jolloin tunnistaminen tekniikan kehittymisen myötä tuli mahdolliseksi. Sittemmin menetelmät ja tekniikat ovat kehittyneet, mutta käsinkirjoitettu teksti on silti haaste. Käsinkirjoitettua tekstiä on edelleen paljon, koska lomakkeet ovat pääsääntöisesti edelleen täytetty kynällä eikä tietokoneella. Perusprosessi käsinkirjoitettua tekstiä tunnistettaessa ei eroa tulostetun tekstin tunnistamisesta: ensin tunnistetaan kirjaimia ja sitten sanoja. Tekstin tyylin variaatioiden määrä vain on paljon suurempi. Käsinkirjoitetun tekstin tunnistusta varten tarvitaan huomattavasti suurempi sanasto kuin tulostetun materiaalin ollessa kyseessä. Samoin tunnistusmoduulin opettamiseen tarvitaan enemmän materiaalia. Saatavilla on kuitenkin nykyään paljon pieniä mo- biililaitteita, jotka sisältävät tekstintunnistusteknologiaa. Mobiililaitteet ovat käytettävissä olevien resurssien osalta vielä varsin rajoittuneita, joten suurten sanastojen ylläpitäminen ei ole mahdollista. Tutkimusta on tehty käytettävän sanaston koon pienentämiseksi ja edistystä on myös tapahtunut [Roy et al., 2009].

Käsinkirjoitettu teksti sisältää useimmiten valmiiksi kaltevuuksia ja vinoumia johtuen pääsääntöisesti kirjoittajan tyylistä. Nämä on hyvä korjata ennen kuin kirjaimia ja sanoja ryhdytään määrittämään tekstistä, jotta ne eivät vaikuta tunnistamiseen [Kim et al., 1999]. Lisäksi tunnistettavasta materiaalista voidaan poistaa ylimääräiset möykyt sekä laittomilta vaikuttavat kirjaimia yh- distävät viivat. Varsinainen tekstiksi muuntaminen voidaan tehdä pilkkomalla materiaali ensin sanakomponenteiksi ja siitä edelleen kirjaimiksi. Ennen kirjainten tunnistusta materiaalia on kuitenkin useimmiten tarpeen siivota, koska kir- joitettu teksti voi mennä osittain lomakkeen viivojen ja muun tekstin päälle [Ye et al., 2000]. Saatuja kirjainkomponentteja verrataan tämän jälkeen sanastossa oleviin kirjainkomponentteihin, joista poimitaan todennäköisimmät vaihtoeh- dot painoarvoineen. Saatujen vaihtoehtojen perusteella muodostetaan sanat. Tunnistuksen tarkkuutta voidaan parantaa käyttämällä rinnakkain useampia kirjainten luokittelumenetelmiä [Maruyama et al., 1999]. Tätä käsitystä vahvistavat useamman tutkimuksen samankaltaiset tulokset. Maruyaman [1999] kehittämässä menetelmässä käytetään kuvioiden vertailua ja HMM- menetelmiä (Hidden Markov Models). Kirjainten tunnistuksen jälkeen vuorossa on normaalisti sanojen tunnistaminen.

6.6. Rajapinnat Lomakkeen digitalisointijärjestelmän suunnittelijalle ja toteuttajalle on tarjolla useita vaihtoehtoisia ohjelmointirajapintoja OCRä varten. Rajapintoja on olemassa Javalle, C#:a sekä myös muille ohjelmointikielille. Seuraavaksi tarkastellaan eräitä saatavilla olevia rajapintoja.

6.6.1. ABBYY FineReader ABBYY Finereader ei ole pelkästään rajapinta ohjelmoijalle, vaan kokonaisratkaisu dokumenttien digitalisointiin [ABBYY]. Tässä alakohdassa ABBYYa tarkastellaan kuitenkin vasta ohjelmointikirjastona ja vasta luvussa 9 kokonaisrat- kaisuna. ABBYYn ohjelmointikirjasto on nimeltään ABBYY Finereader Engine, josta on saatavilla versio 9.0. Rajapinta on saatavilla useille eri alustoille: Windows, Mac, Linux, FreeBSD ja Embedded OS. Alustojen sisältämissä toiminnallisuuk- sissa on hieman eroja esim. OCR:n tunnistamien kielien osalta. Tekstintunnis- tuksen lisäksi ABBYY tukee myös viivakoodeja, mikä on lisäarvo kirjastolle. Windows-ympäristöon tarkoitettu kirjasto kykenee tunnistamaan 195 OCR- kieltä ja 113 ICR-kieltä, mukaan lukien suomen kielen. Tunnistusta varten on

31 käytettävissä kaikki tyypillisimmät kuvaformaatit ja konvertoitujen tiedostojen tallennus onnistuu useimmissa yleisissä formaateissa. ABBYY tukee myös useita kehitysympäristöjä:

 Microsoft Visual Studio .NET (VB.NET, C#)  Microsoft Visual Basic 5.0, 6.0  Microsoft Visual C++ 4.0 ja uudemmat  VB Script ja muut skriptikielet  Borland Delphi 2.0 ja uudemmat [ABBYY].

6.6.2. Asprise OCR Asprise OCR tukee useimpia yleisiä käyttöjärjestelmiä. SDK (Software Deve- lopment Kit) on saatavilla sekä Windows- että Unix-ympäristöönkin. Lisäksi SDK on saatavilla useille eri kehitysympäristöille mm.

 Borland C++ Builder  C# .Net  Delphi  Java  Visual Basic  Visual Basic .Net  Visual C++  Visual C++ .Net [Asprise]. Kirjastojen välillä on pieniä toiminnallisia eroavaisuuksia, etenkin tuettujen formaattien välillä. Asprisen OCR:n erikoisuus on tuki epätavallisille, mutta käytetyille kuvaformaateille kuten .wal (Quake2), .mdl (Half-life model) ja .lif (Homeworld file). Tämä antaa vaikkapa pelinkehittäjille hyvät mahdollisuudet kirjaston käyttämiseen. Asprisen kielivalikoimasta löytyy tällä hetkellä vain englanti. Myös Asprisen kirjasto on helppokäyttöinen ja tekstin saa kuvasta ulos vä- häisellä työmäärällä, kuten koodista 1 on nähtävissä. Esimerkki on toteutettu käyttäen C++-ohjelmointikieltä.

#include "AspriseOCR.h"

char* processMyBitmap() { char* text = OCR(“myImage”, IMAGE_TYPE_AUTO_DETECT); return text; }

Koodi 1. Esimerkki Asprise OCR:n käytöstä C++-ohjelmointikielellä.

6.6.3. GOCR GOCR (tai JOCR) on vapaan lähdekoodin OCR-kirjasto, joka on tarkoitettu lä- hinnä Unix-ympäristöön. Koska lähdekoodi on vapaasti saatavilla, kirjasto on siirrettävissä myös muihin ympäristöihin. Ohjeet, esimerkit yms. ovat kirjaston osalta hieman vajavaiset, mutta koodin päälle ymmärtäville henkilöille kirjasto on hyvä aloitus, jos avoin lähdekoodi ei haittaa ja on valmis näkemään hieman vaivaa kirjaston käyttämiseksi [GOCR].

6.6.4. OCR .Net OCR .Net tarjoaa Windows-ohjelmoijalle kirjastot tekstin ja viivakoodien tunnistamista varten. Kirjaston heikkous on tuettujen kielien vähyys. Vain englan- nin, espanjan, italian, saksan, ranskan ja ruotsin kielet ovat tuettuja, joten suo- menkielistä tunnistusta kaipaavalle kirjasto ei sovellu. Kuvien muuntaminen tekstiksi käy kätevästi parilla koodirivillä (ks. koodi 2) [File Innovations].

Public Sub processMyBitmap()

OCR1.BitmapImage = myBitmap OCR1.Process() TextBox1.Text = OCR1.Text

End Sub

Koodi 2. Esimerkki OCR .Netin käytöstä Visual Basicillä.

6.6.5. Tesseract OCR HP kehitti vuosien 1985 ja 1995 välillä ilmaisen C++-pohjaisen OCR-kirjaston Tessecrat OCR. Vuoden 1995 jälkeen kehitys oli seisahduksissa, kunnes Google otti kirjaston kehitettäväksi vuonna 2006. Kirjaston toimivuus on taattu Win- dows- ja Ubuntu-ympäristöissä. Näiden lisäksi kirjasto todennäköisesti toimii myös Mac- ja Linux-ympäristöissä, mutta niiden osalta testaus ei ole järjestel- mällistä [Google Code, 2010].

STRING* processMyImage() { ...

STRING* text_out = new STRING(); BLOCK_IT b_it = &blocks; for (b_it.mark_cycle_pt(); !b_it.cycled_list(); b_it.forward()) { BLOCK* block = b_it.data(); TBOX box = block->bounding_box(); char* text = TessBaseAPI::TesseractRectUNLV(image->get_buffer(), image->get_bpp()/8, bytes_per_line, box.left(), image->get_ysize() - box.top(), box.width(), box.height()); *text_out += text; delete [] text; if (tessedit_serial_unlv == 1) TessBaseAPI::ClearAdaptiveClassifier(); }

return text_out; }

Koodi 3. Esimerkki Tessecrat OCR:n käytöstä C++-ohjelmointikielellä. Tessecrat on ollut mukana OCR-kirjastoille tehdyssä testissä [Rice et al., 1995] ja pärjäsi vertailussa hyvin. Vertailussa oli mukana kahdeksan OCR-

34 kirjastoa ja yhdessä Caere OCR:n kanssa Tessecrat oli ainut, joka sisälsi tuen myös tunnistukseen 300 dpi:n tarkkuudella. Tuolloin suoritetut testit ovat edelleen valideja ja Tessecratin kotisivulta löytyy uudemmilla versioilla ajetut vastaavat testit. Testit antavat hyvän kuvan kirjaston kehittymisestä vuosien aikana. Pahin puute on tuen puuttuminen suomen kielelle. Kirjaston tukemat kielet ovat englanti, ranska, italia, saksa, espanja ja hollanti. Käyttäminen ei myös- kään ole yhtä yksinkertaista kuin aiemmin esillä olleiden kirjastojen, ja kehitys avoimen lähdekoodin ohjelmistona näkyy kirjastossa hieman hajanaisena ot- teena. Koodiesimerkkiä 3 on hieman karsittu ja vain tekstin tunnistuksen kannalta oleelliset seikat ovat mukana. Kuten esimerkistä voi havaita, vaatii Tes- secrat varsin paljon työtä tekstin saamiseksi ulos kuvasta. Toisaalta toiminnot voi piilottaa omaan uudelleen käytettävään alikirjastoon.

6.6.6. TOCR TOCR on niin ikään ohjelmointikirjasto Windows-ympäristöön ja on saatavilla aina Windows 95:sta Windows Vistaan. Windows 7 -tuesta ei ollut vielä tietoa. TOCR osaa mukautua huonolaatuiseen materiaaliin huomioiden liian vaaleat ja tummat taustat sekä korjaten vääristymiä ja tahroja. TOCRin kielivalikoima si- sältää kaikki yleisimmät kielet: englanti, ranska, italia, saksa, hollanti, ruotsi, norja, suomi, tanska, espanja ja portugali [Transym]. Kirjasto on saatavilla C-, C#-, Visual Basic, VB .Net ja Delphi- ohjelmointiympäristöille. C#-esimerkissä (ks. koodi 4) on TOCRia käyttävä funk- tio tekstin tunnistamiseen ennalta määritetystä kuvasta.

private string processMyBitmap() { int status; int jobNo = 0; string answer = ""; TOCRRESULTS results = new TOCRRESULTS(); TOCRJOBINFO jobInfo = new TOCRJOBINFO();

jobInfo.InputFile = “myFile”; jJobInfo.JobType = TOCRJOBTYPE_TIFFFILE;

status = TOCRInitialise(ref jobNo); if (status == TOCR_OK) { if (OCRWait(jobNo, jobInfo)) { if (GetResults(jobNo, ref results)) FormatResults(results, ref answer); } TOCRShutdown(TOCRSHUTDOWNALL); }

return answer; }

Koodi 4. Esimerkki TOCRin käytöstä C#-ohjelmointikielellä.

6.7. Verkkopalvelut Selaimella käytettävät verkkopalvelut ovat olleet jo pitkään arkipäivää ohjel- mistokehityksessä. Verkkopalvelun etuna ovat saavutettavuus sekä riippumat- tomuus. Varsinaisia asennustoimenpiteitä ei tarvita, koska palvelu on jatkuvasti toiminnassa palveluntarjoajan palvelimella. Ennen käytön aloittamista voi kuitenkin olla tarve asentaa selaimeen lisäosia, joita ohjelma tarvitsee toimiak- seen. Siksi ei siis voida puhua täydellisestä asennusriippumattomuudesta. Verkkopalvelua voidaan käyttää useilla eri selaimella ja yhteensopivuusongel- mat ovat arkipäivää. Se mikä toimii Firefoxilla, ei välttämättä toimikaan Inter- net Explorerilla. Jos palveluntarjoaja ei ole huomioinut muuttuvia ympäristöjä,

36 voi käyttäjälle tulla ongelmia tilanteessa, jossa hänellä ei olekaan käytössään sama selain, jolla hän palvelua tavallisesti käyttää. Verkkopalvelu ei myöskään vaadi käyttäjältä ylläpidollisia toimenpiteitä, koska palvelu päivittyy palveluntarjoajan suorittaessa päivityksen palvelimelle. Käyttäjällä on siis aina käytössään viimeinen versio, eikä versioristiriitoja tarvitse murehtia. Haittapuolena tästä on se, että käyttäjä ei voi vaikuttaa käyttä- määnsä versioon. Muuttuva käytettävyys voi aiheuttaa hetkellisiä ongelmia ohjelman käytössä, jos käyttäjä ei ole voinut tai osannut varautua niihin. Pullonkaulaksi käytön osalta voi muodostua kaistanleveys. Tunnistettavak- si kelpaavat tiedostot ovat tavallisesti kuvia ja siten voivat olla kooltaan suuria, jos niiden halutaan olevan hyvälaatuista. Tiedonsiirtotarve voi siksi olla hyvinkin suuri, jos materiaalia on paljon ja lataus voi kestää pitkän aikaa. Tähän vaikuttaa ratkaisevasti se, missä palvelu sijaitsee. Hajautettu palvelu on paremmin käyttäjän saatavilla paremmin kuin yhdessä paikassa sijaitseva palvelu. Lisäksi hajauttamalla voidaan turvata palvelun toimintaa. Käyttäjä on myös riippuvainen palvelun toimivuudesta. Palvelun ollessa alhaalla käyttäjän työt seisovat. Ilman varasuunnitelmaa välilliset kustannukset voivat nousta hyvinkin suuriksi katkoksen pituudesta riippuen. Katkoksiin on syytä varautua riskianalyysillä ja varasuunnitelmalla. Myös OCR on saanut omat verkkopalvelunsa. Näihin kuuluu esimerkiksi OCR Terminal, joka tarjoaa tekstintunnistuksen palveluun toimitetulle materiaalille [OCR Terminal]. Verkkopalvelua voi käyttää dokumentin digitalisointi- järjestelmän yhteydessä aivan yhtä hyvin kuin tavallista kirjastoa, jos palveluun on olemassa ohjelmallinen rajapinta. Verkkopalveluiden kustannukset vaihtelevat suuresti. Hinnoittelumalleja on tarjolla useita erilaisia [OCR Terminal]. Hinnoittelu on yleensä kuukausi- tai vuosipohjaista. Vaihtoehtoisesti maksu voi myös olla käyttöön perustuvaa, mi- kä on käytännöllistä etenkin, jos tarve on satunnaista. Kuukaudet, jolloin tarvetta ei ole, eivät myöskään aiheuta kustannuksia. Vuosi- tai kuukausimaksupohjaisten palveluiden kustannus voi pitkällä ai- kavälillä tarkasteltuna vaikuttaa suurelta verrattuna perinteisiin kertamaksulli- siin ohjelmalisensseihin. Tässä yhteydessä on kuitenkin hyvä huomioida myös välilliset kustannukset liittyen ylläpidollisiin tehtäviin ja päivitystarpeisiin.

6.7.1. OCR Terminal OCR Terminal [OCR Terminal] toimii siten, että käyttäjä lataa materiaalin palveluun, jossa se tunnistetaan ja tunnistamisen jälkeen konvertoidaan tekstifor-

37 maattiin. Ladattava materiaali voi olla kuva- tai pdf-tiedosto. Tuetut formaatit ovat .jpeg, .gif, .bmp, .tiff ja .pdf. Konvertoidun ja käyttäjälle palautettavan tiedoston formaatit ovat puolestaan .doc, .txt, .rtf ja .pdf. Käyttäjä maksaa palvelun käytöstä vain käytön mukaan, joten tarpeettomia kustannuksia ei synny. Huhtikuussa 2010 palvelu oli hinnoiteltu seuraavasti:

 Ensimmäiset 20 sivua ovat ilmaisia  Seuraavat 50 sivua 9 senttiä / sivu  Seuraavat 150 sivua 7 senttiä / sivu  Seuraavat 300 sivua 6 senttiä / sivu  Seuraavat 500 sivua 5 senttiä / sivu  Seuraavat 1000 sivua 4 senttiä / sivu. (Huom! Hinnat ovat dollareissa, koska palveluntarjoaja on amerikkalainen.)

6.7.2. Online OCR Online OCR on krediittipohjainen verkkopalvelu. Käyttäjä saa liittymisen yh- teydessä 5 aloituskrediittiä tiedostojen konvertoitiin. Lisäkrediittejä voi ansaita suorittamalla erilaisia toimenpiteitä tai rahalla ostamalla. Palvelu tukee esim. .pdf-, .doc-, .xls-, .rtf-, .html- ja .txt-formaatteja, mukaan lukien myös tavalli- simmat kuvaformaatit. Konvertoidut tiedostot ovat saatavilla .pdf-, .doc-, .xls-, .html-, .rtf- tai .txt-formaatissa. Kielivalintoja palvelussa on käytettävissä 28 erilaista [OnlineOCR.net 1]. Palvelun rinnalla toimii myös OCR Web Service, joka on pelkästään maksullinen palvelu. Hinnoittelu voi perustua kuukausittaiseen tai päivittäiseen käyttöön. Kuukausittainen hinnoittelu on seuraavanlainen

 Max. 1000 sivua / kuukausi 9,95$ = 1 senttiä / sivu  Max. 2000 sivua / kuukausi 19,95$ = 1 senttiä / sivu  Max. 3000 sivua / kuukausi 24,95$ = 0,8 senttiä / sivu  Max. 5000 sivua / kuukausi 34,95$ = 0,7 senttiä / sivu  Max. 7000 sivua / kuukausi 41,95$ = 0,6 senttiä / sivu  Max. 10000 sivua / kuukausi 49,95$ = 0,5 senttiä / sivu [OnlineOCR.net 2]. OCR Web Service tarjoaa myös ohjelmointirajapinnat C#- ja PHP-kielille, sekä käytön SOAP-protokollan kautta. Palvelu on siis suoraan integroitavissa lomakkeentunnistusjärjestelmään.

6.7.3. Muut verkkopalvelut WebOCR:ä käytetään erillisen pääteohjelman kautta. Ohjelman käyttämä pal- velin on käyttäjän päätettävissä, joten eri vaihtoehtoja voidaan käyttää. Palvelu on toistaiseksi beta-asteella, joten tarkempia tietoja ei vielä ole [ExperVision]. Toisin kuin Online OCR niin Free Online OCR on oikeasti ilmainen palvelu. Palvelun käyttöliittymä on yksi ainoa verkkosivu, jonka kautta tiedostot lähe- tään ja jossa konvertoitu teksti näytetään. Käyttäjän ei edes tarvitse rekisteröi- tyä palveluun. Tuettuja konvertoitavien tiedostojen formaatteja ovat .jpeg, .png, .gif, .bmp, .tiff sekä .pdf. Tuettuja kieliä on kaikkiaan 29 mukaan lukien suomi [t-reinhard.ch].

6.7.4. Integraatio tiedostonhallintaan Verkkopalvelua käytettäessä käyttäjä on riippuvainen selaimesta. Tavallisesti käyttäjän on ladattava tiedostonsa palveluun latausdialogien avulla. Tunnista- misen valmistuttua käyttäjän on ladattava tunnistettu materiaali itselleen joko suoraan palvelusta tai vaihtoehtoisesti sähköpostista. Palvelu siis vaatii käyttä- jältä erillisiä toimenpiteitä, jotta prosessi etenee. Käyttöä voisi helpottaa hyö- dyntämällä Dropboxin innovaatiota yhdistää verkkopalvelu ja tietokoneen tie- dostonhallinta yhdeksi toiminnalliseksi kokonaisuudeksi [Dropbox]. Dropbox on tiedostojen jakamiseen tarkoitettu palvelu, jossa käyttäjällä on käytössään tietty määrä tilaa omille tiedostoilleen. Palvelua voi käyttää kolmel- la eri tavalla:

 pelkästään selaimella  esiasennuksen jälkeen pelkästään tiedostonhallinnalla  selaimella ja tiedostonhallinnalla. Erilaisia tiedostojen jakamispalveluja on ollut käytössä jo pitkään, mutta aiemmin integraatio tiedostojärjestelmän kanssa on ollut hyvin löyhä. Dropboxin innovaatio on tiedostonhallinnan kytkeminen tiukasti mukaan palvelun käyt- töön. Verkkopalvelun lisäksi käyttäjä voi asentaa koneelleen tarjolla olevan eril- lissovelluksen, joka integroi palvelun tietokoneen tiedostonhallintaan. Ohjel- maan asennettaessa käyttäjä valitsee hakemiston, jota Dropbox käyttää tiedostojen synkronointiin. Palvelu lataa hakemistoon tallennetut tiedostot automaattisesti verkkopalveluun ja sinne lisätyt tiedostot puolestaan määritettyyn hakemistoon. Käyttäjän ei siis tarvitse ladata tiedostoja palveluun erikseen, vaan kopiointi hakemistoon riittää. Asentamalla ohjelman toiselle koneelle saa käyt-

39 täjä tiedostot synkronoitumaan myös sinne. Kun tähän vielä lisätään yhteisölli- syys jaettujen hakemistojen muodossa, on paketti kunnossa. Tiedostonhallintaintegraatiota voisi hyödyntää myös OCR-palvelun yhtey- dessä siten, että käyttäjä voisi pudottaa tunnistettavan materiaalin suoraan esimääriteltyyn hakemistoon, josta se siirrettäisiin automaattisesti tunnistus- palveluun. Tunnistuksen tuottama materiaali synkronoitaisiin toiseen esimääri- teltyyn hakemistoon käyttäjän koneella.

6.8. Tiedostoformaateista Edellisten rajapintojen ja palveluiden esittelyn yhteydessä tulivat esille erilaiset tunnistettavaksi ja tallennettavaksi sopivat tiedostoformaatit. Tarkasteltaessa tuettujen formaattien listaa (Liite 1 ja Liite 2) voidaan nähdä, että osa palveluista tukee todella laajaa skaalaa erilaisia formaatteja, kun taas toiset ovat rajoittu- neet vain muutamaan formaattiin. Ensi näkemältä tämä voi vaikuttaa ongel- malta ja olla myös peruste olla ottamatta tuotetta käyttöön, vaikka kyseessä on vain puute. Tiedostoformaatti on lopulta kuitenkin vain malli tiedoston sisältämälle materiaalille, joka kertoo, mitä tiedosto sisältää ja missä järjestyksessä tiedot ovat. Formaattia voidaan vaihtaa lukemalla tiedoston sisältö ja tallentamalla saatu tieto uuteen toivottuun formaattiin Yksinkertaisimmillaan toimenpide vaatii vain ohjelmointiympäristön peruskirjastojen käyttämistä, mutta toisinaan voi olla tarve manuaaliselle käsittelylle. Manuaalinen muunnos voi tulla eteen harvinaisempien tai omien tiedosto- formaattien kohdalla. Oman tiedostoformaatin ollessa kyseessä, ei sitä varten ole olemassa valmista muunnoskirjastoa, joten implementointi jää kehittäjän vastuulle. Joskus formaatti voi myös olla niin uusi tai vähän käytetty, että sitä varten ei ole tehty muunnoskirjastoja. Asia erikseen ovat suljetut formaatit, joiden mallia ei ole yleisesti tiedossa. Näissä tapauksissa kehittäjän on ensin selvi- tettävä tiedoston malli, jotta sisältö saadaan muunnettaviksi. Tiedostoformaatit voivat olla rakenteeltaan hyvinkin monimutkaisia, mikä hankaloittaa muunnoskirjaston luomista. Huomioon otettavia seikkoja voi olla paljon ja tekemiseen kuluu paljon aikaa ja vaivaa. Myöhemmin voidaan havaita, että käytetty aika on mennyt hukkaan, kun formaattia ei enää tarvitakaan tai se poistuu muuten käytöstä. Yleisillä formaateilla on myös tapana elää ja malli voi ajan saatossa muuttua. Kehittäjän on siis oltava jatkuvasti ajan hermolla, jotta formaatti vastaa todellisuutta. Joskus voikin olla järkevää ottaa käyttöön ulkoinen kolmannen osapuolen maksullinen kirjasto, joka sisältää tarvittavat

40 tiedostoformaatit. Tiedostoformaatin päivittyessä ei tarvitse tehdä muuta kuin vaihtaa käytetty kirjasto, kunhan kehittäjät ovat huomioineet tiedostoformaat- tiin tulleet muutokset. Kirjastoihin sisältyy yleensä myös tuotetuki, joten on- gelmien edessä kehittäjä ei ole yksin.

7. Tiedot tietomalliin Tässä luvussa selvitetään miten paperilomakkeesta kerättyjen ja tunnistettujen tietojen tallentaminen käytettävään tietomalliin tapahtuu. Tarkasteluun otetaan sekä tuntemattoman että tunnetun tietomallin käsitteet. Tekstintunnistuksen jälkeen paperinen lomake on saatu täysin digitalisoitua ja lomakkeen sisältö on odottamassa tallennusta tietomalliin [Sojka, 2005]. Teks- tin lisäksi myös lomakkeen sisältämät kuvat voidaan siirtää erikseen tietomalliin. Tiedon siirtäminen voi tapahtua

 tunnettuun tietomalliin  tuntemattomaan tietomalliin. Vaihtoehdoista jälkimmäinen on toimivuuden kannalta parempi, koska täl- löin järjestelmää ei sidota kehitysvaiheessa tiettyyn teknologiaan ja toimintata- paan. Tarvittaessa erityyppisen tai tehokkaamman tietomallin käyttöön ottami- nen onnistuu helposti. Kummassakin tapauksessa tietomalli voi sijaita fyysisesti eri paikassa kuin muu järjestelmä ja tietojen päivittäminen voi tapahtua verkkoyhteyden kautta [Gibson and Rodney, 2000]. Jos yhteys on nurin ei tietojen päivityskään onnistu. Tähän ongelmaan on syytä varautua, koska järjestelmä toimii kuin liuku- hihna, joka tukkeutuu pahemman kerran, jos hihnalle syntyy jossain kohtaa tu- kos. Kuvanlukijan ja OCR:n jatkaessa toimintaa, vaikka data ei enää siirry eteenpäin tietomalliin, on vaara, että syntyy muistiongelmia, jotka voivat johtaa järjestelmän hidastumiseen ja lopulta jopa kaatumiseen. Tietomallin sijaitessa fyysisesti samassa paikassa muun järjestelmän kanssa vastaavan ongelman vaara on vähäisempi, mutta ei poissuljettu. Tietomalli voi olla kuitenkin palvelun tai prosessin takana, jonka jumittuminen voi joka tapauksessa estää tietojen päivittämisen. Tietojen tallennuksen jälkeen prosessi on digitalisoinnin osalta valmis. Tä- män jälkeen loppukäyttäjä voi aloittaa todellisen työn eli tiedon analysoinnin ja louhinnan, jotta kerätystä tiedosta saadaan kiteytettyä oleellinen informaatio ulos [Sojka, 2005].

7.1. Tunnettu tietomalli Tunnettu tietomalli on kuin kauppa, johon data sijoitetaan omille hyllyilleen tunnistuksen jälkeen käyttöä varten tai odottamaan mahdollista siirtoa eteen- päin. Tietomallin tyyppi on määritelty jo järjestelmän kehitysvaiheessa, eikä si-

42 tä voi enää käytön aikana muuttaa. Yksinkertaisimmillaan tietomalli voi olla pelkkä tekstitiedosto tai binääritiedosto, mutta myös tehokkaampi tietokanta [Sojka, 2005]. Etuna tunnetussa tietomallissa on vahva integraatio järjestelmään. Yhtä tietomallia testaamalla voidaan varmistua siitä, että järjestelmä toimii kokonai- suutena. Lisäksi ylläpidolliset tehtävät helpottuvat, koska ylläpito voi keskittyä käytettyyn tekniikkaan. Tietomalliin tallennettujen tietojen siirtäminen toiseen tietomalliin automaattisesti on mahdollista, mutta tällöin on aina tapauskohtaisesti kehittävä tarvittavat muunnostyökalut. Muunnostyökalut mahdollistavat datan konver- toimisen toisen tietomallin mukaiseksi. Jos tarve on jatkuvaa, aiheuttaa se jär- jestelmän kehittäjälle tarpeetonta työtä. Loppukäyttäjälle muunnostyökalun kehittäminen voi taas olla liian työlästä. Tunnettua tietomallia on hyvä käyttää, jos järjestelmä on kehitetty tiettyä tarkoitusta varten, eikä tietomallia ole tarvetta tai syytä vaihtaa lennossa.

7.2. Tuntematon tietomalli Käytettäessä tuntematonta tietomallia ei sen todellinen rakenne ole tiedossa, eikä sillä myöskään ole merkitystä järjestelmän kannalta. Järjestelmän ja tietomallin väliin rakennetaan avoin rajapinta, jonka kautta tiedonsiirto tapahtuu. Käytettävä tietomalli kytketään järjestelmän tarjoamaan rajapintaan löyhästi kiinni joko asennusvaiheessa tai ajon aikana. Tietomallia voidaan myös vaihtaa ajon aikana ja mahdolliset käytettävissä olevat tietomallit voidaan listata järjes- telmän toimesta. Tuntematon tietomallia käyttävä järjestelmä mukautuu loppukäyttäjän tarpeisiin paremmin kuin tunnettua tietomallia käyttävä. Digitalisoitu tieto on lopulta se, mikä käyttäjää kiinnostaa, ja käytön kannalta on oleellista saada tieto kerrasta oikeaan paikkaan ja oikeassa formaatissa. Rajapinta tietomalliin voi olla hyvinkin yksinkertainen. Rajapinnan tarjo- amien väylien parametreiksi riittävät useimmiten viite luodun tai tunnistetun lomakemallin kenttään sekä varsinainen tietoalkio. Tietoalkio on tavallisesti joko merkkijono tai kuva.

8. Diagnostiikka ja etähallinta prosessissa Tässä luvussa perehdytään lyhyesti prosessin kannalta riittävään järjestelmästä saatavaan diagnostiikkaan sekä soveltuvaan etähallintaan. Järjestelmän vakaan ja tehokkaan toiminnan kannalta riittävä diagnostiikka on oleellista [Bechtold, 1998]. Tämä pitää sisällään fyysisten laitteiden, kuten kuvanlukijoiden, toiminnan sekä itse järjestelmän suorituskyvyn ja toimivuuden tarkkailun. Lisäksi jär- jestelmän ylläpidon helpottamiseksi ja virhetilanteiden korjaamiseksi järjestel- mään voidaan upottaa mukaan etähallintaan liittyvää toiminnallisuutta. Diagnostiikka voidaan toteuttaa järjestelmään kiinteästi sisältyvänä moduu- lina tai ulkoisena palveluna. Käytettäessä ulkoista palvelua tulee järjestelmän sisältää diagnostiikkarajapinta, johon diagnostiikkapalvelu kytketään kiinni. Ulkoisen palvelun etuna on diagnostiikkainformaation suodattaminen vastaa- maan käyttäjän tarpeita [Linxia and Lee, 2010]. Eri käyttäjäryhmille voidaan helposti luoda erilliset, tarkoin rajatut ja toisistaan riippumattomat näkymät. Passiivinen järjestelmästatus, aktiiviset viestit ja varoitukset mahdollistuvat myös diagnostiikan lisäämisen myötä. Järjestelmän ollessa keskeinen osa organisaation toimintaa on toimivuus hyvä konkretisoida esimerkiksi diagnostiikkanäytön avulla. Paras sijainti näy- tölle on keskeisellä paikalla toimipaikassa, josta se on helposti useamman hen- kilön nähtävissä. Näkyvyys auttaa huomaamaan ongelmat järjestelmän toiminnassa. Näytöltä voidaan seurata esimerkiksi käsiteltyjen lomakkeiden mää- rää, tunnistuksen oikeellisuutta yms. raportointia. Käytössä voi olla myös laite, joka osaa määrittää kuvanlukijan jonossa olevien lomakkeiden määrän esim. lomakekasan korkeuden tai painon perusteella. Jos jonkun kuvanlukijan luokse alkaa muodostua jonoa, tilanteeseen voidaan reagoida välittömästi. Järjestelmän toimivuuden ollessa kriittistä voidaan toimivuudesta lähettää aktiivisesti viestejä ja informaatiota ylläpidolle sekä muille ennalta määritetyille tahoille. Lähetettävät viestit voivat olla toimivuusraportteja tai ilmoituksia mahdollisesti havaituista vioista [May et al., 2004]. Viestin aktivoitumista varten voidaan määritellä laukaiseva ehto tai useita ehtoja. Näin esimerkiksi skannattavien lomakkeiden alkaessa loppua voidaan kohdehenkilöille lähettää ensin huomautus tilanteesta ja lopulta varoitus, jos lomakkeet pääsevät kokonaan loppumaan. Järjestelmän sisäisistä virheistä puolestaan voidaan lähettää kii- reellinen virheilmoitus, jotta vika saadaan mahdollisimman nopeasti ylläpidon tietoon ja edelleen korjaukseen.

Diagnostiikka voi sisältää myös etähallintasovelluksen, jolla järjestelmän tilaa voidaan testata ja tarvittaessa myös muuttaa [Wang et al., 2004]. Tästä on apua, jos ylläpito ei ole fyysisesti samassa paikassa järjestelmän kanssa. Jokai- sen pienen ongelman takia paikan päälle lähteminen ei ole kannattavaa ja etä- hallinnan avulla tätä tarvetta voidaan vähentää. Etähallinnan puuttuessa voidaan turvautua puhelintukeen, mutta tällöin ollaan sen varassa, että käyttäjä kykenee ja uskaltaa tehdä tarvittavat toimenpiteet. Lisäksi käyttäjä voi ymmär- tää asiat eri tavalla kuin neuvoja antava henkilö, mikä voi lopulta johtaa isom- piin ongelmiin.

9. Markkinakatsaus valmisratkaisuihin Silmäys ohjelmistomarkkinoille on käsillä ennen viimeistä lukua. Tässä luvussa tutkitaan, mitä valmisratkaisuja paperilomakkeiden digitalisointiin on saatavilla markkinoilta. Tarkasteltavana ovat kirjastot, jotka sisältävät kaiken toiminnallisuuden käyttöliittymää lukuun ottamatta, sekä paketista suoraan käyttöön otettavat valmisohjelmistot. Markkinoilta löytyy nykyään useita valmisratkaisuja paperilomakkeiden digitalisointiin. Ratkaisut sisältävät lähes kaiken prosessissa tarvittavan toiminnallisuuden ja hoitavat työn skannauksen aloittamisesta tunnistetun digitaalisen lomakkeen tallennukseen. Vain kuvanlukijan hankinta jää käyttäjälle erilliseksi huolenaiheeksi. Digitalisoinnin lopputulos on yleensä tiedosto käyttäjän valitsemassa formaatissa. Saadakseen tiedoston sisältämät tiedot varsinaiseen tietomalliin, tulee käyttäjän itse luoda järjestelmä, joka kykenee käsittelemään tallennetun tyyppi- siä tiedostoja, jotta sisältö saadaan luettua ja edelleen siirrettyä varsinaiseen tietomalliin. Ohjelmien tukemat tallennusformaatit ovat kuitenkin yleisiä ja vaihtoehtoja on yleensä useampia kuin yksi, joten yleiskäyttöisen työkalun kehittä- minen on mahdollista. Otettaessa käyttöön kokonaisratkaisu säästytään järjestelmän suunnittelun ja kehittämiseen kuluvilta kustannuksilta. Lisäksi samalla saadaan valmistajan tarjoama käyttötuki sekä mahdolliset päivityspalvelut. Menetyksiin kuuluvat omien lisäyksien ja tarpeiden huomioiminen ohjelmassa. Vaihtoehtona on teh- dä tilaus omasta ohjelmasta jollekin ohjelmistovalmistajalle. Räätälöitävän sovelluksen hinta on kuitenkin yleensä moninkertainen verrattuna valmiiseen sovellukseen, joten se ei siksi ole aina mahdollista.

9.1. ABBYY Finereader ABBYY oli esillä jo aiemmin käsiteltäessä OCR-rajapintoja. Pelkän OCR- kirjaston lisäksi ABBYYstä on tarjolla myös kaikki palvelut sisältävä sovellus. Kuten aiemmin on kerrottu, on ABBYYn kielivarasto yksi laajimmista. Kielten tunnistus on automaattinen ja sen lisäksi ohjelma tunnistaa dokumentin sisäl- tämät eri kielet. ABBYY on saatavilla sekä Windows- että Mac- käyttöjärjestelmille [ABBYY]. Kuvassa 6 on nähtävissä ABBYYllä tunnistettu dokumentti. Ohjelman sisältämä ADRT-ominaisuus (Adaptive Document Recognition Technology) kykenee monipuolisiin dokumentin rakenteeseen liittyviin tunnis-

46 tustehtäviin. Tunnistus ymmärtää ylä- ja alatunnisteiden sekä sivunumeroiden käytön ja olemassaolon. Ohjelma tukee myös yleisten viivakoodien tunnistamista. Käyttäjä voi tarvittaessa muokata tunnistettua dokumentin rakennetta. Esimerkiksi jos skannattava materiaali on aikakausilehdestä peräisin, ohjelma osaa muodostaa sitä vastaavan virtuaalisen näkymän. Aikakausilehti sisältää kuitenkin usein tekstin alla olevan taustakuvan, mikä voi aiheuttaa ongelmia automatiikalle. Automaattisen tunnistuksen jälkeen käyttäjä voi korjata virheitä ja lisätä tunnistamattomia alueita. Vastaavasti voidaan toimia muidenkin materiaalien kanssa, joissa on taustakuva.

Kuva 6. ABBYY Finereader.

Ohjelmasta löytyy myös tuki isommille organisaatioille jaetun lisenssikäy- tön myötä. Ominaisuus on hyvä, koska jos käyttäjät vaihtelevat, ei turhia li- senssejä kuitenkaan tarvitse ostaa seisomaan. Hienompi ominaisuus on kuitenkin hajautettu dokumenttien käsittely. Työtaakka voidaan jakaa kaikkien tai osan organisaation verkossa olevien käyttäjien kesken, vaikka siten että jokainen suorittaa vain yhden toimenpiteen prosessista. Ohjelma voidaan myös määrittää tarkkailemaan tiettyä kansiota tai sähköpostia saapuvan materiaalin osalta. Uusi materiaali otetaan heti vastaanottamisen jälkeen automaattisesti prosessoitavaksi.

9.2. FormSuite FormSuite ei ole sovellus vaan 32-bittisille .NET- ja ActiveX-ympäristöille tarkoitettu ohjelmointiympäristö, joka sisältää kaiken oleellisen digitalisoinnissa tarvittavan toiminnallisuuden. Kaikki oleelliset tunnistusmenetelmät löytyvät kirjastosta: ICR, OCR ja OMR. Tuetut kielet ovat englanti, tanska, hollanti, suomi, ranska, saksa, italia, norja, portugali, espanja ja ruotsi [Accusoft]. Kirjastossa on omat etunsa ja haittansa verrattuna valmiiseen sovellukseen. Suurin hyöty on avoimuus ja muokattavuus, koska käyttäjä ei ole sidoksissa sovelluksen suunnittelijan näkemykseen käyttöliittymästä ja sovelluksen sisäi- sistä tarpeista. Käyttäjä voi kehittää tarvitsemansa sovelluksen perustuen omiin tarpeisiin ja käyttää kirjastoa vain tarvitsemiltaan osin. Tämä samainen seikka on samalla myös haitta, koska sovelluksen kehittäminen vie aikaa ja resursseja. Kuvassa 7 on nähtävissä esimerkki ForumSuitesta toiminnassa Accusoftin omassa demo-ohjelmassa FormAssistissa.

Kuva 7. FormAssist.

Ominaisuuslista on kattava ja pitää sisällään kaiken perustoiminnallisuu- den sekä vähän lisää. Kuvien käsittelyä varten kirjastosta löytyy monia kuvan laatua parantavia menetelmiä kuten suoristus, viivojen poisto, kirjainten täy- dennys ja tasoitus. Lomaketietämys on myös viety pitkälle ja lomakkeiden tunnistaminen sekä erottaminen toisistaan on mahdollista. Lisäksi lomakkeista voidaan poimia vain sisällön kannalta tärkeiden alueiden sisältämä informaatio. Kuvien käsittelyä varten kirjastossa on 80 erilaista toimintoa.

Kirjastosta on saatavilla myös kevyt versio FormFix, joka sisältää pelkästään lomakkeen tunnistamiseen tarkoitetun toiminnallisuuden.

9.3. OCRopus Kuten FormSuiten tapaan myös OCRopus on ohjelmointikirjasto, joka on kuitenkin tarkoitettu C++-kehitysympäristölle. Kirjasto on Googlen sponsoroima ja pohjautuu kahteen tutkimusprojektiin: 1990-luvun puolivälissä kehitettyyn ICR-järjestelmään ja useisiin dokumentin rakenteen analysointimenetelmiin. Järjestelmä sisältää rakenteen tunnistamisen, kirjainten tunnistuksen, OCR:n ja monikielituen. Kuvien esikäsittelyä varten kirjasto sisältää suoristuksen sekä muut tavalliset korjausmenetelmät. OCRopusta hyödyntäviä projekteja ovat esimerkiksi  DECAPOD, joka on tarkoitettu kirjojen digitalisointiin suuressa mitta- kaavassa  OCRosearch, joka tarjoaa automatisoidun digitaalisen kirjaston ylläpi- don [Google Code, 2010]. Järjestelmä on suunniteltu laajennettavuutta silmällä pitäen, eivätkä sen si- sältämät osat ole tiukasti kiinni toisissaan. Kehittäjä voi tarvittaessa vaihtaa rakenteen analysointiin ja OCR:n liittyvät oletuksena käytetyt alijärjestelmät. Li- säksi järjestelmään voidaan kytkeytyä kiinni myös skriptikielillä kuten Lua ja Python.

9.4. SimpleIndex Helppokäyttöisyyttä hakevalle SimpleIndex on tarkastelemisen arvoinen vaih- toehto [Simple Software]. Ohjelma sisältää kaiken skannauksen ja tietokantatal- lennuksen välillä. Lomakerakenteen tunnistaminen on myös automatisoitu ja lisäksi ohjelma osaa tunnistaa samankaltaiset kentät ja niihin liittyvän sisällön. Kerätyn tiedon tallennus onnistuu mihin tahansa tietokantaan. Kuvassa 8 on SimpleIndexin käyttöliittymä, johon on manuaalisesti lisätty tunnistettavat alueet. Ohjelma ymmärtää myös useammalle kuin yhdelle lomakkeelle jaettuja lo- makekokonaisuuksia (esimerkiksi hakemus ja siihen liittyvät pakolliset liitteet). Skannauksen yhteydessä ohjelma voi tarkistaa, että kaikki vaadittavat lomakkeet on skannattu ja varoittaa, jos jotain puuttuu. Lomakekokonaisuudet saadaan näin tallennettua kokonaisuuksina. Ohjelmaan ei voi kytkeytyä suoraan ohjelmallisesti kiinni, mutta komento- rivin kautta tämäkin onnistuu epäsuorasti. Tämä mahdollistaa oman käyttöliit-

49 tymän tekemisen, jos ohjelman sisältämä oletuskäyttöliittymä ei ole ominai- suuksiltaan tai toiminnoiltaan riittävä.

Kuva 8. SimpleIndex.

9.5. WindFORM GDI (Graphics Development International, Inc.) on kehittänyt useita työkaluja dokumenttien hallintaan ja digitalisointiin liittyen. Valikoimasta löytyy sovel- lukset sekä OCR- että ICR-tunnistusta varten (WindFORM OCR ja WindFORM for ICR). Lisäksi valikoimassa on myös DataGold-ohjelma, joka on näistä lähin- nä haetun kokonaisratkaisun kaltaista järjestelmää. Eri ohjelmat integroituvat toistensa kanssa ainakin jossakin määrin, joten toimintoja voi poimia eri ohjel- mista [GDI]. DataGold osaa skannata ja tunnistaa lomakkeita. Sisällön osalta tekstintunnistukseen on käytettävissä sekä OCR- että ICR-menetelmät. Järjestelmä tallentaa kerätyn informaation käyttäjän määrittämään tietokantaan, joka voi olla jo- kin seuraavista:  ODBC  DDE  OLE 2.0 [GDI].

WindFORM OCR ei sisällä oletuksena tukea monikielisyydelle. Järjestel- mässä on valmis 90000 sanan sanavarasto ja ilmeisesti siis englanniksi, mihin ei kuitenkaan löytynyt suoraa varmistusta. Käyttäjä voi tuoda järjestelmään omia sanastojaan, mikä mahdollistaa esimerkiksi Suomen kielen lisäämisen. Kuvassa 9 on nähtävissä WindFORM OCR:n generoima lomakerakenne kuvan perusteella.

Kuva 9. WindFORM OCR.

10. Yhteenveto Paperilomakkeiden digitalisoiminen kuulostaa nopeasti ajatellen helpolta ja yk- sinkertaiselta toimenpiteeltä. Kuten on kuitenkin havaittu, on prosessi varsin monimutkainen ja koostuu useista eri menetelmistä. Tekstin saaminen paperilomakkeesta aina prosessoitavaksi merkkijonoksi asti vaatii useita työvaiheita alkaen käyttäjän fyysisestä suorituksesta skannauksen aikana tekstintunnistuksen vaatimaan raskaaseen tietokoneella suoritettavaan matemaattiseen lasken- taan. Tekstintunnistusta on tutkittu paljon ja useita erilaisia menetelmiä ongelman ratkaisemiseksi on ehdotettu. Tarkkuus ei kuitenkaan ole täydellinen, joten kehittämisen varaa on edelleen. Nopeus on toinen tekstintunnistuksen kannalta oleellinen tekijä. Hidas, mutta tarkka, tekstintunnistus saa muun prosessin ja työt seisomaan. Prosessi on ositettavissa selkeisiin kokonaisuuksiin, mikä helpottaa ymmär- tämistä. Tästä on etua myös järjestelmää suunniteltaessa, koska tarvittaessa on mahdollista keskittyä vain yhden vaiheen vaatimiin spesifeihin tarpeisiin ja vaatimuksiin. Vaiheiden kesken erot toiminnallisuuden osalta ovat hyvinkin isoja. Paperilomakkeiden saaminen digitaalisiksi kuviksi ei vaadi suuria pon- nisteluja, mutta sen sijaan tekstintunnistus on tekstissä esiintyvien eroavai- suuksien, etenkin käsinkirjoitetun tekstin kohdalla, hyvin vaativaa. Prosessin selkeästä osittamisesta ymmärryksen helpottamiseksi on hyötyä myös hajauttamisen kannalta. Toiminnallisuuden ollessa omissa paketeissaan voidaan järjestelmä hajauttaa useammalle palvelimelle. Lisäksi samaa toimintoa voidaan suorittaa useammalla kuin yhdellä palvelimella jakamalla materiaali palvelinten kesken. Kuorman jakaminen nopeuttaa prosessin suoritusta. Useammalla palvelimella suoritettavat samat vaiheet paitsi nopeuttavat niin samalla myös turvaavat järjestelmän toimintaa, koska yhden palvelimen pu- toaminen pois toiminnasta ei vielä tarkoita koko prosessin pysähtymistä. Ha- jauttamista on sovellettu jo käytäntöön markkinoilta saatavassa ABBYY Fine- reader -ohjelmassa [ABBYY]. Automatisointi on prosessin kannalta avainasemassa. Käsiteltävien lomakkeiden määrä voi olla hyvinkin suuri, ja jos käyttäjän on oltava koko ajan läsnä, sidotaan arvokkaita henkilöstöresursseja. Kuten on havaittu, prosessin vaiheet skannausta lukuun ottamatta ovat hyvin pitkälti täysin automatisoitavissa. Parhaimmillaan käyttäjää tarvitaan vain passiiviseen valvontaan sekä virheiden korjaamiseen. Automatiikka ei kuitenkaan ole pelkästään onni ja autuus. Au-

52 tomatiikan olleessa käytössä rinnalle on syytä tuoda mukaan riittävä diagnostiikka sekä etähallintamahdollisuuskin tietyissä rajoissa. Järjestelmän omaval- vonta ja tilanneraportit virheilmoituksineen estävät prosessin täydellisen py- sähtymisen, jos käyttäjä ei ole aktiivisesti valvomassa toimintaa. Paperilomakkeiden digitalisoimista suunniteltaessa ei tarvitse lähteä liikkeelle aivan tyhjältä pöydältä. Nopeinta on ottaa käyttöön valmisratkaisu, mutta tällöin joudutaan useimmiten tinkimään tarpeista, koska ohjelman tarjoamat ominaisuudet eivät välttämättä ole täysin se mitä haetaan. Vaihtoehtona on oman järjestelmän suunnittelu, jossa voidaan hyödyntää olemassa olevaa materiaalia tutkimusten ja valmiiden kirjastojen osalta. Kehittäjälle jää näin suunni- teltavaksi teknologiaa ja tekniikkaa käyttävän rungon kehittäminen. Aikaa vie- vintä on tehdä kaikki alusta asti itse. Tämä tutkimus on ollut katsaus paperilomakkeiden digitalisointiprosessiin yleisellä tasolla. Tutkittavaa prosessin eri vaiheiden sisältämien tekniikoiden ja menetelmien osalta riittää edelleen.

Viiteluettelo [Abad et al., 2006] Jose L. Abad, Sherif Yacoub, Daniel Ortega, Paolo Faraboschi and John Burns, Semantic-Based Noise Reduction for Digital Documents, ICGST International Journal on Graphics, Vision and Image Processing (GVIP) 6, Special Issue on Applicable Image Processing (2006), 57-61.

[ABBYY] ABBYY, ABBYY FineReader Homepage, http://finereader.abbyy- .com/. Checked 19.4.2010.

[Accusoft] Accusoft Pegasus, Formsuite Homepage, http://www.accusoft.com/- formsuite.htm. Checked 20.4.2010.

[AIM, 2000], AIM, Inc, OPTICAL CHARACTER RECOGNITION (OCR), http://www.aimglobal.org/technologies/othertechnologies/ocr.pdf. Checked 9.4.2010.

[Amin and Fischer, 2000] A. Amin and S. Fischer, A Document Skew Detection Method Using the Hough Transform, Pattern Analysis & Applications 3, 3 (2000), 243-253.

[Antonacopoulos and Karatzas, 2004] Apostolos Antonacopoulos and Dimos- thenis Karatzas, A Complete Approach to the Conversion of Typewritten Historical Documents for Digital Archives, In: Document Analysis Systems VI, Lecture Notes in Computer Science 3163 (2004), 90-101.

[Asprise] LAB Asprise!, Asprise OCR SDK v4.0 Homepage, http://asprise.com/- product/ocr/selector.php. Checked 21.4.2010.

[Baid, 2000] Henry S. Baid, The State of the Art of Document Image Degrada- tion Modeling, In: Proceedings of 4th IAPR International Workshop on Docu- ment Analysis Systems (2000), 1-16.

[Baird et al., 2004] Henry S. Baird, Daniel Lopresti, Brian D. Davidson and Wil- liam M. Pottenger, Robust Document Image Understanding Technologies, In: Proceedings of Conference on Information and Knowledge Management (2004), 9-14.

[Bechtold, 1998] Richard T. Bechtold, Diagnostic Software Architectures, Devel- opment and Evolution of Software Architectures for Product Families, Lecture Notes in Computer Science 1429 (1998), 143-147.

[Beitzel et al., 2003] Steven M. Beitzel, Eric C. Jensen and David A. Grossman, Retrieving OCR Text: A Survey of Current Approaches, In: Symposium on Document Image Understanding Technologies, SDIUT'03 (2003), 145-151.

[Belaïd and Belaïd, 1999] Y. Belaïd and A. Belaïd, Form Analysis by Neural Classification of Cells, In: Document Analysis Systems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 741.

[Casey et al., 1992] Richard Casey, David Ferguson, K. Mohiuddin and Eugene Walach, Intelligent forms processing system, Machine Vision and Applica- tions 5, 3 (1992), 143-155.

[Cavnar and Gillies, 1994] William B. Cavnar and Andrew M. Gillies, Data Re- trieval and the Realities of Document Conversion, In: Proceedings of Digital Libraries '94 (1994).

[Cesarini et al., 1998] Francesca Cesarini, Marco Gori, Simone Marinai and Gi- ovanni Soda, INFORMys: A Flexible Invoice-Like Form-Reader System, IEEE Transactions on Pattern Analysis and Machine Intelligence 20, 7 (1998), 730-745.

[Couasnon, 2001] Bertrand Couasnon, Dmos: A generic document recognition method, application to an automatic generator of musical scores, mathematical formulae and table structures recognition systems, International Journal on Document Analysis and Recognition, 8, 2-3 (2001), 111-122.

[Dropbox] Dropbox, Dropbox Homepage, http://www.dropbox.com/. Checked 21.4.2010.

[ExperVision] ExperVision, WebOCR 1.0 (Beta 2) Homepage, http://www.- expervision.com/download-webocr.htm. Checked 21.4.2010.

[Faure, 2000] Claudie Faure, Extracting the tables of contents from the images of documents. In: Proceedings of RIAO 2000 (2000), 121-135.

[File Innovations] File Innovations, Optical Character Recognition Tools Ho- mepage, http://www.ocrtools.com/. Checked 21.4.2010.

[Fujitsu, 2010] Fujitsu, Kofax VRS (Virtual Rescan), http://www.fujitsu- .com/global/services/computing/peripheral/scanners/tech/kofax/. Checked 21.4.2010.

[Fulton, 2010] Wayne Fulton, A few scanning tips, http://www.scantips.com/. Checked 21.4.2010.

[Gatos et al., 1997] B. Gatos, N. Papamarkos and C. Chamzas, Skew detection and text line position determination in digitized documents, Pattern Rec- ognition, 30, 9 (1997), 1505-1519.

[Gibson and Rodney, 2000] Garth A. Gibson and Rodney Van Meter, Network attached storage architecture, Communications of the ACM 43, 11 (2000), 37- 45.

[GOCR] GOCR Homepage, http://jocr.sourceforge.net/. Checked 21.4.2010.

[Google Code, 2010] Google Code, OCRopus Homepage, http://code.google- .com/p/ocropus/. Checked 20.4.2010.

[Google Code, 2010] Google Code, Tesseract OCR Homepage, http://code- .google.com/p/tesseract-ocr/. Checked 19.4.2010.

[GDI] Grahics Development International, Inc., WindFORM Products, http://www.gdisoft.com/gwf.htm. Checked 20.4.2010.

[Jiang et al., 1997] Huei-Fen Jiang, Chin-Chuan Han and Kuo-Chin Fan, A fast approach to the detection and correction of skew documents, Pattern Rec- ognition Letters, 18, 7 (1997), 675-686.

[Kebairi et al., 1999] Saddok Kebairi, Bruno Taconet, Abderrazak Zahour and Said Ramdane, A Statistical Method for an Automatic Detection of Form Types, In: Document Analysis Systems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 738.

[Kieninger and Dengel, 1999] Thomas Kieninger and Andreas Dengel, The T- Recs Table Recognition and Analysis System, In: Document Analysis Sys- tems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 741.

[Kim et al., 1999] Gyeonghwan Kim, Venu Govindaraju and Sargur N. Srihari, An architecture for handwritten text recognition systems, International Journal on Document Analysis and Recognition 2, 1 (1999), 37-44.

[Klink et al., 2000] Stefan Klink, Andreas Dengel and Thomas Kieninger, Doc- ument Structure Analysis Based on Layout and Textual Features, In: Pro- ceedings of International Workshop on Document Analysis Systems, DAS2000 (2000), 99-111.

[Kochi and Saitoh, 1999] Tsukasa Kochi and Takashi Saitoh, A Layout-Free Me- thod for Extracting Elements from Document Images, In: Document Analy- sis Systems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 739.

[Koga et al., 1999] M. Koga, R. Mine, H. Sako and H. Fujisawa, Lexical Search Approach for Character-String Recognition, In: Document Analysis Systems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 739.

[Kolak and Resnik, 2002] Okan Kolak and Philip Resnik, OCR Error Correction Using a Noisy Channel Model, In: Human Language Technology Conference (2002), 257-262.

[Korb, 2008] Joachim Korb, Survey of existing OCR practices and recommenda- tions for more efficient work, http://www.theeuropeanlibrary.org/portal/- organisation/cooperation/telplus/outcomes.php. Checked 9.4.2010.

[Kwag et al, 2002] H. K. Kwag, S. H. Kim, S. H. Jeong and G. S. Lee, Efficient skew estimation and correction algorithm for document images, Image and Vision Computing 20, 1 (2002), 25-35.

[Lam et al., 1993] Stephen W. Lam, Javanbakht Ladan and Sargur N. Srihari, Anatomy of a form reader. In: Proceedings of the International Conference on Document Analysis and Recognition, ICDAR'93 (1993), 506-509.

[Lavirotte and Pottier, 1998] Stéphane Lavirotte and Loïc Pottier, Mathematical formula recognition using graph grammar, In: Proceedings of the SPIE 3305 (1998), 44-52.

[Lecun et al., 1998] Yann Lecun, Léon Bottou, Yoshua Bengio and Patrick Haff- ner, Gradient-based learning applied to document recognition, In: Proceed- ings of the IEEE 86, 11 (1998), 2278-2324.

[Lenox and Woratschek, 2002] Terri L. Lenox and Charles R. Woratschek, Opti- cal Character Recognition, In: Roger R. Flynn Computer Sciences Volume 2, Software and Hardrware, Macmillan Reference USA, 2002, 132-134.

[Liang at al., 1996] J. Liang, J. Ha, R. M. Haralick and I. T. Phillips, Document layout structure extraction using bounding boxes of different entities. In: Proceedings of Workshop on Applications of Computer Vision, WACV '96 (1996), 278-283.

[Liang, 1999] Jisheng Liang, Document Structure Analysis and Performance Evalua- tion, University of Washington, 1999.

[Likforman-Sulem et al., 2006] Laurence Likforman-Sulem, Pascal Vaillant and Aliette de Bodard de la Jacopière, Automatic name extraction from de- graded document images, Pattern Analysis & Applications 9, 2-3 (2006), 211- 227.

[Lin et al., 1996] Jenn-Yih Lin, Chi-Wei Lee and Zen Chen, Identification of business forms using relationships between adjacent frames, Machine Vi- sion and Applications 9, 2 (1996), 56-64.

[Linxia and Lee, 2010] Linxia Liao and Jay Lee, Design of a reconfigurable prognostics platform for machine tools, Expert Systems with Applications 37, 1 (2010), 240-252.

[Maoa et al., 2003] Song Mao, Azriel Rosenfeld and Tapas Kanungo, Document Structure Analysis Algorithms: A Literature Survey, In: Proceedings of SPIE Electronic Imaging (2003), 197-207.

[Maruyama et al., 1999] Kenichi Maruyama, Makoto Kobayashi, Yasuaki Na- kano and Hirobumi Yamada, Cursive Handwritten Word Recognition by Integrating Multiple Classifiers, In: Document Analysis Systems: Theory and Practice, Lecture Notes in Computer Sciences 1655 (1999), 735.

[May et al., 2004] Adolf May, Benjamin Coifman, Randall Cayford and Greg Merritt, Automated Diagnostics of Loop Detectors and the Data Collection System in the Berkeley Highway Laboratory, University of California, Berkeley (2004).

[Milewski and Govindaraju, 2006], Robert Milewski and Venu Govindaraju, Extraction of Handwritten Text from Carbon Copy Medical Form Images, In: Document Analysis Systems VII, Lecture Notes in Computer Science 3827 (2006), 106-116.

[Mori et al., 1999] Shunji Mori, Hirobumi Nishida and Hiromitsu Yamada, Opt- ical Character Recognition, John Wiley & Sons, New York, 1999.

[Nartker et al., 2003] T. Nartker, K. Taghva, R. Young, J. Borsack and A. Condit, OCR correction based on document level knowledge, In: Proceeding of SPIE 5010 (2003), 103-110.

[Neves et al., 2008] Luiz Antônio Pereira Neves, João Marques de Carvalho, Jacques Facon and Flávio Bortolozzi, Table-form Extraction with Artefact Removal, Journal of Universal Computer Science, 14, 2 (2008), 252-266.

[OCR Terminal] OCR Terminal, http://www.ocrterminal.com/. Checked 19.4.2010.

[OnlineOCR.net 1] OnlineOCR.net, Online OCR Homepage, http://www- .onlineocr.net/. Checked 20.4.2010.

[OnlineOCR.net 2] OnlineOCR.net, OCR Web Service Homepage, http://www- .ocrwebservice.com/. Checked 20.4.2010.

[Osterer and Stamm, 2008] Heidrun Osterer and Philipp Stamm, Adrian Frutiger Typefaces: The Complete Works, Birkhäuser Basel, 2008, 175-190.

[Peng et al., 2003] Hanchuan Peng, Fuhui Long and Zheru Chi, Document Im- age Recognition Based on Template Matching of Component Block Projec- tions, IEEE Transactions on Pattern Analysis and Machine Intelligence 25, 9 (2003), 1188-1192.

[PrimeRecognition] Prime Recognition, Inc., Prime Recognition Homepage, http://www.primerec.com/. Checked19.4.2010.

[Rawat et al., 2006] Sachin Rawat, K.S. Sesh Kumar, Million Meshesha, Indra- neel Deb Sikdar, A. Balasubramanian and C.V. Jawahar, A Semi- automatic Adaptive OCR for Digital Libraries, In: Document Analysis Sys- tems VII, Lecture Notes in Computer Science 3872 (2006), 13-24.

[Rice et al., 1995] Stephen V. Rice, Frank R. Jenkins and Thomas A. Nartker, The Fourth Annual Test of OCR Accuracy, Information Science Research Institue, University of Nevada (1995).

[Roy et al, 2009] Vandana Roy, Sriganesh Madhvanath, Anand S. and Raghu- nath R. Sharma, A Framework for Adaptation of the Active-DTW Classifi- er for Online Handwritten Character Recognition, In: International Confe- rence on Document Analysis and Recognition (2009), 401-405.

[Shafait et al., 2007] Faisal Shafait, Joost van Beusekom, Daniel Keysers and Thomas M. Breuel, Page Frame Detection for Marginal Noise Removal from Scanned Documents, In: Image Analysis, Lecture Notes in Computer Sciences 4522 (2006), 71-83.

[Sherkat et al., 2005] Nasser Sherkat, Tony Allen and Wing Seong Wong, Use of colour for hand-filled form analysis and recognition, Pattern Analysis & Applications 8, 1-2 (2005), 163-180.

[Shirari et al., 1994] Sargur N. Srihari, Stephen W. Lam, Jonathan J. Hull, Rohini K. Srihari and Venugopal Govindaraju, Intelligent Data Retrieval from Raster Images of Documents, In: Proceedings of Digital Libraries '94 (1994), 34-40.

[Simple Software] Simple Software, SimpleIndex, http://www.simpleindex- .com/. Checked. 20.4.2010.

[Sojka, 2005] Petr Sojka, From Scanned Image to Knowledge Sharing Formats and Technologies in the Digital Mathematics Library Project. In: Proceed- ings of I-KNOW '05 (2005), 664-672.

[Spivak, 2002] Polina K. Spivak, Discovery of Optical Character Recognition Algorithms using Genetic Programming, In: Genetic Algorithms and Genetic Programming at Stanford (2002), 223-232.

[Staelin et al., 2007] Carl Staelin, Michael Elad, Darryl Greig, Oded Shmueli and Marie Vans, Biblio: automatic meta-data extraction, International Journal on Document Analysis and Recognition 10, 2 (2007), 113-126.

[t-reinhard.ch] t-reinhard.ch, Free OCR, http://www.free-ocr.com/. Checked 21.4.2010.

[Taghva et al., 1998] Kazem Taghva, Allen Condit, Julie Borsack, John Kilburg, Changshi Wu, and Jeff Gilbreth, The MANICURE Document Processing System, In: Document Recognition V, Proceedings of SPIE 3305 (1998), 179- 184.

[Tang and Liu, 1997] Yuan Yan Tang and Jiming Liu, Information Acquisition and Storage of Forms in Document Processing, In: Proceedings of the 4th In- ternational Conference on Document Analysis and Recognition, ICDAR'97 (1997), 170-174.

[Taylor et al., 1992] Suzanne Liebowitz Taylor, Richard Fritzson and Jon A. Pas- tor, Extraction of data from preprinted forms, Machine Vision and Applica- tions 5, 3 (1992), 211-222.

[Tong and Evans, 1996] Xiang Tong and David A. Evans, A Statistical Ap- proach to Automatic OCR Error Correction in Context, In: Proceedings of the Fourth Workshop on Very Large Corpora (WVLC-4) (1996), 88-101.

[Traeger et al., 2006] Avishay Traeger, Nikolai Joukov, Josef Sipek and Erez Zadok, Using free web storage for data backup, In: Proceedings of the Second ACM Workshop on Storage Security and Survivability (2006), 73-78.

[Transym] Transym, TOCR Homepage, http://www.transym.com/. Checked 21.4.2010.

[Trier et al., 1996] Øivind Due Trier, Anil K. Jain and Torfinn Taxt, Feature extraction methods for character recognition-A survey, Pattern Recognition 29, 4 (1996), 641-662.

[Wang et al., 2004] J.F. Wang, Peter W. Tse, L.S. He and Ricky W. Yeung, Re- mote sensing, diagnosis and collaborative maintenance with Web-enabled virtual instruments and mini-servers, The International Journal of Advanced Manufacturing Technology 24, 9-10 (2004), 764-772.

[Wikipedia, 2010] Wikipedia OCR-A font, http://en.wikipedia.org/wiki/OCR- A_font. Checked 28.4.2010.

[Wu et al., 2008] Jui-Chen Wu, Jun-Wei Hsieh and Yung-Sheng Chen, Mor- phology-based text line extraction, Machine Vision and Applications 19, 3 (2008), 195-207.

[Ye et al., 2000] X Ye, M. Cheriet and C.Y. Suen, A generic system to extract and clean handwritten data from business forms, In: Proceedings of the Seventh International Workshop on Ffrontiers in Handwriting Recognition (2000), 63-72.

[Zheng et al., 2005] Yefeng Zheng, Huiping Li and David Doermann, A Paral- lel-Line Detection Algorithm Based on HMM Decoding, IEEE Transactions on Pattern Analysis and Machine Intelligence 27, 5 (2005), 143-155.

[Zhilan et al., 2007] Hu Zhilan, Lin Xinggang and Yan Hong, Document image retrieval based on multi-density features, Frontiers of Electrical and Electron- ic Engineering in China 2, 2 (2007), 172-175.

Liite 1

OCR-kirjastojen käyttämät tiedostoformaatit

ABBYY Finereader OCR .Net TOCR Asprise OCR Luku Kirjoitus Luku Kirjoitus Luku Luku .bmp x x x x .dbf x .dcx x .chead x .cut x DjVu x .dcx x .dds x .doc x .docx x .doom x .csv x .html x .gif x x .ico x .jng x .jpeg x x .jpg x x x .lbm x .lif x .mdl x .mng x .pbm x .pcx x .pcd x .pdf x .pgm .pic x .pix x .pnm .ppt x .pptx x .png x x .pnm x .psd x .pxr x .raw x .rtf x .sgi x .tga x .tiff x x x x .txt x .wal x .xls x x .xlsx x .xml x x .xpm x ABBYY Finereader OCR .Net TOCR Asprise OCR Luku Kirjoitus Luku Kirjoitus Luku Luku .bmp x x x x .dbf x .dcx x .chead x .cut x DjVu x .dcx x .dds x .doc x .docx x .doom x .csv x .html x .gif x x .ico x .jng x .jpeg x x .jpg x x x .lbm x .lif x .mdl x .mng x .pbm x .pcx x .pcd x .pdf x .pgm .pic x .pix 63 x .pnm .ppt ABBYY Finereaderx OCR .Net TOCR Asprise OCR x .pptx Luku Kirjoitus Luku Kirjoitus Luku Luku .bmp.png x x x x .dbf.pnm x x .dcx.psd x x .chead.pxr x x .cut.raw x .rtf x DjVu x .sgi x .dcx x .tga x .dds x .tiff x x x x .doc x .txt x .docx x .wal x .doom x .xls x x .csv x .xlsx x .html x .xml x x .gif x x .xpm x .ico x .jng x .jpeg x x .jpg x x x .lbm x .lif x .mdl x .mng x .pbm x .pcx x .pcd x .pdf x .pgm .pic x .pix x .pnm .ppt x .pptx x .png x x .pnm x .psd x .pxr x .raw x .rtf x .sgi x .tga x .tiff x x x x .txt x .wal x .xls x x .xlsx x .xml x x .xpm x 64

Liite 2

OCR-verkkopalvelujen käyttämät tiedostoformaatit

OCR Terminal Online OCR Free Online OCR Luku Kirjoitus Luku Kirjoitus Luku .bmp x x x .doc x x .html x .gif x x x .jpeg x x .jpg x x .pcx x .pcd .pdf x x x x .png x .rtf x x .tiff x x x .txt x x .xls x