<!doctype linuxdoc system>
<linuxdoc>
<article>
<titlepag>
<title>Howto's-met-LinuxDoc-mini-HOWTO</title>
<author><name>David S. Lawyer,<newline>
Vertaald door: Ellen Bokhorst</name></author>
<date>v0.0.1, Maart 2001</date>


<abstract>
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.
</abstract>
</titlepag>
<toc>

<!-- Change log
v0.01 algemene url voor Greg Ferg. html heeft de voorkeur boven sgml
(volgens D. Merrill's suggestie, maar...)
-->

<sect><heading>Introductie</heading>

<sect1><heading>Kun je een HOWTO schrijven?</heading>
<p> 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.
</p>
</sect1>

<sect1><heading>Copyright (sla dit over als je haast hebt)</heading>
<p> 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:

<enum>
<item> 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).
</item>
<item>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.
</item>
<item>Geef krediet aan de vorige auteurs en mensen die een belangrijke
bijdrage hebben geleverd.
</item>
</enum>
</p>
</sect1>

<sect1><heading>Waarom ik dit schreef</heading>
<p>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.
</p>
</sect1>
</sect>

<sect><heading>Het formaat van HOWTO's</heading>
<sect1><heading>Introductie</heading>
<p> 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 &eacute;&eacute;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 &lt;punthaken&gt;. Dit worden tags genoemd. De
webpagina's maken gebruik van: <em>Hypertext Markup Language</em>. De LDP
maakt voor zijn documenten van iets dergelijks gebruik. 

De talen die het LDP gebruikt, voldoen aan de <em>Standard Generalized
Markup Language</em> afgekort tot <em>SGML</em>. De LDP maakt nu gebruik
van de volgende twee varianten van sgml: <em>LinuxDoc</em> en
<em>DocBook</em>. 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).
</p>
</sect1>
</sect>


<sect><heading>LinuxDoc vergeleken met DocBook</heading>
<p> Een manier om dit te doen is op de LDP-site te gaan kijken
<url url="http://www.linuxdoc.org"> 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
&lt;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:

<tscreen><verb>
<emphasis>release&etago;emphasis> release
<em>release&etago;em>
</verb></tscreen>

Ja, in DocBook moet je het woord "release" tweemaal intikken. Voor het
beginnen van een sectie:
<tscreen><verb>

<sect>
<title>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&euml;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>
&lt;!doctype linuxdoc system>
&lt;linuxdoc>
&lt;article>
&lt;title>Eerste voorbeeld (voorbeeld1)&lt;/title>
&lt;author>&lt;name>David S.Lawyer&lt;/name>&lt;/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&iuml;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>

&lt;title>Tweede Voorbeeld (voorbeeld2)&lt;/title>
&lt;author>&lt;name>David S. Lawyer&lt;/name>&lt;/author>
&lt;date>v1.0, juli 2000&lt;/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&euml;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&euml;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&euml;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&iuml;nterpreteerd. Maar wat als je een tag in een document wilt
laten zien? Hierbij gebruik je voor de punthaken een codewoord.

Voor de &lt kun je $amp;lt gebruiken en voor de &gt; $amp;gt. 
lt betekent less than (kleiner dan) en gt greater than (groter dan). Hier is
bijvoorbeeld een p-tag: &amp;lt;p&amp;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 &amp;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> &amp;lt;p>. Dit zal niet per abuis worden herkend als een tag
aangezien er geen openings &lt; 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;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 &lt;newline&gt;
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>
&lt;tscreen>&lt;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;amp;</tt> voor de ampersand (&amp;), 
</item>
<item>Gebruik <tt>&amp;lt;</tt> voor een linker punthaak (&lt;),
</item>
<item>Gebruik <tt>&amp;gt;</tt> voor een rechter punthaak (&gt),
</item>
<item>Gebruik <tt>&amp;etago;</tt> voor een linker punthaak met een slash 
(<tt>&etago;</tt>)
</item>
<item>Gebruik <tt>&amp;dollar;</tt> voor een dollarteken (&dollar;),
</item>
<item>Gebruik <tt>&amp;num;</tt> voor een hekje (&num;),
</item>
<item>Gebruik <tt>&amp;percnt;</tt> voor een procentteken (&percnt;),
</item>
<item>Gebruik <tt>&amp;tilde;</tt> voor een tilde (&tilde;),
</item>
<item>Gebruik <tt>``</tt> en <tt>''</tt> voor aanhalingstekens, of gebruik
   <tt>&amp;dquot;</tt> voor &dquot;.
</item>
<item>Gebruik <tt>&amp;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
&eacute;&eacute;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&ouml;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&ouml;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>