Runeberg February 2005

runeberg@lists.lysator.liu.se

12 participants
10 discussions

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 26 Feb '05

26 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 25 Feb '05

25 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 25 Feb '05

25 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 25 Feb '05

25 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

<chapter> och </chapter>
by Ingemar Olson 25 Feb '05

25 Feb '05

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

3 2

Romsons kapitäler
by Bo Lennart Wahlman 22 Feb '05

22 Feb '05

I enkla fall bör man kunna ersätta kapitäler med versaler i samma grad som övrig text, tycker jag. Men ibland har kapitälerna en informativ funktion alltefter sammanhanget. Se exempelvis många datorinstruktionsböcker, där kapitäler används när vanliga versaler, kursiv och understrykning inte räcker till för alla grupperingar man behöver indikera. Från egen yrkesverksamhet kan jag nämna Radio Regulations, en viktig handling som utges på flera språk av Internationella Teleunionen (ITU). Där skulle väsentliga ting bli helt galna om man inte återger kapitäler korrekt. Så småningom hamnar kanske liknande även på (nordiska) Runeberg, och till dess bör problemet vara löst på ett eller annat sätt. Typografiskt är kapitäler "versaler i förminskad grad på brödtextens kägel". Detta skulle i Runeberg möjligen kunna förenklas till "versaler i minskad grad", men det ger kanske vingligt radavstånd. Vid egna försök påverka formateringen i korr-sidans inmatningsfält lyckas jag inte göra något selektivt på enstaka ord, utan det jag försöker med påverkar hela sidan. Om det nu gått att införa <spärr> </spärr> och <sp> </sp> kunde man väl tänka sig något i still med <kap> </kap>, alternativt <ka> </ka> för att göra formateringen mindre utrymmeskrävande? Bo Lennart Wahlman

1 0

Dubbla mellanslag och dubbla blankrader
by asq 03 Feb '05

03 Feb '05

Visst söker ni väl automatiskt efter dubbla mellanslag och dubbla blankrader innan den färdiga boken läggs ut? (Som i Gutenberg projektet). Dessutom är det väl så att dubbla eller fler mellanslag ändå bara blir ett mellanslag i den färdiga HTML texten??? Det är väl ganska onödigt att sitta och ta bort dubbla mellanslag manuellt! För övrigt så är det väl också bäst att göra en så korrekt korrekturläsning från första början och inte bara indexera "hysteriskt". Det blir svårt att veta om en sida är mer eller mindre färdig - nu ser jag ett flertal hastigt "korrlästa" sidor med många fel kvar.

1 0

Dubbla mellanslag och dubbla blankrader
by ANNA-SOFIA 03 Feb '05

03 Feb '05

Hej Visst söker ni väl automatiskt efter dubbla mellanslag och dubbla blankrader innan den färdiga boken läggs ut? (Som i Gutenberg projektet). Dessutom är det väl så att dubbla eller fler mellanslag ändå bara blir ett mellanslag i den färdiga HTML texten??? Det är väl ganska onödigt att sitta och ta bort dubbla mellanslag manuellt! För övrigt så är det väl också bäst att göra en så korrekt korrekturläsning från första början och inte bara indexera "hysteriskt". Det blir svårt att veta om en sida är mer eller mindre färdig - nu ser jag ett flertal hastigt "korrlästa" sidor med många fel kvar.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Runeberg February 2005