2006-04-09 kl. 14.15 skrev Åke Broxvall:
Tabellerna är ett problem för sig, och de förekommer rikligt i dessa sammanhang. Den som gör HTML av sidorna får det besvärligt att passa ihop de olika kolumnerna. Med den font med fix bredd på bokstäverna, som erbjuds i korrigeringsrutan, kan det fås att se riktigt bra ut. Men när man kontrollerar via "Återvänd till originalsidan", där den OCR:ade utskriften återges med en proportionell font (Arial ?) så blir tabellerna snedvridna. Än värre skulle det vara på en HTML-sida med oformatterade tabeller.
Korrekt. Ibland i alla fall. Men man måste se till att det inte är den egna datorns buffertversion (även kallad cache-minne) från någon tidigare inläsning, som man tittar på. Vid kontroll av eget arbete är det alltså klokt att alltid rutintömma buffertminnet, och nyhämta det som verkligen är lagrat hos Runeberg, innan man granskar resultatet.
I min läsare (Safari) kan jag i två av Runebergs tre ramar byta stil till vilken stil jag vill bland de fonter, som finns i min dator. När jag väl kommit underfund om vilka knappar jag ska trycka på, vilket tog sin tid. (Ramen med förlagan kan jag naturligtvis inte göra något åt; den är ju — och måste så vara — vad den är.) Men jag måste ställa om de påverkansbara ramarna var och en för sig, individuellt. Vad jag inte vet är om Runeberg sväljer den av mig valda stilen, när jag spara definitivt, eller om Runeberg behåller den ursprungliga stilen men med mina rättelser. Det kan ju vara ett problem om jag använder MONACO, och händelsevis Runeberg sväljer det, och sedan någon annan, som saknar MONACO i sin dator, försöker läsa revideret med någon jokerfont. Då kanske det inte alls ser ut som det jag försökt åstadkomma. Tacksam för upplysning från någon Runebergsk system-person, som vet hur Runeberg hanterar detta.
Hur godtyckligt stilval fungerar med andra läsare än Safari har jag inte undersökt. Någon av Runeberg-delegater med annan läsare, som kan ge besked?
När det gäller tabeller är ju font med konstant breddsteg A & O. COURIER finns väl hos de flesta, men är uselt på att visa
skillnad mellan 1 (ett) och l (gement Ludvig).
Det är MONACO bättre på: 1 resp l.
(Jag har i detta e-brev försökt skriva exemplen på just det viset, men det är ju inte säkert alla mottagare av detta brev ser det på samma sätt, allt efter de font-resurser man råkar ha.) Nolla och Olof ger liknande problem:
0Oo (COURIER) resp
0Oo (MONACO).
I tabeller och ekvationer med sifferuppgifter är det ju jätteviktigt att det inte blir några missar härvidlag.
Finns det någon konstanbreddstegsstil, annan än COURIER, som vi kan ena oss om att finns tillgänglig hos alla, eller åtminstone de flesta, och sålunda kan rekommenderas vid tabellarbete?
Man skulle behöva fler styrkoder, typ XML-definitioner, för att redan från början kunna ställa upp snygga och korrekta tabeller på en HTML-sida.
Ja, som på Wikipedia, ungefär. Vad jag saknar särskilt på Runeberg är f ö funktionen "förhandsgranska", så att man bl a i tabeller kan kontrollera, att allt blir som man tänkt sig innan man sparar. Det är så mycket som kan gå fel. Att som det nu är "spara på riktigt" bara för att konstatera att något blev fel trots att det var riktigt tänkt, belastar ju Runebergs versionsminne alldeles i onödan med en massa skrot.
Nu påstås vissa runebergdokument vara UTF-8-kodade, och det tycks fungera, när man direkthämtar något tecken därifrån, men att skriva samma tecken på HTLM-språk verkar inte fungera. Att "dra" ett "rött tecken" tillhandahållet av Runeberg fungerar inte hos mig: Hela Javascriptet följer med, och jag måste radera si så där 20 oönskade tecken, innan det (åtminstone nästan) blir som jag vill. Att enligt anvisningar klicka på rött tecken för att få det att hoppa in till skrivmärket i korret fungerar inte alls hos mig. (Tidigare meddelat till Runeberg.)
Men ibland har OCR-texten lyckats med något udda tecken, t ex kursivt µ (my), som verkar gå bra att klippa/kopiera och klistra, när andra metoder misslyckats. Exempel på detta finns på en del sidor i DUPLEX. (Orkar inte leta fram en länk till exempelsida just nu.)
Åter till den aktuella kemitabellen. Liksom Ingemar Olson har jag noterat den missade fetstilen på andra raden. Icke blott det, utan desslikes syns <b> och </b> i revideret, vilket det inte borde. Förslaget att "&" spökar är möjligen en ledtråd, men jag undrar. Dels måste man ju kunna skriva det som text utan att det tolkas som programkod, dels måste det, om det nu ska föreställa programkod, åtföljas av något godkänt HTML-kommando avslutat med semikolon. Detta är inte fallet här. Hade det varit något som tillnärmelsevis hade kunnat vara en korrupt programkod, borde det resulterat i ERROR av något slag. Jag kan inte finna annat än att <b> och </b> placerats korrekt, men varför fungerar det inte? En möjlighet kunde vara att det är något fel på bråkstrecket i </b>. UTF-8 känner ju flera varianter på "lutande streck" som ser nära lika ut (Solidus, Fraction Bar, Box Diagonal etc.) Jag har några funderingar, men har inte gjort några försök, för att inte "ha sönder felet", om andra vill titta på nuvarande problemläge. Jag tycker det är viktigt att inte bara få korret rätt, utan att det kan fastställas vari knuten består.
Hos mig med Safari ser tabellen acceptabel ut med såväl COURIER som MONACO. Men ska man vara riktigt petig, så har den några skönhetsfläckar.
• En oönskad blankrad mellan post 3 och 4.
• Blanksteg kring förnamns-initial har placerats inkonsekvent, vilket gör att namnkoumnen inte är riktigt inrättad lodrätt.
• Sista posten har ett sättarfel: står c) skall vara e). Detta fel kvarstår i revideret; borde ha korrigerats mot manus.
• Sättaren har varit inkonsekvent vid postsluten: en blandning av punkt och semikolon. Detta kunde ha harmoniserats, om man nu inte ska vara fullständigt bokstavstrogen mot manus. Man kan ha olika mening härom: Ett mål är att slutprodukten ska vara sökbar. Men gör man i sökbegreppet fel på punkt eller semikolon, missar sökningen, när den borde ge träff. Å andra sidan: Gäller forskningsuppgiften att ta reda på sättares noggrannhet eller något annat grannlaga får ju inte den minsta iakttagbara skillnad kallas för urkundsförfalskning. (Eget praktikfall: Skulle en gång låta Notarius Publicus vidimera en avskrift. Han underkände p g a ett missat punkttecken!). Mitt förslag vi detta fall är:
• c) korrigeras till e) • den extra blankraden tas bort • punkt och semikolon får stå som det är • fetstilproblemet på rad 2 undersöks för att förklara varför, och sen korrigeras så att det blir rätt i slutprodukten.
Övrig synpunkt är att rubrikraderna kunde rangordnas med funktionen <h></h> (med tillämpliga argumentsiffror).
Några erfarenheter från egen kamp med tabeller
1 Det s k konstanta breddsteget fungerar inte tillsammans med exempelvis punkttecken, utropstecken, >, < med mera. Dessa tecken måste ändå finnas med i somliga tabeller, som blir snedvridna därav, trots att man läser med konstant breddsteg.
2 UTF-8 har en hel rad blanksteg av olika bredd, som man kan komplettera med för att få snygga tabeller (Hairline, Narrow Space, en-space, em-space, Quad etc) Somligt är radbrytande, annat icke. Lite lurigt att hitta dessa i exposéer av UTF-tecken, eftersom de ju inte ses som annat än just blank på skärmen. Har man otur, pekar man bara på en vakant plats i UTF-tablån. Vad som är vakant eller inte beror helt på hur pass välsorterad aktuell font är. Men låter man muspilen vila ett tag på något misstänkt osynligt tecken, så dyker det ju ofta upp en etikett någonstans, som talar om vad det handlar om. Såvida man inte har avaktiverat etikettfunktionen i datorn, förstås.
3 Om tabellen innehåller kursiveringar, fetstil e d, måste man först skapa tabellen utan dessa formateringar. När man är nöjd med resultatet sätter man som sista åtgärd in <i></i>, <b></b>, eller vad det kan vara. <sub> och <sup> räknas också till denna kategori. Då kan det i korr-läge se ut som katastrof, men vid kontroll-läsning av revideret med tolkning av all programkod, ser det oftast godtagbart ut. Men inte alltid, Bl a kan OCR ha lagt in en osynlig och svårupptäckt kod för <TAB>, omgiven av ett eller flera blanksteg. Om man uppmärksamt stegar sig igenom mellanrummen i ett blankfält, ser man ibland på skärmen att skrivmärket hoppar längre än vanligt, och då kan man radera den osynliga TAB:en och lägga dit något annat i stället. TAB:ar är elastiska inom en kolumn och kan, blandade med vanliga tecken, vara exakt ett blanksteg långt, och då är de mycket svårupptäckta. Enligt erfarenhet är OCR nyckfullt. Råtexten har ofta en ostruktuerad blandning av hårda blanksteg och elastiska tab:ar. Har man då av någon anledning ändrat antalet tecken i en kolumn kan man drabbas av diverse spratt, där boven är ett elastiskt TAB:tecken. Jag har numera som rutin att i OCR:ade tabeller rutinmässigt och hänsynslöst radera alla blanksteg och lägga till mina egna, som jag vet vad de går för. Och då väljer jag s k Hårt blanksteg ("No-breaking space") som [jag tror] HTML-iseringen respekterar utan att komprimera, även om det kommer flera i följd. Kan någon verifiera min tro?
Hur man skapar det hårda blanksteget varierar från maskin till maskin och från program till program, så var och en får leta rätt på det i sin egen datormiljö.
4 Man får se upp med radsluten. Ibland blir det ny rad med automatik alltefter den satsbredd man har råkat välja. Ibland blir det hård radbrytning p g a ett osynligt ny–rad–tecken, som inte behövs. Det skulle ha blivit radbrytning med automatik i alla fall, även utan ny–rad–tecknet. Men om satsbredden ändras, t ex p g a att annan person läser på annan dator, kan det som såg bra ut från början ändå bli fel. Sens moral: leta efter alla onödiga ny–rad–tecken och ta bort dem och låt automatiken svara för radbrytningen. Om det måste bli ny rad även vid ändrad satsbredd, sätt dit ett tvingande ny–rad–tecken. Tänk även på att i kritiska fall, så kan ett enda dubblerat blanksteg var som helst på raden stöka till radbrytningen. Detta kan ge svåra problem vid tabeller med många eller breda kolumner, där radlängden mellan marginalerna inte vill räcka till.
En kardinalpunkt: se till att det inte blir en sidbrytning eller spaltbrytning mitt i en tabell! Om det i extremfall är en så omfattande tabell att flera sidor inte kan undvikas, upprepa ett eventuellt huvud på varje ny tabellsida.
Om radlängden inte räcker till på en stående sida, skulle det i många fall kunna lösas med liggande format. Hur vrider man 90° om OCR-manus ligger i oönskat läge? Vilka regler vill Runeberg ha för hanteringen av liggande udda, eller liggande jämn sida? D v s ska fästmargen ligga upptill eller nedtill vid bokhäftning (ryggen)? Udda eller jämn sida torde inte kunna avgöras förrän vid ombrytningen av den färdig-HTML-iserade slut-versionen. men färdiga revider bör läggas i standardiserad riktning för att underlätta korrekt ombrytning. Det bör inte vridas på en höft. Vilken standardriktning önskar redaktionen?
F ö har originalet ej sällan vridit liggande sidor på ett sätt som med dagens typografi räknas som svårt fel. Man ska inte behöva vrida och vända på boken för kunna läsa liggande material på både jämn och udda sida på samma uppslag. Nu uppstår den principiella frågan: ska originalets galenskaper permanentas, eller är det tillåtet att i trots av manus kasta om vridningsriktningen på vissa sidor i den elektroniska upplagen? Två villkor bör vara uppfyllda:
• Vid läsning på datorskärmen får en liggande sida inte visas upp–och–ner • Vid utskrift av den elektroniska boken ska alla liggande sidor utan efterbearbetning lämna skrivaren i den riktning som idag anses vara typografiskt korrekt. (Jämna sidor = vänstersida i stående riktning ska ha häftrand/hålmarg nedtill; udda sidor = högersida i stående riktning ska ha häftrand/hålmarg upptill.)
5 "Lådtecken", vare sig de kommer från de vanliga ASCII- eller ANSI-samlingarna eller från UTF-8-repertoaren, fungerar inte, även om de sätts in i ett sammanhang med konstant breddsteg. En stötesten är att Runeberg tycks envisas med utökad kägel (d v s radavstånd större än teckengraden) i sina texter. Detta innebär att man inte lyckas få sammanhängande vertikallinjer. Andra UTF-8-tecken i gruppen "combining character" fungerar inte heller som förväntat. Kan ibland se bra ut i korrläge, men när man sen kontrollerar det av Runeberg lagrade resultatet Tangentbordets vertikalstreck, som fungterar perfekt i DOS, går alls icke i i Runebergs fönstermiljö, som ju ändå i princip ska vara mer avancerat än DOS. D v s, visst skrivs något på skärmen, men sammanhängande vertikalstreck blir det inte. Motsvarande horisontellt med understreck och överstreck.
Önskas att Runeberg presenterar sina OCR-korr med gradens kägel utan ökning.
Övrigt (när jag ändå är igång)
Lars Aronsson skrev i en kommentar att man funderar på något sätt att hantera ekvationer och musikaliska tecken. Till detta vill jag foga en önskan om medel att skriva kemiska strukturformler på ett vettigt sätt. Det finns små hjälpprogram som fungerar bra i Windowsmiljö tillsammans med OB-program. Hur det är i Mac-världen, vet jag inte, men det är väl inte omöjligt att något finns även för den miljön. Kan det anpassas för Runeberg? Det är inte bara i kemiska fackuppsatser strukturformler förekommer, utan det finns också i skrifter för en bredare publik. I "Ugglan" t ex.
Jag har sett att somliga korrläsare har realiserat enkla exponenter och index med hjälp av koderna <sup> och <sub>. Jag tipsar om att det i UTF-8 finns alla tecken man behöver i avdelningarna superscript och och subscript (även bokstäver, inklusive en del grekiska). Några få sifferexponenter finns redan i grunduppsättniningen av ASCII/ANSI, vilket kan komma till pass för texter, som ännu inte har hunnit bli omkodade till UTF-8: ¹, ², ³.
B L Wahlman