lör 2005-03-12 klockan 22.47 skrev Christer Romson:
B L Wahlman:
- Ibland innehåller förlagan en figur på halvspalt eller så, med
kringflödande brödtext. OCR lämnar då figurens plats tom, 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?
Hur gör du för att kontrollera spaltbredden? Om man inte använder sig av specialtekniker så görs alltid radbrytningen om av webbläsaren oavsett hur du brutit raden när du korrläser. Undantaget är t.ex. om man använder inledande blanktecken (tänkt för poesi). Om du inte använder sådant så kan du ha ett ord per rad eller hela stycket på en jättelång rad. När den slutgiltiga texten skickas ut till webbläsaren så bryter den om texten med tanke på bredden på användarens fönster och det aktuella typsnittet.
Jag kan inte se någon som helst fördel med att försöka hårdkoda radbrytningen i det här fallet. Du vet ju inte hur brett användarens webbläsarfönster är. Om du gör brytningen för en 5 cm smal spalt och användaren bara har plats för 4,5 cm långa rader så kommer man få en automatisk radbrytning av varje tänkt 5 cm-rad till en 4,5 cm-rad och en 0,5 cm-rad.
Jag är inte heller riktigt säker på vad som menas, men jag kan försöka svara i alla fall.
Våra texter visas på två olika sätt. Så länge texterna till ett kapitel visas varje sida i taget tillsammans med faksimilbilderna (dvs så länge kapitlet inte slagits ihop till en html-sida) så visas OCR-texten med <pre>...text...</pre>. Det gör att radbrytningar man stoppar in när man korrekturläser kommer att fortsätta att synas för nästa läsare.
När vi senare slår ihop texten för hela kapitlet till en html-fil så kommer det inte att finnas några <pre>-taggar längre, och då kommer texten att visas radbruten där det passar bredden för användarens webbläsare.
Så länge man korrekturläser tycker jag att det är bra att man behåller (eller, om radbrytningar saknas i OCR-texten, rent av återskapar) de radbrytningar som finns på den tryckta sidan. Det innebär att om det på den tryckta sidan finns illustrationer som tar upp halva spalten så kommer OCR-texten att se ut så här ett tag, och det tycker jag är en fördel, eftersom det brukar vara lättare att alternera med blicken mellan OCR-texten och faksimilbilden om radbrytningarna är likadana i båda texterna. På det sättet vet man ungefär var på raden man ska titta när man flyttar blicken mellan de olika fönstren.
- I Geodet förekommer på flera ställe hänvisning 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 'Tekniska institutet' med gemen begynnelsebokstav på 'institutet'. Originalet är alltså inkonsekvent. Hur ska Runebergs korr-läsare förhålla sig till sådant?
Jag kan inte se något som helst skäl att försöka "förbättra" originalet på den punkten! Det ska vara mycket mera uppenbara misstag för att vi ska rätta dem. Om det någon gång stode "Tekniska intsitutet" så borde man rätta det fullständigt uppenbart felaktiga "ts" till "st", men låta "i" stå kvar.
Korrekt. Det som står i våra instruktioner är att vi ska efterlikna det tryckta originalet och det ser jag ingen anledning att frångå. Om vi börjar korrigera faktafel i den tryckta texten (även felräkningar) så dröjer det inte länge innan någon börjar korrigera faktafel i Nordisk Familjebok, och till slut kan man inte känna igen verken vi började med alls.
Personligen skulle jag vilja ha ett sätt att märka upp rena stavfel ("intsitutet" ovan) så att man kan visa texten utan dem, men jag vill samtidigt ha möjlighet att visa texten så som den verkligen trycktes. Vad det gäller räknefel i exempel och liknande faktafel som den *dåtida* läsaren skulle kunnat upptäcka så tycker jag att det är bättre att skriva något om sådant i förordet till den elektroniska upplagan. Man kan för den delen ibland skriva något om hur innehållet i texten förhåller sig till nutida kunskap också, men jag tycker att man bör hålla isär fel gentemot dåtida kunskap och fel gentemot nutida kunskap. (Kanske Bo Lennart är intresserad av att skriva förord till geodet?)
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 förekommer i den äldre litteratur, som förekommer i Runebergprojektet. Detta återspeglas i OCR-texten. Då uppstår frågan: ska man eftersträva en "bokstavstrogen" återgivning i den slutliga digitaliserade utgåvan, eller ska man "modernisera" utförandet av författarens/förlagets syn på saken?
Här finns det teknikaliteter i html att ta hänsyn till. När html-koden innhåller en sekvens av blanktecken och radbrott så ska det visas som ett blanktecken. Det går att trixa så att det visas två blanktecken efter varandra, men i normalfallet så kommer det vara bortkastat att försöka lägga in dubbla blanka mellan meningar.
Dels är detta lite komplicerat i html, som Christer säger, dels är detta också något som har med typografi att göra, inte med textens faktiska innehåll. Det finns inget semantiskt innehåll i ett dubbelt mellanslag efter en punkt istället för ett enkelt. Redan av punkten och efterföljande versal kan man se att det är slut på en mening och början på nästa, så det extra mellanslaget tillför ingenting. Det är bara en estetisk sak. Jag tycker inte att det är väsentligt att försöka behålla detta.
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.
Jag tror att samma sak som för dubbla blanktecken även gäller tab-tecken. När de visas i webbläsaren så blir det likadant som ett blanktecken. (Fast tabeller kanske skapas med pre-taggar?)
När kapitel slås ihop till HTML är det fritt fram för den som gör det att välja om man vill göra det med <pre>...</pre> eller med <table>...</table>. Det senare är mycket mer jobb. Hur det beror blir på en massa saker: hur snyggt korrekturläst tabellen är innan, hur mycket tid man har, om det är en massa komplicerade dubbelkolumner och annat krångel och så vidare.
Vad det gäller TAB-tecken håller jag med: sådana bör inte finnas i OCR-texten. Det borde nog rent av scripten som installerar OCR-texten se till, faktiskt. *noterar*
Hans