Thomas Gartz

Transkript

1 Thomas Gartz Kodningspraxis för Zacharias Topelius Skrifter A INLEDNING... 2 A.1 KODSPRÅKEN XML OCH TEI... 2 A.2 AUTOMATISKT OCH MANUELLT... 6 A.3 XML COPY EDITOR... 8 A.4 FILSTRUKTURER B TEXTETABLERING B.1 ALLMÄNT B.2 GRAFISKA MARKERINGAR B.3 ENSKILDA TECKEN B.4 UTGIVARENS ÄNDRINGAR C MANUSKRIPT C.1 ALLMÄNT C.2 HÄNDER OCH PENNOR C.3 ÄNDRINGAR D VARIANTER D.1 IDENTIFIERING (JUXTA) D.2 KATEGORISERING OCH KODNINGSMETOD D.3 AVGRÄNSNING E OMARKERADE TEXTINSLAG E.1 NAMNKODNING E.2 FRÄMMANDE SPRÅK F KOMMENTARER F.1 PUNKTKOMMENTARER F.2 PERSONUPPGIFTER G GENRESPECIFIKT G.1 PROSA G.2 LYRIK G.3 BREV G.4 DRAMATIK G.5 DAGBÖCKER G.6 FÖRELÄSNINGAR H FÖRTECKNINGAR H.1 ELEMENT, ATTRIBUT OCH VÄRDEN H.2 SPECIALTECKEN (ENTITETER) H.3 TEI-MODULER

2 A Inledning A.1 Kodspråken XML och TEI Uppdaterad Vår kodning har sin utgångspunkt i det s.k. Text Encoding Initiative, förkortat TEI. Dess senaste version, benämnd P5, kan studeras på nätet (1350 sidor, finns på adressen TEI utgör ändå endast en yttre ram för vår kodningspraxis: det ges ofta flera alternativ, vi måste fastslå vad vi kodar och vad vi inte kodar, och i vilka kategorier vi indelar varianter, kommentarer m.m. Det är ytterst viktigt att alla alltid följer exakt samma kodningspraxis, annars uppstår det sedan problem vid visning, maskinell sökning och framställning av böcker. All ny kodning som tas i bruk bör därför införas i denna kodningsmanual. TEI består av riktlinjer för textkodning inom ramen för det mer generella kodspråket XML (extensible Markup Language). XML-kodningen har sin utgångspunkt i s.k. taggar (ex: <p>) som ofta bör efterföljas av skilda s.k. sluttaggar (ex: </p>). Mellan (start)taggen och sluttaggen finns den text som man vill markera med taggen ifråga. Denna helhet t.ex. <p>z. Topelius</p> går under benämningen element. Men det förekommer också s.k. tomma element som inte omsluter någon text. De efterföljs inte av någon skild sluttagg, utan avslutas inne i starttaggen med ett snedstreck (ex. <lb/>). I taggen <p rend="noindent"> är p som vanligen står för textstycke det s.k. elementnamnet. Ofta används emellertid den kortare termen element också då enbart elementnamnet (dvs. elementtypen) avses. I XML kan (eller måste) man definiera egna element, vilket inte är möjligt i HTML (som används för kodning av webbsidor) där det finns en uppsättning färdiga elementnamn. rend är ett s.k. attribut och noindent är ett attributvärde. Ett element kan också sakna attribut, eller ha flera attribut (ordningsföljden har ingen betydelse, men inför gärna attributen i samma följd som i exemplen i denna manual). När ett attribut används måste det alltid tilldelas ett värde som alltid bör omges av citattecken (även då det är fråga om numeriska värden såsom siffror, procenttal eller färgkoder). Taggen i exemplet ovan placeras i början av ett textstycke, och efterföljs i slutet av stycket av sluttaggen </p>. Taggen <p> står i HTML alltid för textstycke, men i XML kan samma tagg användas för att markera precis vad som helst. Inom ramen för TEI är det ändå färdigt definierat att <p> står för textstycke (och är en förkortning av paragraph ). Däremot tas det i TEIriktlinjerna inte ställning till om och i så fall hur man i kodningen skall registrera om ett stycke är indraget eller inte. Ifall man inte anser det vara relevant att återge vilka textstycken som är indragna i originalet så kan man i TEI koda dem alla med enbart <p>taggar (standardiserade indrag kan införas i samband med visningen utan att de behöver kodas). I vår kodningspraxis skiljer vi emellertid (som regel) mellan indragna och ickeindragna stycken. De sistnämnda kodas <p rend="noindent"> medan vi för de indragna 2

3 styckenas del använder oss av ett s.k. förvalt värde ( default value ). Det innebär att vi inte kodar t.ex. <p rend="indent">, utan enbart <p> står i vår kodning för indraget stycke. 1 I detta dokument återges alla taggar med fetstil och i indigoblå färg, med undantag för attributen som är rödfärgade. Texten som markeras av taggarna återges i grönt. Färgerna och fetstilen har ingen annan betydelse än att de gör instruktionerna mer lättlästa. XML skiljer emellertid på versaler ( stora bokstäver ) och gemener ( små bokstäver ) så i detta hänseende bör man vara noga med att följa skrivningen i instruktionerna. Som regel används gemener i kodningen, versaler förekommer t.ex. i hexadecimala nummer och i elementnamn, attribut samt attributvärden som består av två sammanskrivna ord (<placename>, spanto, "noborder"). Observera också att taggarna måste öppnas och stängas i en given ordningsföljd, dvs. så att den först öppnade taggen stängs sist och den senast öppnade taggen stängs först: Ex: <p><hi>hertiginnan af Finland.</hi></p> Elementen kan alltså inte överlappa varandra. Däremot kan de vara inordnade i ett hierarkiskt mönster. En dikt kan i XML t.ex. kodas i ett <poem>-element som kan vara indelat i <stanza>element (för strofer) och dessa kan i sin tur indelas i <line>-element för enskilda versrader (observera att dessa elementnamn endast utgör exempel: vi använder dem inte eftersom de inte är giltiga inom ramen för TEI). Utgående från hur elementen förhåller sig till varandra betecknas de som parent, child och sibling (syskonelement). Man kan också i ett s.k. valideringsschema fastslå t.ex. att varje <poem>-element måste innesluta minst ett <stanza>-element, och att varje <stanza> måste innehålla minst en <line>. Därtill kan man t.ex. ange att stavningen <Stanza> inte är tillåten och att varje <poem>-element också måste innesluta ett <heading>-element med diktens titel. Med hjälp av ett sådant schema kan man sedan granska att ett dokument är giltigt, dvs. fyller de uppställda kraven. XML/TEI-kodningen innnehåller ingen information om hur texten ska visas, utan det styrs av skilda s.k. stilmallar (eng. style sheets ). Texten kan sedan gestaltas på otaliga sätt, och allt som har kodats kan också beaktas vid visningen. Med attributet rend kan man t.ex. registrera att ett ord är spärrat i originalet, men i stilmallarna kan man sedan välja att ersätta spärrningen med kursivering. Webbläsare kan visa XML-filer också utan att de är knutna till en stilmall, men i så fall visas också kodningen som vanlig text. Filerna måste vara (kodningstekniskt) helt felfria, annars visas de inte alls. Redigeringsprogram som är avsedda för XML kan automatiskt granska att dokumentet är välformat ( well-formed ) dvs. inte innehåller något som strider mot de grundläggande reglerna för XML-kodning. Om man kopplar ett valideringsschema (eller ett s.k. DTD som fyller samma funktion) till sin XML-fil kan redigeringsprogrammet dessutom kontrollera att dokumentet på varje punkt är förenligt med de krav som man själv ställer, t.ex. att elementet <p> är tillåtet men inte elementet <P>. Detta går under benämningen validering. 1 Avvikelser från detta anges i de genrespecifika avsnitten. 3

4 I redigeringsprogrammets inställningar bör man välja synliga blanksteg ( white space visible ). De kan också gärna synliggöras i ordbehandlaren vid studium av dessa instruktioner. Blanksteg införs aldrig inne i en tagg, utan före och efter taggen, förutsatt att ett eller flera ord markeras i sin helhet. Ex. 1: Författaren <hi>zacharias Topelius</hi> föddes år Han... Ex. 2: År 1818 föddes författaren <hi>zacharias Topelius</hi>. Han... I exempel 2 införs alltså inget mellanslag efter sluttaggen, eftersom det i texten inte ska finnas något blanksteg mellan Topelius och den avslutande punkten. (Taggen <hi> används för grafiska markeringar.) Ex. 3: Författaren <hi>z</hi>acharias <hi>t</hi>opelius... Blanksteg bör alltså i exemplet införas efter Författaren och efter acharias, men inte före opelius. Blanksteg vid radbrytning Det är skäl att vara särskilt uppmärksam med blanksteg på de textställen där raden bryts i redigeringsprogrammet. En radbrytning står i XML-kodningen för blanksteg, förutsatt att det är fråga om en egentlig radbrytning som införts med enter-tangenten, och som innebär att raderna har skilda nummer. Men man kan också ställa in XML-redigeraren så att radlängden anpassas efter utrymmet på skärmen. Dessa tillfälliga radbrytningar är inte betydelsebärande, och att det i kodningsteknisk mening är fråga om en och samma rad framgår av att de två (eller flera) visningsraderna har samma nummer. Flera på varandra följande blanksteg kan automatiskt reduceras till ett enda blanksteg. Om t.ex. ett fristående ord har strukits i ett manuskript kan det därför kodas som i följande exempel: Ex. 4: Författaren <del>zacharias</del> Topelius Eftersom det strukna ordet inte syns vid visning av den slutliga texten skulle denna kodning alltså utan blankstegsreduktion resultera i dubbla blanksteg mellan de återstående orden. I de specialfall då det skall finnas flera blanksteg i texten bör det därför anges på annat sätt (beroende på sammanhanget med det tomma elementet <space/> eller med s.k. entitetsreferenser). Inte heller tecken som har en särskild betydelse i XML kan införas som sådana då de ingår i själva texten, utan de bör ersättas med entitetsreferenser (ex: > anges med >). Specialtecken kan som regel införas som sådana i kodningen (de hittas under symbol eller motsvarande i XML-redigerarens rullgardinsmeny). Endast en del mycket ovanliga tecken måste anges med entitetsreferenser, det gäller t.ex. ovanliga bråktal och arabiska bokstäver. 4

5 För att möjliggöra länkning (till en databas, eller mellan textställen i samma fil/ skilda filer) kan enskilda element förses med s.k. id:n 2. Ett id måste börja med en bokstav men kan också bestå av siffror, och det bör vara unikt för hela XML-filen. Det får alltså inte förekomma ett identiskt id ens i en annan elementtyp. Därför är det skäl att förse olika slags id:n med skilda prefix: ifråga om fotnoter som tillhör grundtexten används t.ex. prefixet ftn, och ifråga om utgivarkommentarer används prefixet en ( editorial note ). Prefixet efterföljs i dom flesta fall av en löpande numrering som börjar med 1. Detta för att det inte skall bli onödigt svårt att hålla reda på och granska id:na, tekniskt sett har ordningsföljden ingen betydelse, ftn5 kan efterföljas av ftn3. Om man vill införa en utgivarkommentar till mellan en3 och en4 kan man använda en3b. Ex: <note id="ftn1" n="1" place="foot" anchored="true">[filens första fotnot]</note> Ett id består alltså av ett attribut och ett attributvärde (som anges inom citattecken). Ett id är inte avsett för visning, utan fotnotens synliga nummer anges i n-attributet. En del id:n införs manuellt i filerna, medan id:n för länkning av personnamn och ortnamn införs med hjälp ett datorprogram som utarbetats enkom för detta ändamål (Mikael Norrgårds TEI Name Selector ). Att varje manuellt infört id är unikt kan man granska genom att göra en sökning på t.ex. id=ftn och gå igenom förekomsterna. Kodningstekniska kommentarer kan införas var som helst i XML-filerna. De skrivs in i taggar som ser ut på följande sätt: <!--[kommentar]-->. De kodningstekniska kommentarerna bör färgas grå i XML-redigeraren, 3 ifall så inte sker har kommentaren ifråga inte införts på rätt sätt. Kommentarer av det här slaget är främst till för redaktionellt bruk, och kan eventuellt avlägsnas i något skede. Men de kan ändå också riktas till de (eventuella) användare som studerar själva de kodade filerna. I kommentarerna kan man till exempel ange att man är osäker på om man har kodat det aktuella textstället korrekt. Man kan också utnyttja de grå kommentarerna till att föra kollationeringsprotokoll inne i XML-filerna, och t.ex. ange att <!--LaM ändrat "och" till "ock"--> genast efter textstället ifråga. En pedagogisk och lättbegriplig nybörjarguide i XML finns på adressen En webbkurs i TEI-kodningens grunder finns på I slutet av denna manual finns en förteckning över de elementoch attributkombinationer (samt attributvärden) som är tillåtna i vår kodningspraxis. Förteckningen är avsedd att underlätta uppgörandet av stilmallar och valideringsscheman, men också att fungera som en slags snabbguide. Förutsatt att man först tar del av de egentliga kodningsinstruktionerna kan man sedan i elementförteckningen behändigt kolla upp t.ex. hur ett attributvärde skall skrivas, eller försäkra sig om att en viss kombination av element och attribut faktiskt är tillåten. 2 Vi använder oss av kortformen id: enligt de senaste TEI-riktlinjerna (P5) borde attributet skrivas xml:id. 3 Ifall man använder ett annat program än XML Copy Editor kan kommentarerna ha en annan färg (i Oxygen är de gröna). Eftersom åtminstone forskare kommer att få tillgång till XML-filerna så kan man i samband med granskningar eller senare kodningsomgångar eventuellt avlägsna en del sådana grå kommentarer som enbart är avsedda för redaktionellt bruk. Grå kommentarer som lämnas kvar i filerna bör vara någorlunda välformulerade. 5

6 A.2 Automatiskt och manuellt Uppdaterad Förutsatt att det är fråga om en tryckt grundtext så inleds det praktiska arbetet med att texten skannas. Genom själva skanningen åstadkoms endast elektroniska faksimil av textsidorna. Dessa faksimil utgör alltså bilder i datatekniskt hänseende, och de måste sedan omvandlas till text genom s.k. OCR-behandling ( Optical Character Recognition ). Detta arbetsmoment resulterar i sin tur i en s.k. råtext, som alltid innehåller en del teckentolkningsfel (numera dock vanligen bara ett eller två små fel per sida, förutsatt att skanningen och OCR-behandlingen har genomförts på ett professionellt sätt). Råtexten måste alltså alltid granskas manuellt, dvs. kollationeras mot originalet. Skanningen och OCR-behandlingen utförs inte inom redaktionen, utan av en utomstående specialist. I samband med OCR-behandlingen förses texten automatiskt med en grundläggande TEIkodning. Den automatiska kodningen omfattar allt som krävs för att texten skall kunna gestaltas på samma sätt som i originalet. Det här innebär kodning för rubriker, styckeindelning, paginering, (fot)noter och grafiska markeringar som t.ex. kursiveringar. Tack vare ett s.k. TEI-filter kan textfilerna ändå kollationeras i en vanlig ordbehandlare (utan att kodningen syns). TEI-filtret fungerar i två riktningar: det konverterar först de automatiskt kodade filerna till OpenOffice.org:s filformat (.odt ), och sedan när texten har kollationerats färdigt (två gånger) konverterar det tillbaka till TEI-kodning. 4 I samband med kollationeringen i ordbehandlaren korrigeras förstås främst teckentolkningsfel, men också om t.ex. en styckeindelning har fallit bort så kan den införas i form av en s.k. mall. Styckeindelningen (mallen) i ordbehandlaren översätts sedan till kodning av TEI-filtret. Mallarna utgör alltså ordbehandlarens motsvarighet till kodningen, och det innebär att om t.ex. 55 i TEI-filen är kodat som ett sidnummer, så syns det i ordbehandlaren i form av en rödfärgad bakgrund. Det förekommer att det saknas kodning för något enskilt sidnummer i råtexten, och i sådana fall kan man alltså införa den i ordbehandlaren i form av en mall (en character style eller en paragraph style, beroende på om sidnumret finns inne i ett textstycke, eller mellan två stycken). Det syns alltså i ordbehandlaren om det finns direkta fel i den automatiska kodningen. Det kan gälla blanksteg före och efter pagineringskodning (eller att den helt saknas), kodningen för styckeindelning eller -indrag eller att (kodning för) enstaka styckeindelningar eller att betydelsebärande ornament inte är återgivna i råtexten. Skilda instruktioner har utarbetats för kollationeringsmomentet ( Kollationering med OpenOffice.org, T. Gartz , 18 s., pdf-fil). Efter kollationeringsskedet kvarstår (förhoppningsvis) inga teckentolkningsfel i den automatiskt etablerade kodningen. Originalets sättnings- och tryckfel korrigeras däremot först i kodningen. De förtecknas emellertid i samband med kollationeringen, i likhet med alla suspekta textställen (ifall t.ex. ett ord verkar saknas i originalet). En del ovanliga 4 Observera att TEI-filtret endast fungerar med OpenOffice.org 2, inte med den nyaste versionen OpenOffice.org 3. 6

7 specialtecken och bråktal måste också införas i samband med den manuella kodningen. Därtill kan kodningen som genererats av TEI-filtret i många fall vara onödigt fragmentarisk, dvs. svårläst till följd av att t.ex. kursiveringen av ett uttryck har kodats ord för ord. Men även om textfilerna formellt sett är TEI-kodade så är det i praktiken snarast frågan om en kodning på HTML-nivå. Det innebär att textfilerna enbart har försetts med en kodning som registrerar hur texten har gestaltats i originalet. Kännetecknade för XML och TEI-kodning är att man inte enbart kodar t.ex. att ett ord är kursiverat, utan om möjligt också varför det har kursiverats (betoning, främmande språk, namn etc.). Sådan semantisk kodning måste självfallet införas manuellt. Förutom att grafiska markeringar kodas på ett mer avancerat sätt, så kodar man i TEI vanligen också en del sådana textinslag som inte har framhävts i originalet. Det kan gälla t.ex. olika slags namn eller inslag på främmande språk. Kodningen av omarkerade textinslag fungerar som en grundkodning som möjliggör införande av länkning. Men den kan också utnyttjas för framhävande av olika slags textinslag med någon lämplig bakgrundsfärg, för inomredaktionella ändamål (t.ex. genererande av listor med inslag på grekiska) och av sökmotorer som utnyttjar XML-kodning. TEI:s mer avancerade kodning av grafiskt markerade textinslag tjänar samma syften som kodningen av omarkerade inslag, men innebär därtill att man vid visning kan välja att t.ex. ersätta spärrning med kursivering endast i vissa fall. Den manuella kodningen behövs också för allt som utgivarna tillför texterna, och för att registrera alla ingrepp som utgivarna gör i texten. Tryckfel kan förstås korrigeras också utan kodning, men TEI-kodningen möjliggör att man kan registrera var utgivarna har gjort ingrepp i texten, och hur textstället ifråga ser ut i originalet. I den mån texter normaliseras registreras också den ursprungliga ordalydelsen. 5 Den manuella kodningen sker vanligen i en s.k. XML-redigerare. Vi använder oss främst av XML Copy Editor, ett gratisprogram av open source -typ. Det är ett mycket enkelt och användarvänligt program, men det har ändå alla de egenskaper som behövs för införandet av kodning. En annan redigerare som ofta används för TEI-kodning heter Oxygen, det är ett mer avancerat (kommersiellt) program. Inte heller den kodning som införs manuellt i XML-redigeraren behöver i någon större utsträckning skrivas in för hand. I redigeraren finns nämligen en elementmeny, och att införa t.ex. namnkodning är därför nästan lika lätt som att kursivera ett ord i en ordbehandlare. Därtill blir en attributmeny synlig då man klickar på det ställe där attributet skall införas. Införandet av attributvärden fungerar på samma sätt. Endast i en del undantagsfall måste kodning skrivas in för hand, det kan gälla t.ex. ovanliga specialtecken som måste införas i form av kodning (s.k. entitetsreferenser) eller olika slags id:n. Vilka element, attribut och värden som ingår i menyerna bestäms av det valideringsschema som knyts till filen (på de första kodraderna, före själva TEI-kodningen 5 Detta med undantag för små konsekvensändringar (som enbart markeras med <reg>-taggar). 7

8 börjar). 6 Det ingår omkring 500 element i TEI, men i menyn syns alltså endast sådana element som enligt vår kodningspraxis får införas på det aktuella textstället. Om grundtexten är ett manuskript måste däremot själva texten skrivas in på datorn för hand, det samma gäller förstås också för alla andra manuskript som transkriberas. Manuskripten kan skrivas in i en ordbehandlare, och automatiskt förses med den mest elementära kodningen vid konvertering till TEI. Alternativt kan de skrivas ut direkt i XMLredigeraren, i det fallet kan kodandet underlättas av s.k. startmallar. De innehåller den kodning som finns i alla texter av en viss typ, t.ex. brev eller diktmanuskript, främst är det fråga om kodning som bör finnas i början av textfilerna. id:n som möjliggör länkning av personnamn (och eventuellt ortnamn) behöver inte införas helt manuellt, utan de införs halvautomatiskt med programmet TEI Name Selector. Programmet har skräddarsytts för vår kodningspraxis av Mikael Norrgård. Det underlättar radikalt införandet av id:n. När man öppnar en TEI-fil i programmet dyker det upp en lång förteckning över t.ex. de namn på personer som förekommer i texten. I en annan kolumn visas det sammanhang (ett par textrader) i vilket namnet förekommer, och i en tredje kolumn visas de personposter som redan är införda i databasen. Ifall den person som ett namn refererar till redan ingår i persondatabasen så krävs det bara ett par klickningar med musen för att namnförekomsten skall förses med ett för personen unikt id. I de fall då det visar sig att personen ifråga ännu inte har införts i databasen kan man lägga till en post i databasen (denna funktion är alltså integrerad i TEI Name Selector). Posten förses automatiskt med ett unikt id kodaren behöver alltså aldrig själv hålla reda på vilka id:n som redan har tagits i bruk. A.3 XML Copy Editor Uppdaterad Medan man kodar en textfil i XML Copy Editor-programmet kan man genom en enkel klickning på en blå bocksymbol uppe i verktygsraden kontrollera att kodningen är wellformed, dvs. att den svarar mot de mest elementära och allmänna kraven på en XMLkodad textfil. Om man därtill har knutit ett valideringsschema till filen kan man genom att klicka på en grön bocksymbol (bredvid den blå) granska inte enbart att kodningen är förenlig med TEI, utan också att den är i enlighet med vår tillämpning av kodspråket ifråga. Version 1.2 som utkom hösten 2008 möjliggör dessutom s.k. bakgrundsvalidering ( validate-as-you-type ). I denna version har också en del programmeringsfel åtgärdats, vilket innebär att det är skäl att uppdatera till den nya versionen ifall man har version 1.1 installerad. Programmet kan laddas ner gratis på adressen: I den mån man skriver in kodning för hand märker man ofta genast om man skrivit fel. Detta tack vare att programmet registrerar vilka inslag i textfilen som utgör kodning av 6 I XML Copy Editor styrs menyerna för attribut och attributvärden emellertid inte av valideringsschemat, utan varje attribut eller värde måste först skrivas in en gång. 8

9 olika slag, och visar dem olika i olika färger. Elementnamnen färgas blå och attribut röda. Dessutom visas entitetsreferenser i rödfärgad fetstil, och redaktionella kommentarer färgas grå. 7 Ifall t.ex. kodningen för kommentaren inte införs korrekt framgår det tydligt i och med att den mot förväntan inte färgas grå. Färgerna i redigeringsprogrammet gör också filerna mer lättlästa, men någon annan funktion har de inte. Osynlig fil? I samband med att man öppnar en ny fil i XML Copy Editor kan det förekomma att endast ett par rader är synliga. Då kan man kolla om kvadraten uppe till vänster innehåller ett plustecken: om så är fallet klickar man på den, tecknet ersätts av ett minus, och TEI-filen blir sannolikt synlig i sin helhet. Alternativt kan man välja Unfold tags som hittas under View -rubriken i rullgardinsmenyn. Om det här inte hjälper kan man bocka för Wrap Words som också finns under View. Det är i vilket fall som helst skäl att välja wrap words när man öppnar en ny fil i redigeringsprogrammet. Detta eftersom det innebär att radlängden anpassas efter utrymmet på skärmen (dessa tillfälliga radbrytningar är som framgått inte betydelsebärande). I de fall då man transkriberar manuskript direkt i redigeringsprogrammet används alltså vanligen en startfil. Denna kan i och för sig sparas och öppnas som vilken fil som helst, men då måste man komma ihåg att ändra filnamnet före man sparar filen efter att ha infört kodning eller text som hänför sig till en enskild text. Ett bättre sätt är att göra startfilerna till s.k. templates. Det sker genom att man helt enkelt sparar filerna i rätt mapp: Program/ XML Copy Editor/ templates/ [filnamn].xml. Efter det dyker startfilen upp som ett dokumenttypsalternativ i samband med att man skapar en ny fil (dvs. klickar på New som hittas under File -rubriken i rullgardinsmenyn). Text som skall kodas med hjälp av elementmenyn måste först markeras, och det går till på samma sätt som i en ordbehandlare. Text kan alltså markeras antingen med tangentbordet (shift + piltangenter) eller med musen. Observera att enskilda ord behändigt kan markeras genom att man dubbelklickar på musen. Efter att texten har markerats införs önskat kodningselement genom en dubbelklickning i elementmenyn. Elementnamn som ingår i valideringsschemat är synliga endast då markören finns på ett textställe där elementet enligt vår kodningspraxis får införas. Observera också att kodningsmenyerna kan flyttas till vänstra kanten av skärmen. Om något element saknas i menyn till följd av att valideringsschemat är ofullständigt eller inte har uppdaterats behöver man skriva in det för hand endast en gång per textfil. Efter att man infört elementet ifråga klickar man på save (diskettsymbolen) och därefter väljer man Reload som hittas under File -rubriken i rullgardinsmenyn. Elementnamnet dyker då upp i kodningsmenyn. Ifall man vill införa attribut så aktiverar man markören inne i starttaggen. En attributmeny dyker då upp intill textstället ifråga, och önskat attribut kan införas genom en dubbelklickning (eller med piltangenter och enter). Dessa 7 Elementnamnen, attributen, entitetsreferenserna och de redaktionella kommentarerna är färgade på motsvarande sätt i denna manual. Attributvärdena är däremot färgade med blått i manualen trots att de är svarta i XML Copy Editor. 9

10 menyer styrs inte av valideringsschemat, utan endast attribut och värden som tidigare har använts (i samma fil) syns i menyerna. För att attribut och värden som använts under samma kodningssession ska bli synliga krävs att man sparar filen och klickar på Reload. Innan det manuella kodandet inleds är det ifråga om stora textfiler ändamålsenligt att kartlägga vilka namn som är frekvent förekommande i texten. Dessa kan nämligen kodas halvautomatiskt med hjälp av programmets Find & Replace-funktion. Namnet införs i Findrutan, och i Replace-rutan placeras det innanför namnkodningstaggar. Sedan behöver man bara klicka på Find next och Replace. Därefter upprepas proceduren för ordets genitivform. För att undvika ovidkommande träffar är det skäl att ha match case förkryssat (däremot fungerar det inte så bra att använda blanksteg före namnen i Findoch Replace-rutorna, detta eftersom det kan finnas automatiskt införd kodning intill namnen). Replace All -funktionen (eller Global Replace ) kan emellertid inte användas, eftersom det skulle medföra att genitivändelserna blev utanför kodningstaggarna. XML Copy Editor stöder reguljära uttryck (regular expressions, regex), vilket eventuellt kunde utnyttjas för verkställandet av mer avancerade substitueringar. Förutsatt att en stilmall har knutits till textfilen ifråga (på de översta kodningsraderna) kan man testvisa filen (i webbläsaren) genom att klicka på jordklotssymbolen i redigeringsprogrammets verktygsrad. Längst till höger i samma verktygsrad finns en kedjesymbol. Med den kan man välja att låsa kodningen, så att man endast kan göra ingrepp i själva texten. Det har förekommit att kodningslåset kopplats på oavsiktligt. Om man avser att skriva en tagg (ett större än - eller ett mindre än -tecken) och en entitetsreferens (< eller >) istället dyker upp på skärmen så är det kodningslåset som har aktiverats. Trots att vi använder ett ovanligt enkelt redigeringsprogram finns det en hel del inställningsmöjligheter i rullgardinsmenyerna. Under rubriken View kan man alltså välja wrap words så att radlängden anpassas efter skärmen, och i samma meny kan man välja Hide Tags and Attributes. Det innebär att endast själva texten är synlig, men observera att enstaka blanksteg kan saknas (eller dubbleras) trots att kodningen är helt korrekt. Kodningens innebörd beaktas inte i den här visningen. Under View kan man också ändra på textstorleken. Observera att man kan klicka på increase eller decrease flera gånger för att ytterligare förstora eller förminska textstorleken. De flesta specialtecknen kan införas som sådana (en del ovanliga tecken måste anges som entitetsreferenser och skrivas in för hand). Under Insert -rubriken väljer man Symbol, och då dyker det upp en symbolruta på skärmen. I den bör man välja Unicode nere till höger (istället för förhandsinställningen ASCII ). Sedan kan man söka efter rätt tecken i de olika kategorierna ( subsets ). Man kan ofta utgående från deras namn sluta sig till var ett visst tecken kan tänkas finnas, ofta anges det också i förteckningen över specialtecken (i den här manualen). Observera att det ofta finns flera tecken som ser ungefär likadana ut, och att det därför kan vara skäl att utgående från entiteten kontrollera att tecknet faktiskt är det som vi använder t.ex. som tankstreck eller citattecken. För att kodningen och texten ska visas på ett mindre kompakt och mera lättläst sätt kan man välja pretty-print som hittas under XML -rubriken. Kodningsraderna visas då också 10

11 med olika stora indrag beroende på var de olika elementen befinner sig i XML-filens hierarki. Starttaggar och sluttaggar som finns på olika rader kopplas till varandra med vertikala linjer (förutsatt att man inte inaktiverat indentation guides i Options / Editor, som hittas under Tools -rubriken i rullgardinsmenyn). Indragen är enbart till för att göra filerna mera lättlästa, de är inte betydelsebärande och man behöver inte införa eller modifiera indrag manuellt. OBS: Pretty-print -funktionen får endast användas innan man inleder den manuella genomgången av en fil, ifall det föreligger ett behov av att snygga till en automatiskt genererad kodning. Det har nämligen visat sig att funktionen kan fördela kodningen på olika rader på ett sådant sätt att det ger upphov till överflödiga blanksteg. Dessutom ersätter pretty-print entitetsreferenser för specialtecken med en wysiwyg-visning, vilket på Windows XP-datorer kan leda till att en del tecken visas som tomma kvadrater. Om man klickar på Tools i rullgardinsmenyn och väljer Options så dyker det upp en ruta för inställningar. I den kan man växla mellan två kategorier: General och Editor. I General torde inga förhandsinställningar behöva ändras (kontrollera ändå att Remember layout on close är förkryssat). Språket i programmets användargränssnitt kan ändras, men dessa instruktioner är skrivna för den engelskspråkiga versionen. Det finns en svensk version, men den är undermålig. I Editor -kategorin kan för det mesta allt vara förkryssat. Man bör åtminstone kolla att blankstegen är synliggjorda i form av svarta punkter ( White space visible ). Det torde också vara ändamålsenligt att ha Intelligent backspace/ delete -funktionen aktiverad. Den innebär att hela taggen raderas även om man bara trycker en gång på backspace. Det kan kännas ovant till en början, men det underlättar nog kodandet. Det skadar inte heller att ha Tag completion aktiverat, och ofta är det också skäl att ha Always insert closing tag förkryssat. Det sistnämnda med undantag för de fall då man skriver in manuskripttext för hand och av någon anledning också skriver in en del av elementen för hand. Med Highlight current line kan man välja om den kodningsrad man befinner sig på skall framhävas med färgad bakgrund eller inte. Med Indentation guides avses alltså de vertikala linjer som visuellt sammankopplar starttaggar och sluttaggar, förutsatt att elementet innehåller så mycket text och kodning att båda taggarna visas i början av en rad. Observera också att man kan ändra teckensnitt i Editor -kategorin. Man kan t.ex. först välja lämplig textstorlek (under View -rubriken i rullgardinsmenyn) och sedan försöka hitta ett teckensnitt som känns behagligt att läsa i den textstorlek man har valt. I XML Copy Editor:n kan man ha flera filer öppna samtidigt. När man stänger programmet (och datorn) och sedan startar det på nytt så öppnas automatiskt de filer som man hade öppna när programmet stängdes. Men en viktig egenskap som man lätt kan undgå att märka är att det också är möjligt att ha två eller rentav tre filer synliga samtidigt. Detta åstadkoms genom att man placerar muspekaren över ett filnamn uppe på sidan, och klickar på musen så att man håller musknappen nertryckt. Därefter drar man filnamnet till till den vänstra, högra, nedre eller övre kanten på skärmen, så att bakgrunden delvis 11

12 färgas. Det framgår då av det färgade området huruvida skärmen indelas vertikalt eller horisontalt om man släpper upp musknappen. Den här möjligheten kan utnyttjas t.ex. om man vill jämföra med hur man tidigare kodat ett liknande textställe i en annan fil. Notera också att man kan ändra inställningarna på datorn så att alla TEI-filer automatiskt öppnas i XML Copy Editor:n. ******************************************** OBS: Ifall XML-filen inte är well-formed så meddelar programmet det i samband med att man sparar filen. Programmet uppger exakt var felet finns (vilken rad och hur många steg in på raden, nere till höger ser man var man befinner sig). Men eftersom det är fråga om fel inom ramen för XML-kodning (på ett generellt plan) så kan felet i relation till TEI och vår kodningspraxis mycket väl finnas långt tidigare i koden. Lokalisering av kodningstekniska fel Ofta uppger programmet t.ex. att </div>-taggen i slutet av filen är mismatched. Det innebär inte att det är något fel på den taggen, utan att programmet förväntar sig att något annat element ska stängas senast före </div>-taggen. Då kan man tillfälligt skriva in </ omedelbart före </div>-taggen, så ser man vilken tagg programmet förväntar sig senast på det aktuella stället. Det kan t.ex. vara en </p>-tagg som saknas någonstans långt tidigare i filen. Det kan finnas otaliga <p>-taggar i en stor fil, så för att hitta felet bör man gå systematiskt till väga. Man kan skriva in </ ungefär mitt i filen: ifall programmet kompletterar med ett p så saknas sluttaggen någonstans i första hälften av filen, i annat fall saknas taggen i senare häften. Beroende på utfallet upprepar man sedan proceduren vid antingen en fjärdedel eller tre fjärdedelar av filen osv. tills man lyckas lokalisera felet. ******************************************** A.4 Filstrukturer Uppdaterad Indelning i filer Grundtexten kodas i en huvudfil tillsammans med utgivarens ändringar, vilket innebär att också den etablerade texten manifesteras i huvudfilen. 8 Kommentarerna ingår också i huvudfilen, med undantag för standardkommentarer om personer. De sistnämnda införs i databaser, och i huvudfilen ingår därmed endast ett id som hänvisar till kommentaren ifråga. I huvudfilen införs också namnkodning och kodning av främmande språk m.m. Varianterna kodas i en skild fil med själva grundtexten (alltså utan utgivarens ändringar), och i filer med de övriga textversionerna. 8 I den mån normaliseringar införs med enkel kodning (dvs. markeras med <reg> utan att <choice>-kodning används) kan grundtexten emellertid inte visas som sådan. 12

13 ********************************** OBS: Ifråga om texter till vilka det förekommer (externa) varianter bör man alltså spara en skild fil som endast innehåller grundtexten, och som man kan arbeta vidare med när varianterna kodas. ********************************** Textfilerna består av den minsta konstnärliga eller annars meningsfulla helheten, dock så att det inte blir fråga om större helheter än vad som är ändamålsenligt att visa på webben. Ifråga om fiktiva texter kan textfilerna uppdelas i enskilda dikter eller korta noveller, medan romaner och längre noveller uppdelas i kapitel. Varje brev kodas skilt för sig, dagböckerna kodas i filer med anteckningar från en månad, och föreläsningarna kodas i filer som omfattar en termin. Inget hindrar ändå att man arbetar med större texthelheter, ifall man bedömer det som ändamålsenligt, filerna kan sedan lätt delas upp i ett senare skede. De kodade textfilerna bör förses med namn som slutar på.xml (och alltså inte.tei). Observera ändå att filer som ännu skall bearbetas i OpenOffice.org tillfälligt måste ha namn med slutdelen.tei (gäller alltså de skannade och OCR-behandlade filerna, som sådana eller uppdelade i mindre helheter). Sökning i flera filer Eftersom utgåvan kommer att omfatta ett mycket stort antal TEI-kodade filer föreligger det ett behov av att under arbetets gång genomföra sökningar i flera eller många filer samtidigt. För detta ändamål har vi tagit i bruk shareware-programmet EditPlus Text Editor, som kan laddas ner på adressen Programmet får gratis utvärderas under 30 dagar, efter det bör man köpa en licens för en billig penning. De filer som man vill söka i måste placeras i samma mapp, om de inte färdigt råkar finnas i samma. Mappen får finnas var som helst på datorn (eller på Topelius-servern). Observera att det i mappen inte får finnas andra filer av samma typ dvs. med samma slutdel i filnamnet (t.ex. *.xml ) som de man vill söka i. Man kan också välja att samtidigt söka i filer i alla underordnade mappar. Filerna bör vara i *.xml eller *.tei-format, eller också i ett enkelt textformat (*.txt). För de TEI-kodade filernas del krävs alltså ingen konvertering, medan sökningar inte kan genomföras direkt i OpenOffice.org- eller Word-filer. Men det krävs bara att man skapar en mapp för ändamålet, och sen öppnar filerna ifråga i t.ex. OpenOffice.org, och sparar i den nya mappen med Save as, Text Encoded (.txt), Edit filter settings och Unicode (UTF-8). Det är alltså samma tillvägagångssätt som i kollationeringsprogrammet Juxta. Förfarandet är också i stort sett det samma ifall det är fråga om Word-filer. I Wordprogrammet väljer man först save as, sedan det enkla textformatet *.txt och till sist väljer man annan kodning och Unicode (UTF-8). 13

14 I EditPlus väljer man i rullgardinsmenyn Search / Find in Files (alternativt klickar man på en symbolknapp med flera pappersark). Då dyker det upp en Find in Files -ruta i vilken man väljer rätt mapp (alternativt tar man fram rätt mapp längst till vänster i programmet, och väljer current file directory i Find in Files-rutan). I Find in Files-rutan bör man också ange vilka filtyper man vill söka i, t.ex. *.txt eller *.tei. Vill man söka i flera olika filtyper används semikolon, t.ex: *.tei;*.xml (båda ändelserna torde åtminstone tillsvidare förekomma bland våra TEI XML-filer). Utöver det behöver man bara ange vilken teckenföljd man vill söka efter. Därtill finns det en del inställningsmöjligheter, man kan bl.a. välja om sökningen ska göra åtskillnad mellan versaler och gemener, och om man vill söka efter teckenföljder eller enbart hela ord. Programmet stödjer också s.k. reguljära uttryck ( regular expressions ). Programmets instruktioner kan fås fram via Help i rullgardinsmenyn. Välj därefter Help / Help Topics / Search Menu och Find in Files. Till sist måste man klicka på Next uppe till höger för att Find in Files -instruktionerna skall dyka upp på skärmen. (Om man klickar på Regular Expression kan man se hur man gör mer avancerade sökningar). Sökningarna resulterar i långa listor, i vilka träffarna visas i ett sammanhang på ett par textrader. Man kan sedan dubbelklicka på en förekomst för att komma till det aktuella textstället i filen ifråga. TEI Header I motsats till TEI-kodningen i övrigt är informationen i den s.k. TEI Headern inte knuten till något visst textställe, utan den är till för att beskriva filen på ett övergripande plan. TEI Headern kan jämföras med titelsidan i ett tryckt verk. Den kan innehålla information om själva texten, dess ev. tryckta förlaga, kodningen, revideringar m.m. TEI Headern införs i början av varje TEI-fil, och kodas i ett <teiheader>-element samt i underordnade element för information av olika slag. TEI Headern bör i likhet med själva den kodade texten vara underordnat det s.k. rotelementet <TEI.2>, som alltså öppnas alldeles i början av TEI-koden och stängs till sist. 9 TEI Headern kan ha följande beståndsdelar: 1) en filbeskrivning som kodas i elementet <filedesc> 2) en kodningsbeskrivning som införs i <encodingdesc>-elementet och också kan innehålla information om förhållandet mellan den digitala texten och dess tryckta förlaga (t.ex. om ev. normaliseringar) 3) en textprofil, som införs i elementet <profiledesc> och kan innehålla information om textens ämnesområde, vem eller vilka som skrivit den o.s.v. 4) en förteckning över revideringar, som kodas i <revisiondesc>-elementet. 9 Vi använder rotelementet <TEI.2> (istället för <TEI>) eftersom vår kodningspraxis inte fullständigt överensstämmer med TEI Guidelines. 14

15 OBS: Av dessa fyra huvudkategorier utgör endast <filedesc> ett (i största allmänhet) obligatoriskt inslag i TEI Headern! I filer som innehåller variantkodning måste emellertid också <encodingdesc>-elementet ingå i TEI Headern, och <profiledesc> behövs om det finns flera händer i ett manuskript. Informationen i de olika huvudkategorierna struktureras därtill med hjälp av följande elementtyper: a) grupperingselement (ex: <editionstmt>, <titlestmt>), som innesluter ett antal element med en viss slags information b) deklarationer (ex: <tagsdecl>, <refsdecl>), i vilka redogörs för vilken kodningspraxis man följt i olika hänseenden. c) beskrivningar (ex: <settingdesc>, <projectdesc>), som innehåller beskrivningar som antingen kan vara fritt formulerade eller anges i diverse underordnade element. Den obligatoriska huvudbeståndsdelen <filedesc> bör innehålla en bibliografisk beskrivning av den elektroniska texten. <filedesc> kan innehålla sju underelement, av vilka tre är obligatoriska: <titlestmt>, <publicationstmt> samt <sourcedesc>. En minimi- TEI-Header ser alltså ut på följande sätt: <teiheader> <filedesc> <titlestmt>...</titlestmt> <publicationstmt>...</publicationstmt> <sourcedesc>...</sourcedesc> </filedesc> </teiheader> Observera att elementen som är underordnade <filedesc> bör införas i en viss ordningsföljd. Ifråga om de tre obligatoriska elementen är den rätta ordningsföljden alltså 1) <titlestmt>, 2) <publicationstmt> och 3) <sourcedesc>. Åtminstone ifråga om korta texter som brev och diktmanuskript inför vi allmän information i databaser, och därför behövs det i stort sett endast en minimi-tei-header i de kodade filerna. I startfilerna ingår ändå också <profiledesc> eftersom det elementet behövs om det finns flera händer i manuskriptet. I <titlestmt> införs ett <title>-element i vilket anges brevets eller manuskriptets signum. I ett <respstmt> som också är underordnat <titlestmt> uppges i elementen <resp> och <name> vem som är ansvarig redaktör för texten ifråga. I <publicationstmt> införs endast en <publisher>-tagg med innehållet Zacharias Topelius Skrifter. I <sourcedesc> uppges (i <p>-taggar) Arkivsignum: se databas. Om det finns flera händer anges de i <handnotes>elementet som alltså är underordnat <profiledesc>. De enskilda händerna införs i <handnote>-taggar. 15

16 Strukturelement <text><body> All etablerad text bör omslutas av elementet <body> som i sin tur bör finns inuti <text>elementet. De öppnas alltså i början av den etablerade texten, genast efter <teiheader>elementet. De stängs sist i filen (dock före rotelementet <TEI.2>) i den omvända ordningsföljden </body></text>. <div> Texten i en TEI-fil d.v.s. innehållet i <body>-elementet kan vid behov indelas i textsektioner (i kodningstekniskt hänseende) som består av t.ex. enskilda kapitel eller dikter. Detta sker med <div>-element som kan vara antingen numrerade eller onumrerade. De numrerade elementen <div1>... <div7> kan användas om man anser att det finns ett behov av en hierarkisk indelning av texten i större och mindre avsnitt, så att ett kapitel t.ex. alltid avgränsas med <div4>. I vår kodningspraxis har vi ändå åtminstone tillsvidare gått in för att använda enbart onumrerade <div>-element. (Man får inte använda både numrerade och onumrerade <div>-element i en och samma TEI-fil). I <div>-elementet kan type-attributet användas för att ange vilken slags textsektion det är fråga om, t.ex. <div type="chapter">. Vi utnyttjar också <div>-elementet för att ange att ett diktmanuskript är oavslutat, och för att i en del specialfall indela brev i en tidigare och en senare del. I bägge fallen används attributet part vid sidan av type-attributet (ex: <div type="poem" part="y">). I lyrikkodningen (filerna med etablerad text) avgränsas kommentardelen med hjälp av elementet ifråga. Därtill kan attributet xml:lang användas i <div>-elementet, ifall t.ex. ett brev i sin helhet är skrivet på ett annat språk än svenska. <milestone/> Vid sidan av <div>-elementet har vi också tagit i bruk ett <milestone/>-element för att koda textindelningar. I motsats till <text>-, <body>- och <div>-elementen så innesluter <milestone/> inte någon text, utan det är ett tomt element. I vår kodning används det (i kombination med unit="part") för att registrera indelningar i avsnitt, som i originalen markeras med blankrad. 16

17 B Textetablering B.1 Allmänt Uppdaterad Paginering och sidbrytning Pagineringstaggen <pb/> placeras i sidbrytningen, sidnumret avser efterföljande sida (pb står för page break ). Utgångspunkten är att sidnumret är utskrivet, dvs. man behöver aldrig explicit ange att type="printed" (tryckta texter) eller type="written" (manuskript). OBS 1: Endast själva sidnumret (arabiskt eller romerskt) införs i pagineringskodningen. Eventuella föregående s. eller efterföljande punkter utelämnas. Felaktiga sidnummer korrigeras stillatigande. Ifall ett sidnummer i ett manuskript har ändrats så införs enbart det slutliga numret (själva ändringen kodas alltså inte). OBS 2: Om sidnumret finns inne i ett textstycke: blanksteg efter (men inte före) pagineringstaggen! Om sidnumret finns inne i ett ord: inga blanksteg, bindestreck avlägsnas. a) originalets paginering, tryckt text <pb type="orig" n="8"/> <pb type="orig unprinted" n="15"/> Ifall sidnumret inte är utskrivet (men sidan ändå har beaktats i den fortsatta pagineringen) anges värdet unprinted i attributet type, 10 och det outskrivna sidnumret införs i n. <pb type="orig"/> Om sidan inte beaktats vid pagineringen införs inget n-attribut. b) originalets paginering, manuskript Paginering som införts av författaren: <pb type="author" n="54"/> <pb type="author unwritten" n="55"/> Ifall ett enskilt sidnummer inte är utskrivet (men sidan ändå har beaktats i den fortsatta pagineringen) eller om författarens paginering kompletteras av utgivaren så anges värdet unwritten i attributet type, och det oskrivna sidnumret införs i n. Om sidan ifråga inte beaktats vid pagineringen införs inget n-attribut. Paginering införd senare av annan person: <pb type="other" n="22"/> <pb type="other unwritten" n="81"/> 10 Enligt TEI-riktlinjerna (P5) borde man egentligen använda ett ed-attribut i <pb/>, men vi använder type eftersom attributvärdena syftar på såväl utgåva som enskild sidnumrering. 17

18 Ifall ett enskilt sidnummer inte är utskrivet (men sidan ändå har beaktats i den fortsatta pagineringen) eller om manuskriptets paginering kompletteras av utgivaren så anges värdet unwritten i attributet type, och det oskrivna sidnumret införs i n. Om sidan ifråga inte beaktats vid pagineringen införs inget n-attribut. OBS: senare in- och sammanbundna manuskript kan ha dubbel paginering: en ursprunglig av Topelius som löper per häfte, och en senare tillkommen av annan hand som löper per arkivenhet. I ett sådant fall införs bägge pagineringarna på följande sätt: <pb type="author" n="3"/><pb type="other" n="53"/> Ifall ingendera pagineringen har införts av författaren: <pb type="other" n="3"/><pb type="other2" n="53"/> Den första pagineringsserien anges alltså som other, inte som other1! c) Paginering i ZTS: Efter att texten ifråga har ombrutits för den tryckta versionen så införs vår utgåvas paginering och sidbrytning i kodningen: <pb type="zts" n="8"/> (utskrivet sidnummer) <pb type="zts unprinted" n="15"/> (outskrivet sidnummer) <pb type="zts"/> (sidbrytning; sidan obeaktad vid paginering) Titlar och rubriker Titlar och rubriker kodas med elementet <head>. Ifall en rubrik är fördelad på flera rader (och det inte är enbart av utrymmesskäl) används det tomma radbrytningselementet <lb/> inne i <head>. Observera att <lb/> i så fall inte skall föregås eller efterföljas av blanksteg. Kapitelrubriker: <head>1. En middag under den gamla goda tiden.</head> Motton, citat etc. i anslutning till rubrik eller titel: <head type="motto">[text]</head> Rubriker på lägre nivå: För rubriker på lägre nivå (än den som kodas med enbart <head>) används <head type="sub">, <head type="sub2">, <head type="sub3"> osv. beroende på hur många rubriknivåer det finns. Verktitlar och avdelningsrubriker: Verktitlar kodas också med <head> (detta eftersom vi har tagit ibruk <title>-elementet för omnämnda verk. I <head>-elementet anges att type="title". Avdelningsrubriker i 18

19 lyriksamlingar, tidigare och senare delar i romaner och andra liknande sektionsrubriker kodas som type="section". Ex. 1: <head type="title">hertiginnan af Finland</head> Ex. 2: <head type="section">förra afdelningen. Kriget.</head> För eventuella rubriknivåer mellan <head type="section"> och <head> kan <head type="section2">, <head type="section3"> osv. användas. Verk-i-verk: Titlar för verk-i-verk t.ex. Röfvarebandets hjeltevisa. i Läsning för barn kodas med <head type="incorp"> ( incorp står för incorporated work ). *Senare införs ev. också <div>-kodning med vilken själva verket-i-verket avgränsas.] Grafiska markeringar: Ifall en rubrik (eller titel) i sin helhet är grafiskt markerad (t.ex. understruken) kan attributet rend införas i direkt i <head>. Om rubriken endast delvis är grafiskt markerad används <hi>-elementet inne i <head>: Ex. 1: <head rend="underline">1. En middag under den gamla goda tiden.</head> Ex. 2: <head>1. <hi rend="underline">en middag under [...] tiden.</hi></head> Ifall t.ex. en avdelningsrubrik är kursiverad, och man vill registrera det i kodningen, så anges både type och rend i <head>: Ex. 3: <head type="section" rend="italics">förra afdelningen. Kriget.</head> Nytt avsnitt Ifall början på ett nytt avsnitt i originalet har markerats med en blankrad så kodas det enbart med <milestone unit="part"/> (ingen blankrad skall alltså införas i kodningen). Ifall indelningen i avsnitt (i originalet) framhävs med skiljelinje eller avlångt ornament så anges det med attributet type som tilldelas värdet bar: <milestone unit="part" type="bar"/> (Motsvarande streck i slutet av kapitel kan betraktas som dekorationer och återges inte.) Textstycken etc. Textstycken kodas med <p>-taggar ( paragraph ). Originalets radbrytningar kodas (med <lb/>-taggar) endast i de undantagsfall då de uppfattas som betydelsebärande. Textstycken med indrag: <p>några ögonblick derefter lågo de gamle vännerne Severin Björck, benämnd Mösset, och Vincent Ek, benämnd Vågbrytaren, i hvarandras armar.</p> 19

20 Textstycken utan indrag: (t.ex. i början av ett kapitel) <p rend="noindent">ordentlighet är en mycket berömlig dygd i alla förhållanden, men jag fruktar, att dess hemvist sällan är att söka på en författares skrifbord.</p> Helt indraget textstycke: <p rend="parindent">[textstycke]</p> (Textstycken i vilka samtliga rader är indragna, t.ex. blockcitat.) Repliker i prosatext: <p rend="dialogue"> Jaså, du har varit tingsskrifvare de senare tiderna?</p> Alla textstycken som inleds med tankstreck kodas med attributvärdet dialogue. Repliker som inte markeras med tankstreck (utan istället t.ex. med citattecken) kodas som vanliga textstycken. Även textstycken som inleds med tankstreck enbart i den etablerade texten (dvs. efter att normaliseringar och rättelser införts) kodas med rend="dialogue". Grafiskt markerade stycken: Ifall ett textstycke i sin helhet är grafiskt markerat (med t.ex. kursivering) får rendattributet enligt vår kodningspraxis inte användas direkt i <p>-elementet. Istället införs rend-attributet i ett <hi>-element: <p><hi rend="italics">ord ord ord.</hi></p>. Centrerat inslag: <p rend="center">[text]</p> Centrering anges alltså med attributet rend och värdet center. <p rend="center"> innebär att samtliga rader i stycket centreras: flera centrerade rader som utgör en enda mening eller annars kan uppfattas höra till samma stycke kan alltså införas i ett enda <p>-element i vilket radbrytningar (som inte enbart beror på utrymmesbrist) kodas med det tomma elementet <lb/>. Centrerade skiljelinjer: <p rend="center"><figure type="bar"/></p> Vårt tidigare sätt att koda indelning i avsnitt som markerats med skiljelinje eller avlångt ornament. Använd istället <milestone/>-elementet, se ovan ( Nytt avsnitt ). Blankrader: Blankrader som inte markerar början på ett nytt avsnitt kan vid behov införas som ett tomt <lb/>-element (man skall helst undvika att återge blankrader i form av tomma <p/>element eftersom de inte utgör textstycken). Men observera att blankrader inte skall införas i kodningen ifall de finns t.ex. i anslutning till rubriker eller runt diktstrofer: i sådana fall kan (standardiserade) mellanrum åstadkommas i stilmallarna. 20