Runeberg

runeberg@lists.lysator.liu.se

299 discussions

Tankar om typografi vid korr-läsning
by Bo Lennart Wahlman 14 Mar '05

14 Mar '05

2005-03-13 kl. 23.02 skrev Christer Romson: >> ... dels är detta 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. > > Utom i de sällsynta fall då en förkortning följs av stor bokstav (fil. > Dr.) eller så en mening börjar med liten bokstav (Sverige stred i > 30-åriga kriget. de la Gardie var en stor fältherre under den epoken.) > I de här fallen skulle ett enkelt ordmellanrum mellan "fil." och "Dr." > visa att de hör till samma mening och det dubbla mellan "kriget." och > "de la Gardie" visa att de hör till olika. De här fallen är så få och > så uppenbara ur sammanhanget att vi inte behöver ta någon speciell > hänsyn till dem, men Vän Av Ordning kan inte låta bli att påpeka det i > alla fall. Ett intressant fall som visar att det är viktigt med god typografi. Naturligtvis håller jag med om att hela idén med Runebergprojektets frivilliga — i bästa mening amatörer — måste bygga på några få, enkla regler, så att det inte blir för krångligt för den som är mindre fullfjädrad. Men man måste se upp med en del fällor, som kanske inte är uppenbara i första skedet, men som i slutskedet kan bli störande, rent av löjligt eller åtminstone svårbegripligt, så att läsaren tvinga läsa flera meningar upprepade gånger, innan författarens budskap står klar. "fil. Dr." är ett fall där en rutinerad korrekturläsare skall förutse att det någon gång i framtiden kan bli aktuellt med radbrytning ungefär där. Titel får absolut inte radbrytas så här: … text text fil. Dr. mera text … utan i det fall inte hela titeln får rum på sista raden så ska alltsammans föras över till början på nästa rad, så här: … text text fil. Dr. mera text … Lösningen är att man så tidigt som möjligt använder hårt blanksteg. Då undviker man framtida korrekturfel, då ursprungstexten bearbetas på ett eller annat sätt. Så enkla saker som förändring av brödtextens grad eller stil (samt naturligtvis ändring av satsbredden) kan i annat fall göra att det som från början såg bra ut, blir tokigt på slutet. Här gäller som förr att liten tuva kan stjälpa hela lasset. D v s, en minimal ändring kan få stora konsekvenser för resten av dokumentet. T e påverka sidbrytningen, så att en tabell bryts mitt i. Skräckfall när tabellhuvudet kommer nederst på en sida och tabellens innehåll, utan huvud, kommer på nästa sida Förbjudet! Ett liknande fall är när en rubrik i ensamt majestät hamnar nederst på en sida, och budskapet kommer på nästa sida utan rubrik. Annat som inte får radbrytas är • Personnummer, trots "bindestrecket, divis", bör inskrivas med hårt bindestreck • datum, dito. Skräckexempel: … text 12/ 3 1936 text text … Här skulle det behövas "hårt bråkstreck", men så vitt jag vet existerar det inte. • atikelnummer, tillverkningsnummer och liknande alfanumeriska sekvenser • långa numeriska tal. T e 47111428563141595 eller 47 111 428 563 141 595. Det finns dock specialfall, där denna regel måste brytas. Ska man skriva det hittills mest noggrant kända värdet på det magiska talet "pi" med flera tusen decimaler, så räcker inte en rad, inte ens en fullskriven sida med minsta läsbara grad (= 4 punkter?) • flerordsförkortningar typ o. s. v., o s v, bl. a., bl a. Har någon författare (hemska tanke) skrivit O. B. S! måste det ju stå kvar. Obrutet. • mätetal med tillhörande enhet. Typ 123 km; talet och sorten måste hänga ihop på samma rad • namn på personer och orter, exempelvis: Mag- nus Mat- hilda Sveri- ge de la Gardie är ett bra exempel. Annat korrekturläsaren bör vara uppmärksam på är typerna af Heidenstam, von Sydow, MacKey, Mac Key, Key–Åberg, MacIntosh, Mc Adam (uppfinnaren av "makadam" som vägbeläggning). (Den här inskriften är gjord med många tecken per rad, och jag har — som jag tror — skrivit af Heidenstam och von Sydow med hårt blanksteg. Jag antar att mången läsare av detta alster har andra marginalinställningar än jag, och det ska bli spännande att se hur detta utfaller, eller om någon fått ett ensamt 'af' eller 'von' sist på en rad. Är naturligtvis avhängigt huruvida vederbörandes läsprogram känner igen hårt blanksteg. Men har nu JAG "otur" så har slumpen styrt så att detta radslutkritiska fall inte inträffar, trots ändrad satsbredd.) — • • • — Allt detta bludder är naturligtvis detaljer, som "allmänheten" kanske inte tänker på vid korr-läsningen, men som har betydelse för slutprodukten. Den får inte framstå som alltför amatörmässig. Målet är ju att den färdiga produkten ska med behag kunna avnjutas, alternativt utan stötestenar kunna användas som källa till en doktorsavhandling i något märkligt, aldrig tidigare skådat ämne. Den ska vara sökbar med datorkraft. Utan att doktoranden (eller motsvarande) går i taket över källans dåliga TEKNISKA kvalitet. Den tekniska kvaliteten och produktens användbarhet står Runeberg för. (Eventuell dålig kvalitet i budskapet får ju författaren stå för, vilket också Runeberg mycket riktigt påpekar i sina anvisningar.) Rätt vad det är blir väl Runebergprodukterna så pass kända, att de resulterar i en recension i någon litterär eller vetenskaplig tidskrift. Då är det ju bra om kritiken av kvalitet och användbarheten av produkten blir positiv. Vi bör sträva efter att första korret är så bra som möjligt, vilket besparar Redax mycket städarbete. Resultat: Färdiga volymer med hög kvalitet produceras i ökad takt. Jag har i någon tidigare diskussion noterat synpunkten att en korrad sida skulle OK-märkas först efter minst en andra granskning. Underförstått en annan person än den som gjorde första korret. Jag stöder den tanken. Den i läsekonsten vane blir lätt blind och ser inte faktiska fel, därför att öga och hjärna registrerar flera ord i följd som en enhet, och därför rätt tolkar budskapet, även om detaljer är felaktiga. Det hjälper inte hur många gånger man läser igenom sitt eget alster; ändå blir det något fel kvar. Korrekturläsaren måste läsa varje enskilt ord och varje skiljetecken för sig för att upptäcka felen. Det är tidskrävande och mödosamt. Därför är det bra med "en second opinion" på revideret, så att eventuella missar rättas. Det kan också vara kniviga fall, där det kan finnas olika syn på hur vissa problem kan lösas. Situationen illustreras ganska bra av den diskussion jag sett om hur man ska förfara med repliker i dramatik; hur hexameter och annan poesi på bästa sätt ska korras. Det är många praktiska problem man stöter på. Själv har jag kämpat hårt med ekvationer (Geodet). De är matematiskt inte särskilt avancerade; ligger på gymnasienivå. Men med "runebergsåtergivning" blir det kompexa saker att hantera med — på en och samma ursprungsrad — förekommande många växlingar fram och tillbaka mellan och , interfolierat med / och flera gånger. Ibland bör raden starta med <tab> och sluta med några tecken i klartext. En halv ursprungsrad kan bli ända tre rader lång, innan allt är färdigt. Kanske sträcker sig utanför redigeringsfältet, så att man måste rulla texten mycket. Det är då lätt att man tappar överblicken och missar en och annan återställning med eller placerar den på fel ställe bland alla och . Jag har ibland frågat mig om man får kursivera operatorer. Exempel: Kan jag skriva den enkla ekvationen a+b+c(x+y)=d som a+b—c/(x+y)=d? eller måste jag krångla till det? I somliga fonter finns inte "kursiva plustecken" och "kursiva minustecken" och "kursiva likhetstecken". Och även om så skulle finnas så stämmer det inte med sättningsregler för ekvationer. Ekvationstypografiskt riktigt är a + b — c / ( x + y = d vilket redan nu blev 66 tecken och 20 tecken med den förenklade formateringen. Ursprungstexten ovan innehåller 12 tecken. Värsta fallet allså mer än 5 gånger så långt som ursprunget. Ska något inuti långa exemplet ovan kvadreras med 2 eller rotutdragas med omskrivning x—2, därför att Runeberg än så länge inte tillhandahåller rot-tecken, så blir det än värre. Och så kursiverade grektecken mitt i eländet, så blir det komplicerat innan sidan är klar. Då vore det som förstahands-korrare tryggt om det funnes en andra person som kunde identifiera eventuella misstag och rätta till dem, eller förhoppningsvis kunna verifiera att allt är rätt gjort. — • • • — Som någon helt korrekt påpekat, innebär dubbla blanksteg mellan meningar ingenting semaniskt och kan oftast undvikas. Beakta dock Christer Romsons iakttagelser om fil. Dr. m m. Men underlättar kanske läsningen något. Samma resonemang kan tillämpas på tabeller. Bortsett från några undantagsfall tillför kursivering och fetstil i tabeller ingen ändring av budskapet, men underlättar kanske läsningen något. Därför borde teckenformatering i tabeller kunna underlåtas. Då kan tabellen göras snygg för ögat och underlätta läsningen MYCKET. Utan att i egentlig mening budskapet går förlorat. — • • • — Jag har noterat flera tidigare diskussionsinlägg om typografi, och jag återkommer till dem. Nog om detta. Ska nu ta mig an ytterligare någon Geodet-sida, som efter hand har blivit ganska arbetskrävande typografiskt (och med en hel del — för all del ursäktliga — tillkortakommanden av OCR att tampas med. B L Wahlman bo.lennart.wahlman(a)wah.se

2 1

Tankar om typografi vid korr-läsning
by Bo Lennart Wahlman 13 Mar '05

13 Mar '05

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 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 -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 och 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 2 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

3 3

Korrektion av "Tankar om typografi"
by Bo Lennart Wahlman 12 Mar '05

12 Mar '05

I morse cirkulerades: > 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 = = = = =. I stridens hetta blev det förstås några formella fel (ej i sak, hoppas jag): > 5. I Geodet förekommer en hel del indexerade variabler. För detta > ändamål finns funktionen . Men det som ska sättas emellan > 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 -variant, d v s i > upphöjd position i samma läge som apostrof, men verkligen typografiskt > utformat som prim, bis (= sekund) etc? Står -variant, v g läs -variant. > 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. Står Tehniska, v g läs Tekniska. Beträffande övriga småmissar här och där borde jag naturligtvis ha korrekturläst mig själv lite bättre! Jag tror budskapet ändå kan förstås, och jag hoppas på överseende med att jag stundom slirat på tangenterna. B L Wahlman bo.lennart.wahlman(a)wah.se

1 0

OCR-rekrytering
by Lars Aronsson 09 Mar '05

09 Mar '05

Projekt Runeberg, Det som bromsar mig mest just nu är OCR. Komplicerade sidor med spalter och tabeller (i uppslagsverk och tidskrifter) gör att jag måste gå igenom och se att OCR-programmet har hittat rätt. För att komma snabbare framåt måste fler dela på det arbetet. Romaner och diktsamlingar där sidorna har en enkel struktur går däremot lätt att OCR-tolka, nästan helt automatiskt. Här finns ett pedagogiskt problem. Som nybörjare kan man ju inte från start ta på sig de mest komplicerade uppgifterna. Man måste öva upp sina färdigheter och gradvis ta på sig de svårare arbetena. Nu tänker jag ta för vana att hoppa över OCR på de böcker jag scannar, och lämnar därför fältet öppet för den som vill att göra ett försök med OCR. När man ser att ett verk saknar OCR-texter under faksimilbilderna, kan man gå till verkets innehållsförteckning, och där finns länken "download" längst ner på sidan. Den länken leder till en speciell download-sida varifrån man kan ladda ner de inscannade bilderna och även ladda upp den färdiga OCR-texten. Nedladdningen kräver i de flesta fall att man har en bredbandsanslutning eftersom det rör sig om många megabyte. Under "Recently published titles" finns nu flera verk som saknar OCR-text. De här två har vanlig löpande text: * "Betänken Eder!" http://runeberg.org/betanken/ * "Kungl. Maj:ts förordningar om automobiltrafik", http://runeberg.org/automob/ De här tre har notskrift som man får se till att OCR-programmet hoppar förbi: * Vita bandets sångbok, http://runeberg.org/vitaband/ * Svensk söndagsskolsångbok, http://runeberg.org/sondag/ * Sånglekar från Nääs, http://runeberg.org/sangnaas/ En början till instruktioner för OCR-tolkning finns på wiki-sidan http://runeberg.org/wiki/OCR och som för alla wiki-sidor så välkomnar vi hjälp att förbättra dem. -- Lars Aronsson (lars(a)aronsson.se) Projekt Runeberg - fri nordisk litteratur - http://runeberg.org/

3 2

Grektecken, OCR, Utf-8 och önskelista
by Bo Lennart Wahlman 02 Mar '05

02 Mar '05

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 , 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 Figurtitel <img> om texten varit bilden överställd resp <img>Figurtiltel om texten varit bilden underställd. Formatering eller 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(a)wah.se

3 3

Re: Grektecken, OCR, Utf-8 och ?nskelista (Bo Lennart Wahlman)
by Anders Thulin 26 Feb '05

26 Feb '05

Bo Lennart Wahlman <bo.lennart.wahlman(a)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'. -- Anders Thulin ath*algonet.se http://www.algonet.se/~ath

1 0

om <chapter>
by Agneta Åhrberg 25 Feb '05

25 Feb '05

Hu så många mail som legat medan jag ägnat mig åt flunsan. Vad det gäller <chapter> som i Familj-Journalen så blev jag helt förvirrad av alla de brutna avsnitten, med bilder och fortsättningar i samma eller nästa nummer. För att reda ut det, krävs total koncentration och 0 störningar. Så ser inte mitt liv ut. Därför gör jag en ensam bild till ett eget kapitel, när det inte går att sammanfoga med det hela kapitlet. Då det gäller Psalmboken så rörde det sig om Huvudrubrik, Underrubriker, delrubriker, och ibland en liten löst inplacerad hänsyftningsrubrik. Det är tur att det inte var trafiken jag rörde mig i, men så fort jag trodde att jag hade saken klar för mig så dök en ny rubrik upp. Alltså tog jag till och gjorde <chapter> av de enskilda rubrikerna tills nästa tänkbara rubrik dök upp. Jag uppfattar det som enda sättet att kunna ha lite kontroll på var jag var och om någon annan gjort något mer, om jag varit borta från verket ett tag och faktiskt inte minns. Jag har mycket stöd av att ha indexeringen gjord först. Även om det är OK om någon (jag?) korrekturläser först och det indexeras sen. Bäst är självklart om man kan göra ett helt verks alla åtgärder på en gång, men det beror lite grann på vad det är för verk. HC Anderssons Pictures of Sweden var helt OK för mig att göra så med. Men i Ivan the Skjuts-Boy är det så pass mycket fel i OCR-texten att det kommer att ta evigheter. Vad det gäller sådana "tekniska detaljer" som "de tre fälten och | -streck" och sånt så kanske det är möjligt att ta till det där med Runeberg Digest Light. Alltså raka konkreta instruktioner "Gör så här för att skapa en Innehållsföretckning som är sökbar för ett verk." och den som vill och har möjlighet att begripa mer kan klicka på en särskild ruta. Hälsning Agneta

1 0

OCR-program, hur funkar det?
by Anders Thapper 24 Feb '05

24 Feb '05

Hej, Jag förundras ibland över OCR-programmet och de tolkningar det gör och undrar om någon kan förklara hur det går till eller ge mig en länk där jag kan läsa om det själv. I uppfinningarnas bok förekommer ofta orten München och i väldigt många fall tolkas detta som Mimenen, jag kan se att antalet staplar passar bra men eftersom Mimenen mig veteligen inte är ett ord så begriper jag inte varför den tolkningen uppstår och återkommer igen och igen. Sen är ett vanligt fel att "om" tolkas som "örn", "han" som "lian", och "ro" som "rö", även när det inte finns något synligt smuts som kan lura tolkningen. I alla dess tre fall är det rätta ordet betydligt vanligare i svenska språket än det feltolkade och om programmet var osäkert så skulle det väl gissa på det mer använda, eller? Till sist undrar jag om det finns någon förklaring till att vissa ord får kapitäl även när de inte ska ha det, till exempel verkar detta drabba jern och jernet ganska ofta medan jag inte har märkt det på andra ord som börjar på j, beror det på att jern inte känns igen som ett ord? tacksam för svar, Anders Thapper

2 1

Grekiska tecken
by Lars Aronsson 24 Feb '05

24 Feb '05

Projekt Runeberg, De av er som haft ögonen på "Recent Changes"-sidan de sista dagarna kan ha sett en del märkliga "skräptecken" susa förbi. I och med inscanningen av ett finskt uppslagsverk, "Pieni Tietosanakirja", finns nämligen ett övervägande skäl att gå utanför den teckenstandard ISO 8859-1 som Projekt Runeberg tillämpat sedan starten 1992. Lösningen heter Unicode och närmare bestämt dess variant UTF-8. Detta gör att texter kan innehålla grekiska, ryska, arabiska, kinesiska, fonetiska och andra udda skrivtecken. Ett tydligt exempel är uttalsanvisningarna i början av det finska uppslagsverket, http://runeberg.org/pieni/1/0005.html Övergången från ISO 8859-1 till UTF-8 görs för ett verk i taget. I skrivande stund är det enbart verken /pieni/ och /geodet/ som omfattas, samt sidan "Recent Changes". Hittills kan det betraktas som ett experiment och jag tar gärna emot förslag på ytterligare verk där det finns behov och där vi kan prova ut tekniken innan vi inleder en övergång i större skala. I och med att UTF-8 förändrar sättet som "ä" lagras internt, så vill jag från nu avråda från att använda markeringen <spärr> för spärrad stil. I stället bör vi använda <sp> för detta. Tills vidare fungerar båda sätten att markera, så lägg ingen energi på att byta ut existerande markeringar. Men använd helst <sp> från nu. -- Lars Aronsson (lars(a)aronsson.se) Projekt Runeberg - fri nordisk litteratur - http://runeberg.org/

3 5

Re: Runeberg Digest, Vol 1, Issue 115
by Christer Toorell 24 Feb '05

24 Feb '05

Ref. Ingemar Olson: <chapter> och </chapter> I vissa böcker framgår det av innehållsförteckningen om bilderna ingår i ett kapitel eller inte. I dessa fall anser jag man utan tvekan bör följa den befintliga innehållförteckningen. Om bilden passar ihop med efterföljande text bör <chapter> ligga före bilden. Om bilden ligger efter en passande text bör </chapter> ligga efter bilden. Bilder som hamnat i fel kapitel har jag i vissa fall flyttat <img> intern på sidan så att den hamnat inom rätt kapitel eller lagt den först/sist på sidan. Helsidesbilder (inlagda helsidesbilder) ligger ofta konstigt på grund av bindningsteknik, dessa hamnar ofta fel, men det finns ofta referenser i texten som klargör var de finns. Hur ser det färdiga resultatet ut i dessa fall? Distingta regler för oss "läsare" skulle vara bra att ha. c.toorell (f.n. inaktiv korrekturläsare) ----- Original Message ----- From: <runeberg-request(a)lists.lysator.liu.se> To: <runeberg(a)lists.lysator.liu.se> Sent: Thursday, February 24, 2005 12:00 PM Subject: Runeberg Digest, Vol 1, Issue 115 > Send Runeberg mailing list submissions to > runeberg(a)lists.lysator.liu.se > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.lysator.liu.se/mailman/listinfo/runeberg > or, via email, send a message with subject or body 'help' to > runeberg-request(a)lists.lysator.liu.se > > You can reach the person managing the list at > runeberg-owner(a)lists.lysator.liu.se > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Runeberg digest..." > > > Today's Topics: > > 1. Re: Grekiska tecken (Lars Aronsson) > 2. <chapter> och </chapter> (Ingemar Olson) > 3. SV: [Runeberg] Grekiska tecken (Bertil Holmstr?m) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Feb 2005 04:19:16 +0100 (CET) > From: Lars Aronsson <lars(a)aronsson.se> > Subject: Re: [Runeberg] Grekiska tecken > To: Christer Romson <christer.romson(a)privat.utfors.se> > Cc: runeberg(a)lists.lysator.liu.se > Message-ID: <Pine.LNX.4.58.0502230413230.10372(a)sara.aronsson.se> > Content-Type: TEXT/PLAIN; charset=ISO-8859-1 > > Christer Romson skrev: > >> Aproppå markering av olika textstilar. Hur markerar man kapitäler? > > Jag tror att det redan finns en HTML-markering <smallcaps> för > kapitäler, så mycket talar för att man borde använda den. Exakt > hur vi borde göra, bör styras av vad som är användbart för den > som ska använda texten i nästa steg. Och HTML bör ju vara ett > rimligt användningsområde för de texter vi scannar och > korrekturläser. Jag inbillar mig att man skriver <smallcaps>Projekt > Runeberg</smallcaps>, varvid detta alltså visas som PROJEKT RUNEBERG > där P och R är fullstora bokstäver. > > P.S. Min slutrad säger nu "fri nordisk litteratur" på finska, precis > som rubriken på vår startsida. > > > -- > Lars Aronsson (lars(a)aronsson.se) > Projekti Runeberg - vapaa pohjoismainen kirjallisuus - > http://runeberg.org/ > > > ------------------------------ > > Message: 2 > Date: Wed, 23 Feb 2005 00:34:46 -0800 > From: "Ingemar Olson" <bio2935c(a)hotmail.com> > Subject: [Runeberg] <chapter> och </chapter> > To: runeberg(a)lists.lysator.liu.se > Message-ID: <BAY13-F431A486BE2EFE4F639088C5630(a)phx.gbl> > Content-Type: text/plain; format=flowed > > Ibland händer det att artiklarna inte följer varandra så bra. > > T. ex. en artikel börjar på sidan 50, fortsätter på 51 och slutar på 53. > Texten till nästa artikel börjar på sidan 53, men det är också en bild på > hela sidan 52. Eller kanske den första artikeln har text på 50, 51, 52 och > 53, och på 52 är det också en mindre bild (alltså inte hela sidan) som hör > till artikeln som börjar på 53. > > Vad jag har gjort hittills med <chapter>-taggarna är att lägga till dem > där > texten börjar och slutar. Och om det är nån bild som inte passar mellan > början och slutet så har jag inte brytt mig om det. > > Men nu undrar jag om det finns något bättre sätt. Så att man kan se på > innehållssidan alla sidor som hör till artikeln. > > Går det??? > > Ingemar > > > > > ------------------------------ > > Message: 3 > Date: Wed, 23 Feb 2005 21:28:05 +0100 > From: Bertil Holmstr?m <bertilh(a)brikks.com> > Subject: SV: [Runeberg] Grekiska tecken > To: "'Lars Aronsson'" <lars(a)aronsson.se>, "'Christer Romson'" > <christer.romson(a)privat.utfors.se> > Cc: runeberg(a)lists.lysator.liu.se > Message-ID: <20050224095437.9D27F1B801E(a)mail.lysator.liu.se> > Content-Type: text/plain; charset="iso-8859-1" > > > > > > -----Ursprungligt meddelande----- > > Från: runeberg-bounces(a)lists.lysator.liu.se > [mailto:runeberg-bounces@lists.lysator.liu.se] För Lars Aronsson > > Skickat: den 23 februari 2005 04:19 > > Till: Christer Romson > > Kopia: runeberg(a)lists.lysator.liu.se > > Ämne: Re: [Runeberg] Grekiska tecken > > > > Jag inbillar mig att man skriver <smallcaps>Projekt > > Runeberg</smallcaps>, varvid detta alltså visas som PROJEKT RUNEBERG > > där P och R är fullstora bokstäver. > > > > Jag skriver ofta om fartyg, i en miljö där fartygsnamnet skall skrivas > just > som anges ovan: PROJEKT RUNEBERG där P och R är fullstora bokstäver, > övriga > 2 punkter mindre. Jag har provat <smallcaps>Projekt Runeberg</smallcaps> - > på min browser, Explorer, blir det bara Projekt Runeberg. > > > > Jag tvingas skriva ENKÖPING (om brödtexten har > size="3") eller TEST > > > > Någon som vet mera? > >

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Runeberg