Bo Lennart Wahlman bo.lennart.wahlman@wah.se skriver bl.a.
Nedan följer en lista på återkommande missar jämte eventuell förklaring på varför det blev så svårt för OCR.
• En bov är typsnitt med seriffer i förlagan och att närliggande tecken hamnat så tätt att hårstrecken hakar i varandra.
OCR-program verkar komma i två huvudgrupper: de som har lätt att rekonstruera brutna tecken (t.ex. ett svagt tryckt m som bryts upp i något som liknar ett n och ett i, eller tre punktlösa i), medan dessa program ofta har svårt att bryta isär tecken som bundits ihop; och så de programmen som har det motsatta problemet.
Calera WordScan (gammalt avlidet program, men mycket bra på sin tid) hade lätt att separera hopbundna tecken: för det programmet blev det bra om man scannade 'mörkt'. FineReader verkar ha lättare med motsatsen: dvs. den kan binda ihop separerade fragment bättre än det kan separera bundna.
För bästa reslutat måste man scanna efter OCR-programmet förmåga -- och detta är såvitt jag vet aldrig dokumenterat. Jag räknar med att det tar två-tre arbetsdagar att komma underfund med var OCR-programmets styrka ligger. Det betyder typiskt också att sådana här automatiska exponeringsfunktioner måste kopplas ur -- och det kan ge andra problem att fajtas med.
Sedan hänger det litet på hur programmen separerar tecken. Finereader verkar *inte* gå efter faktiska segment, utan gör någon sorts gissning -- det syns rätt bra när man tränar programmet var den tror att olika teckengränser kan gå. Ibland syns också att nedhänget i j, y och g hamnar överst på raden under. Det betyder att om den gissar fel kan två optiskt väl skiljda segment tolkas som om de tillhörde samma tecken. (Ett segment är en sammanhängande 'svart' area i en svartvit bild -- 'ö' består av tre segment.) De exemplen du ger med s.k. kernade tecken ('VA') brukar vara perfekta för att se om programmet gör rätt (dvs. går efter segmenten) eller om det använder genvägar. Med dagens hyfsat snabba maskiner så tror jag man kan göra rätt utan att det kostar för mycket i åtgången tid. Men de flesta OCR-program skrevs för maskiner två generationer tillbaks.
till?</footnote>. à tolkas alltid som å av OCR. Det vore tacknämligt om man kunde lära OCR att känna igen detta.
Det där har typiskt med språkval att göra. Tyvärr antar de flesta OCR-program att ett viss språk (typ Engelska) endast innehåller en fast uppsättning tecken. Dyker det upp något annat, så tolkas det som det närmaste av den fasta uppsättningen. é blir då e eller 6 om man har valt engelska.
FineReader gör så -- svenska innehåller inga à, í, ë, och om jag minns helt rätt inte ü heller. Lars har redan beskrivit vad man måste göra för att tala om att sådana 'osvenska' tecken kan dyka upp -- och det är tyvärr så att man måste göra om det för varje nytt jobb, om man inte använder litet knep och kopierar inställningsfilen till det nya jobbet. Dessutom måste man ofta ge programmet litet särskild träning att skilja mellan tecknen. Detta är ett område där FineReader inte fungerar som en svensk normalanvändare vill. (Jag tror att det finns en dyrare 'corporate'-version som tillåter att språkinställningar sparas mellan jobb ... och version 7 av FineReader är inte bättre den.)
För stora jobb är det värt att ägna en timme eller så att lära upp OCR-programmet på de olika typsnitt som används: man har igen det när man gör korrekturläsningen. Tyvärr är det också här så att få om ens någon OCR-tillverkare talar om hur bästa träning görs: sker den t.ex. bäst från noll-läge, eller skall man utgå från inbyggd kunskap? Skall man träna alla tecken (dvs. bekräfta dem som tolkas rätt), eller endast de som läses fel? Osv. (Textbridge var underbart i detta sammanhang: tränar man det fel -- och det kan man inte upptäcka förrän man börjar köra på allvar och ser att alla 'h' nu tolkas som 'hi', t.ex. -- är det oftast lika bra att starta om från början igen.)
Semikolon förekommer ymnigt i Geodet. Jag tror inte OCR har klarat semikolon rätt en enda gång: det blir - , eller något liknande för jämnan. Där borde det väl försökas att ge OCR någon extra tolkningsregel att hålla sig till. I dessa fall är det oftast helt klart i facsimilen att semikolon avses, ingen smuts. Det förefaller mig som om OCR helt enkelt inte läsrt sig tecknet semikolon.
Samma sak gäller korrekta citattecken (dvs. ‘ “ ” ’. I FineReader kan man dessutom inte träna om dem, enligt dokumentationen. Semikolon borde vara en träningsfråga, dock. Tankestreck kan man träna fram.
Vad som är klart för en människa är tyvärr inte lika klart för ett program, speciellt inte om det gissar sig fram till var enskilda bokstäver börjar och slutar. (FineReader är också rätt glad i att vertikaljustera inscannade texter som är aningen skeva -- och det leder ofta till att byggda tecken som ; uppfattas som två separata symboler. OCR är svårt.)
Har sett kommentar från någon som saknat möjlighet skriva musikaliska kors och b. Det finns säkert en hel rad musiktecken som skulle vara önskvärda. [... och mycket annat...]
Unicode kommer att bli en stor hjälp för enskilda tecken när det supportas fullt ut. Men det kommer inte att hjälpa till med notsats (som är otäckt svårt att göra bra -- det krävde typiskt specialutbildad sättare i de fall man inte gjorde kliche från litografi) eller med annat teknisk sättning, typ matematik, fysik eller kemi. Enskilda tecken (‽ eller ∰ eller ∀) kan hanteras lätt, typ vektor-notation (som borde kunna göras görs som Unicode-accenter) eller logik-symboler, men att skriva en integral 100% korrekt går inte. Här kommer endast markup eller att behålla en scannad bild på problemtexten att fungera (modern version av litograferad sats :-).
Jag misstänker att sådana passager i texten bör märkas upp som 'kan inte göras rätt idag - detta är endast ett närmevärde som bör revideras'.