Från: bo.lennart.wahlman@wah.se Datum: den 12 mars 2005 07.15.30 MET Till: Runeberg@lists.lysator.liu.se

Efter att nu ha tränat en tid och tampats med diverse praktiska problem som har krävt ett ställningstagande, känner jag tiden mogen för att ventilera en rad detaljer, som, så vitt jag kunnat finna, inte är reglerade. Det är viktigt att:

• Olika korrläsare inte hanterar i grunden samma problem på sitt individuella sätt; • ingen inför något, som projektledningen sätter tummen ned för; • när något problem rapporteras till projektledningen, direktiv SNABBT blir offentliggjorda, så att ingen fortsätter med egna "uppfinningar", som inte kan sanktioneras. • Regelboken för korrläsning utökas med anvisningar för de vanligaste, av yrkesfolk praktiserade, typografiska sättningsreglerna, t e när man ska eller inte ska kursivera eller fetgöra skiljetecken; inget, enkelt eller dubbelt blanksteg i diverse situationer; hur man ska realisera korta och långa "streck": bindestreck (divis), minustecken vid matematik ("n-dash"), tankstreck ("tankeminus", "m-dash") o s v.

Jag har för egen del konstaterat bl a följande problem, som behöver lösas resp "de-facto-standard" vartill projektledningens officiella sanktion sökes (exempelvis för bruket av <img>).

Här är några för mig aktuella problem:

1. Saknar tecken för att göra "lådor", d v s inramningar och sammansatta tabellhuvuden, feta och magra kolumnskiljande linjer.

2. Har med "DOS-metoder" (+-----+, ====!====, |, _______) gjort en del tabeller. I mina förfsta försök formaterade jag på gängse sätt med <i> </i> <b> </b> för att troget återge förlagans formatering. Men då blir tabellen helt onjutbar för den som "googlar" in på revideret. Ibland är förlagan så dålig, att det kräver mycket arbete att rätt tolka bilden, och det arbetet vill man bespara googlaren genom att servera ett revider, där ett färdigtolkat budskap kan avläsas utan större besvär.

Något senare underlät jag avsiktligt att göra formateringar inuti tabeller, som då blev någorlunda snygga — under förutsättning att de läses med stil med fast breddsteg för alla tecken. Men är det rätt att hoppa över författarens formateringar? Jag fick också en kommentar från någon korrläsar-kamrat med innebörd "Vaffö–de–då?". Hoppar jag över formateringen är ju formellt sidan inte färdig-korrad, även om den i detta skick är ganska bra. Då blir det kanske en bromskloss för färdigställandet. Den som "känt" mest för volymen, menar att han gjort sitt, bryr sig inte mer om den; ägnar kanske vidare krafter till någon annan volym. På det viset skyfflas problemet över till slutredigeringen, och Redax får mer jobb än egentligen nödvändigt.

Hur gör vi?

3. Jag är glad över de nyligen införda "röda tecken" i utf-format, som införts bl a för Geodet. Det förekommer en hel del grektecken i den matematik, som finns i Geodet. Men innan det röda kom, hann jag införa åtskilliga egna uppfinningar, t e [alpha] i st f α. Dessa blev OK-ade såsom färdiga. Skall jag gå tillbaka och ändra till UTF–8, eller ska jag sopa det vidare till redaktionens efterbearbetning?

4. Ibland innehåller förlagan en figur på halvspalt eller så, med kringflödande brödtext. OCR lämnar då figurens plats tom (eller stundom fylld med skräptecken), med brödtexten kvarstående i smalspalt. Ska vi då låta det stå kvar på smalspalt som det är, eller ska vi ombryta kringflödet till normalspalt?

Jag har sett att bägge varianterna praktiserats. Någon har tyckt att upprepad korrläsning är lättare om förlagans radbrytningar kan spåras. En annan åsikt är att åtminstone för googlare är ombrytning av smalspalter bäst. Det medför ju också reducerat antal rader sammanlagt på sidan vilket kan vara förmånligt vid eventuell utskrift. Alla har väl någon gång föragargas över att A4:an bara NÄSTAN räckte till och det blev bara en enstaka rad på sida 2, i värsta fall bara en s k horunge, som hade kunnat undvikas vid en ombrytning av sidan.

Direktiv önskas.

5. I Geodet förekommer en hel del indexerade variabler. För detta ändamål finns funktionen . Men det som ska sättas emellan är något av tecknen prim, bis eller t o m "triss". Ett substitut kunde vara ett kommatecken, men i flera aktuella fall blir det tolkningsproblem om förlagan föreskriver att det omedelbart efter ett "index prim" ska följa ett kommatecken, som verkligen ska gälla som kommatecken. En annan metod är att mellan styrtecknen sätta en apostrof eller flera, så här: _'. resp _' '. i "bis-fallet" har jag dessutom lagt emellan ett blanksteg för att förtydliga det hela; undvika tolkning som citat-tecken ( " ). Detta blanksteg har jag dessutom skrivit som "hårt" (nödvändigt) blanksteg för att undvika en eventuell olycklig rabrytning i ett sammansatt tecken. Hårt blanksteg fungerar på min dator och i min web-läsare. Men hur tolkas det av Runeberg, och, framför allt hur blir det tolkat vid efterbehandlingen av slut-korrat dokument vid hopslagningen till HTML?

Kunde man tänka sig en utökning av röda tecknen med index prim, bis etc hämtat från UTF-8. Behov finns även för <sub>-variant, d v s i upphöjd position i samma läge som apostrof, men verkligen typografiskt utformat som prim, bis (= sekund) etc?

Detta behov föreligger inte bara vid matematik ens värld, utan även i äldre litteratur som använder gamla mått såsom fot/feet, tum/inch, linjer.

Kommentar?

6. När det gäller gamla svenska mått ser jag ett behov av hantering av skålpundtecknet, som torde vara en handstilens förvanskning av libra, lb. Samma procedur som torde vara förklaringen av @ som en handstilförvanskning av 'at'. Jag har sökt på wiki-sidor med letat på på annat sätt på Internet, men inte någonstans hittat ett skålpund-tecken. Och ändå fanns det i varenda kokbok, ännu på sent 1800-tal.

Känner någon till en font med skålpundtecken, som man kan mata in i en dator för användning i något ordbehandlingsprogram? (Mac OCH PC!) Att användas i Runebergsammanhang.

7. Jag har i Geodet haft behov att kunna förse en rad tecken (inklusive blanksteg) med sammanhängande understreck. Metod för detta synes saknas i Runeberg. Jag uppfann då <und> </und>, och frågade Runeberg vad man ansåg om det. Jag har hittills inte fått något svar på det, och antar att projektledningen haft viktigare saker för sig. Men problemet kvarstår, och kommer i dagen när ifrågavarande sida ska efterbehandlas för HTML-transformering.

Vid den algebra som förekommer i Geodet — och gissningsvis även i andra runebergdokument — förekommer bråk med täljare och nämnare av mer komplex typ än 3/4 o d. Som surrogat har jag då använt ' / ' som divisionsoperator, men för att undvika möjlig feltorlkning huruvida en viss fakor eller term ska anses till höra nämnaren eller täljaren har måst införa diverse parenteser, som inte finns i förlagan. Uttrycken blir då mycket oöverskådliga, särskilt när det ingår en mängd <i> </i> <sub> och <sup> och så'nt varvid en tämligen enkel ekvation breder ut sig på både två och tre rader. Inte sällan blir det då automatisk radbrytning på olämpligt ställe, t e ' </su ' i slutet på en rad, och ' p> ' i början på nästa.

Jag kan naturligtvis fixa radbrytningen genom att på lämpligt ställe sätta till ' CR NL ' så att det ser hyfsat ut på MIN skärm. Men hur kommer det att uppfattas av Runeberg och andra ev läsare med annan radlängd i sina maskiner?

Fult går väl an, men en ekvation får absolut inte feltolkas, så att budskapet blir förvanskat.

Jag ställer därför frågan på nytt. Vad säger Runeberg om <und> </und>?

8. Tack röda tankstreck. Men på aktuella sidor där UTF-8 införts är det fortfarande kontraorder till höger "don't use long dashes". Vad ska den tvehågsne tro: Bryta mot order eller avstå från ett önskat rött tecken?

Kontraordern bör plockas bort från aktuella korr-sidor.

9. I Geodet förekommer på flera ställe hänvisningt till KTH:s föregångare Tekniska Institutet. Ibland stavas det just så, med versalt T och versalt I. Men ibland har sättaren skrivit 'Tehniska institutet' med gemen begynnelsebokstav på 'institutet'. Originalet är alltså inkonsekvent. Liknande inkonsekvenser finns nog i andra dokumednt också.

Hur ska Runebergs korr-läsare förhålla sig till sådant: ska vi slaviskt migrera missarna, eller ska vi harmonisera upptäckta missar så att bruket blir så konsekvent som möjligt genom hela dokumenteet? I den mån harmonisering anses böra ske, blir det förstås viss beslutsvånda när man ska välja mellan möjliga alternativ. Smaken kan vara olika; vad ska anses vara det rätta?

10. Frågan om hårt blanksteg har berörts i p 7 ovan. Nu har jag i UTF-8 någonstans sett något som kallas "unbreakable space" eller något liknande. Kan det vara något att ta vara på?

11. I Geodet har jag på senare tid vid kvadrat-uttryck ersatt det klumpiga och utrymmeskrävande ² med det betydligt bättre ² (decimal 178). Så vitt jag kan se från min horisont verkar det fungera, åtminstone där. Hur fungerar det för andra, På UTF-8-konverterade sidor resp andra sidor?

i p 1 ovan efterlyste jag tecken att göra lådor med. Jag har i UTF-8-samlingen på wiki-sida uppsökt "box-avdelningen" och försökt hämta lådtecken därifrån. Tycktes först fungera på min skärm, men efter sparning på Runeberg och återläsning (sedan jag för säkerhets skull tömt mitt cache-minne) visade det sig att det helt spårat ur. De ursprungligen fina lådorna i ett tabellhuvud blev bara skräptecken. Samma fenomen antingen provsidan var konverterad för UTF-8 eller inte. Såg i en kommentar nyligen — kanske det var från herr Aronsson själv — att hans dator bestämt vägrade utföra viss manöver. Gissar det är samma egenskap som ligger bakom datorvägran

12. Jag har nog under Geodet-arbetet förväxlat ett kursivt ' w ' med grekiska omega ' ω ', ser ju mycket lika ut. Hur gör man i dylika fall: Låta det passera, eller som 'vän av ordning' söka upp aktuella ställen?

Ställd inför en sådan uppgift omfattande omläsning av 100-talet sidor, önskar man sig en "leta-funktion" i stil med vad som finns i WINDOWS och i [de flesta?] ordbehandlingsprogrammen. I bland har jag velat gå tillbaka flera tio-tal sidor för att se hur jag den gången löste ett visst problem. (Man vill ju arbeta konsekvent genom hela verket.)

Ligger det inom någon rimlighets ram att få tillgång till någon liknande sökfunktion vid korr av Runebergsidor?

13. ' asq ' har två gånger skickat identiska meddelanden om dubbla blanksteg. Jag har ännu inte förstått huruvida frågan var en uppmaning ATT söka efter dubbla blanksteg i OCR-texten, eller att INTE göra det. V g förtydliga budskapet.

Jag har ett eget spörsmål beträffande blanksteg. Enligt en gammal typografregel skulle man sätta texten så att mellanrummet mellan meningar blev det dubbla normala blanksteget jämfört med ordmellanrum inuti meningen. Detta synsätt är väl huvudsakligen övergiven vid modern typografi, men förekommer ej sällan i den äldre litteratur, som förekommer i Runebergprojektet. Detta återspeglas naturligtvis — mer eller mindre väl — i OCR-texten. Då uppstår den principiella frågan: • Ska man eftersträva en "bokstavstrogen" återgivning i den slutliga digitaliserade utgåvan, eller • ska man "modernisera" utförandet (= typografisk bearbetning) av författarens/förlagets syn på saken?

Till detta vill jag upprepa en synpunkt, som jag tidigare i något sammanhang förfäktat:

Det har visat sig, vid detaljgranskning av OCR-resultat, att maskinen uppfattar textens MELLANSLAG (för radujämning till rak högermarg — på svenglisch ofta oriktigt kallat justering) som avsiktliga blankseg och också handlar därefter. I händelse av inbakade figurer med krinflödad text i smalspalt samt vid centrerade rubriker m m blir det gärna påtagligt glest mellan orden. OCR gör det då lättare för sig, och i stället för många blanksteg i följd läggs ett eller flera TAB-steg in med odefinierad standardlängd, eventuellt 8 blank, som är ett vanligt standardval. Jag har träffat på detta ganska ofta, särskilt i samband med tabeller, som jag kämpat en hel del med. Där fåt tabbar ibland förödande effekter, som kan undvikas genom ersättning av lämpligt antal blanksteg. Men obs, för pålitligt resultat måste stil med konstant breddsteg användas, annars blir resultatet oförutsägbart.

Dessa tabbar har egentligen i sig inte någon fast längd, Det de gör är att åstadkomma ett hopp till ett fast läge på raden = standardbredd på kolumner. Vad som menas med standardbredd kan definieras olika från fall till fall. I vissa lägen kan en sådan här gummibandstab få en längd som är mycket nära lika med, men inte exakt, ett normalt blanksteg, och då kan det vara mycket svårt att identifiera tabb:en, särskild om den ansluter till ett eller flera normala blanksteg på endera sidan. I särskil kniviga fall kan det hända att en tab ligger någonstans var som helst i en svit av många blanksteg.

Under resans gång kan det intråffa ändringar på radbrytningarna. Runeberg och jag och andra användare kan ha sin utrustning inställd på andra marginalbredder och spaltbredder. Origanelen, som OCR-tolkas, har oförutsägbara mått på satsytan.

Sammantaget betyder detta att man för ett snyggt och stabilt resultat MÅSTE leta rätt på alla dolda tab-steg, och efter behov byta mot blanksteg, ett eller flera. Man ser detta lättast (eller rättare sagt, minst svårt) om man vid korrläsningen ser till att man använder stil med konstant breddsteg. COURIER har detta, men det finns flera, som kan finnas i den dator man arbetar med.

När det gäller Courier har jag kommit på en lus i åtminstone den font jag har i min dator: Grader-symbolen ' ° ' följer inte det normala fasta breddsteg som gäller för den aktuella graden. T v har jag inte kommit på något ytterligare tecken som avviker från breddstandard. Det har givit mig en hel del huvudbry med trigonometriska tabeller, grader ska beskrivas såväl i huvudet som eljest i tabellen. Det är stört omöjligt att få kolumnerna raka. Man saknar möjlighet att mikrojustera breddsteget (knipning/spärrning, engelska kerning).

Detta är förstås typografiskt "finlir", och vi bör naturligtvis ha någon norm för hur långt ambitionerna ska sträcka sig. Ska vi vara stolta över en kvalitetsprodukt, eller behöva skämmas för ett mer eller mindre mediokert resultat? Eller något däremellan. Vad säger projektledningen?

14. I Geodet behöver jag skriva kvadratrötter. Rot-tecken saknas (hittills) i röda raden. Jag har försökt med surrogatet bock (checkmark) hämtat från Unicodetabell, men det fungerar inte. Jag har då tagit till nödlösningen att skriva om uttrycket till negativ exponent men är utrymmeskrävande och ger svåröverskådligt resultat som kräver extra parenteser som behöver ännu mera utrymme.

Ersätta rotmärket med operatorn SQR eller motsvarande jämte en massa parenteser i flera nivåer? (I Geodet har jag hittills behövt upp till 3 parentesnivåer.) Finns något bättre förslag att hantera rot-uttryck? Det som önskas är något som med rimliga medel klarar även ett bråk under rot-märket.

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