Jeg vil skrive en bog - men hvordan?

En af mine kommende projekter er at skrive en bog. Jeg har prøvet det før som nogle kan huske :-) For mange år siden var jeg sammen med ca 120 andre i gang med at skrive "Linux - Friheden til at vælge", som stadig kan findes på www.linuxbog.dk. Jeg kan afsløre, at jeg har valgt at bruge tools på en Linux-maskine :-) Jeg har brug for jeres indspark til hvilke "tools" jeg skal kaste mig over.

Den gang skrev vi www.linuxbog.dk brugte vi SGML/XML-filer i DocBook-format. Det fungerede godt. Vi havde en masse tekst-filer med en ret enkel mark-up til figurerer og referencer, som vi oversatte til HTML eller PDF (via sgmltools fra docbook.org). Dog var det lidt af en blindgyde med få maintainere på det, og der var ikke andre, der brugte samme tools.

Da jeg skrev min PhD-afhandling på 300++ sider lavede jeg den i LaTeX. Super godt! LaTeX integrerer fantastisk godt med Emacs f.eks. med AUCTeX og til store projekter kan jeg ikke se noget godt alternativ til LaTeX. Grundlæggende svarende LaTex-kode til DocBook - dvs. en ret enkel markup, og man skal "compile" for at kunne se den endelige repræsentation som PostScript/PDF-fil.

Jeg har til mange småting brugt at dele tekst-filer (eller regneark) via Google Docs. Den store fordel er at det er super nemt at samarbejde med andre, og filen er "bare i skyen" og endda versions-kontrolleret. Jeg er meget tilfreds med det, men versions-kontrol-delen er "simpel", og håndtering af billeder, referencer og lignende imponerer mig slet ikke.

Jeg har også en hel del erfaring med forskellige wikier. Men om det er godt til at skrive en hel bog i - det er jeg mere usikker på. Især er jeg usikker på hvordan udprintning går,

Livet er for kort til at vælge at skrive i Word (som faktisk kan køres under Wine/CrossOver- punktum... Jeg har været der mange gange. Det holder ikke især når dokumenterne bliver store. Et oplagt forslag er LibreOffice, men er det ikke reelt de samme problemer som at skrive i Word?

Lad mig lige give lidt flere rammer for projektet. Jeg regner med at skrive ca 100 sider og der skal mange figurer ind. Den endelige tekst skal kunne printes ud - og det vil være det primære medie - men kan jeg lave en web-udgave af min tekst så vil det være fint. Jeg har intet problem i at at hoppe på et nyt system for at lære noget nyt. Jeg har heller ikke noget problem i skal skulle smide tid i at sætte "tools" op på mine Linux-maskiner om nødvendigt. Skulle løsningen ikke inkludere versions-kontrol, så lægger jeg selv Mercurial eller Git med i løsningen - det ligger til mit højreben.

Skriv meget gerne hvad I ville vælge af værktøjer - og hvorfor!

/pto

Kommentarer (35)
Leif Lodahl

Hej Peter,
Spændende projekt.
Jeg vil foreslå at du/I bruger LibreOffice med Zotero plug-in til referencehåndtering (referencer kan deles). Hvert kapitel skrives som et selvstændigt dokument med standardtypografier og standard alt muligt. Dokumenter kan udveksles via Dropbox, UbuntuOne eller whatEver.
Redaktøren oprettet hoveddokument, som indrettes som "bog", altså med de rigtige typografier og sideopsætning. Når standardtypografierne i kapitlerne indlæses i hoveddokumentet, formateres indholdet efter typografierne i hoveddokumentet. På den måde kan de enkelte forfattere koncentrere sig om indholdet. Eneste ulempe er at krydshenvisninger mellem kapitlerne (fra dokument til dokument) er lidt besværlig, men dog mulig.
Ændringshåndteringen er ikke super god, men fungerer dog.
Tillad IKKE at der bruges andet end LibreOffice eller Open Office. Word vil ødelægge dokumenterne.

Peter Toft Blogger

Min gode ven Patrick Koetter kom lige med et sjovt indspark "Lav indholdsfortegnelsen/oversigt på papir"!
Kan det være en god plan? Jeg vil nok give ham ret, men jeg lurer på at lave den del via et mindchart eller lign i første udkast....
Kommenter gerne

Klaus Elmquist Nielsen

Det handler grundliggende om hvordan man arbejder bedst. Papir og skriveredskab kan nogle ting som en computer ikke kan. Blandt andet er brugergrænsefladen meget umiddelbar og teksten behøver ikke være lineær. Forskning i skriveprocesser indikerer at man tænker bedre når man skriver.

Jeg så en notits om en forsker som bruger et mindmap program gemt i dropbox til at holde styr på sine forskningsideer. Det er også en fremgangsmåde.

Det vigtigste er at anvende de tekniker der virker bedst for en. Med en PhD på "syndelisten", selv om det som alle andre uddannelser blot er et godt grundlag at studere videre på, må der være en vis erfaring med hvad der virker for dig. Brug den viden!

Tomas Krag

Folkene bag Flossmanuals.net (et projekt der skriver manualer til open source software), har udviklet det web-baserede værktøj Booktype (tidligere booki). Det er egentligt tænkt til collaborative bog projekter, men er i det hele taget et glimrende bud på at tage alle fordelene ved en wiki og tilpasse den til det mere lineære bog format. Og så er det open source det hele.

Aner ikke om det passer til dit formål, men jeg har været glad for det i de bogprojekter jeg har været involveret i (og så kender jeg også folkene bag).

Det lyder da i øvrigt spændende at du har planer om at udvide forfatterskabet.

Tomas

Martin Schlander

Du skulle jo gerne distribuere din bog i et anstændigt e-bogsformat - normalt EPUB. Der findes faktisk extensions til LibreOffice der giver EPUB-eksport.

Calligra 2.6 udkommer i denne måned med et nyt modul - Calligra Author - som er beregnet decideret til at forfatte (e-)bøger, med eksport til EPUB2 og MOBI. Selvfølgelig kan det ikke forventes at være perfekt, da det er første release af et helt nyt program (som dog bygger på Calligra Words og Calligras biblioteker, så udviklingen kan gå pænt stærkt).

Michael Rasmussen

Hvorfor ikke blot simpelt (x)html?
- Super nemt at vedligeholde referencer (web developer plugin -> link validator)
- Super nemt at dele med andre
- Super nemt at versionere
- Validering (web developer plugin -> validate html/css)
- Styling er super nemt med css3
- Der findes utallige converteringsprogrammer til stort set alle document formater
- Enhver editor kan anvendes - super plugins til Emacs og Vi
- Kildens dokumentformat baseret på iso-8859-1 eller utf-8 så det må formodes at være langtidsholdbart

Poul Krogh

Scrivener er et helt fantastisk værktøj, der ikke fokuserer så meget på formateringen, som på skriveprocessen. Oprindeligt et OSX program, men der findes også en windows udgave. Det er et forsøg værd at se om den kan køre under Wine (Der kan downloades en free trial, og programmet er ret billigt - men alle pengene værd)
Indholdsfortegnelse laver du vha. Scriveners Corkboard.

Jesper Stein Sandal Blogger

Før du ser på værktøjerne, så må du lige dele lidt mere om processen:

Det lyder, som du gerne vil skrive bogen sammen med andre? Det er en helt speciel udfordring i forhold til at skrive selv. Og skal det i så fald være dig, der samler trådene fra en masse forfattere? Eller skal alle skrive en masse dele, som sættes sammen? Eller skal forfatterne skrive på de samme tekster?

(Den mest velafprøvede model er ikke at bruge samarbejdsværktøjer, men derimod udpege en redaktør)

Hvordan skal det udgives? Skal den sælges til et forlag? I så fald skal det bare være så meget standardtekst som muligt, og så er en tekstbehandler det bedste værktøj. Skal det være en selvudgivelse på tryk? I så fald skal du vælge noget, hvor du selv kan sætte det op - og det skal nok aftales med trykkeren. Skal det være en webudgivelse? Eller skal det være en e-bog?

Processen dikterer værktøjet. Grundlæggende ville jeg dog forsøge at holde formatering væk fra skriveprocessen, medmindre det er en pointe i sig selv (f.eks. hvis du vil skrive en wiki med mange krydsreferencer). Du skal alligevel regne med at bruge cirka dobbelt så lang tid på efterfølgende redigering end på skrivningen. Og det handler mere om omskrivning end om at formatere overskrifter og fodnoter.

Torben Mogensen Blogger

Jeg plejer at bruge LaTeX til bogprojekter. Der er stort set ingen grænser for, hvad du kan gøre med LaTeX, og til formler, tabeller, krydsreferencer, index og bibliografier er LaTeX uovertruffet. Og det er forholdsvis let at lave globale ændringer for layout. Og resultatet i PDF kan se meget professionelt ud, hvis man bare gør en smule ud af opsætningen af layoutparametre. Der er diverse standard document styles, man kan låne fra til det.

Man kan nemt dele et dokument op i flere filer, hvilket gør det nemt at arbejde sammen om et større værk. Og da kildeteksten er almindelig tekst, kan man bruge tekstbaserede værktøjer såsom diff, grep, og lignende.

Men der er visse ting, der er lidt bøvlet, heriblandt indsættelse af billeder og brug af farver. Desuden er værktøjerne til konvertering til HTML lidt primitive.

Morten Juhl-Johansen Zölde-Fejér

To værktøjer, der kan være interessante:
LyX er et af de værktøjer, der i brugerflade minder om et tekstbehandlingsprogram, men som anvender LaTeX til at lave dokumenterne. Det er meget rart at skrive større ting i. Den har desuden integration med referencestyringsprogrammet JabRef, som er en brugerflade til BibTeX. Jeg har tidligere lavet en artikel om LyX og en om JabRef.
Et større system, som jeg var imponeret over, når det kommer til eksport til mange formater, er Publican - et system beregnet til at skrive dokumentation og med mulighed for eksport til rigtigt, rigtigt mange formater. Et opmærkningssprog i familie med DocBook - man opgiver, hvilke outputformater, man vil have det i, og det genererer den så; laver man det i flere sprog, opgiver man, hvilke sprog man gerne vil have genereret i dag... så gør den det. Projektets brugerguide er et godt eksempel på et nydeligt resultat - det bliver rigtigt pænt. Jeg brugte det kun til noget kort, så jeg ved ikke, hvordan det er at bruge til større ting - men jeg var i hvert fald imponeret at outputresultaterne.
Klaatu lavede en episiode af Hacker Public Radio om Publican, hvilket var det, der fik mig til at udforske den

Esben Madsen

generelt er jeg enig med flere andre om at adskilt indhold og formattering er vejen frem... min erfaring med libre office er i øvrigt at det ligesom med word er rigtig bøvlet at arbejde med figurer (med captions osv) medmindre man kun indsætter dem en gang og ikke f.eks. opdaterer dem (ja man kan godt "linke" til eksterne figurer i stedet for at indlejre, men det giver nogle andre problemer)...

LaTex + versionskontrol er naturligvis altid godt når man skal samarbejde om det og giver et rigtig godt output (vil du lave grafisk layout af tabeller der evt. skal opdateres senere kan de evt. eksporteres fra libre office calc til en separat .tex-fil)...

Mht. wiki'ens mulighed for udgivelse i bogformat, så er jeg faktisk ok imponeret over wikipedias bog-værkstøj som kan kobles på enhver mediawiki med collection udvidelsen

Martin Kofoed

Jeg ville vælge dette:

http://wiki.eclipse.org/Mylyn/WikiText

Vi bruger det delvist til systemdocs på arbejde. Det versioneres sammen med koden og buildsystemet flytter seneste version til http server. Fra IDE'et kan der eksporteres til HTML, DocBook, XSL-FO etc.

Det vigtigste er efter min mening at sikre sin exit-strategi, dvs. når man fjerner alt rundt om selve indholdet, hvor let er det så at konvertere til noget læs-/brugbart?

Morten Jagd Christensen

Hvis nu der var tale om en guide til layout, design, logodesign
etc. Så ville jeg nok ikke vælge LaTeX. Typisk leges der her meget med
kerning, fonts, fontstørrelser, alignment af text med billedelementer osv.
Det er altsammen temmelig uproduktivt i LaTeX efter min mening.

Men hvis dine figurer er grafer eller billeder som 'bare' skal placeres et passende sted og teksten 'blot' skal flyde passende udenom, så er LaTeX da en klar mulighed.

Hvis du selv generer figurerne og de ikke er alt for komplicerede rent grafisk så kan LaTeX i kombination med TikZ og Memoir pakkerne være en fin løsning. Du kan her i høj grad parametrisere figurene (baggrund, rammer og andre elementers størrelse, farve, orientering osv.).

Her er et eksempel jeg selv har arbejdet på i et års tid: http://issuu.com/mortenjc/docs/matematik

Ulempen er klart at man skal være lidt af en tekniknørd for at finde
glæde i at arbejde med LaTeX. Det er både du og jeg, men er dine bogprojekt-samarbejdspartnere også? Hvis ikke skal du måske overveje noget andet ;-)

s_ mejlhede

Indholdsfortegnelser.
Jeg har det selv lidt "svært" med at komme igang. Men en god måde for mig er at skrive alle kapitlerne med overskrift samt underafsnit, som jeg så laver en auto genereret indholdsfortegnelse på bagrund af.
Så er opgaven delt op, og overskuelig, man kan bare tage et underkapitel af gangen, det har hjulpen mig med meget report skrivning. Det første kapitler er jo opgave beskrivelse, som man bare klipper/klister og så er man igang. Ved godt det ikke er en rapport du vil skrive, men denne arbejdsmetode virker god og overskueligt for mig.

Lars Kruse

Her hos os i Praqma har vi kastet vores lid til DocBook,som du allerede er bekendt med. Det er en del besværligheder og uhensigtsmæssigheder forbundet med DocBook. Gennem de seneste 4 måneder har vi har haft to hovedopgave studerende i praktik fra CBS/KNord til at udvikle løsninger på de problemer vi så.

De har dels lavet en simpel forbedret udarbejdelse af index-strukturen i DocBook og desuden taget udgangspunkt i Det DocBook Maven plugin som findes allerede og lavet en del ændringer og optimeringer hertil (de har ikke released endnu, men det kommer). Fordelen ved DocBook er at kilden bliver kompileret til formatting objects - som herfra kan tages videre til utallige af formater, PDF, HTML, docx, odt... - fra den samme kilde.

Et af forbillederne for de to studerendes arbejde var "Jenkins - The definitive Guide" https://github.com/wakaleo/jenkins-the-definitive-guide-book. Som netop er en (O'Reilly) bog som er skrevet med bidrag fra mange forskellige forfattere som et fælles projekt.

Ideen for os og vores studerende har grundliggende været, at de principper vi anvender for at udvikle og integrere kode når vi udvikler, skal være de samme som ligger til grund for det at skrive en bog i fællesskab: Der skal være en Continuous Integration process som starter automatisk på hvert eneste commit til VCS, det skal være muligt at merge kilden (der røg LibreOffice og Word af!), konfigurationen skal være styret fra centralt hold, den enkelte bidrager skal have fokus på content.

Vi har vores kilde i Git, Jenkins overvåger vores repository og starter Maven med de studerenes forbedrede DocBook goal.

Vores studerende er færdige nu og har en endelig præsentation hos os internt her i Praqma i næste uge - inklusiv to live eksempler på relevante bruger scenarier. Jeg har spurgt dem om de er interesserede i at holde denne præsentation for offentligheden og det vil de meget gerne.

Giv gerne til kende hvis det har interesse, vi vil gerne arrangere et gå-hjem-møde i løbet af Januar - hold øje med www.praqma.com/events eller følg @Praqma på Twitter.

MVH
Lars Kruse

Henrik Christian Grove

Jeg er en af de ca. 120 der skrev på "Friheden til at vælge". Men jeg er også en af dem der blandede sig i konverteringen fra DocBook til andre formater.

En af de ting jeg husker var at som tiden gik kom der flere og flere ønsker om at kunne påvirke udseendet (f.eks. flere spalter) af enkelte afsnit i de formater der understøttede det og andre ting DocBook ikke understøttede på fornuftig vis. Derfor vil jeg anbefale at skrive i et format der er så stærkt som muligt, det er nemmere at lade være med at bruge muligheder end at undvære muligheder.

DocBook har sikkert udviklet sig siden, men jeg tvivler på det har nået LaTeX's styrke, så når du kender LaTeX er det det eneste rimelige svar, specielt når print er dit primære medie. Husk dog at LaTeX også har udviklet sig, så der er bedre måder at gøre ting på. Lars Madsens bog er rigtig god.

Det er længe siden jeg har kigget på værktøjerne til at konvertere LaTeX til HTML, men sidst jeg gjorde var de ganske rigtigt ikke imponerende, men det er også det eneste mulige proble, i at vælge LaTeX.

.Henrik

Henrik Kramshøj Blogger

Giv gerne til kende hvis det har interesse, vi vil gerne arrangere et gå-hjem-møde i løbet af Januar

Jeg vil være interesseret, specielt da jeg har været forbi Docbook tidligere men er gået tilbage til LaTeX.

LaTeX giver klart den mest effektive skrivning for mig og specielt muligheden for automatisk at indsamle data fra andre systemer og inkludere er perfekt i mine brugssituationer. Docbook som har en bedre mulighed for konvertering til noget som andre kan arbejde videre på er dog indimellem et krav - og nej, jeg GIDER i skrive i Word og bruge 3-5 gange så lang tid!

Findes der værktøjer som kan konvertere fra "office formater", MS eller Libre eller andre, til Docbook?

Mads Bahrt

Ifth. flad HTML kontra Wiki har jeg flere gange med stor succes læst store flade HTML-filer på ebookreader hvis der ikke var et mere passende ebookformat ( f.eks. da jeg læste http://www-cs-students.stanford.edu/~blynn/gitmagic/book.html). Omvendt har jeg endnu ikke set nogle gode løsninger til at få wikier ind på ebookreaders. Det ville ellers være fedt i forhold til både Wikipedia og Wikitravel.

Det er selvfølgelig mere en diskussion af outputformater end hvilket værktøj du skal bruge.

Flemming Kjær Jensen

Jeg er enig med Jesper Stein Sandals kommentarer om processen. Du må overveje om du har flere faser eller flere processer om du vil for at nå dit mål om at producere en bog. Faserne i bogproduktionen kunne være idéoplæg, kreative skrivefase, forfatter og "fagfælle" review samt produktionsklargøring.

I alle faser vil versionering være rigtigt godt, specielt i review hvor et versionerings tag for et givent review release vil være en god hjælp. Git eller Mercurial hjælper dig her.

Bogen opstår i den kreative fase så tænk over at vælge værktøjer som giver mindst anledning til udfordringer og modstand for alle involverede parter.

Min anbefaling er at benytte pandoc (http://johnmacfarlane.net/pandoc/). Du kan blandt en række formater skrive i reStructured Text eller Pandoc Extended Markdown. Output kommer i PDF, LaTeX, HTML formaterne med mange andre som mulighed. Det frigør dig fra at skulle fokusere alt for meget input og output og du kan koncentrere dig om at skrive brødteksten og stadig have fornuftigt output format. Den eneste begrænsning jeg pt har ramt er farvning af dele af tekstområder som Markdown pt ikke understøtter. Du kommer dog til at bygge dit "build workflow" selv. Jeg benytter mig pt af Rakefiles.

I forhold til de mange figurer så kunne du eventuelt tage en stak hvidt papir, en håndfuld penne i forskellige farver og vær kreativ. Scan herefter resultatet ind og lad det være et idéoplæg til de diagrammer, grafer, figurer du senere laver i de relevante værktøjer, som du anvender til formålet. Uanset om du laver idéoplæg eller forstudier til figurer på papir eller i Viso og Excel så skal figurerne jo eventuelt designes fra bunden eller efterbehandles professionelt i Illustrator. Bliv inspireret af Tufte fra hans bøger vedrørende "removing unnecessary chartjunk" (bøgerne "The Visual Display of Quantitative Information" samt "Envisioning Information" er gode at have læst inden man laver grafer).

Min pointe er at den kreavtive fase, både for brødtekst og figurer, kan og bør måske være opdelt i produktion og herefter forfinelse. Jeg er selv tilhænger af LaTeX men må erkende at Markdown samt reStructured Text kan øge produktiviteten uden større indflydelse på det færdige resultat. Med hensyn til figurer så scanner jeg frihåndstegninger til idéoplæg. Efterfølgende kan du altid hente data fra databaser, regneark og lignende ind i R Project, matplotlib, matlab, etc. eller tegne det rent i Illustrator, OmniGraffle eller hvad du allerede kender. Det øger produktiviteten for mig.

Håber det kan inspirere din bogproduktion.

Morten Juhl-Johansen Zölde-Fejér

Jeg har også arbejdet med spektret fra Markdown, som jeg enormt godt kan lide for dens læselighed - men som mangler nogle ting, man har brug for, og når man så går tilstrækkeligt ind i Extended Markdown, så ender man i noget, hvis læselighed nærmer sig LaTeX. Jeg har til Markdown brugt ReText, som jeg har lavet den danske oversættelse af - et meget behageligt værktøj, men jeg har så heller ikke skrevet en bog i det.
AsciiDoc lægger sig også i den familie, og med nogle gode eksportmuligheder til andre formater.
Nu arbejder jeg jo alene i tekst, så jeg ved ikke, om det er som at arbejde i LaTeX, når man skal arbejde billeder ind i sine dokumenter...

Theis Holtz Hansen

Som en anden har nævnt i debatten, så er Scrivener blevet er favorit for forfattere. Der findes endda en beta version af programmet til Linux. Fordelen ved Scrivener er, at den i modsætning til andre tekstbehandlingsprogrammer, ikke går ud fra man skriver sin tekst i den rækkefølge den skal læses. Desuden holder den bedre styr på research information.
Link til Linux beta: http://www.literatureandlatte.com/forum/viewforum.php?f=33

www.literatureandlatte.com

Måns Mårtensson

Prøv at se på http://tiddlyspace.com/
Eller http://tiddlyweb.com/
Mere specifikt ang. samarbejde om større dokumenter:
http://tiddlydocs.tiddlyspace.com/

http://tiddlydocs.tiddlyspace.com/Introduction%20to%20TiddlyDocs

Jeg har en tjeneste kørende på http://tiddlyspace.gir.dk
Opret et brugerspace - opret et "underspace" og "inkludér" tiddlydocs.
Inkludér dine "co-forfatteres" spaces i dit "tiddlydocs-space".
Alt hvad de har offentliggjort vil være tilgængeligt - og opdateres løbende, i dit "tiddlydocs-space".
Hvis du foretager ændringer til inkluderede materialer (tiddlere) - bliver de klonede - og du overtager ejerskabet.
Du har versionskontrol - mulighed for revertering og alle de værktøjer/plugins til rådighed som du kan drømme om.

Hvis du er interesseret - bør du prøve det af - om ikke andet for at afsøge potentialet.

Mvh Måns

Frederik 'Freso' S. Olesen

Omvendt har jeg endnu ikke set nogle gode løsninger til at få wikier ind på ebookreaders. Det ville ellers være fedt i forhold til både Wikipedia og Wikitravel.


Wikipedia har en "Create a book" funktion hvor du kan vælge hvilke sider du vil have med i din "bog", og så eksportere denne til ePub, PDF, ODT, eller OpenZIM (som jeg ikke kender). Der er også den direkte "Download as PDF" hvis du kun er interesseret i en enkelt artikel.

Services som Instapaper eller Pocket kan også bruges til at samle flere artikler (Wikipedia, blogs, m.m.) og eksportere til bl.a. ePub.

Ebogsprogrammet Calibre har vist også en funktion/et plugin til at importere fra MediaWiki-artikler, svjh.

Log ind eller Opret konto for at kommentere