Bertil Holmstr?m bertilh@brikks.com wrote:
Jag har ibland frågat mig om man får kursivera operatorer.
Ur rent teoretiskt synpunkt får man göra allt som inte förvirrar läsaren. Sedan bör det också vara någon sorts nytta med det hela också: annars är det inte stor mening med det. (Jag minns en bok av James Martin som jag tror handlade om databaser - den använde kanske 20 olika typografiska former för att uttrycka olika betydelser, och var naturligtvis helt oläslig.) Så frågan är egentligen: vad skulle kursivering vara till för reell nytta för läsaren i detta fall?
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. 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.
Liknande begränsningar finns i vanlig sats: normalt kursiveras t.ex. inte parenteser, även om många teckensitt innehåller sådana.
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?
B L Wahlman:
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 är användarens webbläsarprogram som får in html-koden och presenterar den på bildskärmen. Det är helt korrekt html att ha kursiva plustecken. Jag har svårt att tänka mig att det kan hända något värre i praktiken än att det blir ett icke-kursivt frågetecken.
Som programmerare vet jag i och för sig att det finns väldigt många sätt som ett program kan bli fel på. Man kan naturligtvis tänka sig att det någon gång funnits en webbläsare som inte kunde visa ett kursivt plustecken eller att det kommer komma en sådan någon gång i framtiden. Men det finns ingen teknisk anledning att tro att just plustecknet skulle drabbas av problem när de kursiveras.
Christer
2005-03-19 kl. 16.19 skrev Christer Romson:
B L Wahlman:
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 är användarens webbläsarprogram som får in html-koden och presenterar den på bildskärmen. Det är helt korrekt html att ha kursiva plustecken. Jag har svårt att tänka mig att det kan hända något värre i praktiken än att det blir ett icke-kursivt frågetecken.
Som programmerare vet jag i och för sig att det finns väldigt många sätt som ett program kan bli fel på. Man kan naturligtvis tänka sig att det någon gång funnits en webbläsare som inte kunde visa ett kursivt plustecken eller att det kommer komma en sådan någon gång i framtiden. Men det finns ingen teknisk anledning att tro att just plustecknet skulle drabbas av problem när de kursiveras.
Noterat. Tar det som ett stöd för att "global kursivering" av ekvationsuttryck skulle kunna vara tillåtligt.
Emellertid: I Runebergs slutprodukt får absolut ingen operator vara ersatt av "icke-kursivt frågetecken". Vis av erfarenheten från Runeberg-korrespondens där @ (tecknet till vänster ska föreställa snabel-a) kommer fram riktigt IBLAND, men stundom med surrogatet "%40", så vet jag inte om jag törs använda "global kursivering" i mitt fortsatta korr-arbete. Kan bli jobbigt att justera tillbaka efteråt, eftersom jag har detta på säkert hundratals ställen redan och bedömer att det kommer att finnas i stor mängd även i resten av Geodet. Och i somliga andra böcker desslikes.
Det skulle kännas skönt om projektledningen efter undersökning kunde ge klart besked om tummen upp, alternativt ner för bruk av "global kursivering" i ekvationer. Man vill veta mer bestämt än att det KANSKE skulle kunna gå för sig. När beslutet väl är fattat, bör instruktioner om sanktionerat förfarande inarbetas i anvisningarna för korrekturläsning.
För undvikande av missförstånd påpekas att frågan gäller inte bara plustecknet, utan generellt för alla operatorer i algebraiska uttryck. Kursiverat rottecken? Kursiverad exponent?
B L Wahlman bo.lennart.wahlman@wah.se
Bo Lennart Wahlman skrev:
Noterat. Tar det som ett stöd för att "global kursivering" av ekvationsuttryck skulle kunna vara tillåtligt.
Jag har väntat med att lägga mig i den här debatten eftersom jag inte tycker tiden är mogen att lämna något slutgiltigt svar. Jag inser att det är jobbigt att kursivera varje "x" och "y" för sig i ekvationerna. Men är "global kursivering" det enda alternativet? Det kanske finns någon ännu smidigare lösning än dessa två som vi diskuterar just nu? Vi är ju inte de första som försöker märka upp matematiska formler. Wikipedia har ju ett sätt att markera <math> och </math> runt sina ekvationer. Jag har inte lärt mig exakt hur det fungerar, men det kanske vore något även för Projekt Runeberg att satsa på? En bra ansats är ofta att fråga sig: Vad ska vi med det här till egentligen? Varför sitter vi och korrekturläser en bok full av matematiska formler? Vad tänker vi använda den till? Ska vi göra texten sökbar? Ska vi göra snygga utskrifter? Ska vi få något som lätt går att klippa och klistra till en Wikipedia-artikel eller en skoluppsats?
Ärligt talat, så scannade jag nog "Geodetisk mätningskunskap" mest för de fina bilderna på gamla mätinstrument. :-) Att boken också råkade vara full av ekvationer, var inget jag fäste mig vid. Men vi har ju många texter som är fulla av ekvationer. Även Nordisk familjebok och Salmonsens konversationsleksikon. För att inte tala om Teknisk Tidskrift.
Emellertid: I Runebergs slutprodukt får absolut ingen operator vara ersatt av "icke-kursivt frågetecken". Vis av erfarenheten från Runeberg-korrespondens där @ (tecknet till vänster ska föreställa snabel-a) kommer fram riktigt IBLAND, men stundom med surrogatet "%40", så vet jag inte om jag törs använda "global kursivering" i mitt fortsatta korr-arbete.
Ursäkta, men när råkade du ut för det här med "%40"? Jag hoppas att du inte har intrycket att vi skulle ha för vana att slarva bort tecken och ha sönder texter.
Hej!
2005-03-26 kl. 07.41 skrev Lars Aronsson:
Bo Lennart Wahlman skrev:
Noterat. Tar det som ett stöd för att "global kursivering" av ekvationsuttryck skulle kunna vara tillåtligt.
Jag har väntat med att lägga mig i den här debatten eftersom jag inte tycker tiden är mogen att lämna något slutgiltigt svar. Jag inser att det är jobbigt att kursivera varje "x" och "y" för sig i ekvationerna. Men är "global kursivering" det enda alternativet? Det kanske finns någon ännu smidigare lösning än dessa två som vi diskuterar just nu? Vi är ju inte de första som försöker märka upp matematiska formler. Wikipedia har ju ett sätt att markera <math> och </math> runt sina ekvationer. Jag har inte lärt mig exakt hur det fungerar, men det kanske vore något även för Projekt Runeberg att satsa på? En bra ansats är ofta att fråga sig: Vad ska vi med det här till egentligen? Varför sitter vi och korrekturläser en bok full av matematiska formler? Vad tänker vi använda den till? Ska vi göra texten sökbar? Ska vi göra snygga utskrifter? Ska vi få något som lätt går att klippa och klistra till en Wikipedia-artikel eller en skoluppsats?
Simpla uttryck som exempelfallet borde väl räcka med <MATH>...</MATH>? Synd att inte TeX stödjer Unicode, för man kommer egentligen ganska långt med Unicode! (Så länge det inte gäller matriser och tabeller.) Men TeX har ju enkla syntax för sån't... (∫ → \int, ∑→ \sum, etc.)
MathML är intressant, men jag tror det mest lönsammaste är TeX.
/Roger
P.S. Hoppas ni har Unicode installerat! D.S.
-
Anders Thulin -
Bo Lennart Wahlman -
Christer Romson -
Lars Aronsson -
Roger Persson