Runeberg March 2005

runeberg@lists.lysator.liu.se

11 participants
19 discussions

Re: [Runeberg] Poaching
by Ingemar Olson 19 Mar '05

19 Mar '05

> >Ingemar, har du någon som helst grund för att uttala dig om vad jag vill >göra? Jag är en av "vi andra som korr-läser" och jag tror inte du har någon >som helst aning om huruvida jag vill "helst själv göra slut på det jag >börjat" eller inte. Jag ser gärna att andra korrläser samma verk som jag >håller på med, och jag skulle bli lätt irriterad om det visade sig att man >kastade bort en månad bara för att någon av missriktad hänsynhet väntade >för att se om jag skulle ändra något mer. > >För mig har det varit självklart att vem som helst kan korr-läsa vad som >helst när som helst på Runeberg. Om du har fått något annat intryck så kan >jag ju förstå om du är irriterad. Är det någon instruktion eller annan sida >som ger ett vilseledande intryck på den här punkten? Borde i lägga till >något stycke i korr-instruktionen om att andra kan hoppa in och redigra i >verk som man själv håller på med? > > Christer Romson Absolut, du har rätt. Det står inget om vad man kan eller inte kan. Och det är inga nyheter för mig heller. Jag visste det när jag började korr-läsa. Men i alla fall ... Förlåt om jag växlar till engelska nu (det är ju det "officiella" Runeberg språket) men jag tror inte jag kan hitta de rätta orden på svenska. Jag hoppas att ni förstår mig ändå. This has to do with why I am doing anything for Project Runeberg at all. It is a personal statement and may not apply to everyone, or anyone, else. Nonetheless, I would be surprised if I am alone. First of all let me say that the only work I have done anything with is Svenska Familj-Journalen. It's a monthly magazine - about 400 pages per year. I like reading the articles, it gives me a small measure of historical perspective of what people were thinking and doing "back then". I have no interest in novels or encyclopedias or technical manuals. There are many of those types of work available in Runeberg and if that is what you like to read and work with, then that's great. But they're not for me. Maybe I should just read the pages and not participate in the project at all? Alas, I also like the idea of making things better for those who come after me, so I "joined up". That aspect too gives me a certain satisfaction. So you see that I'm not in this just for the sake of proofreading as many pages as possible. My main reason for participating is because it gives me some pleasure and a feeling of accomplishment to do so. I don't see that anywhere in the Project goals, nor do I see how it could be. The purpose of the Project *is* to proofread as much as possible. But that is not *my* goal. If you think about it I suspect that most of you share this feeling. After all, you are all getting paid the same amount of money as I am. One of the few things that I can *see* that represents the amount of effort I have spent on this activity is that green proof-bar line. Every day I look at that green line and I say to myself: I DID THAT! I can see that it's a little longer every day. Every millimeter represents an hour of my time. I am proud of it! It's my paycheque - the only visible confirmation that I've done anything at all. It makes me happy to make that dark green line grow longer. Proof-reading a page here and a page there does not give me the same feeling of achievement. Maybe *you* don't care about seeing any confirmation of what you've done, but *I* do care. So when that green line moves without me having done anything, then it also ceases to mean anything. And there goes my payback - out the window. In Svenska Familj-Journalen there are 19 volumes. Only two of those were all green. I did those two. No one else has been interested enough to make a concerted effort to complete any of those volumes. Just me. And I was 90% of the way through a third volume. Then someone decided that they just had to jump into the line in front of me and complete the last little bit. WHY? It wasn't a coincidence that the first 90% of the line was green. It was because someone (me) was deliberately going through it from start to end. It was obvious. If *you* do nothing at all, the line will continue to grow (as I work on it) and soon the volume will be complete anyway. And the Project editors will be pleased to have another volume done. There are many thousands of pages available in the other volumes - proof-reading any one of them will also contribute to the Project. The thing is that there is nothing *special* about any of those. The only *special* pages were the ones that I hadn't got around to yet. They stood out like a sore thumb, a bunch of red and light green at the end of a long line of dark green. They were special because *I* had made them special. Not you. So let me continue. Now I am going to continue where I left off and re-proof-read the remainder of the volume anyway. I can see that it is not in fact "all ok", and I really DO want it to actually be correct. I will have to scrutinize the text just as carefully now as I do when reading a previously untouched page. But now it will not be a pleasure. There will be nothing to show me what I have accomplished. So it will just be a chore. So there you have it. You may not agree with what I have written. It is not in agreement with the official Runeberg policy, but that is how I feel about it I now consider this topic closed and do not intend to comment further. Ingemar

1 0

Poaching
by Ingemar Olson 18 Mar '05

18 Mar '05

OK, jag vet inte vad det heter på svenska. Tjuvjakt, eller något liknande. Jag hade hållit på med Svenska Familj-Journalen, 1872. Det var nästan klart med hela årgången, bara sista numret kvar. Och då måste jag resa bort ett tag. Nu när jag kommer tillbaka ser jag att någon har "hoppat in" och korr-läst resten. Och det började bara ett par dar efter jag slutade. Är jag den enda som kan lista ut att om det är en korr-stapel som är 90% grönt, så är det klart att någon "håller på" med den? Nog finns det väl många andra verk som ni kan syssla med. Titta tillbaka om en månad, och om stapeln fortfarande sitter på 90%, så fritt fram. Det spelar väl ingen roll för redaktörerna, men vi andra som korr-läser vill väl helst själva göra slut på det vi börjat. (suck) Ingemar

2 1

Re: Kursivt plustecken??
by Bo Lennart Wahlman 18 Mar '05

18 Mar '05

2005-03-17 kl. 18.38 skrev Bertil Holmström: > Nedanstående fråga tror jag intresserar dig: = = = = = = > Denna fråga ställdes nyligen av bo.lennart.wahlman(a)wah.se > > 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 Hoppsan, det bidde fel! Så här skulle den enkla ekvationen ha varit: a+b+c/(x+y)=d Och så ramlade en parentes bort. V g läs a + b — c / ( x/i> + y ) = d F'låt! B L Wahlman bo.lennart.wahlman(a)wah.se

1 0

Kursivt plustecken??
by Bertil Holmström 17 Mar '05

17 Mar '05

Hej Anders! Nedanstående fråga tror jag intresserar dig: Bakgrunden är Runebergsprojektet, ett ambitiöst projekt vid Linköpings Universitet att digitalisera nordisk litteratur däribland material med matematiska och fysikaliska ekvationer. Textsidor skannas in och grov-OCR-as i Linköping, frivilliga krafter korrekturläser och korrigerar, och ställs då inför problem som diskuteras med andra medverkande i projektet. Denna fråga ställdes nyligen av bo.lennart.wahlman(a)wah.se 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+bc/(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. Hälsningar bertilh ---------------------------------------------------- Bertil Holmström Ulveliden 15 416 74 Göteborg

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Runeberg March 2005