Firebird Documentation IndexScrivere documenti per Firebird → Gli elementi che si usano più di frequente
Firebird Home Firebird Home Indietro: Impostare il vostro documento DocBookFirebird Documentation IndexRisali: Scrivere documenti per FirebirdAvanti: Lingua e stile

Gli elementi che si usano più di frequente

Elementi gerarchici
Liste
Link
Listati, schermate, vista letterale ed esempi
Tabelle
Immagini
Avvertimenti
Testate di paragrafo
Vari elementi in linea
Considerazioni finali sugli elementi

Questa sezione spiega l'uso degli elementi usati più frequentemente nella documentazione Firebird. Include inoltre molti esempi in formato DocBook XML. Usando uno strumento di scrittura specifico per XML, viene visualizzata una cosa completamente diversa rispetto agli esempi, ma aprendo il file con un editor di testi, o potendo visualizzare nel proprio editor la vista sorgente XML, si dovrebbe vedere appunto il testo XML vero e proprio come negli esempi. Si possono anche studiare i sorgenti XML del modulo del manuale, per vedere come altri autori hanno utilizzato ed applicato i vari marcatori.

Preghiamo di leggere comunque la sezione sugli elementi gerarchici anche sapendo scrivere testi DocBook fluentemente, in quanto contiene alcune linee guida relative al nostro progetto. Dopodiché potete, stante l'ipotesi precedente, saltare il resto delle sezioni su DocBook.

I novizi non siano scoraggiati dalla lunghezza apparente di questa sezione. La raccomandazione è quella di leggere attentamente la sezione sugli elementi gerarchici, e farsi un'idea sulle altre. Non preoccuparsi se qualcosa risulta incomprensile a prima vista, e sopratutto non cercate di imparare tutto a in blocco! Basta aver a portata di mano questa guida scrivendo, e rivedere le sezione degli elementi utili man mano che servono (quando si hanno incertezze).

Elementi gerarchici

La gerarchia più comune è, partendo dalla cima: <set><book><chapter><section><para>. Un libro (book) può anche contenere uno o più <article> (articolo) invece di <chapter>.

Adesso tratteremo alcuni aspetti legati alla struttura del documento.

L'attributo id

Insiemi, libri, capitoli o articoli e le sezioni principali dovrebbero avere un attributo id. Anche altri elementi potrebbero averlo. L'attributo id permette all'elemento che lo contiene di essere referenziato partendo da un'altra parte del documento, e perfino da un altro documento del set. Gli id non sono visibili nel documento reale (tranne che nel sorgente HTML), ma sono utilizzati per generare i nomi di file HTML.

Tutti gli attributi id di un set devono essere univoci e quindi fra loro distinti. Notare che le versioni nelle diverse lingue sono in set diversi, quindi si possono pure lasciare gli id originali in una traduzione.

Per convenzione interna al progetto Firebird, all'interno di un libro o di un articolo, ogni id deve avere un valore che inizia con la stessa parola in minuscolo, esempio usersguide, seguita da un meno, seguiti da una o più parole in minuscolo rempre separate da un meno. Esempi sono usersguide-intro e usersguide-download-install. Attenzione: questa non è una prerogativa di DocBook, ma una convenzione interna nostra.

L'attributo lang per i set non inglesi

Creando un nuovo set, o traducendone uno, bisogna impostare l'attributo lang nell'elemento radice, ad esempio:

<set id="firebird-books-it" lang="it">

Questo assicura che venga generato il testo giusto per note, attenzione, suggerimenti, ecc., e che vengano generati i corretti simboli in base alla lingua. Sarebbe bene definire l'attributo anche all'inizio di ogni documento, nel caso che siano rigenerati fuori del contesto di un set.

Per i set in inglese, l'attributo lang è opzionale.

Titoli

I vari set, libri, articoli, capitoli e sezioni devono avere sempre un title, o come elemento figlio diretto o all'interno di un elemento xxxinfo (vedi oltre). È legale includerlo in entrambi, ma in questo caso i due titoli devono essere identici. Diversamente dall'id, che è un attributo, title è un elemento. E, parimenti, il titolo apparirà nel documento finale.

Se il titolo è lungo, si dovrebbe aggiungere subito dopo un elemento titleabbrev (titolo abbreviato), contenente, appunto, una forma abbreviata del titolo. La ragione è che ogni pagina HTML generata contiene una cosiddetta barra della gerarchia, come dire «voi-siete-qui», sia in cima che in fondo. Questa linea mostra il percorso a partire dalla cima (il set) fino alla pagina in cui siete. I singoli elementi sono cliccabili così oltre a informare dove si è, permette di navigare risalendo agli elementi superiori facilmente. Siccome ha un aspetto migliore quando sta' tutto in una sola linea, viene mostrato pertanto il titolo abbreviato quando l'elemento ne ha uno; altrimenti si usa il titolo. La stessa tecnica viene utilizzata nel pannello della struttura dei documenti PDF (cioè la finestra per navigare rapidamente che è alla sinistra).

Elementi informativi

Scrivendo un libro o un articolo, bisogna includere un elemento bookinfo o un articleinfo all'inizio. All'interno si possono mettere informazioni sull'autore ed altro. Esistono altri elementi xxxinfo, ma raramente se ne ha bisogno.

<book id='usersguide' lang='en'>
  <bookinfo>
    <title>Firebird Users Guide</title>
    <author>
      <firstname>William</firstname>
      <surname>Shakespeare</surname>
    </author>
    <edition>25 January 2006 – Document version 1.2</edition>
  </bookinfo>
  ...
  ...
</book>

Se l'autore è una società, o un'altra organizzazione, o un gruppo a cui ci si può riferire collettivamente, si usa corpauthor invece di author:

<corpauthor>IBPhoenix Editors</corpauthor>

Se ci sono più autori, desiderando nominarli separatamente, si crea un elemento author (o corpauthor) per ciascuno e li si riunisce in un elemento authorgroup tutti internamente all'elemento xxxinfo.

Tipi di sezioni

Gli elementi di sezione sono leggermente diversi dagli altri, in quanto ne esistono due tipi:

  • C'è l'elemento <section> come già anticipato. Può essere usato recursivamente, cioè si può avere una <section> dentro una <section> dentro una <section>... Questo ha il vantaggio di poter muovere intere sottostrutture su e giù per la gerarchia senza dover cambiare i marcatori.

  • Poi ci sono i <sect1>, <sect2> ... <sect5>. Questi elementi devono essere propriamente posizionati, con una <sect1> più esterna, più <sect2> entro la <sect1> ecc. Non si può mettere una <sect3> direttamente in una <sect1>. È meno flessibile di <section>, ma raramente crea problemi. D'altra parte la stessa rigidità è in <set>, <book> e <chapter> ed ugualmente non ci si fa caso.

Nota

Nelle prime versioni di queste guide, era raccomandata per ragioni di presentazione la forma <sectN>. Per miglioramenti successivi nei fogli di stile, questo non è più necessario e si può scegliere come si vuole.

Appendici

Si possono aggiungere uno o più elementi appendix dopo l'ultimo capitolo di un libro, o dopo l'ultima sezione di un articolo. Le appendici possono contenere più o meno tutto quello che può essere contenuto in una section, incluse altre sezioni.

Esempio di struttura

L'esempio seguente da' un'idea di come strutturare il documento:

<?xml version="1.0" encoding="UTF-8"?>

<book id="usersguide" lang="it">

  <bookinfo>
    <title>Firebird - Guida utente</title>
    <author>
      <firstname>Giovanni</firstname>
      <surname>Pascoli</surname>
    </author>
    <edition>25 gennaio 2006 – Documento versione 1.2</edition>
  </bookinfo>

  <chapter id="usersguide-intro">
    <title>Introduzione</title>
    <para>Buongiorno! Questa è l'introduzione alla guida utente
      del RDBMS Firebird.</para>
  </chapter>

  <chapter id="usersguide-download-install">
    <title>Per scaricare ed installare Firebird</title>
    <para>In questo capitolo si mostra come scaricare ed
      installare Firebird.</para>
    <section id="usersguide-download">
      <title>Scaricare Firebird</title>
      <para>Per scaricare Firebird da Internet, per prima cosa andate
        alla seguente URL: ecc. ecc. ecc.</para>
      ...altri paragrafi, e sono possibili eventuali sottosezioni...
    </section>
    <section id="usersguide-install">
      <title>Installare Firebird</title>
      <para>Installare Firebird sul vostro sistema è una cosa così:
        ecc. ecc.</para>
      ...altri paragrafi, e sono possibili eventuali sottosezioni...
    </section>
  </chapter>

  ...altri capitoli ancora...

  <appendix id="usersguide-dochist">
    <title>Elenco (o storia) delle revisioni</title>
    ...ne parliamo dopo!

  <appendix id="usersguide-license">
    <title>Licenza d'uso</title>
    ...ne parliamo dopo!
</book>

Alcuni punti da notare

  • Per prima cosa, notare ancora che i valori degli attributi devono essere sempre fra apici. Ovviamente, usando un editor di attributi, non vanno messi, perchè ci pensa l'editor a farlo.

  • Come si può vedere dall'esempio, i <chapter> e le <section> possono iniziare direttamente con uno o più elementi <para>. Ma attenzione, una volta inclusa una sezione in un capitolo o una sottosezione in una sezione, non si possono più aggiungere elementi <para> dopo di essi, solo internamente ad essi. Solo i buoni editor che riconoscono XML DocBook non permettono di fare un errore simile, ma scrivendo il testo XML DocBook a mano è una di quelle cosa che è bene sapere.

  • Usando un editor XML, è raramente necessario creare un elemento <para> direttamente. Ad esempio, inserendo un elemento <chapter> o <section> con XMLMind XML Editor, viene creato automaticamente un primo <para> vuoto. E quando si digita il tasto INVIO all'interno del testo di un paragrafo, in quel punto il paragrafo viene automaticamente chiuso da un </para> e ne viene aperto uno nuovo.

Saltare il resto delle sezioni sugli elementi conoscendo già tutto sull'argomento elementi di DocBook.

Liste

DocBook ha disponibili diversi tipi di elementi a lista, dei quali, i più frequentemente usati sono i seguenti:

itemizedlist

Una lista itemizedlist viene usata per elencare una serie di cose il cui ordine non è importantissimo:

<itemizedlist spacing="compact">
  <listitem><para>Le arance sono succose</para></listitem>
  <listitem><para>Le mele si dice facciano bene</para></listitem>
  <listitem><para>Molti ritengono i limoni troppo aspri</para>
    </listitem>
</itemizedlist>

Gli oggetti in lista sono generalmente evidenziati con un pallino nel documento finale:

  • Le arance sono succose

  • Le mele si dice facciano bene

  • Molti ritengono i limoni troppo aspri

Senza mettere l'attributo spacing, viene ritenuto normal, che significa che viene inserito uno spazio verticale (usualmente di una linea) tra ogni oggetto in lista.

orderedlist

Si usa una orderedlist quando si desidera evidenziare l'ordine degli elementi:

<orderedlist spacing="compact" numeration="loweralpha">
  <listitem><para>Sumeri 3300 aC – 1900 aC</para></listitem>
  <listitem><para>Impero Assiro 1350 aC – 612 aC</para></listitem>
  <listitem><para>Impero Persiano 600 aC – 330 aC</para>
  </listitem>
</orderedlist>

Per default, vengono messi numeri arabi (1, 2, 3, ...) per elencare gli oggetti, ma si può cambiare attraverso l'attributo numeration. Risultato:

  1. Sumeri 3300 aC – 1900 aC

  2. Impero Assiro 1350 aC – 612 aC

  3. Impero Persiano 600 aC – 330 aC

procedure

Una procedure ha spesso lo stesso aspetto di una orderedlist, ma il significato è diverso: una procedura elenca una serie di passi da eseguire in un preciso ordine:

<procedure>
  <step><para>Apri la serratura</para></step>
  <step><para>Svaligia la casa</para></step>
  <step><para>Fatti arrestare</para></step>
</orderedlist>

Ecco come diventa l'esempio:

  1. Apri la serratura

  2. Svaligia la casa

  3. Fatti arrestare

Dentro uno step si possono includere elementi substeps, che a loro volta possono avere più step.

variablelist

Una variablelist è fatta di varlistentrys, ognuno dei quali contiene un term seguito da un listitem:

<variablelist>
  <varlistentry>
    <term>Marcatore</term>
    <listitem>
      <para>Un testo incluso fra parentesi angolari</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term>Elemento</term>
    <listitem>
      <para>Un marcatore iniziale, un corrispondente marcatore finale,
        e tutto quel che c'è dentro</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term>Contenuto di un elemento</term>
    <listitem>
      <para>Tutto quel che c'è tra due marcatori corrispondenti</para>
    </listitem>
  </varlistentry>
</variablelist>

Risultato:

Marcatore

Un testo incluso fra parentesi angolari

Elemento

Un marcatore iniziale, un corrispondente marcatore finale e tutto quel che c'è dentro

Contenuto di un elemento

Tutto quel che c'è tra due marcatori, iniziale e finale, corrispondenti

Notare che questa lista, che elenca i vari tipi di liste, è anch'essa una variablelist con i nomi degli elementi (itemizedlist, orderedlist, etc.) come termini. La prossima sezione ( i Links ) consisterà di una frase iniziale seguita da una variablelist.

Link

Si possono creare link a destinazioni nel proprio documento, in un altro documento del set, o su internet.

link

link è l'elemento generico per indirizzare ad un altro punto del documento o del set. L'attributo linkend deve essere sempre presente ed il suo valore deve essere l'id dell'elemento a cui ci si vuole collegare (il link target).

Cliccare <link linkend="docwritehowto-introduction-it">qui</link> per
tornare all'introduzione.

Nel documento finale, la parola «qui» sarà il punto caldo (hot text), cioè: il link cliccabile che porta alla destinazione, in questo esempio all'introduzione:

Cliccare qui per tornare all'introduzione.

Attenzione

Per quanto link possa puntare dovunque nell'intero set, si dovrebbe farlo solo se la destinazione è all'interno dello stesso file PDF del link. La versione HTML è in grado di fare qualsiasi hyperlink, ma i link dei PDF non funzionano tra documenti diversi. I nostri PDF sono costituiti da un book o da un article; se la destinazione è fuori del documento è meglio usare un ulink (vedi oltre).

ulink

Si usa un ulink per puntare ad una risorsa Internet. L'attributo url è obbligatorio:

Cliccare <ulink url="http://docbook.org/tdg/en/">questo link</ulink>
per leggere The Definitive Guide on DocBook (in inglese).

Le parole «questo link» genereranno un hyperlink a http://docbook.org/tdg/en/, come questo:

Cliccare questo link per leggere The Definitive Guide on DocBook (in inglese).

email

Si può fare un link ad una posta elettronica con ulink, ma è più facile usare l'elemento email con cui l'indirizzo di email viene visualizzato come un link cliccabile. Questo frammento XML:

Inviare una mail a
<email>[email protected]</email> per 
iscriversi.

genera il seguente risultato:

Inviare una mail a per iscriversi.

Desiderando evidenziare un testo diverso da quello della email di destinazione stessa, si può usare ulink e l'attributo url col protocollo mailto://

Avvertimento

Includendo link ad indirizzi di mail, che siano essi con email o con ulink, o solo menzionandoli nel testo, se il testo viene pubblicato in internet, questi indirizzi di email sono esposti ai rognosi robot cacciatori di indirizzi usati dagli spammer. Questo può aumentare la quantità di porcheria che arriva a quell'indirizzo. È necessario assicurarsi sempre che il proprietario di quell'indirizzo sia d'accordo nel pubblicarlo!

anchor

Un anchor è un elemento vuoto che etichetta un punto esatto nel documento. Essendo completamente invisibile, non viene visto dai lettori, ma può essere utilizzato come destinazione di un link. È utile quando si vuol andare direttamente a metà o alla fine di lungo paragrafo:

<para id="naufrago">
  Bla bla bla bla...
  ed ancora bla bla bla...
  e poi bla bla bla, ma forse non vi ho detto bla bla bla...
  Ed ora un punto interessante del paragrafo a cui voglio arrivare 
  direttamente:
  <anchor id="salvataggio"/>Eccoci qui!
  Ed altri paragrafi continuano interessanti 
  ( come un convegno di tromboni... )
  e dai, e dai, e dai...
  e non finiscono più...
</para>

Avendo messa l'ancora (anchor), si può creare il link ad essa:

<link linkend="salvataggio">Vai al punto interessante</link> nel
mezzo di quel lunghissimo paragrafo.

Se la destinazione del link è un elemento breve, o l'inizio di un elemento, è più comodo dare all'elemento stesso un id e riferirlo nell'attributo linkend del link.

Listati, schermate, vista letterale ed esempi

programlisting

Per includere frammenti di codice sorgente nel documento, li si mette in un elemento programlisting. Quanto verrà scritto in un programlisting verrà reso identico, inclusi a capo, spazi, ecc.. Inoltre il documento sarà stampato con fonti a passo fisso. Il termine «listato sorgente», o «program listing», deve essere inteso in senso lasco: si può usare sia per frammenti di SQL come per esempi di DocBook XML. Questa guida, e specialmente la sezione sugli elementi che si sta' leggendo, è piena di programlisting, così è facile rendersi conto di come appaiono:

La resa di un programlisting è come in questa linea.

Importante

Nel programlisting bisogna limitare la lunghezza della linea a circa 70 caratteri, altrimenti il testo esce dal lato destro del documento PDF. Lo stesso succede per tutti gli altri elementi che impongono la conservazione del formato, come screen, literallayout, ecc.

screen

Si usa un elemento screen per mostrare ciò che un utente vede o potrebbe vedere sullo schermo di un computer in modalità testo, o in una finestra terminale. Anche in questo caso lo schema viene conservato e si usa una font a passo fisso, ma la semantica è diversa. La resa potrebbe essere del tutto diversa (oppure per niente) da un programlisting. Questo è un breve esempio, giusto per mostrare che succede cercando di ricostruire un modulo inesistente dell'albero del modulo del manuale (notare: il primo è un programlisting, il successivo è effettivamente uno screen):

<screen>
D:\Firebird\manual_incl_howto\src\build>build ugh
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

Buildfile: build.xml

BUILD FAILED
Target `ugh' does not exist in this project.
</screen>

E questo è quel che ne risulta:

D:\Firebird\manual_incl_howto\src\build>build ugh
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

Buildfile: build.xml

BUILD FAILED
Target `ugh' does not exist in this project.
literallayout

literallayout, al pari di screen e programlisting, lascia intatto il formato ma normalmente non cambia la font, a meno di impostare l'attributo class a monospaced. È ancora più generico dei precedenti nel senso che al contenuto non viene attribuito nessun significato particolare: si può pertanto mettere qualsiasi testo di cui si voglia conservare lo schema.

Esempio:

<literallayout>
The Sick Rose

Oh Rose, thou art sick!
The invisible worm
That flies in the night,
In the howling storm,

Has found out thy bed
Of crimson joy,
And his dark secret love
Doth thy life destroy.

  — William Blake
</literallayout>

Risultato:

The Sick Rose

Oh Rose, thou art sick!
The invisible worm
That flies in the night,
In the howling storm,

Has found out thy bed
Of crimson joy,
And his dark secret love
Doth thy life destroy.

  — William Blake

example

Un example è un esempio formale con un titolo. Di solito gli si da' un id per potergli fare riferimento da altre parti del documento. L'indice degli esempi viene generato automaticamente nella stampa del documento. Spesso si possono trovare anche dei programlisting in un example, oppure screen, para, liste varie, ecc.

Ecco un esempio di example:

<example id="docwritehowto-sql-example">
  <title>Un esempio di SQL</title>
  <para>Con questo comando si possono listare tutti i record della
  tabella COUNTRY:</para>
  <programlisting>SELECT * FROM COUNTRY;</programlisting>
</example>

Il risultato sarà più o mano così:

Esempio 1. Un esempio di SQL

Con questo comando si possono listare tutti i record della tabella COUNTRY:

SELECT * FROM COUNTRY;


Volendo fare un example senza il titolo obbligatorio, si usa un informalexample. Gli esempi informali non sono compresi nell'indice degli esempi.

Tabelle

Non si avranno molte difficoltà a fare tabelle con DocBook, avendo già un po' di pratica con le tabelle in HTML fatte per un sito web. Sebbene differenze ci siano, le tabelle DocBook sono molto più ricche.

Una tabella consiste di un title e di uno o più tgroup, di solito uno solo basta e avanza. L'elemento tgroup ha un attributo obbligatorio: cols. Bisogna impostare il valore dell'attributo al numero di colonne desiderate nel tgroup. Nel tgroup si possono mettere elementi thead, tfoot e tbody. Ognuno di questi può avere una o più row (righe), che a loro volta possono avere tante entry (celle) quante specificate nell'attributo cols. (Si possono raggruppare le celle, ma non entriamo nel dettaglio ora.)

Questa è la struttura basilare. Segue un esempio, prima nel sorgente XML DocBook e poi la tabella risulatante così come risulta nel documento. Si ignorino per il momento i vari <colspec>; sono elementi non obbligatori usati per dare un aspetto migliore.

<table id="docwritehowto–table–dboftheyear">
  <title>LinuxQuestions.org poll: Database of the year 2003</title>

  <tgroup cols="3">
    <colspec align="left" colname="col–dbname" colwidth="2*"/>
    <colspec align="right" colname="col–votes" colwidth="1*"/>
    <colspec align="right" colname="col–perc" colwidth="1*"/>

    <thead>
      <row>
        <entry align="center">Database</entry>
        <entry align="center">Votes</entry>
        <entry align="center">Percentage</entry>
      </row>
    </thead>

    <tfoot>
      <row>
        <entry>Total</entry>
        <entry>1111</entry>
        <entry>99.99</entry>
      </row>
    </tfoot>

    <tbody>
      <row>
        <entry>MySQL</entry>
        <entry>405</entry>
        <entry>36.45</entry>
      </row>
      <row>
        <entry>Firebird</entry>
        <entry>403</entry>
        <entry>36.27</entry>
      </row>

      ... 5 more rows not shown here ....

    </tbody>
  </tgroup>
</table>

E questa è la tabella risultante:

Tabella 2. LinuxQuestions.org poll: Database of the year 2003

Database Votes Percentage
Total 1111 99.99
MySQL 405 36.45
Firebird 403 36.27
Postgres 269 24.21
Oracle 25 2.25
Berkeley DB 4 0.36
Sybase 3 0.27
DB2 2 0.18


Naturalmente, questi sono i risultati di una vera rilevazione fatta a LinuxQuestions.org. Come si può vedere, se solo tre persone avessero votato per Firebird si sarebbe vinto. Se qualcuno le conosce, per favore indicatele al nostro Inquisitore Capo. Desidera tanto fargli un certo «discorsetto»... ☺

Le tabelle vengono automaticamente messe in un loro indice. una informaltable ha la stessa struttura di una table ma non richiede titolo e non viene inclusa nell'indice. Per poter innestare delle tabelle (tabelle in tabelle), o si usa una table/informaltable all'interno di una entry, oppure una entrytbl invece di una entry.

Le tabelle hanno molte altre caratteristiche rispetto a quanto mostrato, ma al momento questo basta, e le altre cose si possono esplorare secondo necessità.

Tabelle HTML

Dalla versione 4.3 di DocBook si possono riempire le tabelle come in HTML, con i tr invece delle row, e td/th invece degli elementi entry. Il motivo? Ci sono due situazioni dove è utile usare le tabelle HTML:

  • Avendo già la tabella HTML pronta, non si deve perdere tempo nel convertirla;

  • Volendo usare differenti colori di sfondo nella tabella, è più semplice. Questo si può fare anche in DocBook, ma solo con Istruzioni di Elaborazione, una per ciascun oggetto di ogni elemento che necessita di un colore specifico. Con le tabelle in HTML si può usare l'attributo bgcolor dell'oggetto.

Una tabella HTML non può avere tgroup; si mettono i tr o direttamente nella tabella o negli elementi thead / tfoot / tbody che sono diretti figli della tabella. Inoltre ha un attributo caption invece di un title. (Ovviamente, una informaltable non nè l'uno nè l'altro.)

Ecco il sorgente di una tabella HTML:

<table bgcolor="blue" border="1">
  <caption align="bottom">Una tabella in stile HTML</caption>

  <tr bgcolor="#FFE080">
    <th>Prima colonna</th>
    <th bgcolor="#FFFF00">Seconda colonna</th>
  </tr>
  <tr align="center">
    <td bgcolor="orange" colspan="2">Cella di tabella che occupa due
      colonne</td>
  </tr>
  <tr>
    <td bgcolor="#00FFC0">Eccomi qui!</td>
    <td align="right" bgcolor="#E0E0E0" rowspan="2" valign="bottom">
    Adesso me ne vado qua!</td>
  </tr>
  <tr>
    <td bgcolor="#FFA0FF">Una riga ancora...</td>
  </tr>
</table>

Ed ecco come viene:

Tabella 3. Una tabella in stile HTML
Prima colonna Seconda colonna
Cella di tabella che occupa due colonne
Eccomi qui! Adesso me ne vado qua!
Una riga ancora...

Non tutti gli elementi e gli attributi di tabella sono supportati dai nostri fogli di stile. Per esempio, non vengono considerate le proprietà specificate negli elementi col e colgroup. Si possono invece specificare negli elementi td e th, oppure estendere i fogli di stile!

Nota

In XMLMind, si possono creare tabelle HTML solo dal menù aperto col pulsante «Aggiungi tabella» sulla toolbar. Dal pannello di edit si possono aggiungere solo normali tabelle DocBook.

La restituzione di tabelle grandi in PDF

Le tabelle DocBook appartengono ad un gruppo chiamato elementi formali. Gli elementi formali sono incluse in indici generati automaticamente (tabelle, figure, ecc.); se un elemento formale non ha un attributo id, il foglio di stile gliene attribuisce uno. Inoltre, il modello che genera il file XSL-FO (è una fase intermedia per ottenere il PDF) da ad ogni oggetto formale l'attributo keep-together.within-page="always" per impedire che ci siano salti pagina all'interno dell'oggetto. Questo di solito va bene, ma che succede se l'oggetto non ci stà in una pagina? Fino a poco fa, abbiamo usato Apache FOP 0.20.5 per rendere il file XSL-FO in PDF. Questo processore semplicemente ignorava l'attributo keep-together se l'oggetto era troppo grande. Ma la versione attuale (Apache FOP 0.93) lo applica sempre. Se l'oggetto è troppo grande, il risultato è che viene troncato o distrutto in qualche altro modo per farlo rientrare nella pagina. Questa è una caratteristica, non un problema, per cui non ci si può lamentare.

Ci sono due modi per aggirare il problema se una tabella diventa troppo grande per stare in una pagina:

  1. Se la tabella non ha bisogno di un titolo e non interessa che sia inclusa nella lista delle tabelle, si può usare al suo posta una informaltable.

  2. Si può inserire una istruzione di elaborazione all'inizio della tabella:

    <table frame="all" id="ufb-about-tbl-features">
       <?dbfo keep-together='auto'?>
       <title>Summary of features</title>

    In XMLMind, si fa così:

    1. Mettere il cursore da nel titolo oppure selezionare tutto l'elemento del titolo.

    2. Dal menù, selezionare Modifica -> Elabora Istruzione -> Inserisci Istruzione di Elaborazione Prima. Una linea in cui il testo sarà verde apparirà sopra il titolo.

    3. Digitare keep-together='auto' su quella linea.

    4. Con il cursore ancora su quella linea, nel menù selezionare Modifica -> Elabora Istruzione -> Cambia l'Obiettivo dell'Istruzione di Elaborazione... . Compare una finestra di dialogo.

    5. Nella finestra, modificare il testo target in dbfo e confermare cliccando su OK.

    Naturalmente si può fare lo stesso con tabelle più piccole se le si vuole rendere interrompibili. L'istruzione opposta, <?dbfo keep-together='always'>, impedisce le interruzioni delle tabelle informali, cioè in informaltable. Bisogna accertarsi che l'elemento stia in una pagina prima di farlo, naturalmente.

Immagini

Per includere un'immagine, si usa un mediaobject contanente un imageobject che a sua volta contiene un elemento imagedata:

<mediaobject>
  <imageobject>
    <imagedata align="center" fileref="images/services.png"
      format="PNG"/>
  </imageobject>
</mediaobject>

Ci si potrebbe meravigliare della necessità di avere tre elementi innestati per includere un'immagine. Ci sono buone ragioni, ma non ve lo dirò ;-) — non ci interessano. Tutto quello che c'è da sapere è come si fa..

Indipendentemente da dov'è l'immagine relativamente al sorgente DocBook, l'attributo fileref deve essere sempre del tipo images/filename.ext. Questo perchè, sia per l'HTML che per il FO, i file delle immagini sono tutti copiati nella subdirectory images della directory di uscita. (Il file FO è una forma intermedia, ed una volta convertita in PDF, l'immagine è inclusa nel file.)

Se il fileref non è giusto dal punto di vista del file sorgente, l'immagine non si vedrà in XMLMind. Se da' fastidio, in Linux si può creare un link simbolico alla directory delle immagini mentre in Windows bisogna copiare le immagini nello stesso sottodirettorio del fileref, cioè nel nostro caso images. Sembra che creare dei link in Windows non risolva il problema. Fate questo solo sulla vostra copia privata, non committate archivi di immagini duplicate al repository! (vedi anche la nota qui sotto).

Un mediaobject è formattata come blocco separato. Per fare in modo che l'immagine sia allineata nel testo usare invece un inlinemediaobject; gli elementi interni (cioè imageobject e imagedata) restano gli stessi.

Nota per i traduttori

Per i traduttori (ovvero: non fate come me ☺ ehm…) Ogni immagine che non viene modificata o sostituita da una versione tradotta, non va copiata nelle immagini della propria lingua. A partire dal gennaio 2006, gli strumenti di ricostruzione prima cercano un'immagine nella directory della lingua (ad esempio manual/src/docs/firebirddocs-it/images), e, se non la trovano, cercano in manual/src/docs/firebirddocs/images. In questo modo, usando l'immagine originale, non è necessario sprecare spazio sul CVS duplicandola. La stessa cosa si applica a tutti gli altri insiemi: se un'immagine riferita dalle Note di Rilascio spagnole non si trova in rlsnotes-es/images, viene usata, se esiste, quella in rlsnotes/images. Questo purtroppo non funziona attraverso gli insiemi, cioè da un insieme fare riferimento ad una immagine di un altro insieme.

Avvertimenti

DocBook dispone di vari marcatori per blocchi di testo come note, avvisi, consigli, ecc. Nel documento risultante tipicamente tali blocchi risultano indentati ed evidenziati con una icona o una parola che esplicita lo scopo. Questi marcatori sono, in ordine alfabetico:

<caution>, <important>, <note>, <tip>, e <warning>

e significano, nell'ordine: «attenzione», «importante», «nota», «suggerimento», «avviso». Questo è un <tip> di esempio; gli altri si usano nello stesso identico modo:

<tip>
  <para>Inserendo un elemento di attenzione, importante, nota,
    suggerimento o avviso nel testo, non iniziate con le parole
    attenzione, importante, nota, suggerimento o avviso, perchè 
    queste parole sono usualmente inserite in modo automatico 
    dal sistema di generazione.
  </para>
</tip>

E questo è il risultato:

Suggerimento

Inserendo un elemento di attenzione, importante, nota, suggerimento o avviso nel testo, non iniziate con le parole «attenzione», «importante», «nota», «suggerimento» o «avviso», perchè queste parole sono usualmente inserite in modo automatico dal sistema di generazione.

Si può notare che le parole attenzione, importante ecc. hanno un aspetto diverso dal resto del testo: come mai? A dir la verità sono state incapsulate con alcuni marcatori speciali (prima con <sgmltag>, e poi con <literal>) per dare quell'aspetto. Questo però renderebbe l'originale XML alquanto illeggibile, così si è deciso di rimuoverli dal sorgente di esempio.

Si può dare all'avvertimento un opzionale titolo, con «title». Non facendolo viene dato un titolo di default, nella lingua del documento.

Per evidenziare una parte di testo da quanto gli sta' intorno, senza attribuirgli uno di questi marcatori, bisogna usare un <blockquote>.

Testate di paragrafo

Volendo creare una testata ad un paragrafo, oppure un titolo senza creare una sottosezione, ci sono alcune possibilità.

bridgehead

Un bridgehead è un titolo flottante tra paragrafi, non associato all'inizio di un capitolo o sezione. L'attributo renderas determina come sarà l'aspetto finale.

<para>Il biliardo all'italiana si gioca oggi sul biliardo 
internazionale, che è un tavolo privo di buche di 2,84 m x 1,42 m;
si usano tre biglie e cinque piccoli birilli. Le biglie
destinate ai giocatori sono di colore bianco o giallo, 
il pallino di colore rosso. I birilli, alti circa 2,5 cm, 
sono di colore bianco ad eccezione di quello centrale, che è
di colore rosso.</para>

<bridgehead renderas="sect5">Ma come si gioca?</bridgehead>

<para>I birilli devono essere disposti prima di ogni tiro in posizioni 
ben precise, al centro del tavolo, a formare quello che si suole 
definire castello. Bisogna colpire con la propria biglia quella 
dell'avversario cercando possibilmente di indirizzare quest'ultima 
sui birilli, alla cui caduta è attribuito un punteggio.</para>

Il sorgente qui sopra ha questo aspetto:

Il biliardo all'italiana si gioca oggi sul biliardo internazionale, che è un tavolo privo di buche di 2,84 m x 1,42 m; si usano tre biglie e cinque piccoli birilli. Le biglie destinate ai giocatori sono di colore bianco o giallo, il pallino di colore rosso. I birilli, alti circa 2,5 cm, sono di colore bianco ad eccezione di quello centrale, che è di colore rosso.

Ma come si gioca?

I birilli devono essere disposti prima di ogni tiro in posizioni ben precise, al centro del tavolo, a formare quello che si suole definire castello. Bisogna colpire con la propria biglia quella dell'avversario cercando possibilmente di indirizzare quest'ultima sui birilli, alla cui caduta è attribuito un punteggio.

Si è liberi nella scelta del livello di renderas, ma la scelta più logica sarebbe normalmente quella del corrente livello di sezione più (almeno) uno.

formalpara

Un formalpara è un paragrafo con un titolo. L'aspetto dipende dal foglio di stile, nel nostro caso trasforma il titolo indentando tutto.

<formalpara>
  <title>Amor materno:</title>
  <para>Questo è l'amore che ha tua madre per te, da non confondere 
    con l'amor paterno, fraterno o altrui.</para>
</formalpara>

Il risultato viene visualizzato come segue:

Amor materno: Questo è l'amore che ha tua madre per te, da non confondere con l'amor paterno, fraterno o altrui.

Viene aggiunto un punto alla fine del titolo, a meno che non termini già con un carattere di interpunzione.

Vari elementi in linea

Per concludere la sezione sugli elementi di DocBook, mostriamo ora un certo numero di elementi in linea (inline elements). Sono detti «in linea» perchè non interrompono il fluire del testo. Usando ad esempio un elemento emphasis:

Non chiamarmi <emphasis>mai più</emphasis> ciccione!

Il risultato è:

Non chiamarmi mai più ciccione!

Le parole «mai più» sono enfatizzate, e comunque prende posto nella frase. Abbiamo già visto altri elementi in liknea: i vari tipi di link. Altri elementi, come table, warning, blockquote e programlisting, sono sempre mostrati come blocchi e posti separatamente dal testo intorno, perfino se li metti «inline» nel sorgente XML. Non sorprende che siano chiamati elementi a blocchi o brevemente «blocchi» (block elements). I blocchi contengono spesso elementi in linea, ovviamente non è possibile l'inverso.

Bene, cominciamo a vedere qualcosa sugli elementi in linea. Ci saranno esempi, sia sorgenti XML che il risultato in uscita, per molti di essi:

filenamecommandapplicationenvar

Si usa il marcatore filename per evidenziare nomi di file nel senso più generico possibile. Gli attributi possono opzionalmente indicare se il file è una libreria, un link, una directory, ecc.

Mettere il documento nella directrory <filename
class="directory">src/docs/firebirddocs</filename>.

che si leggerà:

Mettere il documento nella directrory src/docs/firebirddocs.

command e application si usano entrambi per programmi eseguibili. command si usa per piccoli programmi e comandi interni; il suo contenuto dovrebbe essere il comando esatto così come dato in una linea di comando; application è usato di solito per grandi programmi e non necessariamente deve essere il nome dell'eseguibile. Entrambi possono riferire lo stesso programma:

Digitare <command>netscape&amp;</command> in una finestra terminale
per lanciare il <application>Netscape Navigator</application>.

Questo apparirà così:

Digitare netscape& in una finestra terminale per lanciare Netscape Navigator.

envar invece serve per indicare una variabile d'ambiente.

subscriptsuperscript

È immediato intuire cosa fanno:

Dopo la scoperta della formula e = mc<superscript>2</superscript>,
avevo proprio voglia di un bicchiere di H<subscript>2</subscript>O !

Output: Dopo la scoperta della formula e = mc2, avevo proprio voglia di un bicchiere di H2O !

varnameconstantdatabase

L'uso di varname (nome di variabile) e constant (costante) dovrebbero essere ovvii. Il marcatore <database> non è stato previsto solo per i database, ma anche per gli oggetti di database:

La tabella <database class="table">COUNTRY</database> ha due campi:
<database class="field">COUNTRY</database> e
<database class="field">CURRENCY</database>.

Risultato: La tabella COUNTRY ha due campi: COUNTRY e CURRENCY.

functionparameterreturnvalue

Anche questi sono autoesplicativi, credo.

La funzione <function>log</function> ha due parametri
<parameter>a</parameter> e <parameter>b</parameter>.

Risultato: La funzione log ha due parametri a e b.

promptuserinputcomputeroutput

Si usa prompt per una stringa che chiede all'utente di inserire del testo; userinput si riferisce al testo inserito dall'utente (non necessariamente ad un prompt!); computeroutput è il testo mostrato dal computer:

Digitare <userinput>guest</userinput> al prompt
<prompt>login:</prompt> ed il server risponderà con
<computeroutput>Benvenuto, utente guest</computeroutput>.

Risultato: Digitare guest al prompt login: ed il server risponderà con Benvenuto,utente guest.

keycap

Il testo scritto su di un tasto della tastiera, oppure il suo nome comune:

Digitare il tasto <keycap>Del</keycap> per cancellare il messaggio, 
oppure <keycap>SPACE</keycap> per confermarlo.

Risultato: Digitare il tasto Del per cancellare il messaggio, oppure SPACE per confermarlo.

sgmltag

Questo elemento è stato usato moltissimo in questa guida: evidenzia marcatori SGML e XML, elementi, attributi, entità, ecc.:

Se riguarda una directory, impostate l'attributo 
<sgmltag class="attribute">class</sgmltag> dell'elemento
<sgmltag class="element">filename</sgmltag> a
<sgmltag class="attvalue">directory</sgmltag>.

Risultato: Se riguarda una directory, impostate l'attributo class dell'elemento filename a directory.

Altri possibili valori per sgmltag.class sono: starttag, endtag, emptytag, e genentity (per una entità).

emphasiscitetitlefirstterm

Si usa emphasis per evidenziare genericamente delle parole, citetitle per titoli di libri ecc., e firstterm introducendo un nuovo termine o concetto ai lettori:

Si usa <firstterm>DocBook XML</firstterm> per la nostra
documentazione Firebird. Segue una breve introduzione;
<emphasis>per favore</emphasis>, leggetela attentamente!
Per avere ulteriori informazioni al riguardo, comprare il
libro <citetitle>DocBook – The Definitive Guide</citetitle>.

Risultato: Si usa DocBook XML per la nostra documentazione Firebird. Segue una breve introduzione; per favore, leggetela attentamente! Per avere ulteriori informazioni al riguardo, comprare il libro DocBook – The Definitive Guide.

quoteliteral

Usare quote per virgolettare in linea (a differenza di blockquote). Le virgolette vengono messe automaticamente. Usando quote invece di digitare le virgolette (che sarebbe comun que perfettamente legale) ha il vantaggiono che si possono cambiare il tipo di virgolettatura globalmente nel foglio di stile volendolo. Inoltre si diversificano per lingua:

<para>Queste sono <quote lang="en">virgolette inglesi</quote> 
e queste sono <quote lang="fr">virgolette francesi</quote>. 
Invece sono così <quote lang="it">quelle italiane</quote>.</para>

Risultato: Queste sono “virgolette inglesi” e queste sono « virgolette francesi ». Invece sono così «quelle italiane».

Non si dovrebbe usare l'attributo lang nell'elemento quote nei propri documenti. L'attributo lang dell'elemento radice assicura che vengano usate le virgolette giuste. Nella traduzione del vostro documento, e quindi nella modifica alla radice dell'attributo lang, verranno così automaticamente usate le virgolette del linguaggio della traduzione. Ho usato l'attributo in questo caso per mostrare la differenza, e per assicurarmi che le differenti virgolette rimarranno indipendentemente dalla traduzione.

Un literal è una parola o un frammento di testo da prendere alla lettera. È un elemento generico, spesso usato per evidenziare tipograficamente certe parole:

L'ultima parola del vocabolario italiano è 
<literal>zuzzurellone</literal>, credo.

Risultato: L'ultima parola del vocabolario italiano è zuzzurellone, credo.

Ma questi elementi vanno usati sempre e comunque dove è appropriato? Be', facendolo, il documento sarà sicuramente di molto arricchito; sarà più facile trovare i nomi di file, ad esempio, o generare un indice di tutte le applicazioni menzionate. D'altra parte, questi elementi semantici sono talmente tanti (quelli qui elencati sono solo alcuni) che applicandoli dovunque abbia senso, si rischia di impazzire prima di finire il documento. Siccome lo sconsigliamo caldamente, se proprio volete impazzire, be', fatelo solo dopo aver committato il testo :–)

Così, in generale, è meglio non appesantire troppo con questi elementi in linea; usarli solo quando ha veramente senso e meglio non abusarne.

Considerazioni finali sugli elementi

È facile notare come nei documenti restituiti (ne state leggendo uno, ameno che non stiate consultando la versione XML) diversi elementi hanno lo stesso aspetto: un filename, un literal e una application possono avere lo stesso preciso aspetto tipografico, così come emphasis, firstterm e citetitle.

All'ora qual'è l'utilità di tutti questi differenti marcatori? Perchè non usare solo quelli strettamente necessari, come emphasis e literal, se devono sembrare ad ogni modo uguali? Ci sono due buonissime ragioni per non farlo:

  • Primo, se eliminiamo molti dei nostri marcatori in linea lasciando, ad esempio, solo emphasis e literal, perdiamo la semantica. Ricordare che DocBook XML è incentrato sulla struttura e la semantica. firstterm and citetitle possono sembrare identici a emphasis in stampa, ma non sono la stessa cosa. Il sorgente XML lo sa, anche se non lo mostra. Questa è una informazione utile, e non la dobbiamo perdere.

  • Secondo, è possibile adattare i propri fogli di stile per ogni tipo di elemento individualmente. Appena si decide che firstterm deve avere un diverso aspetto da citetitle, possiamo farlo, ma solo se sono già diversi i loro marcatori, non se sono entrambe emphasis nel sorgente XML.

Questo conclude la sezione su DocBook. Con le informazioni date fin qui, si è in grado di scrivere documenti DocBook XML per l progetto Firebird. Naturalmente, usando un editor XML dedicato, cosa caldamente consigliata, sarebbe meglio anche consultarne la documentazione per imparare ad usarlo, cosa che questa guida non insegna a fare.

Indietro: Impostare il vostro documento DocBookFirebird Documentation IndexRisali: Scrivere documenti per FirebirdAvanti: Lingua e stile
Firebird Documentation IndexScrivere documenti per Firebird → Gli elementi che si usano più di frequente