Firebird Documentation Index → Scrivere documenti per Firebird → Gli elementi che si usano più di frequente |
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).
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.
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.
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.
I vari set, libri, articoli, capitoli e sezioni devono avere
sempre un title
, o come elemento
figlio diretto o all'interno di un elemento
(vedi
oltre). È legale includerlo in entrambi, ma in questo caso i due
titoli devono essere identici. Diversamente
dall'xxx
infoid
, 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).
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
, ma
raramente se ne ha bisogno.
xxx
info
<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
.
xxx
info
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.
Nelle prime versioni di queste guide, era raccomandata per
ragioni di presentazione la forma <sect
. Per
miglioramenti successivi nei fogli di stile, questo non è più
necessario e si può scegliere come si vuole.
N
>
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.
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>
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.
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:
Sumeri 3300 aC – 1900 aC
Impero Assiro 1350 aC – 612 aC
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:
Apri la serratura
Svaligia la casa
Fatti arrestare
Dentro uno step
si
possono includere elementi substeps
, che a loro volta possono avere
più step
.
variablelist
Una variablelist
è fatta
di varlistentry
s, 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:
Un testo incluso fra parentesi angolari
Un marcatore iniziale, un corrispondente marcatore finale e tutto quel che c'è dentro
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
.
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.
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
<[email protected]>
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://
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
.
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.
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.
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à.
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:
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!
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.
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:
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
.
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ì:
Mettere il cursore da nel titolo oppure selezionare tutto l'elemento del titolo.
Dal menù, selezionare Modifica -> Elabora Istruzione -> Inserisci Istruzione di Elaborazione Prima. Una linea in cui il testo sarà verde apparirà sopra il titolo.
Digitare keep-together='auto'
su
quella linea.
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.
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.
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/
.
Questo perchè, sia per l'HTML che per il FO, i file delle immagini sono
tutti copiati nella subdirectory filename.ext
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.
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.
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:
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>
.
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.
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:
filename
– command
– application
– envar
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&</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.
subscript
– superscript
È 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 !
varname
– constant
– database
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.
function
– parameter
– returnvalue
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
.
prompt
– userinput
– computeroutput
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à).
emphasis
– citetitle
– firstterm
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.
quote
– literal
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.
È 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.
Firebird Documentation Index → Scrivere documenti per Firebird → Gli elementi che si usano più di frequente |