Howto's-met-LinuxDoc-mini-HOWTO David S. Lawyer, Vertaald door: Ellen Bokhorst v0.0.1, Maart 2001 Dit gaat over het schrijven van HOWTO's in de eenvoudige LinuxDoc markup taal. Het is in eerste instantie bedoeld voor auteurs van het Linux Documentatie Project (en toekomstige onervaren auteurs die snel van start willen gaan). Kijk in de LDP Authoring Guide als je de meer geavanceerde DocBook markup (inclusief XML) wilt gebruiken. Introductie Kun je een HOWTO schrijven?

Heb je info over Linux die van nut zou kunnen zijn voor anderen? Kun je duidelijk schrijven? Weet je hoe gebruik te maken van een tekstverwerker of editor? Wil je duizenden anderen helpen en wil je ze zonder dat het ze iets kost iets laten lezen? Ben je bereid zodra je een document hebt geschreven suggesties via email van lezers te ontvangen en deze info selectief te gebruiken om je HOWTO te verbeteren? Zou je willen dat hetgeen je schrijft op honderden websites over de hele wereld beschikbaar is? Als je op al deze vragen "ja" hebt geantwoord, dan wordt je aangemoedigd iets voor de LDP te schrijven. Wees wel gewaarschuwd dat dit meer tijd in beslag kan gaan nemen dat je in eerste instantie verwacht.

Copyright (sla dit over als je haast hebt)

Copyright (c) 2001 door David S. Lawyer. Kopieer en distribueer dit document gerust in elke formaat (verkoop het of geef het weg). Stuur correcties en opmerkingen aan de beheerder van het document. Je kunt er een afgeleide werk van maken en dit op de volgende voorwaarden distribueren: Als het geen vertaling is: Email een kopie van je afgeleide werk naar de LDP (Linux Documentatie Project) voor vrije distributie op het Internet in een formaat dat de LDP accepteert. Email een dergelijke kopie ook aan de auteur(s) en beheerder (zou dezelfde persoon kunnen zijn). Licentieer het afgeleide werk in lijn met deze licentie of gebruik GPL. Voeg een copyrightmelding in en op z'n minst een verwijzing naar de gebruikte licentie. Geef krediet aan de vorige auteurs en mensen die een belangrijke bijdrage hebben geleverd.

Waarom ik dit schreef

Waarom schreef ik dit, terwijl er reeds een "LDP Authoring Guide" is? De LDP guide is een lang en gedetailleerd boekwerk. Je hebt iets eenvoudigers en beknopters nodig als je snel van start wilt gaan. Bovendien ontbreekt in de LDP guide zelfs het benoemen van de eenvoud van LinuxDoc. Heb ik hiermee voldoende gezegd? Met dank aan Matt Welsh voor zijn example.sgml bestand, dat ik als belangrijke informatiebron gebruikte voor de voorbeeldsecties.

Het formaat van HOWTO's Introductie

Onze HOWTO's worden in diverse formaten uitgegeven: gewone tekst, HTML, PostScript en PDF. In plaats van dezelfde HOWTO in al deze formaten steeds weer opnieuw te schrijven, schrijven we slechts één HOWTO in een bronformaat die door de computer in alle andere formaten wordt geconverteerd. Bekijk eens een bronbestand van een webpagina (als je dit niet al hebt gedaan) om een idee te krijgen hoe dit formaat eruit ziet. Je ziet allerlei soorten woorden tussen <punthaken>. Dit worden tags genoemd. De webpagina's maken gebruik van: Hypertext Markup Language. De LDP maakt voor zijn documenten van iets dergelijks gebruik. De talen die het LDP gebruikt, voldoen aan de Standard Generalized Markup Language afgekort tot SGML. De LDP maakt nu gebruik van de volgende twee varianten van sgml: LinuxDoc en DocBook. Oorspronkelijk maakte het alleen gebruik van LinuxDoc (wat soms onjuist sgml werd genoemd). Het komt er op neer dat html weer een andere variant is van sgml. Nu zijn een aantal mensen overgegaan van de DocBook variant van sgml naar de DocBook variant van de XML standaard. Deze mini-HOWTO gaat in het geheel over het gebruik van de eenvoudige LinuxDoc variant van sgml. Je kunt het de "LinuxDoc markup" noemen. Het kan op een computer worden geconverteerd naar html, gewone tekst, postscript, pdf en DocBook. Het is heel wat eenvoudiger dan html of DocBook en je hebt er geen speciale editor voor nodig aangezien het intikken van de tags erg makkelijk is (of om er macro's voor te gebruiken).

LinuxDoc vergeleken met DocBook

Een manier om dit te doen is op de LDP-site te gaan kijken klik op HOWTOs en vergelijk de bronnen van dezelfde HOWTO dan in de twee formaten: LinuxDoc en DocBook. De DocBook tags zijn vaak langer dan de equivalente LinuxDoc tags en voor dezelfde taak zijn er soms meer van nodig . DocBook gebruikt <para> en &etago;para> tags om paragrafen te omsluiten, terwijl LinuxDoc slechts een lege regel gebruikt om paragrafen van elkaar te scheiden (geen tags). Voor het benadrukken van het woord "release" is de vergelijking: release&etago;emphasis> release release&etago;em> Ja, in DocBook moet je het woord "release" tweemaal intikken. Voor het beginnen van een sectie: Introductie<title> </verb></tscreen> Dus in DocBook moet je heel wat meer typen als je tags met de hand intikt. Maar voor DocBook zijn heel veel soorten tags die in LinuxDoc niet voorkomen, dus het biedt meer mogelijkheden. Slecht een subset van DocBook gebruiken helpt je zoals je kunt zien niet, zoals je uit de hierboven getoonde voorbeelden kunt afleiden. Het is met nog heel wat meer tags vervuild. Met meer en langere tags wordt het document moeilijker leesbaar, tenzij je een editor gebruikt, die ze verbergt. Maar ze verbergen heeft zijn nadelen aangezien het toch wel handig is als je ziet welke tags je hebt gebruikt. Het aantal mensen die gebruik maken van DocBook neemt nog steeds erg toe boven het aantal dat LinuxDoc gebruikt. Maar als je besluit naar DocBook over te stappen dan is daar een programma voor van Reuben Thomas (ld2db) die van hulp kan zijn bij het uitvoeren van de conversie. Het is niet 100% perfect en het kan zijn dat je handmatig nog het een en ander aan moet passen. De LDP converteert een LinuxDoc HOWTO ook automatisch naar DocBook nadat je het hebt aangeleverd. </p> </sect> <sect><heading>Leren van LinuxDoc</heading> <sect1><heading>Introductie</heading> <p> LinuxDoc is heel wat makkelijker te leren dan DocBook. Maar het meeste van wat je over LinuxDoc leert, zal ook bruikbaar zijn voor DocBook. Dus mocht je eventueel besluiten op DocBook over te gaan, dan zal de meeste energie die je in het leren van LinuxDoc hebt gestoken niet zijn verspild. Een manier om te leren is door middel van voorbeelden. Ik heb 3 voorbeeldbestanden geschreven variërend van eenvoudig tot gevorderd. Begin met Voorbeeld1. Deze bestanden zijn hier opgenomen als secties. Om ze naar individuele bestanden om te zetten zou je de tekst eruit kunnen knippen en naar bestanden weg kunnen schrijven. Je zou dan kunnen proberen ze in tekst om te zetten met de opdracht "sgml2txt -f voorbeeld2.sgml" om te bekijken hoe dat eruit ziet. Zorg dat de bestandsnamen op .sgml eindigen. Ga naar een LDP-mirrorsite, zoek de HOWTO's op en selecteer LinuxDoc SGML als je een aantal echte voorbeelden wilt bekijken. Of ga direct naar de hoofdsite: <url url="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/sgml"> Voor nu het eerste eenvoudige voorbeeld. </p> </sect1> <sect1><heading>Voorbeeld 1</heading> <p> <tscreen><verb> <!doctype linuxdoc system> <linuxdoc> <article> <title>Eerste voorbeeld (voorbeeld1)</title> <author><name>David S.Lawyer</name></author> </verb></tscreen> </p> </sect1> </sect> <sect><heading>Introductie</heading> <p> Dit is een erg simpel voorbeeld van de "broncode" voor het LinuxDoc tekstopmaaksysteem. Deze paragraaf begint met een paragraaftag (een "p" omsloten door punthaken). Merk op dat er ook nog andere tags zijn die ook door punthaken worden omsloten. Als je geen tags ziet, dan lees je dus een geconverteerd bestand, dus ga op zoek naar het bronbestand: voorbeeld1.sgml (die met de tags). Dit is de volgende paragraaf. Het wordt slechts door een lege regel gescheiden van de voorgaande paragraaf. De "p" tag is alleen nodig voor de eerste paragraaf van een sectie (net na de sect-tag). De bestandsextensie: sgml staat voor Standard Generalized Markup Language. Je bent nu de LinuxDoc variant van sgml aan het lezen, wat op de allereerste regel van dit bestand is opgegeven. </p> </sect> <sect><heading>Tags</heading> <p> Tags is al datgene dat tussen punthaken staat. De "sect" tag hierboven markeert het begin van een nieuwe sectie van dit voorbeelddocument. "Introductie" was de eerste sectie en je bent nu de tweede sectie getiteld "Tags" aan het lezen. Als dit een lang document zou zijn (zoals een boek) zou een sectie corresponderen met een hoofdstuk. Aan het begin van dit artikel staan "article", "title" en "author". Aan het einde van dit artikel staat een "/article" tag die het einde van dit artikel markeert. Dus er staat een paar "article" tags, als eerste de begintag en de tweede de eindtag. Dus dit gehele artikel wordt omsloten door "article" tags. In latere voorbeelden zul je zien dat net als bij deze nog andere tags in paren voorkomen. Ze beïnvloeden wat zich tussen de paren (begin- en eindtag) bevindt. Elke tagnaam met net ervoor een "/" is een "eindtag". Wanneer deze broncode naar een ander formaat wordt geconverteerd (zoals gewone tekst met het programma sgml2txt) worden de tags verwijderd. Tags dienen alleen voor het sgml2txt programma om de conversie uit te kunnen voeren. Er zijn meer tags te leren. Dus ga alsjeblieft verder met het volgende voorbeeld: voorbeeld2, zodra je dit voorbeeld1 begrijpt. Je hoeft de tags niet echt te onthouden, aangezien ze in latere voorbeelden zullen worden herhaald (maar dan zonder of met weinig uitleg). &etago;article> </p> <sect1><heading>Voorbeeld 2</heading> <p> <tscreen><verb> <!-- Dit is een opmerking. Het wordt genegeerd wanneer het bronbestand naar andere formaten wordt omgezet. --> <!-- De volgende vereiste tag impliceert dat dit bestand in LinuxDoc is opgemaakt --> <!doctype linuxdoc system> <article> <title>Tweede Voorbeeld (voorbeeld2)</title> <author><name>David S. Lawyer</name></author> <date>v1.0, juli 2000</date> <abstract> Dit is de samenvatting. Dit document is het tweede voorbeeld over het gebruik van de Linuxdoc SGML variant van sgml. Het is wat complexer dan het eerste voorbeeld (voorbeeld1.sgml), maar eenvoudiger dan het derde voorbeeld (voorbeeld3.sgml). Na je onderzoek zul je een simpele HOWTO in LinuxDoc kunnen schrijven. Einde samenvatting. &etago;abstract> <!-- De "toc" = Inhoudsopgave. Het zal hier worden aangemaakt. --> <toc> <!-- Begin het hoofdgedeelte van het artikel (of document) hier. Het deel hierboven is een soort lange header. --> <sect><heading>Het Tweede voorbeeld (voorbeeld2.sgml)</heading> <p>Tenzij je bekend bent met markup talen, zou je eerst voorbeeld1.sgml moeten lezen. Wellicht dat je deze voorbeeldbestanden door een vertaalprogramma, zoals sgml2txt, wilt laten verwerken, om ze naar tekst te converteren om te zien hoe anders het resultaat er uitziet in vergelijking met dit "brondocument" met al zijn tags. </p> </sect> <sect>Lay-out van een artikel <sect1>Document Header <p> Een manier om een headerdeel aan te maken is door deze gewoon vanuit een ander .sgml bestand te kopiëren. Vervang dan alles behalve de tags door de juiste info voor je document. Dit is net als het gebruik van een "sjabloon". <sect1>Inhoud van het document <p> Na de header komt de inhoud van het document, bestaande uit geneste secties gemarkeerd door sect-tags. Subsecties worden gemarkeerd door sect1-tags. Aangezien dit de eerste subsectie is binnen de 2e hoofdsectie, is het in feite sectie 2.1. Binnen een subsectie kunnen sub-subsecties voorkomen gemarkeerd door sect2-tags, enz. Voor een sub-sub-sub-sectie gebruik je "sect3". Er zijn zelfs tags als sect4 en sect5, maar het is zeer onwaarschijnlijk dat je ze nodig zult hebben. <sect2> Dit is een sub-sub-sectie <p> Het is 2.2.1. Een "p" tag mag op een eigen regel worden gebruikt. Dit wijzigt niets in het resulterende document. <sect> Meer mogelijkheden in voorbeeld3 <p> Met de tags in dit voorbeeld2 kun je een simpel kort document van een paar pagina's lang schrijven. Maar voor langere documenten of voor andere belangrijke mogelijkheden zoals het plaatsen van links in documenten, moet je het volgende voorbeeld bestuderen: voorbeeld3. Het laat je zien hoe je lijsten en fonts kunt creëren. &etago;article> </verb></tscreen> <sect1> Voorbeeld 3 <label id="example_3"> <p> <tscreen><verb> <!doctype linuxdoc system> <!-- Let op de mailto: na mijn naam. Hier kan de lezer op klikken om me email te sturen --> <article> <title>Derde voorbeeld (voorbeeld3) <author>David S. Lawyer <url url="mailto:dave@lafn.org"> <date>v1.0, juli 2000 <abstract> Dit document is het derde voorbeeld over het gebruik van de LinuxDoc variant van sgml. Het is complexer dan het tweede voorbeeld. &etago;abstract> <!-- Opmerking: toc = Inhoudsopgave --> <toc> <sect> Fonts <p> Ondanks dat er in een gewone tekstuitvoerversie niets van is te zien, werkt het wel voor andere conversies. <bf>vet&etago;bf> <em>benadrukt&etago;em> <sf>sans serif&etago;sf> <sl>slanted font&etago;sl> <tt>typewriter font&etago;tt> <it>schuindruk&etago;it> Een andere manier om dezelfde fonts te krijgen is door de tekst te omsluiten door slashes zoals in: <bf/vet/ <em/benadrukt font/ <sf/sans serif/ <sl/slanted font/ <tt/typewriter font/ <it/schuindruk/ <sect> Links <label id="links_"> <p> Je kunt links creëren (iets waar onder htmlbrowsers op kan worden geklikt om naar elders te gaan). Ze kunnen naar een ander deel van dit document (kruisverwijzingen) gaan of naar een website op het Internet. <sect1> Kruisverwijzingen <p> Als je op <ref id="links_" name="Links"> klikt, zal je worden gebracht naar het begin van de "Links" sectie hierboven (gelabeld met links_). Het label-id kan elk uit te kiezen woord zijn, maar het is verstandig algemene woorden te vermijden zodat je kunt zoeken op unieke labels met je editor. Daarom gebruik ik links_ (met het onderstrepingsteken). De naam van deze link zal (in html opmaak) worden weergegeven als de naam waarop kan worden geklikt. Deze naam (Links) zal ook in de tekstweergave verschijnen. <sect1> URL Links <p> Als je op <url url="http://www.linuxdoc.org"> klikt, kom je bij de website van het Linux Documentatie Project. Hierna volgt een link waaraan een naam is toegevoegd waar mensen op zullen klikken: <url url="http://www.linuxdoc.org" name="Linux Documentation Project">. Als je deze tweede methode gebruikt, dan hoef je zelfs niet uit te leggen waarnaartoe deze link leidt, aangezien dit duidelijk uit de naam blijkt. <sect><heading>Verboden tekens</heading> <p> Alles wat je intikt binnen punthaken zal als een tag worden geïnterpreteerd. Maar wat als je een tag in een document wilt laten zien? Hierbij gebruik je voor de punthaken een codewoord. Voor de < kun je $amp;lt gebruiken en voor de > $amp;gt. lt betekent less than (kleiner dan) en gt greater than (groter dan). Hier is bijvoorbeeld een p-tag: &lt;p&gt;. Natuurlijk wordt hiermee in werkelijkheid geen paragraaf gestart, maar het zal in het geconverteerde document verschijnen als een <p>. Deze codes beginnen allen met een &-teken. De ; na de lt is om het te scheiden. Het is niet nodig als er een spatie achter staat. Bijvoorbeeld: 3 &lt 4. In feite is het zo dat als je weet dat het OK is om een niet gepaarde > te gebruiken, je het zou kunnen schrijven als <p> &lt;p>. Dit zal niet per abuis worden herkend als een tag aangezien er geen openings < is. Er zijn ook nog andere tekens die je niet direct in de tekst kunt plaatsen. Voor & in een AT modem opdracht gebruik je: AT&amp;. Zie voorbeeld3 of de "guide" die met linuxdoc-tools of sgml-tools wordt meegeleverd als er nog andere tekens zijn die problemen opleveren. <sect><heading>Verbatim, Code & Newline</heading> <sect1> Verbatim <p> Als je er zeker van wilt zijn dat tijdens de conversie naar andere formaten bepaalde regels niet samen worden gevoegd, gebruik je verbatim (verb). Een aantal zaken worden nog steeds herkend, ook al staan ze binnen de verbatim tags. Dit zijn onder andere de macro's beginnend met & en eindtags beginnend met /. <tscreen><verb> % sgml2txt -f example.sgml &etago;verb>&etago;tscreen> De "tscreen" stelt het font in op typewriter en zorgt dat de tekst fraai inspringt. <sect1><heading>Code</heading> <p> Hiermee wordt computercode omsloten door twee lijnen. <tscreen><code> Plaats hiertussen computerbroncode &etago;code>&etago;tscreen> </p> </sect1> <sect1><heading>Newline</heading> <p> Om een newline te forceren gebruik je <newline> Deze zin begint altijd aan de linkermarge. </p> </sect1> </sect> <sect><heading>Lijsten</heading> <p> Hiermee worden items in een lijst geplaatst met aan het begin van elk item een markering. Ze beginnen met de "itemize" tag. <itemize> <item> Dit is het eerste item in een lijst.</item> <item> Dit is het tweede item <itemize> <item> Meerdere niveaus (nesten) wordt ondersteund.</item> <item> Het tweede item in deze sublijst</item> &etago;itemize> <enum> <item> Genummerde lijsten met gebruik van <tt/enum/ werkt ook.</item> <item> Dit is itemnummer 2</item> &etago;enum> </item> <item> Het laatste item in de hoofdlijst</item> &etago;itemize> &etago;article> </verb></tscreen> <sect1> LinuxDoc beknopte referentiesheet <sect2> Header deel <p> <tscreen><verb> <!doctype linuxdoc system> <article> <title>Beknopte referentiesheet <author>David S. Lawyer <date>v1.0, juli 2000 <abstract> samenvatting hier &etago;abstract> <toc> <!-- Opmerking: toc = Inhoudsopgave --> </verb></tscreen> <sect2> Lay-out van de inhoud <p> <tscreen><verb> <sect> Hoofdstuk 1 Noot: Plaats een <p> op de eerste regel van <sect1> Subsectie 1.1 iedere sectie (of subsectie, enz.) <sect1> Subsectie 1.2 <sect> Hoofdstuk 2 Kies namen van titels ter vervanging van "Hoofdstuk" <sect1> Subsectie 2.1 "Subsectie", enz. <sect2> Sub-subsectie 2.1.1 <sect2> Sub-subsectie 2.1.2 <sect1> Subsectie 2.2 &etago;article> </verb></tscreen> <sect2> Fonts <p> Hier zijn twee manieren voor: <verb> <bf>boldface font&etago;bf> <em>emphasis font&etago;em> <sf>sans serif font&etago;sf> <sl>slanted font&etago;sl> <tt>typewriter font&etago;tt> <it>italics font&etago;it> <bf/boldface/ <em/emphasis/ <sf/sans serif/ <sl/slanted/ <tt/typewriter/ <it/italics/ </verb> <sect2><heading>Lijsten (nesten is OK)</heading> <p> <tscreen><verb> Opsommingen: Genummerde lijst: <itemize> <enum> <item> Eerste item</item> <item> Eerste item</item> <item> Tweede item</item> <item> Tweede item</item> <item> enz.</item> <item> enz.</item> &etago;itemize> &etago;enum> </verb></tscreen> </p> </sect2> <sect2><heading>Links <label id="links_"></heading> <p> <tscreen><verb> Kruisverwijzingen: Een Email Link: <ref id="links_" name="Links"> <url url="mailto:bob@linuxdoc.org"> </verb></tscreen> </p> </sect2> <sect2><heading>Newline, Verbatim, URL's </heading> <p> <tscreen><verb> Om een newline te forceren <newline> <tscreen><verb> <url url="http://www.linuxdoc.org"> <url url="http://www.linuxdoc.org" name="Linux Documentatie Project">. &etago;verb>&etago;tscreen> </verb></tscreen> </p> </sect2> <sect2><heading>Tekencodes (macro's).</heading> <p> <itemize> <item>Gebruik <tt>&amp;</tt> voor de ampersand (&), </item> <item>Gebruik <tt>&lt;</tt> voor een linker punthaak (<), </item> <item>Gebruik <tt>&gt;</tt> voor een rechter punthaak (>), </item> <item>Gebruik <tt>&etago;</tt> voor een linker punthaak met een slash (<tt>&etago;</tt>) </item> <item>Gebruik <tt>&dollar;</tt> voor een dollarteken ($), </item> <item>Gebruik <tt>&num;</tt> voor een hekje (#), </item> <item>Gebruik <tt>&percnt;</tt> voor een procentteken (%), </item> <item>Gebruik <tt>&tilde;</tt> voor een tilde (˜), </item> <item>Gebruik <tt>``</tt> en <tt>''</tt> voor aanhalingstekens, of gebruik <tt>&dquot;</tt> voor &dquot;. </item> <item>Gebruik <tt>&shy;</tt> voor een zacht koppelteken (dat wil zeggen, een indicatie dat dit een goede plek is om een woord of horizontale uitlijning af te breken). </item> </itemize> <sect><heading>Verkrijgen/Gebruiken van de LinuxDoc Software</heading> <p>Je zou een LinuxDoc document kunnen schrijven zonder in het bezit te zijn van enige LinuxDoc software. Het is echter zeer waarschijnlijk dat er wat fouten in de tags voorkomen (of het gebruik ervan) waardoor het naar je zal worden teruggestuurd ter correctie. Zelfs als er geen fouten instaan, kan het zijn dat het resultaat er niet echt goed uitziet. Dus het beste is als je de software hebt om de broncode op je computer om te zetten. De Debian distributie van Linux bevat een linuxdoc-tools package. Voor niet-Debian distributies is er ook een rpm-package. Het werd voorheen sgml-tools genoemd en versie 1.0.9 (de laatste) kan nog steeds bruikbaar zijn als je niet aan de linuxdoc-tools kunt komen. Gebruik niet het sgmltools-2 package dat primair bedoeld is voor DocBook. Voor gebruik pas je converteerprogramma's toe op de *.sgml bestanden. Typ bijvoorbeeld: "sgml2txt -f my-HOWTO.sgml". Voor type html: "sgml2html my-HOWTO.sgml". Als er fouten worden weergegeven zal het regelnummer en het kolomnummer worden getoond van de lokatie waar de fout werd gevonden in het bronbestand. Door het typen van "man -k sgml" zou je een aantal programma's met een éénregelige beschrijving van elk programma te zien moeten krijgen. <sect><heading>Schrijven van de HOWTO</heading> <sect1><heading>Voor je begint te schrijven</heading> <p>Stuur eerst een email naar de HOWTO coördinator Greg Ferguson <url url="mailto:linux-howto@metalab.unc.edu"> of <url url="mailto:feedback@linuxdoc.org">. Wanneer je een onbeheerde HOWTO overneemt, neem je eerst contact op met de auteur. Dit kan vereist zijn door de copyright-licentie, maar je zou het uit beleefdheid moeten doen ook al is het niet vereist. </p> </sect1> <sect1><heading>Richtlijnen</heading> <p> Deze zijn voornamelijk afkomstig van Tim Bynum (voorheen HOWTO coördinator). <itemize> <item> Zorg ervoor dat je een geaccepteerd formaat gebruikt (zoals LinuxDoc :-). </item> <item> Probeer een betekenisvolle structuur en organisatie te gebruiken, en schrijf duidelijk. Denk eraan dat veel van de mensen die HOWTO's lezen als moedertaal geen Engels spreken. </item> <item> Zorg dat alle informatie correct is. Ik kan dit niet genoeg benadrukken. Bij twijfel, speculeren, maar maak duidelijk dat je slechts gist. Ik gebruik ?? als ik er niet zeker van ben. </item> <item> Zorg dat je de meest recente versie van de beschikbare software behandeld. </item> <item>Overweeg een "FAQ" sectie op te nemen. Het kan ook de naam "Algemene Problemen" of "Probleemoplossing" krijgen. </item> <item> Zorg dat het copyright op je naam staat en voeg een licentie toe die tegemoet komt aan de vereisten uiteengezet in de LDP manifesto. </item> <item> Gebruik de standaardheader met de titel, auteur en datum. (inclusief een versienummer). Zie <ref id="example_3" name="Voorbeeld 3"> </item> <item> Wees er als laatste op voorbereid dat je via email vragen en opmerkingen van lezers zult ontvangen. Hoeveel je mensen helpt is aan jou, maar je zou gebruik moeten maken van goede suggesties en verslagen met fouten. Het kan ook zijn dat je via email "dank je" te horen krijgt als ook email zal ontvangen van mensen die je om hulp vragen die zelfs je HOWTO nog nooit hebben ingekeken. </item> </itemize> </p> </sect1> <sect1><heading>Aanleveren van de HOWTO, enz.</heading> <p> Nadat je de HOWTO hebt geschreven, email je de SGML-broncode naar submit@linuxdoc.org. Dan hoef je de HOWTO alleen nog bijgewerkt te houden door periodiek updates aan te leveren via hetzelfde emailadres dat je gebruikte voor de eerste editie. </p> </sect1> </sect> <sect><heading>Meer informatie</heading> <p>Er is een HOWTO op komst over LinuxDoc die het in veel meer detail beschrijft dan deze mini-HOWTO. Zal ergens in april 2001 (??) worden uitgegeven. </p> </sect> </article> </linuxdoc>