[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
Il sistema standard utilizzato inizialmente per la documentazione di GNU/Linux si è basato sul DTD Qwertz, dal quale hanno avuto origine una serie di derivazioni e di strumenti di composizione SGML che hanno avuto una certa importanza.
In questo capitolo si intende mostrare solo il funzionamento essenziale di alcuni di questi strumenti di composizione; in particolare LinuxDoc e DebianDoc.
Tra tutte le derivazioni di strumenti di composizione SGML basati originariamente sul DTD Qwertz, DebianDoc sembra essere stato il sistema più coerente, con il quale si garantiva la composizione tipografica dal formato PostScript alla pagina di manuale pura e semplice.
La struttura di un sorgente SGML secondo il DTD LinuxDoc è generalmente la seguente:
|
Con l'istruzione <!DOCTYPE linuxdoc SYSTEM> si afferma di voler utilizzare il DTD linuxdoc. Il documento è delimitato dall'elemento article che rappresenta uno tra i diversi tipi di struttura possibile del documento. Il DTD LinuxDoc è derivato dal Qwertz che è strutturato in modo da imitare il comportamento di LaTeX. In questo modo, nel DTD originale sono previste diverse strutture, tutte riferite ad analoghi tipi di documento LaTeX. La tendenza generale è quella di utilizzare sempre solo la struttura article, soprattutto perché lo scopo di SGMLtools è stato quello di permettere la trasformazione del sorgente SGML in un grande numero di altri formati, non solo LaTeX.
Dopo l'inserimento dell'elemento title e di tutto ciò che deve contenere (titolo, autore, descrizione del documento), è possibile inserire il marcatore <toc>, con il quale si intende ottenere un indice generale.
Dopo l'indice generale inizia il testo del documento, suddiviso in sezioni, il cui inizio è evidenziato dai marcatori: <sect>, <sect1>, <sect2>.
Attraverso SGMLtools, si ottiene un documento finale a partire da un sorgente SGML. Per questo, si elabora il sorgente come si fa con un linguaggio di programmazione durante la compilazione. La prima fase è il controllo di validità.
sgmlcheck sorgente_sgml |
Una volta verificata la correttezza formale dal punto di vista del DTD, si può richiedere la trasformazione in un altro formato. Nell'elenco seguente vengono mostrati solo alcuni tipi di trasformazione, i più importanti. In effetti non tutto funziona nello stesso modo e alcuni tipi di conversioni sono difettosi.
Quando si progetta di realizzare un documento attraverso SGMLtools/LinuxDoc, è importante decidere subito quali formati devono essere ottenuti necessariamente, in modo da poter controllare il loro funzionamento dall'inizio dell'opera. Per esempio, il fatto che si riesca a ottenere un formato PostScript corretto, non garantisce che gli altri formati generino un risultato altrettanto buono.(1)
La conversione in LaTeX si ottiene facilmente attraverso il comando seguente:
sgml2latex --output=tex sorgente_sgml |
Viene generato un file con lo stesso nome del sorgente, terminante con l'estensione .tex. Questo file contiene riferimenti a stili addizionali che fanno parte del pacchetto SGMLtools. Questo fatto deve essere tenuto in considerazione se si vuole poi rielaborare questo file con LaTeX.
La composizione del documento in PostScript avviene attraverso l'elaborazione successiva da parte di LaTeX, richiamato automaticamente da SGMLtools.
sgml2latex --output=ps sorgente_sgml |
Quello che si ottiene è un file con lo stesso nome del sorgente, terminante con l'estensione .ps.
La conversione in formato HTML viene gestita completamente all'interno di SGMLtools, attraverso il sistema di programmi in Perl che lo compongono.
sgml2html sorgente_sgml |
Si ottengono una serie di file HTML collegati attraverso riferimenti ipertestuali.
SGMLtools ha un supporto limitato per HTML. Precisamente, consente di verificare un file HTML attraverso il DTD HTML 3.2. Si può usare il comando seguente, che è lo stesso visto nel caso dei file SGML.
sgmlcheck sorgente_html |
sgmlcheck determina da solo che si tratta di un file HTML. Comunque, un file HTML corretto dovrebbe iniziare con la dichiarazione seguente:
|
Eventualmente, sono ammissibili anche altre forme,
|
|
dove Draft si riferisce in particolare alla prima stesura della versione 3.2.
Si può osservare che un file HTML apparentemente corretto dato il risultato che si ottiene con il programma usato per visualizzarlo, può contenere un gran numero di errori formali secondo il suo DTD.
Lo standard LinuxDoc, come suggerisce il nome, è quello che si è utilizzato originariamente per la documentazione di GNU/Linux. Del DTD relativo, linuxdoc.dtd, vengono sfruttate ufficialmente solo alcune delle caratteristiche. Per esempio, la definizione dell'incorporazione di immagini e le tabelle sono rimaste come eredità dallo standard Qwertz, ma il loro utilizzo va evitato, preferendo piuttosto l'uso di strumenti SGML basati su DocBook.
Come accennato all'inizio del capitolo, un documento LinuxDoc inizia con un preambolo che descrive il tipo di documento (linuxdoc appunto), lo stile (in questo caso article), il titolo, l'autore e altre informazioni eventuali.
|
Dopo il preambolo può essere collocato un indice generale che viene costruito automaticamente attraverso l'elemento toc. Quindi si può iniziare il corpo del documento suddiviso in sezioni. Al termine, la chiusura dello stile dichiarato nel preambolo definisce la fine del documento.
Lo stile article è quello standard per i documenti LinuxDoc ed è anche quello raccomandato. Consente la suddivisione del documento per sezioni e non per capitoli. Viene chiuso alla fine del documento.
A seconda dello stile di documento utilizzato, la suddivisione del contenuto può avvenire in modi differenti. In pratica, utilizzando lo stile article, la suddivisione avviene solo per sezioni, identificate dall'elemento sect.
sect
sect1
sect2
Ciò significa che una sezione sect può scomporsi in sottosezioni sect1, che a loro volta si possono scomporre in altre sottosezioni di livello inferiore sect2, ecc. In generale, se possibile, è conveniente limitarsi soltanto a due livelli di suddivisione.
|
L'ambiente delimitato da una sezione di qualunque livello, non richiede l'indicazione esplicita della sua conclusione. È invece necessaria l'inserzione dell'indicazione dell'inizio di un paragrafo, subito dopo il titolo della sezione stessa. L'esempio mostrato sopra dovrebbe chiarirne il funzionamento.
Il testo di un documento normale è suddiviso in paragrafi. L'indicazione dell'inizio o della conclusione di un paragrafo è facoltativa. È sufficiente staccare i paragrafi con almeno una riga bianca per dare questa informazione a LinuxDoc. Resta comunque possibile l'indicazione esplicita dei paragrafi attraverso l'elemento p. È obbligatoria l'indicazione dell'inizio del primo paragrafo di una sezione, perché non esiste altro modo per capire quando finisce il titolo (della sezione) e quando inizia il testo.
Si hanno a disposizione tre tipi di elenchi: descrittivo (descrip), puntato (itemize) e numerato (enum).
L'elenco descrittivo è definito dall'elemento descrip. Le parti descrittive di questo elenco sono costituite da elementi tag. Ciò che è contenuto all'interno della sequenza <tag>...</tag> appare evidenziato in un'unica riga e generalmente non può contenere simboli particolari (dipende dal tipo di trasformazione che si vuole ottenere). Per esempio:
|
genera l'elenco seguente:
primo
primo elemento;
secondo
secondo elemento;
terzo
terzo elemento.
|
L'elenco puntato è costituito dall'elemento itemize che si articola in elementi item, che in pratica costituiscono le varie voci dell'elenco. Per esempio:
|
genera l'elenco puntato seguente:
* primo elemento; * secondo elemento; * terzo elemento. |
L'elenco numerato è costituito dall'elemento enum che si articola in elementi item, come nel caso dell'elenco puntato. Per esempio:
|
genera l'elenco numerato seguente:
1 primo elemento; 2 secondo elemento; 3 terzo elemento. |
Generalmente, se il tipo di composizione finale lo consente, gli elenchi possono essere annidati e contenere anche testo normale che viene rappresentato allineato in modo opportuno.
|
L'esempio sopra riportato si traduce in qualcosa che è simile a ciò che segue:
primo
Primo elemento descrittivo.
Continuazione del primo elemento descrittivo.
secondo
Secondo elemento descrittivo.
1 Prima suddivisione.
a Ulteriore suddivisione.
b Ancora un altro punto.
2 Seconda suddivisione.
* Ecco un sottoelenco puntato.
* Un secondo elemento dell'elenco puntato.
3 Terza suddivisione.
terzo
Terzo elemento descrittivo.
|
Si incontra spesso la necessità di includere in un documento del testo letterale. In generale si tratta di listati di programma o cose simili che possono contenere caratteri o simboli che di solito dovrebbero essere scritti utilizzando dei codici macro particolari. Per questo si utilizza l'elemento verb.
Al suo interno è consentito includere un testo che deve essere riprodotto esattamente com'è, spazi e caratteri strani inclusi, utilizzando, quando possibile, lo stesso carattere usato per il testo normale. Per quanto riguarda la libertà di inclusione di simboli, esiste comunque una piccola limitazione:
il simbolo & può essere inserito solo con un codice macro &ero; (mentre nel testo normale si usa la macro &);
la sequenza di simboli minore+barra obliqua (</), usata di solito per iniziare l'indicazione di un marcatore conclusivo, deve essere rappresentata usando il codice macro &etago;.
Di solito, il testo contenuto in questo elemento è preferibile che appaia in un carattere dattilografico. Per questo, generalmente, verb viene a sua volta inserito in un elemento tscreen.
|
Quando si cita del testo o si vuole fare risaltare una nota, si usano rientri e tipi di carattere diversi. Gli elementi utilizzati per questo scopo sono: quote e tscreen.
All'interno dell'elemento tscreen il testo viene riportato tutto con caratteri a larghezza fissa e rientrato leggermente. Di solito viene usato per incorporare l'elemento verb, in modo da poter inserire simboli particolari senza la necessità di doverli convertire.
|
L'elemento quote fa in modo di rientrare leggermente il testo, per fare risaltare che si tratta di una citazione.
|
All'interno di un testo normale è possibile intervenire per modificare l'aspetto del carattere. Generalmente, qualsiasi intervento verso la definizione dell'aspetto del risultato finale è inopportuno in un sorgente SGML. Infatti, SGML dovrebbe servire per definire gli oggetti che compongono il testo e il documento in generale; quindi, è compito dei programmi di conversione attribuire un aspetto particolare al risultato finale.
LinuxDoc consente ancora di intervenire sull'aspetto di alcune parti di testo, attraverso l'indicazione di testi in corsivo, neretto e dattilografico. Resta tuttavia da considerare che queste possibilità sono destinate a scomparire, in favore di una definizione più precisa delle componenti del testo.
L'elemento bf si utilizza per rendere in neretto il testo racchiuso.
|
L'elemento it si utilizza per rendere in corsivo il testo racchiuso.
|
L'elemento tt si utilizza per rendere in carattere dattilografico il testo racchiuso.
|
Possono essere fatti dei riferimenti interni o esterni al documento. Generalmente, all'interno del documento si utilizza l'elemento label come segnaposto e l'elemento ref come puntatore. Per fare dei riferimenti all'esterno del documento, si fa uso dell'elemento url oppure di htmlurl.
Un'etichetta, definita attraverso l'elemento label, permette di marcare una posizione nel documento a cui si vuole poter fare riferimento. Si tratta di un elemento vuoto che contiene un attributo obbligatorio: ID. Questo attributo contiene il valore dell'etichetta che identifica quindi la posizione che si vuole marcare.
|
L'esempio mostra un possibile uso di label per marcare l'inizio di una sezione. In linea di massima, un'etichetta di questo genere permette di fare riferimenti di due tipi: la pagina in cui si trova e il numero della sezione o dell'oggetto, in relazione al contesto in cui si trova. Un'etichetta può apparire nei contesti seguenti:
all'interno di testo normale, facendo riferimento al capitolo e alla sezione in cui si trova;
all'interno di un elemento caption di una figura, facendo riferimento al numero della figura;
all'interno di un elemento caption di una tabella, facendo riferimento al numero della tabella.
È importante che queste etichette-segnaposto non contengano caratteri strani, altrimenti il programma di composizione potrebbe non gestirle correttamente.
Un elemento ref si comporta come puntatore o riferimento a un'etichetta definita attraverso l'elemento label. All'interno di un documento stampato genera un riferimento numerico che dipende dal contesto in cui si trova l'etichetta (il numero della sezione, della figura o della tabella), mentre in un documento HTML genera un riferimento ipertestuale (link).
Si tratta di un elemento vuoto che contiene un attributo obbligatorio, ID, e uno opzionale, NAME. L'attributo ID contiene il nome dell'etichetta a cui si intende fare riferimento, l'attributo NAME viene inserito per dare un nome al riferimento che viene creato quando si genera un documento HTML.
|
Un elemento pageref di comporta come puntatore o riferimento a un'etichetta. All'interno di un documento stampato genera un riferimento al numero della pagina che contiene l'etichetta.(2)
Si tratta di un elemento vuoto che contiene un attributo obbligatorio, ID, destinato a contenere il nome dell'etichetta a cui si intende fare riferimento.
Un elemento url si comporta come riferimento a un URI. All'interno di un documento stampato genera la rappresentazione di questo indirizzo URI, mentre in un documento HTML crea un riferimento ipertestuale vero e proprio. Un elemento htmlurl si comporta in maniera analoga, ma non riporta l'indirizzo URI nel documento stampato.(3)
Si tratta di elementi vuoti che contengono un attributo obbligatorio, URL, destinato a indicare l'indirizzo URI a cui si intende fare riferimento, e uno opzionale, NAME. Si osservi la differenza tra i due tipi di puntatori attraverso l'esempio seguente:
|
Nel primo caso, assieme al valore dell'attributo NAME viene visualizzato anche l'URI, mentre nel secondo viene mostrato solo il valore di NAME.
L'elemento footnote permette di inserire una nota che da stampare a piè di pagina (ma potrebbe non funzionare correttamente nella composizione in HTML).
|
Il sistema è in grado di generare automaticamente l'indice generale del documento e un indice analitico. Per ottenere l'indice generale è sufficiente inserire l'elemento toc (vuoto) subito dopo il preambolo. L'esempio seguente mostra in che modo si può inserire un indice di questo tipo.
|
Ogni tipo di conversione in un formato finale del documento SGML gestisce la generazione dell'indice generale a modo proprio. Di solito sono garantiti solo due livelli di titoli (sezioni).
L'indice analitico potrebbe essere disponibile solo per la conversione attraverso LaTeX. Si ottiene marcando alcune porzioni di testo attraverso l'elemento nidx, oppure ncdx, come nell'esempio seguente:
|
Quanto contenuto all'interno degli elementi nidx e ncdx non viene a fare parte del testo; tutte le conversioni che non possono farne uso lo trattano come un commento da ignorare. La conversione in LaTeX genera corrispondentemente il comando LaTeX \index{...}, ma nel caso particolare di ncdx, vengono aggiunti dei codici di formattazione in modo tale che nell'indice la stringa corrispondente appaia evidenziata con un testo dattilografico.
Per usare in pratica l'indice analitico, occorrono diverse fasi:
la rielaborazione del file indice;
la costruzione di un documento finale attraverso l'indice, in modo da poterlo abbinare al documento principale.
La generazione del file indice avviene attraverso il comando seguente:
sgml2latex --makeindex sorgente_sgml |
Si ottiene un file, il cui nome ha la stessa radice del sorgente SGML e l'aggiunta dell'estensione .idx. Questo file deve essere rielaborato da makeindex che è un programma abbinato alle distribuzioni comuni di LaTeX.
makeindex < indice_generato > indice_rielaborato |
Il file dell'indice rielaborato potrebbe avere la fisionomia dell'esempio seguente:
|
Per giungere a un risultato finale, cartaceo, occorre aggiungergli qualcosa in modo che diventi un documento LaTeX vero e proprio. Come nell'esempio seguente:
|
In tal modo, attraverso LaTeX si può passare alla trasformazione in un documento finale DVI; successivamente, attraverso dvips, si può ottenere una trasformazione in PostScript.
latex documento_latex |
dvips -o documento_ps documento_dvi |
All'interno di un documento è possibile fare riferimento a immagini in formato EPS (Encapsulated PostScript), che vengono utilizzate nella trasformazione in PostScript attraverso LaTeX e dvips. Parallelamente è possibile fare anche riferimento a immagini (di solito equivalenti) in formati diversi, adatti alla trasformazione in HTML.
L'elemento figure racchiude le informazioni necessarie per l'inserzione di un'immagine. All'interno del marcatore di apertura è possibile specificare la posizione prescelta dell'immagine, per la trasformazione attraverso LaTeX, utilizzando l'attributo LOC (location). In pratica conviene quasi sempre utilizzare la stringa htbp che dice a LaTeX di collocare l'immagine nel posto più adatto, cominciando dalla posizione di partenza (here), quindi nella parte superiore della pagina (top), poi ancora nella parte inferiore (bottom) e infine, se ogni tentativo fallisce, in una pagina dedicata (page). Il valore predefinito di questo attributo è tbp con il significato che si può intuire.
|
L'esempio indica di visualizzare l'immagine esempio.ps collocata nella directory figure/ a partire dalla posizione corrente.
L'elemento eps serve all'interno di un elemento figure per definire il file da visualizzare utilizzando l'attributo FILE. Questo file viene poi utilizzato nella composizione in PostScript attraverso LaTeX. Il nome del file che viene fornito non deve contenere l'estensione .ps che è sottintesa e obbligatoria. Un altro attributo obbligatorio è HEIGHT, con cui si definisce l'altezza dell'immagine. L'esempio già mostrato in precedenza, specificava a questo proposito un'altezza di 5 cm. La larghezza viene regolata in proporzione.
L'elemento img serve invece a definire il file da visualizzare per la composizione in HTML. Anche in questo caso si utilizza l'attributo FILE. Al contrario del caso di eps, il nome del file che viene fornito deve essere indicato completo di estensione.
|
L'esempio indica di includere l'immagine esempio.ps, per la composizione attraverso LaTeX, e esempio.jpg per quella in HTML.
L'elemento caption può essere usato all'interno della definizione di una figura per indicare la descrizione o il titolo della figura stessa. All'interno di questa descrizione si può inserire anche un'etichetta, l'elemento label, in modo da permettere un riferimento al numero della figura all'interno del testo.
|
L'esempio inserisce la figura rappresentata dal file esempio.ps, nel caso di trasformazione in LaTeX, oppure esempio.jpg in caso di trasformazione in HTML; inoltre appare una descrizione e un'etichetta per potervi fare riferimento.
All'interno di un documento è possibile inserire delle tabelle, ma questo solo se si intende trasformare il proprio documento in LaTeX. In HTML si riesce a ottenere qualcosa, ma decisamente scadente. Per questo motivo, l'uso delle tabelle deve essere riservato ai casi di effettiva necessità.
Le tabelle sono composte essenzialmente da righe separate da un separatore di riga, dove ogni riga è suddivisa a sua volta in colonne attraverso un separatore di colonna.
L'elemento table delimita la zona di descrizione di una tabella. All'interno del marcatore di apertura è possibile specificare la posizione prescelta della tabella, utilizzando l'attributo LOC (location), che si comporta nello stesso modo di quello utilizzato nell'elemento figure.
L'elemento tabular, interno a table, definisce le caratteristiche di una tabella. All'interno del marcatore di apertura è necessario specificare l'allineamento orizzontale del contenuto delle celle e la separazione di queste attraverso linee verticali. l'attributo utilizzato per questo è CA (Column alignment) e il suo valore consigliabile è una stringa composta da una serie di lettere l, una per ogni colonna esistente nella tabella.
Le righe della tabella sono concluse dall'elemento rowsep, mentre le colonne sono staccate l'una dall'altra attraverso l'elemento colsep. È possibile inserire una linea orizzontale di separazione utilizzando l'elemento hline. Tutti questi elementi di descrizione delle righe, sono vuoti.
Si osservi questo esempio. Si suppone di voler rappresentare una tabella di quattro righe, più una di intestazione, divisa in due sole colonne, secondo lo schema seguente:
|
Il codice necessario è quello mostrato di seguito.
|
Alcuni caratteri che all'interno di LinuxDoc hanno un significato speciale, oltre a quelli che sono al di fuori della codifica ASCII standard, possono essere inseriti nel testo finale utilizzando dei codici macro; precisamente si tratta delle entità standard.(4)
Questi codici macro sono preceduti dalla e-commerciale (&) e seguiti da un punto e virgola. Nel capitolo 333 appare una tabella riferita alle entità standard di uso comune nell'SGML. Si tratta precisamente della tabella 333.26.
La struttura di un sorgente SGML secondo il DTD DebianDoc ricalca quello che si può vedere dall'esempio seguente:
|
Si può osservare una grande affinità con il DTD LinuxDoc, dove spicca in particolare il fatto che le etichette per la realizzazione di riferimenti incrociati sono inserite come attributi ID degli elementi di suddivisione del testo: chapt, sect,...
DebianDoc presume quindi che si tratti di un libro suddiviso in capitoli, gli elementi chapt, quindi in sezioni a vari livelli: sect, sect1, sect2, sect3 e sect4.
È speciale anche l'elemento di dichiarazione dell'indice generale, toc, che prevede l'attributo DETAIL, al quale si deve assegnare il nome del livello di suddivisione che si ritiene indispensabile includere nell'indice generale: nell'esempio mostrato vengono inclusi solo i capitoli e le sezioni del livello iniziale.
Dal punto di vista dell'SGML, DebianDoc è organizzato con un catalogo unico, che contiene le indicazioni seguenti:
|
Queste righe vengono aggiunte al catalogo del sistema, corrispondente a /usr/share/sgml/catalog, che in pratica è un collegamento simbolico al file /etc/sgml.catalog. Leggendo le dichiarazioni del catalogo si intende che il DTD DebianDoc è costituito dal file dtd/debiandoc.dtd, ovvero /usr/share/sgml/dtd/debiandoc.dtd; inoltre, si vede che viene usato un solo file di entità generali: entities/general, ovvero /usr/share/sgml/entities/general.
Attraverso gli strumenti di DebianDoc, si ottiene un documento finale a partire da un sorgente SGML. Per questo, si elabora il sorgente come si fa con un linguaggio di programmazione durante la compilazione.
debiandoc2dvi [-k] [-p formato_carta] file_sgml |
debiandoc2dvips [-k] [-p formato_carta] file_sgml |
debiandoc2html [-k] file_sgml |
debiandoc2info [-k] file_sgml |
debiandoc2latex2e [-k] [-O] [--] file_sgml |
debiandoc2lout [-k] [-O] [--] file_sgml |
debiandoc2ps [-k] [-O] [-1] [-p formato_carta] [--] file_sgml |
debiandoc2texinfo [-k] [-O] [--] file_sgml |
debiandoc2text [-k] [-O] [--] file_sgml |
debiandoc2textov [-k] [-O] [--] file_sgml |
Ognuno di questi comandi elencati rappresenta un modo differente di elaborare e convertire un sorgente SGML scritto secondo il DTD DebianDoc. Il significato dei nomi dovrebbe essere intuitivo: debiandoc2html significa evidentemente «DebianDoc to HTML», ovvero, «da DebianDoc a HTML». Lo stesso vale, più o meno, per gli altri comandi. In breve:
debiandoc2dvi produce un file DVI attraverso l'elaborazione con il sistema di composizione LaTeX;
debiandoc2dvips produce un file PostScript attraverso l'elaborazione con il sistema di composizione LaTeX;
debiandoc2html produce una trasformazione in HTML, distribuita su più file con estensione .html, collocati in una directory il cui nome corrisponde alla radice del file sorgente;
debiandoc2info produce un file di documentazione Info, attraverso il sistema di composizione Texinfo;
debiandoc2lout produce un file adatto per il sistema di composizione Lout;
debiandoc2ps produce un file PostScript, attraverso l'elaborazione del sistema di composizione Lout, in cui le pagine sono ridotte e raddoppiate (ogni pagina A4 ne contiene due A5, a meno che venga utilizzata l'opzione -1);
debiandoc2text produce un file di testo puro e semplice, con un'ampiezza di 79 colonne;
debiandoc2textov produce un file di testo con i codici di arretramento per ottenere gli effetti di evidenziamento e sottolineatura per la visualizzazione su schermo.
Dal momento che DebianDoc è molto simile a LinuxDoc e che la sua documentazione è abbastanza chiara, non è il caso di ripetere le stesse informazioni anche in questo capitolo. Eventualmente si può rileggere quello precedente. Qui vengono mostrati solo i prospetti riassuntivi degli elementi SGML principali di DebianDoc, attraverso delle tabelle.
|
Tabella 344.37. Elementi della struttura generale di un documento DebianDoc.
|
|
Tabella 344.38. Elementi che rappresentano la suddivisione gerarchica del contenuto di un documento DebianDoc.
|
|
Tabella 344.39. Elementi che si utilizzano nel corpo del testo per modificare l'aspetto del loro contenuto in base al significato che rappresentano.
|
|
Tabella 344.40. Riferimenti.
|
|
Tabella 344.41. Elenchi.
|
SGMLtools lite
Ian Jackson, Arno van Rangelrooij, Debiandoc-SGML Markup Manual
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) Per fare un esempio evidente, basta pensare all'inserzione di immagini e a ciò che si può ottenere in un formato finale puramente testuale: niente immagini.
2) Non ha senso nella traduzione HTML.
3) L'elemento htmlurl crea qualche problema quando si vogliono indicare caratteri speciali nell'URI, come nel caso della tilde. Sotto questo aspetto, per evitare problemi, è meglio limitarsi all'uso di url.
4) LinuxDoc cerca di privilegiare in qualche modo l'ambiente matematico di LaTeX. Per richiamarlo è sufficiente delimitarlo attraverso le parentesi quadre, che così non possono essere usate in modo letterale. Come nel caso di altri simboli speciali, anche le parentesi quadre vanno indicate con l'uso di macro.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome sistemi_sgml_basati_su_qwertz.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
