2005-03-18 kl. 23.11 skrev Anders Thulin:
Bertil Holmstr?m bertilh@brikks.com wrote:
Jag har ibland frågat mig om man får kursivera operatorer.
Anders Thulin har nog missuppfattat frågan och tagit den alltför generellt.
1 Det var inte Bertil Holmström som kastade handsken, utan undertecknad. Bertil H gjorde en kommentar.
2 Frågan gällde ett mycket speciellt fall, nämligen sättningsregler för EKVATIONER, och hur Runeberg-projektet vid hanteringen av revideret rent DATATEKNISKT TOLKAR korrekturläsarens syntax.
Jag ska nu försöka att utveckla problemet lite, och förhoppningsvis inte inveckla mig för mycket. (Ett gammalt talesätt: Problemet synes enkelt, men vänta bara tills jag förklarat det!)
Vid matematisk sats gäller en hel rad av konventioner beträffande antikva, kursiv, fet etc, samt var man ska ha blanksteg. Exempelvis ska en funktion såsom "sin" sättas med antikva, medan det tillhörande argumentet ska kursiveras. En variabel ska vara kursiv, men dess exponent (när sådan förekommer) ska sättas med antikva — idealt med några punkters mindre grad. O s v.
Inom Runebergprojektet har vi tillgång till en mycket begränsad verktygsarsenal vid korrekturläsningen, och därför nödgas man ta till diverse nödlösningar med de verktyg man har. Då blir det ibland klumpiga lösningar. Som jag tidigare framhållit kan en ekvationsrad på kanske 20 nedslag efter formateringen svälla flera rader, om det vill sig illa. (I Geodet finns några fall där det blev så mycket som tre rader av en, matematiskt sett, enkel ekvation. Korrekturläsaren tappar då lätt greppet av sin text, och det är mycket mödosamt — och tidsödande — att få allting rätt .
Slutprodukten i HTML-format ska ju vara så vältypograferad som möjligt, och där har korrekturläsaren möjlighet att genom välgjort arbete underlätta för en automatisk efterbehandling av revideret. Det är ju viktigt att den framtida läsaren/forskaren rätt och lätt kan tolka det han ser i HTML-versionen. Utan att behöva gå tillbala till en smetig PDF-sida. (Som, efter vad jag förstått, inte ens existerar för vissa av Runebergs verk.)
För att förenkla korrekturläsandet skulle man kunna åsidosätta diverse typografiska grundregler med syfte att öka verkningsgraden vid korrekturläsandet. D v s öka produktionen med oförändrade resurser. Det gäller ju att få kontroll över arbetsmagasinet!
Ett sätt är då att i stället för ständiga växlingar mellan <i> och </i> och <i> och </i> igen och igen i en och samma ekvation, göra en "global kursivering" inkluderande även plustecken, parenteser, bråkstreck "/" (!). Men går det för sig vid HTML-iseringen? Vilka fonter kommer att finnas i automaten? Klarar den av "kursiva plustecken"? Kommer den att skriva ett kursivt plustecken (accepteras!), eller kommer det att bli ett jokertecken, eller ett ful-tecken, ett tomrum eller alls ingenting (underkänt!)?
Det var därför jag ställde frågan, i första hand riktad till Redax, i syfte att få direktiv hur man vill ha det. I andra hand för att ringa med klockan mot (eller kanske för?) andra korr-läsare, som förr eller senare råkar på samma eller liknande fall.
Ur rent teoretiskt synpunkt får man göra allt som inte förvirrar läsaren.
Ja! Därför är det ibland saker som man INTE bör göra. Det budskap som ekvationen överbringa får inte bli desinformation. I matematikens värld räcker det inte att göra NÄSTAN rätt.
Sedan bör det också vara någon sorts nytta med det hela också: annars är det inte stor mening med det.
Ja! • T e spara tid vid korrekturläsning, öka produktionen. Och inte skapa så mycket snårskog att korrekturläsaren inte ser träden. • Samtidigt får man inte genom alltför långt driven rationalisering i tidiga produktionsled skapa problem vid efterbehandlingen av revideren. • Därför behövs en övergripande styrning av processen för att fastställa den nivå som anses bäst för projektet och med de regler som behövs för att alla i en inhomogen korrläsar-population ska göra lika. Vad är tillåtet, och vad får man inte göra? Det ska vara möjligt med flera korr-läsare av olika sidor i samma verk, utan att den framtida läsaren ser några kvalitets-skarvar i den färdiga produkten.
Så frågan är egentligen: vad skulle kursivering vara till för reell nytta för läsaren i detta fall?
Ett kursiverat plustecken (motsvarande) är inte till någon nytta för BRUKAREN av slutprodukten. Men är definitivt av nytta för KORREKTURLÄSAREN. Om den är tillåtlig. Men får inte vara SKADLIG i processer efter korrekturläsningen. Det var därför frågan ställdes.
Ur rent praktisk synpunkt känner jag inte till något fall av matematisk sats där kursiv används för elementära aritmetiska operationer.
Näe! Just det!
Det finns faktiskt en svensk bok som behandlar frågan -- den utgavs av Almquist & Wiksell på 50-talet, och skrevs av ... var det William Lansburgh? Ett ex finns (fanns) i universitetsbiblioteket i Linköping, vet jag. De bygger till mycket stor del på anglosaxisk typografi, speciellt sådan som användes av universitetstryckerierna i Storbritannien. Rekommenderas: den är i sig själv ett mycket gott exempel på att bra typografi rör sig med minimala uttryck, utan minsta onödig form.
Tack för tips! Ska höra med folkbiblioteket här hemma om de kan skaffa fram den.
Liknande begränsningar finns i vanlig sats: normalt kursiveras t.ex. inte parenteser, även om många teckensitt innehåller sådana.
Här måste jag anmäla avvikande mening. En grundregel är att skiljetecken — och dit får väl även parenteser räknas — ska anses tillhöra den text den står intill. (Tecknets verkningsområde.) Rent praktiskt blir det ofta utrymmeskonflikt, om man omger ett stycke kursiv text med antikva-parenteser. Det blir för trångt upptill och för glest nertill. Eller vice versa. Ser i bästa fall bara illa ut. I svåra fall kan tecknen t o m överlappa varandra. Lite är det avhängigt huruvida det intilliggande tecknet har stapel eller inte. Har stilen seriffer blir det särskilt svårt. Samma gäller utropstecken och frågetecken (inklusive "inverterade" sådana [¡ ¿], som förekommer i bl a spanska språket). (Det är inte säkert att mina här nyss skrivna inverterade tecken kan tolkas riktigt av alla marknadens e-post-läsare.)
Om man har en fet rubrik avslutad med punkt, ska även punkten vara fet. Är rubriken kursiv SYNS det inte, vare sig punkten är "kursiv" eller inte, så där är det egalt.
B L Wahlman bo.lennart.wahlman@wah.se
P S
F ö så verkar det finnas en "typografisk lus" hos Runeberg: I Ditt citat här överst blev det '?' i st f 'ö'. Men vid annan Runeberg-korrespondens reproduceras faktiskt det väntade ö:et.
Snabel-a:et @ gick bra här, men i andra fall får jag i stället '%40' på såväl skärm som vid utskrift. Någon annan av oss korr-läsare, vem det nu var, sade sig också ha drabbats av liknande effekter.
Inte direkt överraskande vid en salig blandning av PC och Mac i olika tappningar och Outlook/Composer/Mozilla/Opera/Mail/Firefox etc som tuti-frutti ovanpå, kryddat med lite Linux. Det indikerar vad den framtida användaren av Runeberg-projektets färdigprodukter också kan råka ut för. Det är ännu ett skäl varför man bör väga plus och minus för kursiverat plus i Runebergmaskineriet: vilka blir konsekvenserna?