• No results found

Diskussion och egna reflektioner

Det finns tre viktiga punkter som kommit fram under arbets g˚ang, men som inte har platsat i arbetet, pga brist p˚a tid eller relevans f¨or funktionalitet. H¨ar ¨

ar en lista p˚a de tre punkterna: • Omdefinition av vanliga makron. • Paket och klasser.

• Viktigaste metadatan.

De tv˚a f¨orsta punkterna h¨anger ihop n˚agot. F¨or att det ska vara rimligt att prata om skapandet av paket, m˚aste de vanligaste makrona kunna omdefinieras. Vad som ska vara paket och klasser ¨ar n˚agot jag inte fick speciellt bra uppfatt- ning om i b¨orjan p˚a arbetet och det har heller inte f˚att n˚agot utrymme i resten av rapporten. D¨arf¨or vill jag avs¨atta ett stycke med egna synpunkter om det- ta p˚a slutet. Vilken metadata som ¨ar viktig/intressant ¨ar n˚agot jag inte heller funderat speciellt mycket p˚a under arbetets g˚ang. Det var n˚agot jag b¨orjade fundera kring n¨ar jag t¨ankte igenom ut¨okningar av paketet. Jag avs¨atter ¨aven h¨ar ett stycke f¨or att sammanfatta vad jag kom fram till i mina funderingar. De tre punkterna diskuteras utf¨orligt i egna stycken nedan.

Omdefinition av startsection

Jag pratade tidigare i rubrik 3.3 om att jag var tvungen att g¨ora ett tidigt st¨allningstagande i fr˚agan om paketet skulle omdefiniera befintliga makron eller skapa nya. Jag motiverade mitt val baserat delvis p˚a problemet med att omde- finiera vissa makron. Under arbetets g˚ang fortsatte jag ¨and˚a med att unders¨oka m¨ojligheten, kanske f¨or att ha med alternativet som ett paketval. N˚agra av de viktigaste makron jag f¨ors¨okte omdefiniera ¨ar sektionsmakrona. Av n˚agon an- ledning g˚ar det inte att ¨andra hur man vill i \section exempelvis, vilket jag tror beror p˚a att m˚anga andra paket ber¨ors av dem. Ist¨allet f˚ar man g˚a p˚a grunderna och f¨ors¨oka med \startsection. Jag gjorde ett f¨ors¨ok ik¨allkod 19att omdefiniera denna med ett relativt bra resultat. Det enda problemet jag uppt¨ack hittills ¨

ar att \section* inte beh˚aller det definierade avst˚andet mellan rubrik och ef- terf¨oljande text. Detta b¨or, baserat p˚a min erfarenhet inte vara alltf¨or sv˚art att l¨osa.

Kodexemplet ¨ar inte n¨odv¨andigtvis helt komplett, utan ¨ar bara till f¨or att visa att det ¨ar m¨ojligt. En av de f¨orsta saker man b¨or notera med koden ¨ar hur sv˚arl¨asbar den ¨ar med sina m˚anga argument. Men eftersom det ¨ar s˚a h¨ar sektionssystemet ¨ar konstruerat, har man inget val ¨an att h˚alla sig till deras antal argument. Exemplet skapar inte heller n˚agon metadata utan g¨or bara en enkel annotering, eftersom det r¨acker att visa hur det kan genomf¨oras.

7.2. DISKUSSION OCH EGNA REFLEKTIONER 47 K¨allkod 19 Modifikation av @startsection

\let\oldssection\@startsection \let\oldssect\@ssect \def\@startsection#1#2#3#4#5#6{% \@ifstar{\owlSsect{#3}{#4}{#5}{#6}}{% \@ifnextchar[{\owlStartSectionopt{#1}{#2}{#3}{#4}{#5}{#6}}% {\owlStartSection{#1}{#2}{#3}{#4}{#5}{#6}}% } } \def\owlStartSection#1#2#3#4#5#6#7{% \oldssection{#1}{#2}{#3}{#4}{#5}{#6}{\annotcapbox{#7}}} \def\owlStartSectionopt#1#2#3#4#5#6[#7]#8{% \oldssection{#1}{#2}{#3}{#4}{#5}{#6}[#7]{\annotcapbox{#8}}} \def\owlSsect#1#2#3#4#5{% \oldssect{#1}{#2}{#3}{#4}{\annotcapbox{#5}} }

Klasser och paket

I LATEX laddar man en klass, exempelvis book, i b¨orjan p˚a sitt dokument. Sedan f¨oljer man upp med att ladda flertalet paket. Tyv¨arr finns det inte en klar och tydlig definition p˚a vad som ska ligga i klassfiler och vad som ska finnas i paket- filer. Det som ¨ar klart, ¨ar att i klassfiler m˚aste ˚atminstone alla strukturmakron definieras, s˚asom \section. Om ett paket skapar nya strukturmakron ut¨over de vanliga, b¨or det ist¨allet vara en klass d˚a?

Kanske hade det varit smidigast om jag gjorde dels en klassfil och dels en paketfil ist¨allet f¨or att ha allt i mitt owlpaket. Jag hade d˚a rimligen kunnat utg˚a fr˚an n˚agon befintlig klassfil och sett till att alla de vanligaste makrona annote- rades, samt att paketfilen laddades. Rimligen hade jag flyttat ut alla makron med prefixet annot i klassfilen och endast haft grundl¨aggande funktionalitet i paketet.

Vidare skulle ¨aven en separering av metadata makron och annoteringsmak- ron kanske g¨oras och dessa finnas i varsitt paket. Detta ¨ar dock betydligt mer komplicerat, d˚a jag fr˚an b¨orjan p˚a arbetet f¨orutsatte att de h¨angde ihop. Detta medf¨or att det f¨ormodligen skulle inneb¨ara en hel del jobb att bena is¨ar dem, samt att vissa makron kanske ¨ar sv˚ara att avg¨ora i vilket av paketen de h¨or hem- ma! En av f¨ordelarna med tv˚a paket ¨ar att det ¨ar l¨attare att l˚ata anv¨andaren anv¨anda sig av endast metadata, om den skulle vilja det. D˚a ¨ar det bara att lad- da det ena paketet. Just nu tror jag den snabbaste l¨osningen f¨or att f˚a paketet att genomf¨ora medata endast, utan annoteringar, ¨ar genom lite ”fulkodning”. Makrot \annotit ¨ar makrot som skapar sj¨alva annoteringen och ¨ar det makro som alla andra makron anv¨ander sig av. Om man omdefinierar detta makro s˚a den inte skapar n˚agra annoteringar s˚a kommer paketet automatiskt att skapa metadata endast. Nackdelen ¨ar att flera makroanrop kommer att g¨oras som inte fyller n˚agon funktion. Min erfarenhet efter att ha studerat m˚anga andra paket,

48 KAPITEL 7. RESULTAT

¨

ar att det redan finns m˚anga l¨osningar som fungerar enligt den metoden, exem- pelvis hyperref. Inget tyder p˚a att dessa makron s¨anker prestandan n¨amnv¨art vid kompilering, d¨arf¨or b¨or inte detta vara n˚agot att oroa sig f¨or.

Om man skulle v¨alja att skapa sin egen klass, f¨orsvinner lite av problemet med att omdefiniera befintliga makron. De flesta makron man vill definiera befinner sig i regel i klassfilen, vilket g¨or att man kommer att skapa dem fr˚an b¨orjan ist¨allet. I efterhand tycker jag det l˚ater som den b¨asta l¨osningen, men det ¨ar betydligt l¨attare att vara efterklok.

En nackdel med uppdelningen i klass och paket, ¨ar att anv¨andaren inte kan dra nytta av andra klasser. D¨aremot skulle m¨ojligheten finnas att skapa flera nya klasser med st¨od f¨or annoteringar! Det skulle kanske tom g˚a att f˚a som options till flera av de stora klasserna, vilket f¨ormodligen vore det optimala ifr˚an anv¨andarnas perspektiv.

Viktigaste metadatan

N¨ar grunderna till paketet var klara och de flesta standardmakron var imple- menterade s˚a b¨orjade testfasen. Efter f¨orsta testen s˚a kom det fram en del intres- santa makron som paketet borde ha. Detta fick mig att t¨anka till betr¨affande metadatan. Vilken metadata ¨ar det mest troligt att det finns intresse f¨or att anv¨anda? Det f¨orsta jag t¨ankte p˚a var att j¨amf¨ora det med vad som ¨ar viktigast i en rapport vid f¨orsta anblicken. Jag kom d˚a fram till f¨oljande punkter som jag tycker ¨ar de mest sannolika delarna av ett dokument som man vill h¨amta information ur: • Sammanfattning. • Referenser. • Rubriker. • Index. • Nyckelord. • Titel, f¨orfattare mm.

De flesta av dessa punkter fanns redan medtagna, men inte sammanfatt- ningen eller index. Detta fick mig att komplettera paketet mot slutet s˚a att alla dessa omfattades. Det fick mig ocks˚a att fundera p˚a vad paketet redan st¨odjer och till vilket syfte. Jag kom ocks˚a fram till ett antal annoteringar som jag tvivlar starkt p˚a:

• Rubriker p˚a inneh˚allsf¨orteckningen och figurf¨orteckningen, mm. • Rubriken f¨or referenser.

7.3. VIDAREUTVECKLING 49

Related documents