Från: bo.lennart.wahlman(a)wah.se
Datum: den 12 mars 2005 07.15.30 MET
Till: Runeberg(a)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 <sub> </sub>. 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: <sub>'</sub>. resp <sub>' '</sub>. 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 <sup>2</sup> 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(a)wah.se
