<!doctype linuxdoc system>
<article>
<title>HOWTOs with LinuxDoc
<author>David S. Lawyer
<date>v0.09, November 2007
<abstract>

Questo testo tratta di come scrivere gli HOWTO usando il semplice
linguaggio a marcatori (markup) LinuxDoc. &Egrave; rivolto
principalmente agli autori del Linux Documentation Project (e ad autori
futuri alle prime armi che vogliono iniziare rapidamente). Se si vuole
usare DocBook, il linguaggio a marcatori pi&ugrave; completo e difficile,
(incluso XML), vedere la LDP Authoring Guide (Guida per gli autori di
LDP). Traduzione ed adattamenti in italiano a cura di Beatrice Torracca,
beatricet (at) libero (dot) it, e Hugh Hartmann, hhartmann (at) libero
(dot) it, revisione a cura di Vieri Giugni, v.giugni (at) gmail (dot) 
com).
Per versioni aggiornate di questo documento, e per trovare altra documentazione
in italiano sul software libero, visitare il sito dell'<url name="ILDP"
url="http://it.ildp.org">

<toc>
<!-- Change log
v0.09 Put old workaround for fixed -f option bug in appendix. Revised
  comparing to docbook.
v0.08 July. 2007 -f option fixed so it does "-P-cbou", LDP's url is tldp,
  LinuxDoc finds omitted tags, etc., "Entities" heading fixed
v0.07 Apr. 2007 Passed "-P-cbou" to groff via pass option of sgml2txt.
  Explained. 
v0.06 Dec. 2006 Corrected explanation re why fix below works.
  Updated procedure for submissions
v0.05 Oct. 2005: Fix for escape sequences in text output.  Fix link
  to linuxdoc howtos.  Docbook XML
v0.04 Jan. 2005: Howto Generator
v0.03 Dec. 2003: Character codes are seldom needed, ref to HOWTO, misc
  changes
v0.02 Nov. 2003: Comparison errors: don't need to type release twice
v0.01 generic url for Greg Ferg.  hmtl a flavor of sgml (per D.
Merrill's suggestion but ...)
-->
<sect> Introduzione
<sect1>Per partire immediatamente
<p>Per imparare solamente LinuxDoc, si salti a  
   <ref id="learn_" name="Imparare LinuxDoc">.  Se si vuole iniziare a
   scrivere immediatamente, provare a completare 
   gli spazi vuoti in questo modello, che genera output in formato LinuxDoc: 
   <url url="http://www.nyx.net/~sgjoen/The_LDP_HOWTO_Generator.html"
name="The LDP HOWTO Generator">.
   Pu&ograve; essere usato per iniziare a scrivere il proprio HOWTO e lo
   si pu&ograve; finire in seguito usando un editor di testi sul proprio
   PC.

<sect1>Copyright e licenza
<p>Copyright (c) 2001-7 by David S. Lawyer.  You may freely copy and
   distribute (sell or give away) this document.  You may create a
   derivative work and distribute it provided that you license it in the
   spirit of this license and give proper credits.  The author would 
   like to receive your comments, suggestions, and plans for any
   derivative work based on this.

<sect1>Perch&eacute; si dovrebbe scrivere un HOWTO?
<p>Si conoscono cose su Linux per le quali non &egrave; disponibile
   nessuna buona documentazione libera e che potrebbero essere utili ad
   altri? Anche se non si conosce la materia approfonditamente, 
   &egrave; sempre possibile scriverne se si ha la passione, la
   capacit&agrave; e la volont&agrave; di imparare nuove cose su di 
   essa e se si ha il tempo per farlo. Si &egrave; capaci di scrivere
   chiaramente usando un elaboratore o un editor di testi? Si vogliono
   aiutare migliaia di altre persone e permettere loro, senza alcun
   costo, di leggere ci&ograve; che si scrive? Una volta che il
   documento &egrave; stato scritto, si &egrave; disponibili a 
   ricevere, via posta elettronica, suggerimenti dai lettori e ad usare
   selettivamente queste informazioni per migliorare il proprio HOWTO?
   Si &egrave; favorevoli ad avere il proprio documento disponibile su
   centinaia di siti web in tutto il mondo? Se si pu&ograve; rispondere
   "S&igrave;" a queste domande, allora si &egrave; incoraggiati a
   scrivere qualcosa per il Linux Documentation Project (LDP); ma si sia
   preparati all'idea che ci potrebbe volere pi&ugrave; tempo di quanto
   previsto.

<sect1>Perch&eacute; ho scritto questo documento
<p>Perch&eacute; ho scritto questo documento quando c'&egrave; 
   gi&agrave; una "LDP Authoring Guide" (Guida per gli autori
   LDP)?  Perch&egrave; la guida LDP &egrave; un lavoro lungo e
   dettagliato. Se si desidera iniziare rapidamente, &egrave; necessario
   qualcosa di molto pi&ugrave; semplice e breve.
   Grazie a Matt Welsh per il suo file example.sgml che &egrave; stato
   usato come fonte principale di informazioni per le sezioni di 
   esempio.

<sect>Informazioni sulla scrittura di un HOWTO
<sect1>Copyright
<p>Il copyright di tutti gli HOWTO e degli altri documenti LDP &egrave;
   dei rispettivi autori cosicch&eacute; l'LDP non possiede diritti
   speciali sui vostri scritti. Accetta soltanto quei documenti che 
   hanno una licenza che permetta a chiunque di copiarli e distribuirli.
   Incoraggia gli autori ad usare una licenza che permetta anche modifiche;
   in questo modo, se l'autore smette di mantenere un
   documento, qualcun altro pu&ograve; farlo. Per maggiori dettagli si
   guardi il "Manifesto" di LDP.

<sect1>Scegliere un argomento
<p>Se non si &egrave; sicuri dell'argomento su cui scrivere, guardare
   alcuni dei documenti dell'LDP, inclusi quelli in 
   <url url="http://www.tldp.org/authors/unmaint.html" name="HOWTO non mantenuti">.
   Si scelga un argomento per cui si prova interesse e che necessita 
   di una buona documentazione. Se si trova qualcosa di gi&agrave; 
   scritto e attualmente mantenuto che ha bisogno di essere migliorato, 
   si cerchi per prima cosa di contattare l'autore e di sottoporre
   suggerimenti. Se non si riesce a contattare l'autore, si guardi la 
   licenza per vedere se si &egrave; autorizzati a modificare il 
   documento. Anche nei casi in cui non sia possibile fare modifiche 
   o migliorare il documento, si pu&ograve; comunque scrivere un nuovo
   documento sullo stesso argomento partendo da zero, usando un'altra
   impostazione e nuove fonti di informazione.

<sect>Il formato degli HOWTO
<sect1>Introduzione
<p>Gli HOWTO dell'LDP sono rilasciati al pubblico in vari formati: testo
   semplice, HTML, PostScript e PDF.  Invece di dover scrivere lo stesso
   HOWTO in tutti questi formati, si scrive solamente un HOWTO in un
   formato sorgente, DocBook o LinuxDoc, che viene convertito dal
   computer in tutti gli altri.

   Per avere un'idea di come appaia questo formato basta guardare il 
   file sorgente di una pagina web (se non lo si &egrave; gi&agrave;
   fatto). Si vedranno tante parole racchiuse tra due &lt;parentesi
   angolari&gt;: queste sono chiamate "tag". Queste pagine web (tag e
   tutto il resto) sono in html: <em>Hypertext Markup Language</em>.
   L'LDP usa qualcosa di simile per i propri documenti.

   I linguaggi a marcatori che usa l'LDP soddisfano o i requisiti 
   dello <em>Standard Generalized Markup Language (SGML)</em> o quelli
   di <em>XML</em>. Attualmente LDP usa le due seguenti varianti di
   sgml: <em>LinuxDoc</em> e <em>DocBook</em>, oltre alla variante
   <em>DocBook</em> di XML. &Egrave; interessante notare che l'html 
   nasce come un'altra variante di sgml (ma molte funzioni che vengono
   usate nell'html violano le regole dell'sgml, perci&ograve; non
   &egrave; pi&ugrave; sgml puro).

   Questo mini-HOWTO &egrave; totalmente orientato all'utilizzo di
   LinuxDoc, una variante semplice di sgml. Si pu&ograve; chiamarla
   "linguaggio a marcatori LinuxDoc". Pu&ograve; essere convertita
   automaticamente dal computer in html, testo semplice, postscript, pdf
   e DocBook. &Egrave; molto pi&ugrave; semplice rispetto all'HTML o al
   DocBook e non &egrave; necessario un editor speciale in quanto
   &egrave; facile scrivere i tag (o usare macro per essi) nel proprio
   editor o elaboratore di testi preferito.

<sect>LinuxDoc e DocBook a confronto <label id="ld_vs_db">
<p>Prima di leggere questa sezione &egrave; bene avere almeno una
   conoscenza di base dei tag nei linguaggi di marcatura. Perci&ograve;
   se non si sa bene cosa siano, pu&ograve; essere una buona idea
   guardare l'<ref id="example_1" name= "Esempio 1"> per i marcatori di
   LinuxDoc.
 
   Un modo per fare un paragone &egrave; quello di analizzare HOWTO 
   reali sul sito dell'LDP; per trovarli, fare clic su 
   <url url="http://cvs.tldp.org/go.to/LDP/LDP/howto/docbook/" name="Indice dei DocBook">
   oppure su
   <url url="http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/" name="Indice dei LinuxDoc">.
   
   Si noter&agrave; che i documenti DocBook sono pieni zeppi di tag 
   mentre quelli LinuxDoc hanno meno tag e sono perci&ograve; pi&ugrave;
   leggibili e pi&ugrave; facili da scrivere e modificare. Alcuni 
   documenti sul sito LDP hanno marcatori pi&ugrave; chiari di altri,
   perci&ograve; sarebbe bene guardarne pi&ugrave; di uno.

   Si pu&ograve; inizialmente pensare che DocBook sia pi&ugrave; 
   avanzato poich&eacute; in esso ci sono cos&igrave; tanti tag in
   pi&ugrave;, ma ci&ograve; non &egrave; necessariamente vero. Se si
   crea un documento in LinuxDoc e lo si converte in formato DocBook 
   (con il computer) ci saranno pi&ugrave; tag nella versione DocBook,
   inclusi tag nuovi che non erano presenti nella versione LinuxDoc.
   Perch&eacute;? Perch&eacute; LinuxDoc permette di omettere alcuni 
   tag, mentre DocBook no. In questo senso LinuxDoc &egrave; pi&ugrave;
   flessibile e avanzato di DocBook; non solo permette spesso di
   omettere i tag di chiusura come &etago;title>, ma permette di 
   omettere coppie complete di tag iniziali e finali. In LinuxDoc, per
   esempio, i paragrafi sono separati normalmente da righe vuote invece
   che dalla coppia di tag &lt;p> (&lt;para> in DocBook) e in questo 
   modo i tag di paragrafo raramente sono necessari. Un altro esempio
   &egrave; l'inizio di una nuova sezione in un documento LinuxDoc;
   &egrave; sufficiente scrivere il titolo della sezione dopo il tag
   &lt;sect> mentre DocBook richiede che si racchiuda il titolo in una
   coppia di tag &lt;title>.

   Quando si esegue un programma per convertire LinuxDoc in HTML, per
   esempio, la prima cosa che il programma fa &egrave; di cercare tutti 
   i tag omessi e aggiungerli al documento. Viene aggiunta, per esempio,
   una coppia di tag equivalenti alla coppia &lt;title> dopo un tag
   &lt;sect> (inclusi i tag &lt;sect1>, ecc.).  Perci&ograve;, in un
   certo senso, anche LinuxDoc ha molti tag, ma sono nascosti all'utente 
   per rendere il documento molto pi&ugrave; facile sia da scrivere sia
   da leggere. Nella maggior parte dei casi, l'autore di un documento in
   LinuxDoc non &egrave; a conoscenza dell'esistenza della maggior parte
   dei tag mancanti. Non &egrave; necessario (normalmente) che l'autore
   li conosca, dato che esistono solo nella memoria del computer (o in 
   un file temporaneo) quando il PC fa la conversione da LinuxDoc a un
   qualche altro formato (come HTML). In realt&agrave; &egrave; 
   possibile salvare un file che mostri i tag aggiunti, ma ci&ograve;
   viene fatto per lo pi&ugrave; da programmatori durante il debug di
   codice relativo a LinuxDoc (o da persone come me che sono curiose di
   sapere come funzioni).

   I tag DocBook sono spesso pi&ugrave; lunghi dei loro equivalenti
   LinuxDoc come &lt;emphasis> rispetto a &lt;em>.  Per un breve
   confronto si veda il sito web dell'autore: 
   <url url="http://www.lafn.org/~dave/linux/ld_vs_db.txt" name="Comparison of DocBook to LinuxDoc">
   (Confronto tra DocBook e LinuxDoc).

   Il fatto che molti tag siano omessi durante la scrittura in LinuxDoc
   (ma vengano recuperati dal software) &egrave; tuttavia una sola delle
   ragioni per cui i documenti LinuxDoc hanno meno tag. Un'altra ragione
   &egrave; che DocBook ha in realt&agrave; molti pi&ugrave; tag da 
   usare di quanti non ne abbia LinuxDoc. Quest'ultimo per esempio ha un
   unico tag per il nome dell'autore, mentre DocBook ha tag separati per
   il nome, il secondo nome e il cognome. Perci&ograve; in questo senso
   DocBook &egrave; pi&ugrave; potente di LinuxDoc, ma di converso
   &egrave; pi&ugrave; debole perch&eacute; non pu&ograve; recuperare i 
   tag mancanti. La soluzione a questa dicotomia sarebbe quella di unire
   LinuxDoc e DocBook cos&igrave; da mantenere i vantaggi di entrambi. 
   DocBook dovrebbe allora abbandonare il suo attuale stato di 
   linguaggio "XML" poich&eacute; quest'ultimo vieta l'omissione di tag 
   ed altro, mentre SGML lo permette.

   Uno dei motivi per cui non &egrave; permesso omettere tag in DocBook
   &egrave; che ci&ograve; rende pi&ugrave; facile per i programmatori 
   la scrittura di software che lo analizzi e lo converta in altri
   formati. Non &egrave; necessario che il software sia capace di
   individuare e aggiungere i tag mancanti. Fare in modo che le 
   cose siano pi&ugrave; semplici per i programmatori, le rende
   per&ograve; pi&ugrave; difficili per il molto pi&ugrave; vasto numero
   di scrittori che devono usare DocBook.

   Ci sono editor o elaboratori di testo speciali, come Lyx e Bluefish,
   che rendono pi&ugrave; facile scrivere documenti DocBook.  Bluefish, 
   per esempio, aggiunge automaticamente i tag di chiusura.  Per coloro 
   che non vogliono imparare ad usare un nuovo editor o elaboratore di 
   testo, LinuxDoc &egrave; per&ograve; molto pi&ugrave; facile dato che
   si possono inserire i tag a mano o creare un insieme di macro per 
   inserire i tag.  Io uso l'editor vim e se digito ;s esso inserisce il
   tag &lt;sect1>;  ;r inserisce &lt;sect>, ;i inserisce &lt;item>, 
   eccetera.  Per i tag delle intestazioni nelle prime righe di un
   documento, basta copiarle da un altro documento e cambiare le parole
   dopo i tag. Naturalmente io non devo modificare il nome o l'indirizzo
   dell'autore. Un grande vantaggio di LinuxDoc &egrave; perci&ograve; 
   di poterlo usare facilmente con lo stesso editor o elaboratore di 
   testi normalmente utilizzato e con cui si ha familiarit&agrave;.

   Alcune persone che non capiscono la situazione hanno sostenuto l'idea
   che DocBook pu&ograve; essere semplice come LinuxDoc semplicemente 
   usando un sottoinsieme dei tag DocBook. Ci&ograve; non funziona
   perch&eacute; con DocBook continua ad essere necessario un numero di 
   tag diverse volte pi&ugrave; grande di quello necessario per ottenere 
   lo stesso risultato in LinuxDoc a causa del fatto che DocBook non 
   permette l'omissione di tag.

   Nonostante i vantaggi di LinuxDoc, il numero di persone che usa
   DocBook &egrave; molto pi&ugrave; grande di quello delle persone che 
   usano LinuxDoc, in parte perch&eacute; DocBook &egrave; stato 
   promosso dalle case editrici. Esiste un programma di Reuben Thomas 
   (ld2db) che pu&ograve; convertire documenti LinuxDoc in DocBook. Non 
   &egrave; perfetto e molto probabilmente sar&agrave; necessario fare 
   modifiche manuali. Inoltre l'LDP converte automaticamente un HOWTO 
   scritto in LinuxDoc in formato DocBook, dopo che questo &egrave; 
   stato consegnato. Sarebbe bello se esistesse un altro programma che
   convertisse automaticamente i documenti DocBook in LinuxDoc in modo 
   da permettere la loro modifica usando il pi&ugrave; semplice 
   linguaggio a marcatori LinuxDoc.

<sect>Imparare LinuxDoc <label id="learn_">
<sect1>Introduzione
<p>LinuxDoc &egrave; molto pi&ugrave; facile da imparare rispetto a 
   DocBook. Molto di ci&ograve; che si impara riguardo LinuxDoc, 
   tuttavia, sar&agrave; utile anche per DocBook. Cos&igrave;, se 
   eventualmente si decidesse di usare DocBook, la maggior parte dello 
   sforzo speso per l'apprendimento di LinuxDoc non sar&agrave; 
   sprecato.

   Un modo per imparare LinuxDoc &egrave; attraverso degli esempi. Ho 
   scritto tre file d'esempio di difficolt&agrave; che va da facile a
   intermedia. Il contenuto di questi file &egrave; stato copiato in 
   questo HOWTO. Per trasformarli in file individuali si pu&ograve; 
   tagliarli dal testo (partendo dal primo tag) e scriverli in un file. 
   Poi si pu&ograve; tentare di trasformarne uno in un testo semplice 
   usando ad esempio "sgml2txt --pass="-P-cbou" un-esempio.sgml" per 
   vedere come appare. Assicurarsi che i nomi dei file finiscano in
   .sgml.

   Se si desidera vedere alcuni esempi reali si pu&ograve; andare su un 
   sito mirror di LDP, trovare gli HOWTO e selezionare LinuxDoc SGML. 
   Oppure si pu&ograve; andare direttamente al sito principale: 
   <url url="http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/" name="Indice degli Howto (LinuxDoc)">.
   
   Ora il primo semplice esempio.

<sect1>Esempio 1 (nome file: esempio1.sgml) <label id="example_1">
<p>
<tscreen><verb>
<!doctype linuxdoc system>
<article>
<title>Primo esempio (esempio1)
<author>David S.Lawyer  

<sect>Introduzione
<p>Questo rappresenta un esempio molto semplice di "sorgente" per il 
   sistema di formattazione testi LinuxDoc. Questo paragrafo inizia con 
   un tag di paragrafo (una "p" racchiusa tra due parentesi angolari). 
   Notare che ci sono altri tag, anch'essi racchiusi tra parentesi 
   angolari. Se non si vede nessun tag, allora si sta leggendo un file
   convertito, si cerchi invece il file sorgente: esempio1.sgml
   (che contiene i tag).

   Questo &egrave; il paragrafo successivo. Si noti che solo una riga
   vuota lo separa dal paragrafo precedente.
   Pertanto non  &egrave; necessario mettere un tag "p" al suo inizio.
   Il tag "p" &egrave; necessario solamente per il primo paragrafo di 
   una sezione (appena dopo il tag di sezione). Il suffisso sgml del 
   file significa Standard Generalized Markup Language. Quella che si 
   sta leggendo  &egrave; la variante LinuxDoc di sgml, come specificato 
   nella primissima riga di questo file.

<sect>I tag
<p>I tag sono parole all'interno di parentesi angolari. Il tag "sect" 
   qui sopra marca l'inizio di una nuova sezione di questo documento di
   esempio. La prima sezione era "Introduzione" e ora si sta leggendo la
   seconda sezione intitolata "I tag". Se questo fosse un documento 
   lungo (come ad esempio un libro), una sezione corrisponderebbe ad un
   capitolo.

   Si noti che, all'inizio di questo articolo, ci sono i tag "article" 
   (articolo), "title" (titolo) e "author" (autore). Alla fine di questo
   articolo un tag "/article" ne segna la fine. 
   C'&egrave; dunque una coppia di tag "article", il primo 
   &egrave; il tag d'apertura e il secondo il tag di chiusura. Una coppia di
   tag "article" racchiude dunque l'intero articolo.
   Negli esempi successivi, si vedranno altri tag che 
   vanno in coppia come questi. Essi hanno effetto su tutto quello
   che si trova tra la coppia (il tag iniziale e il tag finale). Ogni 
   tag il cui nome sia immediatamente preceduto dal simbolo "/" &egrave;
   un tag di chiusura.

   Quando questo codice sorgente viene convertito in un altro formato
   (come in formato testo semplice usando il programma sgml2txt) i tag 
   vengono rimossi. I tag aiutano solamente il programma sgml2txt a fare 
   la conversione. Ci sono molti altri tag da imparare; quando questo
   primo esempio &egrave; stato compreso, si passi dunque all'esempio
   successivo, l'esempio 2. Non si devono realmente
   memorizzare i tag, dato che saranno ripetuti (ma con 
   poca o nessuna spiegazione) negli esempi successivi.
&etago;article>
</verb></tscreen>

<sect1>Esempio 2 (nome file: esempio2.sgml)
<p>
<tscreen><verb>
<!-- Questo &egrave; un commento. Viene ignorato quando questo file 
     sorgente viene convertito in altri formati.  -->
<!-- Il tag sotto a questo indica il formato di questo file: 
     LinuxDoc -->
<!doctype linuxdoc system>

<article>

<title>Secondo esempio (esempio2)
<author>David S. Lawyer
<date>v1.0, July 2000

<abstract>
Questo paragrafo rappresenta il sommario. Questo documento &egrave; il secondo
esempio sull'utilizzo della variante LinuxDoc-SGML di sgml. &Egrave;
pi&ugrave; complesso rispetto al primo esempio (esempio1.sgml), ma 
pi&ugrave; semplice del terzo esempio (esempio3.sgml). Dopo averlo
assimilato, si sar&agrave; in grado di scrivere un semplice HOWTO 
usando LinuxDoc. Fine del sommario.
&etago;abstract>

<!-- "toc" = l'indice. Sar&agrave; creato in questo punto. -->
<toc>

<!-- La  parte principale dell'articolo (o del documento) inizia qui. La
     parte soprastante rappresenta una specie di lunga intestazione. -->

<sect>Questo secondo esempio (esempio2.sgml)
<p>A meno che non si abbia confidenza con i linguaggi a marcatori, si 
   dovrebbe leggere prima l'esempio 1. Potrebbe essere utile dare in pasto
   questi file di esempio ad un "traduttore" come sgml2txt, per
   convertirli in testo e notare come il risultato appaia differente 
   ripetto a questo documento "sorgente" con tutti i suoi tag.

<sect>Impaginazione dell'articolo
<sect1>Corpo del documento
<p>Dopo l'intestazione viene il corpo del documento, che consiste
   in sezioni annidate marcate dai tag di sezione ("sect"). Le
   sottosezioni sono marcate con i tag "sect1". Dato che questa 
   &egrave; la prima sottosezione all'interno della seconda sezione 
   principale, essa &egrave; la sezione 2.1. All'interno di una 
   sottosezione marcata da "sect1" ci possono essere sotto-sottosezioni 
   come "sect2". Ci sono persino tag come "sect3", "sect4", ecc., ma 
   &egrave; improbabile che sia necessario usarli. Notare che i tag 
   nell'uso reale vanno racchiusi tra parentesi angolari, < e >.

<sect2>Questa &egrave; una sotto-sottosezione
<p>
   Si tratta della sezione 2.1.1. Si noti che il tag "p" pu&ograve; essere 
   su una riga da solo. Questo non cambia nulla nel documento 
   risultante.

<sect1>Intestazione del documento
<p>Un modo per creare una parte di intestazione consiste nel copiarla da 
   un altro file .sgml. Basta poi sostituire ogni cosa, eccetto i tag, 
   con le informazioni corrette per il proprio documento. &Egrave; come 
   usare un modello.

<sect>Ulteriori caratteristiche nell'esempio 3
<p>Con i tag in questo esempio 2 si pu&ograve; scrivere un semplice
   breve documento lungo qualche pagina. Ma per documenti pi&ugrave;
   lunghi o per altre importanti caratteristiche, come l'inserimento di
   collegamenti all'interno del documento, si deve studiare
   l'esempio successivo, l'esempio 3. Esso mostra anche come 
   creare elenchi e usare tipi di carattere.
&etago;article>
</verb></tscreen>

<sect1>Esempio 3 (nome file: esempio3.sgml)<label id="example_3">
<p>
<tscreen><verb>
<!doctype linuxdoc system>
<!-- Notare il "mailto:" dopo il mio nome. Esso permette al 
     lettore del formato HTML di cliccare sul mio indirizzo di posta
     elettronica per inviarmi un messaggio. -->

<article>
<title>Terzo esempio (esempio3)
<author>David S. Lawyer <url url="mailto:dave@lafn.org">
<date>v1.0, July 2000
<abstract>
Questo documento rappresenta il terzo esempio sull'uso della variante 
LinuxDoc di sgml. &Egrave; pi&ugrave; complesso rispetto al secondo
esempio. 
&etago;abstract>
<!-- Commento: toc = Indice -->
<toc>

<sect>I tipi di carattere
<p>Sebbene non compaiano nell'output in testo semplice, funzionano per
   altre conversioni.
<bf>carattere grassetto&etago;bf>              <em>carattere enfatizzato&etago;em>
<sf>sans serif&etago;sf>                       <sl>carattere inclinato&etago;sl>
<tt>carattere a spaziatura fissa&etago;tt>     <it>carattere corsivo&etago;it>
Un altro modo per ottenere questi stessi tipi di carattere consiste nel
racchiudere il testo con il simbolo "/", in questo modo:
<bf/carattere grassetto/                  <em/carattere enfatizzato/
<sf/sans serif/                           <sl/carattere inclinato/
<tt/carattere a spaziatura fissa/         <it/carattere corsivo/
   Si noti che DocBook non ha tag per i tipi di carattere dunque
   sarebbe meglio non usarli se si ha in progetto di fare la conversione
   in DocBook.

<sect>I collegamenti <label id="links_">
<p>Si possono creare collegamenti (qualcosa su cui si pu&ograve;
   cliccare all'interno di un navigatore html per andare da qualche 
   altra parte). Possono indirizzare semplicemente in un'altra parte di 
   questo documento (riferimenti incrociati), tipo l'etichetta ("label") 
   qui sopra, oppure possono indirizzare ad un sito web in Internet.

<sect1>Riferimenti incrociati
<p>Se si clicca su <ref id="links_" name="Collegamenti"> si 
   viene spostati all'inizio della sezione precedente "I
   collegamenti" (che &egrave; etichettata come "links_"). L'etichetta
   pu&ograve; essere una qualsiasi parola liberamente scelta, ma 
   &egrave; buona norma evitare parole comuni, in modo da poter 
   cercare etichette univoche usando il proprio editor. Per questa
   ragione &egrave; stato usato links_ (con il simbolo di
   sottolineatura). Il nome di questo collegamento viene mostrato 
   (nel formato html) come il nome su cui fare clic. Questo nome
   (Collegamenti) &egrave; presente anche nella versione in puro 
   testo.

<sect1>Collegamenti con URL
<p>Se si clicca su <url url="http://www.tldp.org"> si viene spostati
   sul sito web del Linux Documentation Project. Il successivo 
   collegamento aggiunge un nome su cui gli utenti cliccano:
   <url url="http://www.tldp.org" name="Linux Documentation Project">.
   Usando questo secondo metodo, non si deve nemmeno
   spiegare dove porta il collegamento, in quanto &egrave; ovvio dal 
   nome.

<sect>Caratteri proibiti
<p>Ogni parola scritta tra parentesi angolari viene
   interpretata come un tag. Come fare allora per mostrare un tag in un
   documento? Per questo scopo si usa una parola in codice per i 
   caratteri delle parentesi angolari.

   Si pu&ograve; usare &amp;lt per il simbolo &lt; e &amp;gt per il simbolo 
   >. lt = "less than" (minore di), gt = "greater than" (maggiore di). 
   Per esempio, questo &egrave; un tag p: &amp;lt;p&amp;gt;. 
   Naturalmente di fatto non inizia alcun paragrafo, ma appare
   nei documenti convertiti come &lt;p>. Tutti questi codici iniziano con 
   un carattere "&". Il carattere ";" posto dopo lt serve per 
   separarlo. Non &egrave; necessario se c'&egrave; uno spazio dopo di 
   esso. Ad esempio: 3 &amp;lt 4. Di fatto, se si sapesse che va bene 
   usare un > disaccoppiato si potrebbe scrivere &lt;p> come &amp;lt;p>. 
   Questo non sarebbe riconosciuto erroneamente come tag, dato che
   non c'&egrave; l'apertura <. A dire il vero anche 3 &lt; 4 funziona 
   bene.

   Ci sono altri caratteri che non si possono mettere direttamente nel 
   testo del documento. Per il carattere "&" in un comando AT del modem 
   usare: AT&amp;amp;. Se altri caratteri danno dei problemi (lo fanno
   raramente) si veda 
   <ref id="ch_codes" name="Codici dei caratteri (macro)"> o la "guida" 
   che viene fornita con linuxdoc-tools o sgml-tools.

<sect>Verbatim, codice e a capo
<sect1>Verbatim
<p>Se si vuole essere sicuri che il testo appaia esattamente come lo si
   &egrave; digitato, anche dopo la conversione in altri formati, usare 
   il tag verbatim "verb". &Egrave; utile per creare tabelle, e simili. 
   Tuttavia alcune cose vengono comunque riconosciute come marcatori anche se 
   si trovano tra tag verbatim. Tra queste sono incluse le macro che 
   iniziano con il carattere "&" e i tag finali con il carattere "/".

<tscreen><verb>
% sgml2txt --pass="-P-cbou" esempio.sgml 
&etago;verb>&etago;tscreen>
Il tag "tscreen" imposta il carattere a spaziatura fissa e imposta il
rientro in modo bello da vedersi.

<sect1>Codice
<p>Questo racchiude del codice del 
   computer tra due righe tratteggiate.
<tscreen><code>
Mettere il codice sorgente qui.
&etago;code>&etago;tscreen>

<sect1>A capo
<p>Per andare a capo in modo forzato usare <newline>
   Questa frase inizia sempre al margine sinistro.

<sect>Elenchi
<p>Questo mette elementi dentro ad un elenco puntato con un segno grafico
   all'inizio di ogni elemento. Gli elenchi iniziano con il tag 
   "itemize".
   
<itemize>
<item>Questo &egrave; il primo elemento di un elenco.
<item>Questo &egrave; il secondo elemento.
       <itemize> 
       <item>Sono supportati livelli multipli (annidati).
       <item>Il secondo elemento in questo sottoelenco.
       &etago;itemize>
       <enum>
       <item>Funzionano anche elenchi numerati usando <tt/enum/.
       <item>Questo &egrave; l'elemento numero 2.
       &etago;enum>
<item>Questo &egrave; l'ultimo elemento nell'elenco principale.
&etago;itemize>
&etago;article>
</verb></tscreen>

<sect1>Guida di consultazione rapida di LinuxDoc
<sect2>Intestazione
<p>
<tscreen><verb>
<!doctype linuxdoc system>
<article>
<title>Guida di consultazione rapida
<author>David S. Lawyer
<date>v1.0, July 2000
<abstract>Qui va messo il sommario &etago;abstract>
<toc> <!-- Commento: toc = Indice -->
</verb></tscreen>

<sect2>Impaginazione del corpo
<p>
<tscreen><verb>
<sect>Capitolo 1            Nota: si metta un <p> sulla prima riga di
<sect1>Sottosezione 1.1     ogni sezione (o sottosezione, ecc.)
<sect1>Sottosezione 1.2
<sect>Capitolo 2            Si scelgano nomi di titoli da sostituire a
<sect1>Sottosezione 2.1     "Capitolo", "Sottosezione", ecc.
<sect2>Sotto-sottosezione 2.1.1
<sect2>Sotto-sottosezione 2.1.2
<sect1>Sottosezione 2.2
&etago;article>
</verb></tscreen>

<sect2>Tipi di carattere
<p>Ci sono due modi per ottenerli:
<verb>
<bf>carattere grassetto&etago;bf> &lt;em>carattere enfatizzato&etago;em> &lt;sf>carattere sans serif&etago;sf>
&lt;sl>carattere inclinato&etago;sl> &lt;tt>carattere a spaziatura fissa&etago;tt> &lt;it>carattere corsivo&etago;it>
oppure:
&lt;bf/grassetto/ &lt;em/enfatizzato/ &lt;sf/sans serif/ 
&lt;sl/inclinato/ &lt;tt/spaziatura fissa/ &lt;it/corsivo/
</verb>

<sect2>Elenchi (&egrave; possibile l'annidamento)
<p>
<tscreen><verb>
Normali elenchi non numerati:		      Elenchi numerati:
<itemize>                              <enum>
<item>Primo elemento                   <item>Primo elemento
<item>Secondo elemento                 <item>Secondo elemento
<item>eccetera                         <item>eccetera
&etago;itemize>                             &etago;enum>
</verb></tscreen>

<sect2>Collegamenti <label id="links_">
<p>
<tscreen><verb>
Riferimenti incrociati:	                Un collegamento email:
<ref id="links_" name="Collegamenti">   <url url="mailto:bob@tldp.org">
</verb></tscreen>

<sect2>A capo, verbatim, URL 
<p> 
<tscreen><verb>
Per andare a capo forzatamente: <newline>
<tscreen><verb>
<url url="http://www.tldp.org">
<url url="http://www.tldp.org" name="Linux Documentation Project">.
&etago;verb>&etago;tscreen>
</verb></tscreen>

<sect2>Codici di carattere (macro) <label id="ch_codes">
<p>Non &egrave; sempre necessario usarli.
<itemize>
<item>Usare <tt>&amp;amp;</tt> per la e commerciale (&amp;).
<item>Usare <tt>&amp;lt;</tt> per una parentesi angolare sinistra (&lt;).
<item>Usare <tt>&amp;gt;</tt> per una parentesi angolare destra (&gt).
<item>Usare <tt>&amp;etago;</tt> per una parentesi angolare sinistra con
una sbarra (<tt>&etago;</tt>).
</itemize>

   L'uso di questi &egrave; opzionale e io li uso raramente.  
   <itemize>
   <item>Usare <tt>``</tt> e <tt>''</tt> per aprire e chiudere apici 
   doppi.
   <item>Usare <tt>&amp;shy;</tt> per un soft-hyphen (trattino debole),
   per indicare cio&egrave; che questo &egrave; un buon punto per
   spezzare una parola molto lunga e inserire un trattino per la
   giustificazione orizzontale della riga.
   </itemize>

   Usare i seguenti solo se si hanno problemi in LinuxDoc con essi o se
   non si riesce ad ottenerli nel documento formattato. Io ho dovuto
   usarli raramente.
   
   <itemize>
   <item>Usare <tt>&amp;dollar;</tt> per il simbolo del dollaro
   (&dollar;).
   <item>Usare <tt>&amp;num;</tt> per il simbolo cancelletto (&num;).
   <item>Usare <tt>&amp;percnt;</tt> per il simbolo di percentuale
   (&percnt;).
   <item>Usare <tt>&amp;tilde;</tt> per la tilde (&tilde;).
   <item>Usare <tt>&amp;dquot;</tt> per ".
   </itemize>

<sect>Ottenere/Usare il software LinuxDoc
<p>Si potrebbe scrivere un documento LinuxDoc senza avere alcun
   software LinuxDoc. Tuttavia &egrave; assai probabile che esso 
   contenga errori nei tag (o nel loro uso), cos&igrave; da vederselo
   restituire per le correzioni. Anche se non ci fossero errori, il
   risultato potrebbe non apparire nel modo esatto. Perci&ograve;
   &egrave; meglio avere sul proprio computer il software per convertire
   il proprio file sorgente.

   La distribuzione di Linux Debian ha un pacchetto linuxdoc-tools. 
   Esiste anche un pacchetto rpm per distribuzioni diverse da Debian.
   Precedentemente si chiamava sgml-tools; non si utilizzi il pacchetto
   sgmltools-2 perch&eacute; &egrave; destinato principalmente per
   DocBook.

   Per usare linuxdoc-tools, si eseguono i programmi di conversione sui
   file *.sgml. Per esempio, per ottenere un file di testo con una
   versione successiva alla 0.9.21-0.8 digitare: "sgml2txt -f --blanks=1
   mio-HOWTO.sgml". Per le versioni precedenti, a causa di un bug, si
   deve sostituire -f con --pass="-P-cbou". (Se interessati a maggiori
   informazioni su questo bug, guardare
   <ref id="esc_seqs" name="Il vecchio problema con le sequenze di escape nell'output in testo semplice">.)
   Per ottenere output html digitare: "sgml2html mio-HOWTO.sgml". Se 
   appaiono degli errori, saranno mostrati il numero della riga e della 
   colonna corrispondenti alla posizione dell'errore nel file sorgente.
   Digitando "man -k sgml" dovrebbe apparire un certo numero di altri 
   programmi con una descrizione di una riga per ciascuno, ma non tutti 
   sono per linuxdoc-sgml.

<sect>Errori e messaggi di errore
<sect1>Errori che non creano messaggi di errore
<p>Un errore importante &egrave; quello di dimenticare di mettere un tag
   &lt;p&gt; dopo l'intestazione di una sezione. In quel caso non
   c'&egrave; una fine dell'intestazione della sezione: tutto il
   paragrafo successivo diventa parte dell'intestazione e viene inserito
   nell'indice. LinuxDoc dovrebbe essere migliorato per poter 
   individuare questo tipo di errori; per farlo manualmente, si guardi
   l'indice in formato testuale o html. Per correggere basta inserire 
   il tag "p" mancante.

<sect1>Messaggi di errore
<p>Quando si esegue un programma linuxdoc (sgml2html o sgml2txt, per
   esempio) &egrave; possibile che si ottengano messaggi di errore.
   &Egrave; necessario modificare il documento e correggere gli errori.

   Un errore comune &egrave; la mancanza delle virgolette finali. Se si
   ottiene un messaggio di errore che non ha senso e si nota che nella
   posizione corrispondente all'errore sono presenti delle virgolette 
   (" ") che sono corrette, allora &egrave; probabile che
   l'errore consista nell'aver in precedenza inserito una virgoletta di
   apertura a cui non ne corrisponde una di chiusura. Ad esempio 
   &lt;.... id="mia pagina web &gt;, cos&igrave; che linuxdoc 
   pensa che la virgoletta successiva, che pu&ograve; anche essere molti
   paragrafi dopo la posizione della virgoletta mancante, sia la
   virgoletta di chiusura. Dopo la falsa virgoletta di chiusura si
   aspetta quindi un carattere &gt; che chiuda il tag, ma non lo trova.
   Per trovare e correggere la virgoletta mancante, si ricerchi una 
   " precedente.

   Un unico errore pu&ograve; causare molti messaggi di errore.
   Nell'esempio precedente, vari tag possono essere contenuti 
   all'interno delle virgolette sbagliate mentre non avrebbero dovuto
   essere all'interno di alcuna virgoletta. Di conseguenza linuxdoc non
   li trover&agrave;; ci&ograve; fa s&igrave; che non sappia che un 
   certo tag &egrave; stato aperto e, se trova un tag di chiusura,
   dir&agrave; che un certo tag non &egrave; stato aperto. Per esempio,
   se mancasse il tag &lt;itemize>, allora i tag &lt;item> non avrebbero
   senso per linuxdoc ed esso riporter&agrave; un errore per ciascuno di
   questi tag trovato dopo la falsa virgoletta di chiusura.

   &Egrave; bene sapere che l'uso delle maiuscole o minuscole per i nomi
   dei tag non &egrave; importante, perci&ograve; i messaggi di errore
   saranno mostrati con i nomi dei tag in maiuscolo anche se sono stati
   inseriti in lettere minuscole.

   Capire al meglio i messaggi di errore richiede la conoscenza del
   gergo relativo all'sgml, il che non &egrave; veramente necessario a
   meno che non si ottengano errori che non si riescono a correggere e
   dei quali non si capisce il messaggio di errore. La sezione seguente
   tratta del gergo sgml.

<sect>Gergo nei messaggi di errore
<sect1>Introduzione
<p>Non &egrave; veramente necessario leggere questa sezione a meno che 
   non si abbiano problemi oppure non si abbia la curiosit&agrave; di 
   sapere come funzionano l'sgml e linuxdoc. I messaggi di errore 
   possono contenere parole come "element" (elemento), "entity" 
   (entit&agrave;, o "entities" al plurale), "attribute" (attributo),
   "literal" (letterale) e "delimiter" (delimitatore). Vari elementi,
   entit&agrave; e attributi sono definiti per linuxdoc nel "Data Type
   Definition" (o DTD) per LinuxDoc.  Il DTD non li definisce a parole, 
   ma usa un formato piuttosto criptico per definire la loro sintassi 
   (ma non la loro semantica).

<sect1>Gli elementi
<p>Un "elemento" &egrave; un qualcosa come un tag, ma &egrave; un 
   concetto molto pi&ugrave; ampio. Gli elementi esistono non solo in 
   LinuxDoc, ma in tutti i linguaggi sgml, come ad esempio html. 
   L'intero documento LinuxDoc &egrave; diviso in elementi, ma questi 
   sono annidati; questo significa che alcuni elementi possono comparire
   all'interno di altri elementi. Se si usa il tag &lt;article> per il 
   proprio documento, allora tutto il documento &egrave; l'elemento
   &lt;article>, tranne per il primissimo tag che dice che ci&ograve; 
   che segue &egrave; LinuxDoc. All'interno di tale elemento "article" 
   sono annidati molti altri elementi.

   Ogni paragrafo, per esempio, &egrave; un elemento, anche se i 
   paragrafi sono separati tra di loro da una riga vuota invece che da 
   tag. C'&egrave; per&ograve; un tag implicito che racchiude ogni 
   paragrafo ed il software che analizzer&agrave; il documento LinuxDoc 
   di fatto inserir&agrave; questi tag mancanti. Inserir&agrave; anche i 
   tag finali (di chiusura) dove non era obbligatorio scriverli. In
   questo modo LinuxDoc fa risparmiare molto tempo. Un elemento consiste
   perci&ograve; in un tag di apertura, in uno di chiusura 
   (corrispondente a quello di apertura) e a tutto ci&ograve; che 
   &egrave; racchiuso tra di essi (compresi spesso altri elementi con i 
   loro tag). Si noti che i tag anche se omessi sono tuttavia sempre
   implicitamente presenti. In alcuni casi un tag non racchiude
   alcunch&eacute;, come un tag URL per un collegamento Internet; questi 
   tag sono essi stessi elementi. All'interno dell'elemento "article" si
   trovano elementi "sect" (sezioni) che iniziano con &lt;sect>. 
   All'interno degli elementi "sect" ci sono poi spesso elementi 
   "sect1", ecc.

   Ci sono alcuni casi in cui &egrave; presente un elemento, ma &egrave;
   opzionale l'uso sia del tag di apertura, sia di quello di chiusura.
   Perci&ograve; anche se tale tag non &egrave; presente nel documento, 
   le parti del documento che avrebbbe dovuto racchiudere sono comunque 
   elementi di quei tag mancanti.

   Un'entit&agrave; &egrave; come una definizione di macro. Per esempio, 
   si potrebbe definire il nome "elenco" come significativo dei vari 
   tipi di elenchi. Questa parola elenco viene poi usata nel DTD solo 
   per specificare, per esempio, che &egrave; possibile avere un elenco
   all'interno di un paragrafo. &Egrave; semplicemente un'abbreviazione 
   per l'autore di un DTD. Questo tipo di entit&agrave; non &egrave; mai 
   usato in un documento LinuxDoc. Esiste per&ograve; anche un altro 
   tipo di entit&agrave; che pu&ograve; essere usata all'interno di un
   documento ed &egrave; quella che definisce un carattere speciale come
   &amp;etago per &etago; (inizio del tag di chiusura). Lo si usa, per
   esempio, quando si desidere mettere &etago;article> all'interno di 
   una frase per spiegare cosa significa, in modo che il software che 
   converte il LinuxDoc non pensi che sia davvero la fine dell'articolo.

<sect1>Literal e delimitatori
<p>Un "literal" &egrave; il nome di qualcosa, come il nome 
   su cui si clicca in un collegamento html; pu&ograve; essere formato 
   da una o pi&ugrave; parole. Un delimitatore &egrave; ci&ograve; che 
   separa qualcosa da qualcos'altro. Per una "citazione"
   l'ultima " &egrave; il delimitatore di chiusura. Perci&ograve; 
   per name="mio sito web", il "literal"
   &egrave; 'mio sito web' e i delimitatori di questo 
   "literal" sono i due caratteri ": il primo " 
   &egrave; il delimitatore di apertura e il secondo " il 
   delimitatore di chiusura. Cos&igrave; la frase "manca il 
   delimitatore di chiusura di un literal" significa che ci si 
   &egrave; dimenticati di inserire un " finale dopo un nome.

<sect>Scrivere l'HOWTO
<sect1>Prima di iniziare a scrivere
<p>Per prima cosa ci si iscriva alla lista di discussione andando
   all'indirizzo <url url="www.en.tldp.org"> e si sottoponga la propria
   proposta a questa lista. Se si prende in carico un HOWTO non 
   pi&ugrave; mantenuto, si contatti l'autore precedente. Ci&ograve;
   pu&ograve; essere richiesto dal copyright/licenza, ma andrebbe fatto 
   in ogni caso come forma di cortesia.

<sect1>Linee guida
<p>Queste sono principalmente opera di Tim Bynum (un ex-coordinatore
   degli HOWTO).
<itemize>
<item>Assicurarsi di usare un formato accettato (come il LinuxDoc :-).
<item>Cercare di usare una struttura e un'organizzazione significativa, 
      e scrivere chiaramente. Ricordare che molte delle persone che 
      leggono gli HOWTO non parlano l'inglese come loro prima lingua.
<item>Assicurarsi che tutte le informazioni siano corrette. Non
      insister&ograve; mai abbastanza su questo punto. Nel dubbio, si 
      facciano delle congetture, ma si sia chiari sul fatto che si 
      stanno facendo solamente delle ipotesi. Io uso ?? se non sono 
      sicuro.
<item>Assicurarsi di trattare la pi&ugrave; recente versione del 
      software disponibile.
<item>Prendere in considerazione l'inclusione di una sezione "FAQ"
      oppure delle sezioni "Problemi comuni" o "Risoluzione di 
      problemi".
<item>Assicurarsi di mettere nel copyright il proprio nome e di 
      includere una licenza che soddisfi i requisiti dichiarati nel 
      manifesto di LDP.
<item>Usare l'intestazione standard con il titolo, l'autore, la data
      (includendo un numero di versione). Si veda
      <ref id="example_3" name="Esempio 3">.
<item>Da ultimo, prepararsi a ricevere messaggi di posta elettronica
      con domande e commenti dei lettori. Sta alla propria discrezione 
      quanto aiutare gli altri, ma si dovrebbero ascoltare i buoni 
      suggerimenti e le segnalazioni di errori. Si potrebbero anche 
      ricevere dei messaggi di ringraziamento.
</itemize>

<sect1>Sottoporre l'HOWTO, ecc.
<p>Dopo aver scritto l'HOWTO, inviare via posta elettronica il sorgente 
   SGML all'indirizzo: submit@tldp.org. Successivamente tutto ci&ograve; 
   che &egrave; necessario fare &egrave; tenere aggiornato l'HOWTO 
   sottoponendo periodicamente gli aggiornamenti allo stesso indirizzo 
   di posta usato per la prima edizione.

<sect>Ulteriori informazioni
<p>C'&egrave; un HOWTO, il Linuxdoc Reference, che tratta LinuxDoc in 
   modo molto pi&ugrave; dettagliato di quanto non faccia questo 
   mini-HOWTO.

<sect>Appendice
<sect1>Il vecchio problema con le sequenze di escape nell'output in
testo semplice <label id="esc_seqs">
<p>Prima della versione 0.9.21-0.8 c'era un bug nell'output in formato
   di testo semplice. Per sgml2txt, era necessaria l'opzione
   --pass="-P-cbou" per ottenere l'output in puro testo dato che
   altrimenti, se si usava l'opzione -f, si otteneva un output di testo 
   che metteva l'enfasi sulle parole e sulle lettere usando sequenze di 
   escape e sovrascrittura. L'esempio di un pallino creato con la
   sovrascrittura &egrave; +^Ho che in una stampante stamperebbe "+", 
   poi tornerebbe indietro di uno spazio (^H, backspace) e quindi 
   stamperebbe "o" sopra al "+" esistente. Questo non sembra funzionare 
   sui terminali (non possono sovrascrivere). Notare che anche se si ha 
   la versione pi&ugrave; recente, si ottiene sempre questo output non 
   voluto se non si usa l'opzione -f.

   In caso si sia interessati ai dettagli, --pass passa l'opzione 
   -P-cbou al programma groff (usato da sgml2txt) e l'opzione -P di 
   groff passa le opzioni -cbou a grotty (un post-elaboratore per 
   groff), forzandolo a generare solamente output in puro testo. Vedere 
   la pagina di manuale di grotty. In breve, -c evita le sequenze di 
   escape, ma permette la sovrascrittura, -bou tuttavia proibisce la
   sovrascrittura quando &egrave; usata l'opzione -c. Il risultato 
   &egrave; l'assenza di sovrascritture e di sequenze di escape
   nell'output. -b proibisce la sovrascrittura per far apparire un
   carattere in grassetto, -u previene l'uso della sovrascrittura per
   sottolineare e -o proibisce altri tipi di sovrascrittura quale 
   l'esempio del pallino sopra citato. Un modo alternativo per eliminare 
   la sovrascrittura &egrave; di usare l'opzione -f con sgml2txt, ma 
   &egrave; sempre necessario passare l'opzione -c a grotty per 
   eliminare le sequenze di escape, a meno che non si abbia la versione
   pi&ugrave; recente.

   Che confusione!  L'opzione predefinita dovrebbe probabilmente essere 
   il puro testo, cos&igrave; da rendere tutte queste opzioni non
   necessarie. Finalmente sono riuscito a far correggere tutto 
   ci&ograve;, perci&ograve; da met&agrave; 2007 in poi, si pu&ograve; 
   usare solamente l'opzione -f invece di --pass="-P-cbou".  Se si 
   ottengono queste sequenze di escape e sovrascritture nel proprio file 
   di output, ma si usa il comando Linux "cat" per visualizzare il 
   testo, il risultato &egrave; molto bello. L'uso di paginatori o di 
   editor sul file output di testo tuttavia ha spesso come risultato 
   danni ai caratteri di escape, cos&igrave; che si vedono nel proprio 
   testo un mucchio di caratteri non desiderati, che avrebbero dovuto 
   far parte delle sequenze di escape. In alcuni casi i paginatori 
   possono mostrare alcune sovrascritture correttamente, ma gli editor 
   (come vim) non lo fanno. Eliminare tutte le sovrascritture permette
   perci&ograve; di usare un qualsiasi editor o paginatore per leggere.
</article>
