1 Tack för grektecknen! Synd bara att de inte fanns tidigare. Geodet:s tidigare sidor torde (om ingen vänlig själ redan ändrat på det) innehålla mängder av surrogaten [alpha]. [beta] etc. Fråga: önskar Runeberg omläsning av 100-talet sidor för justering, eller kan det stå som det är och fixas av Redax vid efterbehandlingen?

2 Räcker det att jag kopierar och klistrar från de nytillsatta röda raderna eller bör jag dessutom ställa om kodsidan för mitt tangentbord från "Latin 1 = ISO vad-det-nu-är-för-nummer" till UTF-8?

3 From önskan: Om det går, lägg in en blankrad mellan inmatningsfältet för korr och de nyinlagda UTF-8-teckning. De röda raderna tätt intill korr-fältet stör ögat, när man är nere på sista raden i korr-fältet.

4 Gemena sigma ser inte ut som jag hade väntat mig.

5 Bland övriga tecken förefaller versala THORN och gement thorn ha fått varandras placeringar, eller hur?

6 Har hittat ± bland högre ASCII-nummer i "Latin 1", och ser att ofta OCR klarar det. Men i matematiska sammanhang duger inte det alltid, utan man måste kunna skriva "minus plus" d v s — ovanför +. Det hittar jag inte i de vanliga fonterna. Finns i och för sig i den vanliga fonten SYMBOL, men kan man använda det i Runeberg? I något fall substituerade jag <minus plus> med [minus]/[plus] (tror jag det var). Vad säger Runeberg om det?

7 I formler förekommer ibland s k ellips … som jag här lockat fram som ligatur. (Undrar just om det blir rätt återgivet av läsarens e-post-program!) Tycker det är bättre än tre punkttecken i rad ... som ev kan uppfattas som felskrift eller i något elakt fall bli radbrutet mitt i. Hvad tyx om det?

8 För inte så länge sen "uppfann" någon <img>, som jag sett många praktiserat, och som jag själv ofta använt. Men när jag senast kollade tillåtna markeringar <i>, </i> etc så var inte <img> med som tillåtet. Verkar ha blivit "de-facto-standard", men borde legitimeras om det nu kan accepteras. Har dock sett att det tillämpas lite olika i samband med figurtitlar. Någon hade satt <img>Figurtitel</img>. Själv (och även andra) har skrivit <i>Figurtitel</i> <img> om texten varit bilden överställd resp <img><b>Figurtiltel</b> om texten varit bilden underställd. Formatering <i> eller <b> eller annat alltefter var förlagan antyder. Och så en eller annan blankrad extra för att förtydliga det hela. Här behövs klara direktiv från Runebergledningen hur man ska göra, så att alla tillämpar det enhetligt.

9 Någan hade förundrat sig över att OCR ständigt missar på vissa saker. Jag har också noterat det, och jag tror att det ofta finns andra förklaringar än "smuts" till att det det blir ett svårt jobb för OCR. Egentligen har jag stor beundran för vad OCR verkligen klarar av. Exempelvis i ett tabellhuvud med vertikal text i smal kolumn ömsevis med horisontell text i en något bredare kolumn. Det vertikala roterades 90° och blev alldeles rätt återgivet.

Nedan följer en lista på återkommande missar jämte eventuell förklaring på varför det blev så svårt för OCR. Kanske går det att lägga in någon sorts undantagslista för OCR att kolla mot.

• En bov är typsnitt med seriffer i förlagan och att närliggande tecken hamnat så tätt att hårstrecken hakar i varandra. Typord För där gluggen i F upptill, till höger kommit så nära prickarna i ö att OCR uppfattar det som Por. Detta händer gång på gång med den stil som används i Geodet. I rubriker blir det än värre, då sättaren eventuellt avsiktligt tillämpat s k knipning (engelska kerning) av estetiska skäl. Exempelvis bigrammet "VA", där V.ets högraste del står något till höger om A:ets vänstraste del. I typografiskt "finlir" finns ett antal ligaturer typ "fj" som är svårt för OCR att bemästra. <footnote>Här skulle jag vilja skriva med "hängande indrag", men jag vet ej hur det ska gå till med mitt e-post-program och hur det kommer att uppfattas av mottagaren, som kanske ändrar på radbrytningen på skärmen och vid eventuell utskrift. Någon som vet hur det skulle kunna gå till?</footnote>. à tolkas alltid som å av OCR. Det vore tacknämligt om man kunde lära OCR att känna igen detta. Jag tror att jag minns att é gick bra, men vad jag minns har è aldrig varit aktuellt i de texter jag hållit på med.

• J (Johan) är ett speciellt problem i det att olika typsnittmakare har olika uppfattning om hur denna symbol ska se ut:

— Enligt en skola (mycket vanligt i USA) ska det vara ett "tak" ovanpå så att det liknar ett T (Tore) med en krok åt vänster nedtill.

— En annan variant visar högra delen av "taket" stympat, så att det mera liknar siffran 7 med en krok nedtill. Men somliga människor menar att detta är ju ett i (Ivar). I andra typsnitt är det gemena j som har nerstapel som överskrider baslinjen medan versala J håller sig vilande på baslinjen.

— Vid ett typsnitt är det versala J förlängt nedåt, så att det går en bit under raden (baslinjen) medan det gemena j ligger mycket högre med pricken över relativt högt,

Det säger sig självt att OCR får bekymmer att rätt tolka en krumelur som ska föreställa Johan i ett typsnitt medan samma (eller nära lika) krumelur ska vara Ivar i ett annat.

• Ett klassiskt problem är att göra skillnad O (Olov) och 0 (nolla), på gement l (Ludvig), versalt I (Ivar) och 1 (siffran ett). OCR gör rätt ibland och fel ibland på ett slumpartat sätt. Korrekturläsare (inklusive jag själv) har ibland svårt att märka skillnaden. Man måste vara mycket observant. Val av typsnitt har stor inverkan. Man bör försöka hitta nogot som skriver 0 som 0 s k signalistnolla. (Här MONACO med konstant breddsteg; hur kom det fram?

• OCR har ju att fatta en mängd beslut. Om en pixel varken är svart eller vit utan mer eller mindre grå eller pixeln bara till en del är svart, Ska då OCR besluta pix = svart eller pix = vit?. När OCR gissar så blir det rätt ibland och fel ibland och tillsammans med övriga tecknets pixlar så kan det resultera i att fel tecken skrivs ut.

På blytypernas tid var hela maskineriet (sättmaskin, matriser, tryckpress etc) utsatt för slitage som resulterade i hoppande tecken (ojämn rad) och då kom stundom ett hårstreck lite högre eller lägre än det borde i det färdiga trycket, och då är det inte så konstigt om OCR blir lurat. Här har vi kanske en förklaring till att m läses som ni eller in och tvärt om. li blir h. För mig blir ofta (= nästan jämt) en versal begynnelsebokstav V i ett i övrigt gement ord feltolkat som Y, sannolikt beroende på "oren spets" i V:ets nederdel.

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.

• Icke sällan uppstår onödiga blanksteg. Det kan bero på att förlagan är satt med radutjämning ("rak högermarg"), vilket innebär att mellanslag, d v s inte avsiktligt blanksteg, inlägges i trycksatsen här och där i ordmellanrummen efter vissa sätteriregler. Det kan då komma tolkas som extra blanksteg av OCR. Mellanslag har vanligen mindre bredd än ett blanksteg och i en lång rad uppfattar en normalläsare inte att ordmellanrummen kan vara något ojämna. Är spalten mycket smal, eller minskad då texten flödar kring en bild, händer det att texten ser påtagligt gles ut, även för ett otränat öga. Detta blir särskilt uppenbart om man slarvat med avstavningen av långa ord. Och då lägger OCR gärna till onödiga blanksteg.

En komplikation blir det i speciella fall. Tidvis har det varit en typografisk princip att efter punkt i avslutad mening skall det vara dubbelt blanksteg innan nästa mening börjar. Det har jag konstaterat att OCR ofta iakttar vid tolkningen, men inte till 100 %. Tidigare har principen om dubbla blanksteg mellan meningar varit obligatoriskt i USA. men man tycks på senare tid ha omprövat denna princip; Jag har t o m sett direktiv att inte ha dubbla blanksteg mellan meningar. Om inte annat så är detta utrymmesbesparande, och i längre texter kan det ge flera raders påföljd, vilket i sin tur ger effekter på vettig sidbrytning (undvika s k horungar; engelsk term "widows and orphans ".)

Hur ska vi göra i Runeberg, vara bokstavstrogna och hålla på förlagans dubbla blanksteg mellan meningar, eller konsekvent se till att det bara blir ett?

10 Tabeller med komplexa huvuden är ett speciellt kapitel. Inom kolumnerna vill man ofta ha extra blanksteg här och var, exempelvis vid tal med decimaler, där man vill ha decimalkommat lodrakt oberoende av antalet siffror i heltasdelen resp decimaldelen. Där gör OCR hipp som happ, och det är kanske inte så mycket att säga någonting om. Det är en svår uppgift för OCR. Men jag har efter en del misslyckade tabellförsök kommit på att vid längre textlösa bitar på en rad, så har OCR, i st f att lägga in upprepade blanksteg (ASCII 32) dragit till med en TAB (ASCII 11), som inte är lätt att se vid ordbehandling, även vid den förhållandevis enkla ordbehandlingskapacitet vi har i korr-fältet. Denna TAB har "gummibandkaraktär". Ibland är dess verkan mindre än bredden på ett normalt blanksteg; ibland motsvarar ett TAB-tecken bredden hos två eller flera normala blanksteg. Hur det slår i praktiken beror på vad som finns i den närmaste omgivningen. Ändrar man något på raden kan en sådan osynlig TAB sträcka på sig eller krympa, och raden kan bli korrupt. Om man har vertikalstreck | eller kanske utropstecken ! som kolumnavskiljare avslöjas det av att vertikallinjen slingrar sig något längs kolumnen, och då gäller det att leta reda på den förmädliga TAB:en och ersätta den med ett normalt blanksteg. Men ibland ska den bara tas bort och inte alls ersättas med något annat. Lurifaxen kan finnas var som helst på raden och stundom inte alls i den kolumn man först trodde. Det har hänt mig att det varit flera dolda TAB:ar på samma rad men i skilda kolumner. Först sedan man fått bort alla TAB-arna blir det något så när ordning i tabellen.

Efter ett flertal tabelljobb har jag kommit fram till att sedan jag i korr-fältet fåt fram något som jag är nöjd med måste jag spara och kontrollera hur Runeberg uppfattat hela sidan. Ofta ser jag då någon detalj som behöver förfinas. Jag gör en justering, sparar och kontrollerar. Men inget tycks ha hänt. Har inte Runeberg fattat vad jag vill? Svaret ligger i att min dators cach-minne i sin snabbhetsiver visar samma gamla version som nyss, trots att Runeberg noterat ändringen.

Boten är att spara, lämna Runeberg, tömma mitt cach-minne, och sedan anropa Runeberg från början, hämta fram aktuell sida och kontrollera. Och si, då visar det sig att Runeberg faktiskt har förstått mina intentioner. Om jag nu inte lyckas få allt rätt med det samma så kan det behövas flera omgångar med samma procedur, så blir det lätt lite tjatigt, eller i varje fall tidskrävande.

11 När det gäller tabeller så saknar jag möjliheten att göra sammanhängande vertikallinjer utan gluggar mellan raderna, fyra sorters hörn (hittills simulerade med + ) m m. Detta är möjligt med gamla kodsidan CP 437, men finns inte i den av Runeberg rekommenderade ISO vad-det-nu-är-för-nummer. Ger ett utökat UTF-8 denna möjlighet?

Jag har stickprovsvis tittat lite i Nordisk Familjebok och konstaterat att det finns en hel del kemiska strukturformler, där det skulle vara bra att kunna rita diverse enkla och dubbla linjer, även sneda linjer samt pilar i rekursionsformler.

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. Jag menar alltså situationer som är enlkare än t o m notexempel på treklang i moll och sådant. Mera komplicerade notexempel får man kanske finna sig att återge som bild.

För egen del så ser jag behov att kunna skriva matematik på något vettigt sätt. Bland de enklare (?) är väl att kunna skriva integraler och differentialer, men kommer man till någon bok med mängdlära och "upp-och-nedvända A", "bakvända E" o s v blir det värre. Redan i ren algebra vill man kunna skriva bråk med en riktig täljare och riktig nämnare separerade med ett lååångt horisontellt streck. Inte krångla sig fram med tangentbordets bråkstreck / på en enda lång rad. För att ett sådant förfarande ska bli entydigt måste man lägga till parenteser här och var, kanske i flera nivåer; parenteser som inte återfinns i förlagan. Då gäller det att placera alla parenteser rätt, vilket kräver viss matematisk skolning hos korrekturläsaren. Hur ska jag skriva "limes när x går mot noll" och samtidigt få det på rätt plats under den variabel det hör till? Samt med några punkter mindre grad? Dubbelbråk? Grrr!

Hur ska Runeberg hantera en vektor, som i förlagan återges med bokstav med överstreck? Att transkribera till fetstil skulle ju kunna innebära konflikt med matris, och det var ju inte meningen.

Det finns ett flertal specialprogram som klarar det här, exempelvis "Equation Editor", som brukar följa med MS WORD (fast man kanske måste söka lite i datorn innan får tag på det i en normalinstallation. Det går att göra ganska snygga saker med det , när man kommit underfund med hanteringen.

För notskrift finns det programmet MUSICATOR, som är gratis, åtminstone i demoversion. Har vidare av en slump råkat på IGOR ENGRAVER (svenskt program), som jag t v inte vet så mycket om, men det verkar klara mycket avancerade saker, och lär vara FREEWARE.

Har också sett någonstans specialprogram för kemiska formler, fast jag nu glömt vad det heter — är inte kemist själv.

Skulle man införa allt detta i Runeberg mister man naturligtvis den enkelhet som eftersträvas, men ska man lyckas med ambitionen att få med ALL nordisk litteratur måste man väl lösa detta på ett eller annat sätt. Kanske måste man tänka sig även frivilliga korr-läsare med specialkompetens, som kan eller kan lära sig använda något av dessa program (eller liknande) till Runebergs fromma? Om det nu överhuvud taget är praktiskt möjligt att baka in det i Runebergprojektet. Gör Gutenberg något med anknytning till nämnda problem, som kunde ge uppslag för Runeberg?

<—————oooooOOÔOOooooo—————>

Det bidde ganska långt det här, men det var mycket som tryckte på och ville ut. Det finns mer att diskutera kring dessa ting, men det får anstå till senare tillfälle. Pascal sade: Detta ärende är så brådskande att jag inte har tid att vara kortfattad. Det lite så jag känner det.

Jag hoppas att åtminstone någon orkar läsa igenom ända hit till slutet, och att åtminstone någon pärla ska falla i god jord.

B L Wahlman bo.lennart.wahlman@wah.se