Copyright © 2013 Red Hat, Inc This material may only be distributed subject to the terms and conditions set forth in the GNU Free Documentation License (GFDL), V1.2 or later (the latest version is presently available at http://www.gnu.org/licenses/fdl.txt).
Sommario
Questo manuale illustra come installare Publican. Inoltre fornisce istruzioni sull'uso di Publican per creare e pubblicare libri, articoli e raccolte di volumi basati su DocBook XML. Questa guida assume che si sia già familiari con DocBook XML.
Questo manuale utilizza numerose convenzioni per evidenziare parole e frasi, ponendo attenzione su informazioni specifiche.
Vengono utilizzate quattro convenzioni tipografiche per richiamare l'attenzione su parole e frasi specifiche. Queste convenzioni, e le circostanze alle quali vengono applicate, sono le seguenti.
Neretto monospazio
Usato per evidenziare l'input del sistema, incluso i comandi della shell, i nomi dei file ed i percorsi. Utilizzato anche per evidenziare tasti e combinazione di tasti. Per esempio:
Per visualizzare i contenuti del file
my_next_bestselling_novelnella vostra directory di lavoro corrente, inserire il comando cat my_next_bestselling_novel al prompt della shell e premere Invio per eseguire il comando.
Quanto sopra riportato include il nome del file, un comando della shell ed un tasto, il tutto riportato in neretto monospazio e distinguibile grazie al contesto.
Le combinazioni si distinguono dai tasti singoli tramite l'uso del segno più, il quale viene usato per creare una combinazione di tasti. Per esempio:
Premere Invio per eseguire il comando.
Premere Ctrl+Alt+F2 per usare un terminale virtuale.
Il primo esempio evidenzia il tasto specifico singolo da premere. Il secondo riporta una combinazione di tasti: un insieme di tre tasti premuti contemporaneamente.
Se si discute del codice sorgente, i nomi della classe, i metodi, le funzioni i nomi della variabile ed i valori ritornati indicati all'interno di un paragrafo, essi verranno indicati come sopra, e cioè in neretto monospazio. Per esempio:
Le classi relative ad un file includono
filesystemper file system,fileper file, edirper directory. Ogni classe possiede il proprio set associato di permessi.
Proportional Bold
Ciò denota le parole e le frasi incontrate su di un sistema, incluso i nomi delle applicazioni; il testo delle caselle di dialogo; i pulsanti etichettati; le caselle e le etichette per pulsanti di selezione, titoli del menu e dei sottomenu. Per esempio:
Selezionare → → dalla barra del menu principale per lanciare Preferenze del Mouse. Nella scheda Pulsanti, fate clic sulla casella di dialogo mouse per mancini, e successivamente fate clic su per cambiare il pulsante primario del mouse da sinistra a destra (rendendo così il mouse idoneo per un utilizzo con la mano sinistra).
Per inserire un carattere speciale in un file gedit selezionare → → dalla barra del menu principale. Selezionare successivamente → dal menu Mappa del carattere, digitare il nome desiderato nel campo Cerca e selezionare . Il carattere desiderato sarà evidenziato nella Tabella dei caratteri. Eseguire un doppio clic sul carattere per poterlo posizionare nel campo Testo da copiare e successivamente fare clic sul pulsante . Ritornare sul documento e selezionare → dalla barra del menu di gedit.
Il testo sopra riportato include i nomi delle applicazioni; nomi ed oggetti del menu per l'intero sistema; nomi del menu specifici alle applicazioni; e pulsanti e testo trovati all'interno di una interfaccia GUI, tutti presentati in neretto proporzionale e distinguibili dal contesto.
Corsivo neretto monospazio o Corsivo neretto proporzionale
Sia se si tratta di neretto monospazio o neretto proporzionale, l'aggiunta del carattere corsivo indica un testo variabile o sostituibile . Il carattere corsivo denota un testo che non viene inserito letteralmente, o visualizzato che varia a seconda delle circostanze. Per esempio:
Per collegarsi ad una macchina remota utilizzando ssh, digitare ssh username@domain.name al prompt della shell. Se la macchina remota è
example.comed il nome utente sulla macchina interessata è john, digitare ssh john@example.com.Il comando mount -o remount file-system rimonta il file system indicato. Per esempio, per rimontare il file system
/home, il comando è mount -o remount /home.Per visualizzare la versione di un pacchetto attualmente installato, utilizzare il comando rpm -q package. Esso ritornerà il seguente risultato: package-version-release.
Da notare le parole in corsivo grassetto - username, domain.name, file-system, package, version e release. Ogni parola funge da segnaposto, sia esso un testo inserito per emettere un comando o mostrato dal sistema.
Oltre all'utilizzo normale per la presentazione di un titolo, il carattere Corsivo denota il primo utilizzo di un termine nuovo ed importante. Per esempio:
Publican è un sistema di pubblicazione per DocBook.
Gli elenchi originati dal codice sorgente e l'output del terminale vengono evidenziati rispetto al testo circostante.
L'output inviato ad un terminale è impostato su tondo monospazio e così presentato:
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
Gli elenchi del codice sorgente sono impostati in tondo monospazio ma vengono presentati ed evidenziati nel modo seguente:
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}E per finire, tre stili vengono usati per richiamare l'attenzione su informazioni che in caso contrario potrebbero essere ignorate.
Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
Tips are tips, shortcuts or alternative approaches to the task at hand. Ignoring a tip should have no negative consequences, but you might miss out on a trick that makes your life easier.
Le caselle 'importante' riportano informazioni che potrebbero passare facilmente inosservate: modifiche alla configurazione applicabili solo alla sessione corrente, o servizi i quali necessitano di un riavvio prima di applicare un aggiornamento. Ignorare queste caselle non causa alcuna perdita di dati ma potrebbe causare irritazione e frustrazione da parte dell'utente.
Un Avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati.
Un Avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati.
If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Publican&component=Publican%20Users%20Guide&version=4.1.
Se si hanno suggerimenti su come migliorare il documento, si cerchi di essere il più possibile specifici nella descrizione. Se si trova un errore, si prega di indicare la sezione e di includere anche parte del testo circostante, in modo da poterlo intercettare facilmente.
Publican è uno strumento per pubblicare materiale scritto in DocBook XML. Questa guida spiega come creare e compilare libri ed articoli usando Publican. Non si tratta di un tutorial su DocBook XML; per supporto su DocBook XML, fare invece riferimento alla Guida DocBook: The Definitive Guide di Norman Walsh e Leonard Muellner, disponibile su http://www.docbook.org/tdg/en/html/docbook.html.
Publican è nato come strumento interno al Red Hat's Documentation Group (ora noto come Engineering Content Services). All'occorrenza questa eredità verrà evidenziata.
Progetto. Publican è un sistema di pubblicazione, non solo uno strumento di elaborazione di DocBook. Oltre ad assicurare la validità di un DocBook XML, Publican assicura che ogni file XML sia conforme allo standard di pubblicazione.
Le funzionalità di brand consentono di creare regole di presentazione e look personalizzati, in alternativa allo stile predefinito, per soddisfare le proprie esigenze editoriali. Le scelte effettuate nel codice, tuttavia, non sono modificabili.
Per esempio, le entità possono essere validamente definite in ogni file XML. Tuttavia per garantire che la dichiarazione DTD sia presente, valida e standardizzata, Publican riscrive la dichiarazione in ogni file XML prima di compilare un testo o articolo. Di conseguenza, tutte le entità dichiarate nei file XML vengono perse. Quindi Publican richiede di definire le entità nel file Nome_Doc.ent (vedere la Sezione 4.1.6, «Nome_Doc.ent»).
Al crescere del lavoro editoriale, la definizione di entità senza restrizioni porta alla duplicazione di entità e ad altre pratiche che causano difficoltà di mantenimento. Consolidare la definizione delle entità in un unico posto noto, serve ad alleviare i problemi di mantenimento e contribuisce ad irrobustire l'automazione del processo di compilazione.
Inoltre le entità presentano un ostacolo sostanzialmente insormontabile sulla qualità della traduzione (fare riferimento alla Sezione 4.1.6.1, «Entità e traduzione»). Quindi, si ritiene opportuno mantenere le attuali funzionalità del file Nome_Doc.ent senza aggiungere altre funzionalità o caratteristiche associate all'uso delle entità.
Le procedure indicate in questa sezione assumono che Publican e le sue varie dipendenze siano disponibili nei repository cui ha accesso il proprio sistema.
Aprire un terminale
Diventare utente root: su -
Eseguire il seguente comando per installare il pacchetto publican ed il pacchetto publican-doc della documentazione:
$ yum install publican\*Con Publican sono disponibili anche diversi pacchetti di brand. Eseguire il seguente comando come utente root, per installare i pacchetti per la costruzione di libri brand:
yum install publican-brand
Sostituire brand con redhat, fedora, jboss, ovirt, o gimp. Vedere il Capitolo 5, Branding per una spiegazione del branding in Publican.
Aprire un terminale
Eseguire il seguente comando per installare il pacchetto publican:
sudo apt-get install publicanThis procedure will install the publican version that is in your default Debian repository. It will also install a large number of packages that publican depends on, like Java, XML and image processing libraries and many ancillary Perl modules.
Aprire un terminale
Diventare utente root: su -
Eseguire il seguente comando per installare il pacchetto publican:
$ apt-get install publicanRun the following command to determine what version of publican is installed:
$publican -vversion=2.8
If you need a more recent release of publican than installed by the procedure above, you can query if there other versions available: http://packages.debian.org/publican.
To date, there has not been any backport (http://backports.debian.org/Instructions/) available for publican, so we need to use Apt Pinning https://wiki.debian.org/AptPreferences
Alternatively, you could run Debian testing or unstable in a virtual machine, chroot or linux container.
Assuming there is a more recent version of publican available in the testing repository, and that you are running the current stable, then you can upgrade by:
Aprire un terminale
Diventare utente root: su -
Con un editor di testo aprire il file /etc/apt/sources.list. Per esempio, per modificare il file con gedit, eseguire:
$ gedit /etc/apt/sources.listAggiungere la seguente riga alla fine del file:
#### testing ######### deb http://ftp.us.debian.org/debian testing main contrib non-free
Salvare il file e chiudere l'editor.
Open (or create) your /etc/apt/preferences file in a text editor. For example, to edit the file in gedit run:
$ gedit /etc/apt/preferencesAggiungere la seguente riga alla fine del file:
Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release a=testing Pin-Priority: 400 Package: * Pin: release o=Debian Pin-Priority: -10
Salvare il file e chiudere l'editor.
Eseguire il seguente comando per aggiornare la lista dei pacchetti disponibili nel sistema:
$ apt-get updateRun the following command to try to install the testing version of publican package, and any updated dependancies:
$ apt-get -t testing install publicanBecause Apt Pinning mixes 2 different debian streams in an un-tested way, incompatibilities may happen. For example, you may get a warning like:
Which indicates that you might need to upgrade libxml2 and libxslt to the testing repository version too. This can be done by searching to find the likely library:$publicanWarning: program compiled against libxml 209 using older 208Warning: XML::LibXML compiled against libxml2 20901, but runtime libxml2 is older 20800Warning: program compiled against libxml 209 using older 208Warning: XML::LibXSLT compiled against libxslt 10128, but runtime libxslt is older 10126Can't open publican: No such file or directory at /usr/bin/publican line 430.
[Show All][Hide](and the same again for libxml2)$apt-get search libxsltgambas3-gb-xml-xslt - Gambas XSLT componentlibidzebra-2.0-mod-alvis - IDZebra filter alvis (XSLT filter for XML)libidzebra-2.0-mod-dom - IDZebra filter 'dom' (XML DOM internal document model with XSLT)libical-parser-html-perl - generates HTML calendars from iCalendarslibxsltc-java - XSL Transformations (XSLT) compiler from Xalan-Javalibxml-filter-xslt-perl - Perl module for XSLT as a SAX Filterlibxml-libxslt-perl - Perl interface to the GNOME libxslt librarylibxslt1-dbg - XSLT 1.0 processing library - debugging symbolslibxslt1-dev - XSLT 1.0 processing library - development kitlibxslt1.1 - XSLT 1.0 processing library - runtime librarypython-libxslt1 - Python bindings for libxslt1python-libxslt1-dbg - Python bindings for libxslt1 (debug extension)python-lxml - pythonic binding for the libxml2 and libxslt librariespython-lxml-dbg - pythonic binding for the libxml2 and libxslt libraries (debug extension)python-lxml-doc - pythonic binding for the libxml2 and libxslt libraries (documentation)python3-lxml - pythonic binding for the libxml2 and libxslt librariespython3-lxml-dbg - pythonic binding for the libxml2 and libxslt libraries (debug extension)php5-xsl - XSL module for php5libsp-gxmlcpp-dev - S+P C++ wrapper for Gnome libxml2/libxsltlibsp-gxmlcpp1 - S+P C++ wrapper for Gnome libxml2/libxsltswfmill - xml2swf and swf2xml processorlibxslthl-java - XSLT syntax highlighting
And then upgrading those packages to testing.
$ apt-get -t testing upgrade libxml2 libxslt1.1
Publican has not been usable on OpenSuse up until release 12.1. Certain dependencies were missing and could not be found in any known OpenSuse repository. This is not the case with OpenSuse 12.1 as all dependencies can now be found and installed.
The following instructions describe installing Publican from source because, as yet, there is no Publican RPM for OpenSuse 12.1. The version of Publican is 2.9 taken directly from the source repository - previous versions have not been tested but may work.
At the time of writing, Publican 2.8 was the release version and work on 2.9 was still ongoing. For this reason the following instructions are subject to change.
The OpenSuse install was a default one with the following software categories added at install time:
Technical Writing - for the Docbook tools etc.
Perl Development
Web and LAMP Server
The system used had KDE installed which shouldn't make a difference. The following KDE specific categories were also installed:
KDE Development
Desktop Effects
Finally, the entire Games category was removed.
After OpenSuse had completed installing, and all current updates had been applied, the following steps were followed to install Publican.
Open a terminal session.
Install the dependencies that are available from various online repositories - many of these are not present in the installation DVD repository.
$ sudo zypper install perl-Config-Simple perl-DateTime \ perl-DateTime-Format-DateParse perl-DBD-SQLite perl-DBI \ perl-File-Find-Rule perl-File-Which perl-HTML-Format \ perl-Locale-MakeText-Gettext perl-Template-Toolkit \ perl-Test-Deep perl-Test-Pod perl-XML-LibXSLT \ perl-YAML liberation-fonts
Liberation-fonts is most likely already installed, but it is required. Zypper will not reinstall it if it is already present.
Use cpan to install the remaining dependencies which cannot be installed by zypper:
$ sudo sh cpan File::pushd File::Copy::Recursive Locale::PO pp \ Syntax::Highlight::Engine::Kate XML::TreeBuilder exit Download the source code:
$ cd ~ mkdir -p SourceCode/publican cd SourceCode/publican svn checkout http://svn.fedorahosted.org/svn/publican/branches/publican-2x ./ Build the Publican build script:
$ perl Build.PL If all the dependencies are installed, you should see the following:
WARNING: the following files are missing in your kit:META.ymlPlease inform the author.Created MYMETA.yml and MYMETA.jsonCreating new 'Build' script for 'Publican' version '2.9'
If not, then use cpan (as root) to install the missing modules and run the build again. Replace any forward slashes '/' by a double colon '::' and make sure you use exactly the same letter case, for example: If File/pushd.pm is reported as missing, you would use this to install it:
$ sudo sh cpan File::pushd exit
Assuming all went well, the Build.PL script will have created a new script named Build which we will use to create, test and install Publican 2.9.
$ ./Build There will be lots of text scrolling up the screen for a few minutes, you should eventually see the following:
DEBUG: Publican::Builder: end of buildTest the build:
$ ./Build test Again, lots of scrolling text at the end of which you may see the following:
Test Summary Report-------------------t/910.publican.Users_Guide.t (Wstat: 256 Tests: 5 Failed: 1)Failed test: 5Non-zero exit status: 1t/pod-coverage.t (Wstat: 256 Tests: 9 Failed: 1)Failed test: 7Non-zero exit status: 1Files=10, Tests=68, 420 wallclock secs ( 0.31 usr 0.17 sys + 246.87 cusr 18.73 csys = 266.08 CPU)Result: FAILFailed 2/10 test programs. 2/68 subtests failed.
Don't worry. This is because of a missing wkhtmltopdf utility which is undergoing tests to be added to Publican in the future to replace Apache FOP as the pdf generation tool of choice. If Publican finds wkhtmltopdf it will use it, otherwise it uses FOP.
Unfortunately, at the time of writing, because OpenSuse names one of the dependencies of wkhtmltopdf differently (ghostscript-fonts-std as opposed to ghostscript-fonts) wkhtmltopdf will not run even if force installed with no dependency checks.
Install wkhtmltopdf.
This step is optional. At the time of writing wkhtmltopdf did not work on OpenSuse 12.1 However, as the problems which prevent it working correctly from Publican may have been resolved, the following instructions give details on installing wkhtmltopdf.
If you intend to create indices in your generated pdf documents, you are advised to use Apache FOP rather than wkhtmltopdf. With FOP you get actual page numbers which is better in a printed document.
$ JFEARN=http://jfearn.fedorapeople.org/wkhtmltopdf/f15 MYSYSTEM=i686 ## For 64bit system use MYSYSTEM=x86_64 instead. wget $JFEARN/$MYSYSTEM/wkhtmltopdf-qt-4.7.1-1.git20110804.fc15.i686.rpm wget $JFEARN/$MYSYSTEM/wkhtmltopdf-0.10.0_rc2-1.fc15.i686.rpm
If you use a 64 bit system, make sure to set MYSYSTEM appropriately.
Once downloaded, install both rpms as follows:
$ sudo sh rpm -ivh wkhtmltopdf-qt* rpm -ivh --nodeps wkhtmltopdf-0* exit
You have to use the option to ignore dependencies on the latter rpm due to the ghostscript-fonts problem described above.
Install Publican.
The final stage is to install Publican, even though the testing stage had a couple of sub-tests which failed.
$ sudo sh ./Build test exit The following steps are optional but it's a good idea to test that everything is working before you spend time on your own documents.
Test the installed Publican build:
$publican create --type=book --product=testing --version=1.2.3 --name=TestPublican Processing file en-US/Author_Group.xml -> en-US/Author_Group.xml Processing file en-US/Book_Info.xml -> en-US/Book_Info.xml Processing file en-US/Chapter.xml -> en-US/Chapter.xml Processing file en-US/Preface.xml -> en-US/Preface.xml Processing file en-US/Revision_History.xml -> en-US/Revision_History.xml Processing file en-US/TestPublican.xml -> en-US/TestPublican.xml$cd TestPublican/ publican build --lang=all --formats=html,html-single,html-desktop,txt,pdf,epub
At the time of writing, creating epubs with Publican 2.9 on OpenSuse gave the following error:
runtime error: file /usr/share/publican/xsl/epub.xsl element chooseVariable 'epub.embedded.fonts' has not been declared.at /usr/lib/perl5/site_perl/5.14.2/Publican/Builder.pm line 915
No epub file was created. The individual working files were however, and can be built into an epub book using Sigil, if desired.
Using the Dolphin file manager, you can browse to SourceCode/TestPublican/tmp/en-US/ and view the various output formats that you find there.
This installation procedure assumes you have already installed a working docker (see http://docker.io) environment.
Docker is a lightweight Jail (currently using LXC) that allows you to install and run publican without installing your main Linux installation with all its dependencies.
Aprire un terminale
Download and install the svendowideit/publican container from https://index.docker.io/u/svendowideit/publican/:
$ docker pull svendowideit/publican
This will take some time, as it downloads a fedora based container, and then the dependencies needed for publican
Add a publican bash alias to simplify your usage:
$ echo 'alias publican="docker run -t -i -v $(pwd):/mnt svendowideit/publican"' >> ~/.bashrcThis alias assumes that you are running publican in the documentation root directory (the one with the publican.cfg file in it.
now you can use publican as per the documentation:
$publican --versionversion=3.2.1
It is possible to run publican from a GIT checkout, without installing it, if the dependencies are installed.
To checkout the source from GIT open a terminal.
Eseguire il seguente comando per installare il pacchetto publican:
$cd PATH TO PLACE SOURCE$git clone git://git.fedorahosted.org/publican.git publican
To run publican from this checkout run the following commands:
$PUBLICAN_PATH="PATH TO PLACE SOURCE/publican"$perl -CDAS -I $PUBLICAN_PATH/lib $PUBLICAN_PATH/bin/publican build --brand_dir $PUBLICAN_PATH/datadir/Common_Content/common --formats html
Download the Publican installer from https://fedorahosted.org/releases/p/u/publican/.
Spostarsi nella cartella in cui si è scaricato l'eseguibile Publican-Installer-versione.exe.
Fare doppio click sul file Publican-Installer-versione.exe.
Il programma di installazione inizia presentando una serie di accordi di licenza. Tutti i file che fanno parte di una installazione di Publican sono disponibili sotto licenza libera. Tuttavia, poiché diverse licenze sono più adatte a certe parti di Publican di altre, i file di Publican non vengono tutti distribuiti sotto la stessa licenza libera. Ogni licenza conferisce differenti diritti e responsabilità sulla copia e sulla modifica dei file di una installazione di Publican. Noi usiamo questa combinazione di licenze per consentire di usare Publican il più liberamente possibile e per consentire di scegliere qualunque licenza per i propri documenti, pubblicati usando Publican.
Leggere le condizioni dei vari accordi di licenza. Se si concorda con le condizioni, premere su ciascuna di esse, altrimenti premere .
Il programma di installazione propone di installare diversi componenti: Publican (denominato Main nella finestra d'installazione), alcuni brand (RedHat, JBoss, e fedora), e due componenti di DocBook (il DTD o Data Type Definition, e l'XSL o Extensible Stylesheet Language). I tre brand si trovano raggruppati sotto il controllo espandibile Brands, mentre i componenti di DocBook si trovano nel controllo espandibile DocBook nella finestra di installazione. Vedere il Capitolo 5, Branding per una spiegazione dei brand in Publican. Per rendere i documenti XML in presentazioni di altri formati (come HTML e PDF), Publican usa il DTD e gli stylesheet di XSL. Se non si installano questi componenti, Publican deve scaricare questi dati da Internet ogniqualvolta elabora un documento, il che comporta lunghi ritardi.
Tutti i componenti sono selezionati per impostazione. Deselezionare i componenti eventualmente non richiesti e poi premere , per continuare.
Per impostazione, il programma di installazione creare una cartella denominata Publican nella cartella %ProgramFiles% del proprio computer — tipicamente C:\Program Files\Publican. Per selezionare una cartella differente, inserire manualmente il percorso alla cartella, nella casella di testo etichettata Destination Folder.
Dopo aver impostato la cartella di destinazione, premere .
A questo punto, durante l'installazione di Publican, viene visualizzata una barra di progressione. Per visualizzare i dettagli sul progresso di installazione, premere .
Una volta completato, il programma di installazione visualizza il messaggio Completed.
Premere per chiudere il programma di installazione.
Install Xcode from Mac App store.
Xcode is about 4GB. Be prepared to wait. It has things you need, though.
Install Macports from http://guide.macports.org/chunked/installing.macports.html. Everything you install with it goes into /opt/local, away from your normal OS files.
Aprire un terminale
Install dependencies for publican, which are available as ports:
$sudo port installdocbook-xml docbook-xsl docbook-sgml-4.2 perl5 bash-completion p5-file-pushd p5-config-simple p5-file-find-rule p5-file-slurp p5-class-trigger p5-time-hires p5-list-moreutils p5-ipc-run3 p5-class-accessor p5-test-perl-critic p5-xml-libxslt p5-locale-gettext p5-image-size p5-file-copy-recursive p5-datetime p5-archive-zip p5-timedate p5-html-format p5-dbd-sqlite p5-xml-simple p5-devel-cover p5-test-pod p5-test-pod-coverage p5-template-toolkit
Install CPAN modules for dependencies which can't be satisfied with ports. Note: this step will generate lots of messages, including warnings. Don't worry about them.
$sudo cpanLocale::Maketext::Gettext Locale::PO DateTime::Format::DateParse Syntax::Highlight::Engine::Kate XML::TreeBuilder File::Inplace String::Similarity HTML::FormatText::WithLinks::AndTables
Install FOP if you want PDFs to work:
$sudo port installfop
$echo"FOP_OPTS='-Xms50m -Xmx700m'" > ~/.foprc
Check out Publican Main branch. This command should be run from your user home directory, for instance /Users/yourusername
$git clonegit://git.fedorahosted.org/publican.git
Change directories:
$cdpublican/publican
This directory should contain a file named Build.pl. Verify that you are in the correct directory, then run the following command. Ignore all the messages you get.
$ perl ./Build.PL$ ./Build
Run the following command to install Publican and put all of its bits into /opt/local:
$ sudo ./Build installProcedura 1.1. Create and build a book
$publican create--name=testbook
$ cd testbook$publican build--formats=html --langs=en-US
Open the tmp/en-US/html/index.html file in a browser to prove that it built correctly.
Procedura 1.2. Install a brand
Fix the permissions of the Commons Brand. You have to do this only once. This is a bug that will be addressed eventually.
$find /opt/local/share/publican-type f|xargs sudo chmod 644
Either check out the SVN for your brand, or get a pre-built brand from a friend.
The SVN location for the brands supplied by Red Hat is http://svn.fedorahosted.org/svn/publican
If you use a pre-built brand, extract it as necessary.
If you got the brand from SVN, build it.
$ cd publican/publican-jboss$publican build--formats=xml --langs=all --publish
Install the brand.
$sudo publican install_brand--path=/opt/local/share/publican/Common_Content
You can now use the brand in your books by editing your book's publican.cfg file or specifying the --brand option when creating your book.
Users can set their own default values for Publican in ~/.publican.cfg. Currently, Publican supports the following values:
firstname
surname
formats
lang
langs
This file is completely different to publican.cfg that is used to build a book. It does not accept the same parameters.
Users can set formats, lang, and langs to their standard build parameters.
Esempio 2.1. Setting formats and lang
$echo 'formats: "html,html-single,pdf,txt"' >> ~/.publican.cfg$echo 'langs: "en-US"' >> ~/.publican.cfg$publican buildSetting up en-US[...]Finished txt
Publican 3.0 allows you to add a revision history entry from the command line. You can set your user details in ~/.publican.cfg.
Esempio 2.2. Setting user details
$echo 'firstname: "Dude"' >> ~/.publican.cfg$echo 'surname: "McPants"' >> ~/.publican.cfg$echo 'email: "dude.mcpants@awesome.com"' >> ~/.publican.cfg$publican add_revision --member "Updated examples in chapter 2." \ --member "Removed obsolete example in sect 4.1"
Publican è uno strumento da riga di comando. Per usare Publican su un computer con Sistema Operativo Linux, occorre avviare un emulatore di terminale (come GNOME Terminal o Konsole) oppure passare ad una console virtuale. Per usare Publican su un computer con sistema operativo Windows, avviare la riga di comando, digitando cmd nello
I comandi di Publican hanno uno dei seguenti formati:
The command_option is any of several options for the $ publican command itself. For a complete list of actions see Sezione B.2, «Command actions»
azione è una richiesta di elaborazione per Publican, come creare i file XML per un nuovo documento o creare un documento in HTML dai corrispondenti file XML. Le opzioni_azione si applicano ad una azione, per specificare per esempio la lingua di un documento.
Alcune opzioni_comando influenzano il risultato di una azione, come quando si richiede, per esempio, a Publican di usare nell'output la colorazione ANSI.
Questo capitolo descrive come creare libri ed articoli: i file di configurazione principali, i file in un documento d'esempio, e come compilare un documento.
Usare il comando publican create per creare un nuovo documento corredato di tutti i file necessari.
Il comando publican create accetta diverse opzioni, come indicato in questo capitolo. Quando una opzione accetta un valore, separare il valore con uno spazio o con il segno di uguale; per esempio, publican create --name New_Book o publican create --name=New_Book.
--helpvisualizza l'elenco di tutte le opzioni del comando publican create.
--name Nome_Doc
assegna Nome_Doc al nome del libro o articolo. Questa variabile non deve contenere spazi. Per esempio, il comando create_book --name Test_Book crea un libro di nome Test_Book con tutti i file necessari per creare il libro, ed imposta il parametro BOOKID nel file Test_Book.ent.
--lang Codice_Lingua
imposta la lingua, con il Codice_Lingua, in cui il libro o articolo verrà redatto. Se non si specifica un codice linguistico, Publican per impostazione usa en-US (inglese americano). L'opzione --lang imposta il parametro xml_lang nel file di configurazione publican.cfg. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per maggiori informazioni sui parametri di publican.cfg ed all'Appendice F, Codici di lingua per i dettagli sui codici linguistici.
--version versione
set version as the version number of the product that the book describes. For example, for Red Hat Enterprise Linux 5.1 you would use 5.1. The default version is 0.1. The --version option sets the <productnumber> tag in the Book_Info.xml or Article_Info.xml file. For more information refer to Sezione 4.1.2, «Book_Info.xml».
--edition edizione
assegna il numero di edizione del libro. Questo numero serve ad indicare il rilascio di una nuova edizione di un libro. Il primo rilascio pubblico (general availability o GA) di un libro, dovrebbe avere l'edizione 1.0. Il valore predefinito è 0. L'opzione --edition imposta il tag <edition> nel file Book_Info.xml o nel file Article_Info.xml. Per maggiori informazioni fare riferimento alla Sezione 4.1.2, «Book_Info.xml».
--product Nome_Prodotto
assegna Nome_Prodotto al nome del prodotto descritto dal libro. Questa variabile non deve contenere spazi. Per esempio, usare il valore Fedora per la documentazione Fedora di base, ed il nome del prodotto per gli altri documenti, per esempio Fedora_Directory_Server. Il valore pedefinito è Documentation. L'opzione --product imposta il tag <productname> nel file Book_Info.xml o Article_Info.xml e il parametro PRODUCT nel file Doc_Name.ent.
--type Article --name Nome_Articolo
crea un articolo invece di un libro, assegnando Nome_Articolo al nome dell'articolo. Questa variabile non deve contenere spazi. L'opzione --type imposta il parametro type nel file di configurazione publican.cfg. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per maggiori informazioni sui parametri del file publican.cfg.
--type Set --name Nome_Set
crea un set di documenti invece di un libro, assegnando Nome_Set al nome del set. Questa variabile non deve contenere spazi. L'opzione --type imposta il parametro type nel file di configurazione publican.cfg. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per maggiori informazioni sui parametri del file publican.cfg ed al Capitolo 6, Usare i set per i dettagli sull'uso dei set.
--brand brand
assegna lo stile di presentazione o brand, per esempio RedHat, fedora, JBoss, oVirt o GIMP del documento. Il valore predefinito è common, il brand integrato in Publican. L'opzione --brand imposta il parametro brand nel file di configurazione publican.cfg. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per maggiori informazioni sui parametri del file publican.cfg. Questa opzione richiede che sia installato l'appropriato pacchetto di brand di Publican. Per esempio, per compilare libri con brand Red Hat, occorre installare il pacchetto publican-redhat. Fare riferimento alla Sezione 5.1, «Installare un brand» per istruzioni su come installare pacchetti di brand per l'uso in Publican. Vedere il Capitolo 5, Branding per maggiori informazioni.
Prima di eseguire il comando publican create, spostarsi (con il comando shell cd), nella directory in cui si vuole venga creato il libro. Per esempio, per creare un libro di nome Libro_di_Prova nella directory miei_libri/, eseguire i seguenti comandi:
cd miei_libri/ publican create --name Libro_di_Prova --lang=it-IT
Per visualizzare i risultati di questo comando su un computer con Sistema Operativo Linux, eseguire il comando:
$ lsIl risultato dovrebbe assomigliare a:
Libro_di_Prova/
Per visualizzare il contenuto della nuova cartella Libro_di_Prova/ su un computer con Sistema Operativo Linux, eseguire i comandi:
$cd Test_Book/$ls
Il risultato dovrebbe assomigliare a:
it-IT/ publican.cfgSe si esegue il comando publican create --name Libro_di_Prova --lang it-IT, Publican crea una directory con i file richiesti, che generalmente sono:
publican.cfg
it-IT (una directory)
Libro_di_Prova.xml
Libro_di_Prova.ent
Revision_History.xml
Preface.xml
Chapter.xml
Book_Info.xml
Author_Group.xml
images (una directory)
icon.svg
Se si mantengono diverse versioni di un documento, si può creare un file di configurazione per ogni versione. Quando si crea un documento o il pacchetto relativo, si può usare l'opzione --config per specificare un file di configurazione diverso dal file publican.cfg, e quindi usare un insieme differente di parametri per una particolare compilazione. Per esempio:
publican build --formats html,pdf --langs de-DE,en-US,it-IT --config community.cfg
Il file publican.cfg configura le opzioni di compilazione, e si trova nella cartella radice del libro. Di seguito si riporta un esempio di file publican.cfg, con una descrizione dei parametri ivi presenti:
# Config::Simple 4.59 # Wed Jul 18 13:00:40 2012 xml_lang: "en-US" type: Book brand: common
Parametri predefiniti
xml_lang
specifica la lingua dei file XML sorgenti, per esempio en-US, come impostato con l'opzione --lang nel comando publican create.
type
specifica il tipo di documento — un <article> DocBook, un <book> DocBook o un <set> DocBook, come impostato con l'opzione --type nel comando publican create.
brand
imposta il brand del documento, per esempio RedHat, fedora, JBoss, oVirt o GIMP, come impostato con l'opzione --brand nel comando publican create. Se non si specifica un brand, Publican usa il brand predefinito. Fare riferimento al Capitolo 5, Branding per maggiori informazioni.
Advanced parameters Delete me and reference appendix
arch
filtra l'output in base all'architettura della macchina. Per esempio, impostando arch: x86_64 nel file publican.cfg, l'applicazione Publican include solo gli elementi XML contenenti l'attributo equivalente, per esempio <para arch="x86_64">.
Come accade più in generale con i tag condizionali, il parametro arch può causare notevoli problemi in fase di traduzione di un documento. Vedere la Sezione 4.9.1, «Tagging condizionale e traduzione» per una spiegazione di questi problemi.
Se il nodo radice di un file XML viene escluso dal parametro arch, il documento non può essere compilato, poiché file vuoti non sono file XML validi. Per esempio, se il file Installation_and_configuration-PPC.xml è costituito da un solo capitolo:
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <chapter id="chap-Installation_and_configuration_on_PowerPC" arch="PowerPC"> <title>Installation and configuration on PowerPC</title> [text of chapter] </chapter>
ed il capitolo è incluso nel file User_Guide.xml con un tag <xi:include>, il documento non compilerà se viene impostata la condition: x86 nel file publican.cfg.
Per escludere il capitolo, aggiungere il parametro arch al tag <xi:include> in User_Guide.xml, invece che al tag <chapter> in Installation_and_configuration-PPC.xml.
Se un <xref> punta ad un contenuto escluso dalla compilazione dal parametro arch, la compilazione fallisce. Per esempio, impostando arch: x86 nel file publican.cfg, il comando publican build --formats=pdf --langs=en-US fallisce se il libro ha il tag <xref linkend="Itanium_installation"> che punta a <section id="Itanium_installation" arch="IA64">.
booksspecifica un elenco di libri, separati da spazio, usati in un set remoto. Vedere la Sezione 6.2, «Set distribuiti» per maggiori informazioni sui set distribuiti.
brew_dist
specifica il target da usare per creare il pacchetto RPM desktop in Brew, il sistema di creazione di pacchetti interno a Red Hat. Il valore predefinito è docs-5E. Vedere la Sezione 4.8.2, «Il comando publican package» e la Sezione 5.4, «Creare il pacchetto di un brand» per maggiori informazioni sulla compilazione di pacchetti RPM.
bridgehead_in_toc
specifica se includere gli elementi DocBook <bridgehead> (o intestazioni svincolate) tra gli altri titoli (di sezione e di capitoli), nelle tabelle dei contenuti. Per abilitare questa proprietà, impostare bridgehead_in_toc: 1. Per impostazione, quest'ultimo parametro è impostato a 0 e gli elementi <bridgehead> non sono inclusi nel sommario dei contenuti.
chunk_first
controlla se visualizzare la prima sezione in una nuova pagina, nel rendering HTML. Per visualizzare la sezione in una nuova pagina HTML, impostare il parametro su chunk_first: 1. Per impostazione, il valore predefinito è 0, e la prima sezione viene visualizzata nella stessa pagina del proprio capitolo.
chunk_section_depth
controlla il livello di sotto-sezione a partire da cui queste non vengono riportate su una nuova pagina, nel rendering HTML. Per impostazione, il valore predefinito è 4.
Esempio 4.1. Controllare il livello di sotto-sezione con chunk_section_depth
nessuna suddivisione di sezioni. Tutte le sezioni e sotto-sezioni appaiono nella stessa pagina del capitolo cui appartengono. La successione della pagine è capitolo 1, capitolo 2, capitolo 3, …
la suddivisione di sezione è a "livello 1". Ogni sezione di livello uno, con le relative sotto-sezioni, appaiono su una nuova pagina. La successione delle pagine è capitolo 1, 1.2, 1.3, 1.4 … capitolo 2, 2.1, 2.2, … 2.3 …
la suddivisione di sezione è a "livello 2". La successione delle pagine è capitolo 1, 1.2, 1.2.2, 1.2.3, 1.2.4 … 1.3, 1.3.2, 1.3.3 …
la suddivisione di sezione è a "livello 3". La successione delle pagine è capitolo 1, 1.2, 1.2.2, 1.2.2.2, 1.2.2.3, 1.2.2.4 … 1.3, 1.3.2, 1.3.2.2, 1.3.2.3 …
la suddivisione di sezione è a "livello 4". La successione delle pagine è capitolo 1, 1.2, 1.2.2, 1.2.2.2, 1.2.2.2.2, 1.2.2.2.3, 1.2.2.2.4 … 1.2.3, 1.2.3.2, 1.2.3.2.2, 1.2.3.2.3 …
classpath
imposta il percorso ai file jar (Java archive) per FOP (Formatting Objects Processor). Publican si basa su Apache FOP — una applicazione Java — per rendere i documenti in file PDF. Il percorso predefinito ai file jar di FOP, su un computer con Sistema Operativo Linux è: /usr/share/java/ant/ant-trax-1.7.0.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/batik-all.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/xml-commons-apis-ext.jar.
common_config
imposta il percorso ai file d'installazione di Publican. La locazione predefinita su un Sistema Operativo Linux è /usr/share/publican. Su un computer con sistema operativo Windows, la locazione predefinita è %SystemDrive%/%ProgramFiles%/publican — solitamente C:/Program Files/publican.
common_content
imposta il percorso alla cartella dei file comuni di Publican. I file contenuti forniscono formattazione predefinita, alcuni modelli e grafica generica. La locazione predefinita su un Sistema Operativo Linux è /usr/share/publican/Common_Content. Su un computer con sistema operativo Windows, la locazione predefinita è %SystemDrive%/%ProgramFiles%/publican/Common_Content — solitamente C:/Program Files/publican/Common_Content.
conditionspecifica, prima di una trasformazione, le condizioni per escludere file XML. Vedere la Sezione 4.9, «Tagging condizionale» per maggiori informazioni.
Se il nodo di root di un file XML viene escluso da un tag condizionale, il documento non compila, poiché file vuoti non sono file XML validi. Per esempio, se il file Installation_and_configuration_on_Fedora.xml contiene un solo capitolo:
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <chapter id="chap-Installation_and_configuration_on_Fedora" condition="Fedora"> <title>Installation and configuration on Fedora</title> [text of chapter] </chapter>
ed il capitolo è incluso in User_Guide.xml con un tag <xi:include>, il documento non compila se è presente l'impostazione condition: Ubuntu nel file publican.cfg.
Per escludere il capitolo, aggiungere un attributo condizionale al tag <xi:include> in User_Guide.xml, e non al tag <chapter> in Installation_and_configuration_on_Fedora.xml.
Se un <xref> punta ad un contenuto escluso nella compilazione da un tag condizionale, la compilazione fallisce. Per esempio, con l'impostazione condition: upstream nel file publican.cfg, il comando publican build --formats=pdf --langs=en-US fallisce se il libro ha un tag <xref linkend="betasection"> che punta alla <section id="betasection" condition="beta">.
confidential
contrassegna un documento come confidenziale. Impostando su 1 questo parametro, Publican aggiunge il testo specificato nel parametro confidential_text (per impostazione, CONFIDENTIAL) a piè di pagina o in testa ad ogni pagina di un documento HTML o PDF, rispettivamente. Il valore predefinito è 0 (nessuna intestazione o piè di pagina).
confidential_text
specifica il testo da usare quando il parametro confidential è impostato ad 1. Il testo predefinito è CONFIDENTIAL.
debug
controlla se visualizzare il messaggi di debug durante l'elaborazione. Con il valore predefinito impostato a 0, Publican non visualizza messaggi. Modificare il valore ad 1 per vedere i messaggi di debug.
def_langimposta la lingua predefinita per un sito web gestito da Publican. La tabelle dei contenuti delle altre lingue fanno riferimento ai documenti della lingua predefinita, se non sono disponibili traduzioni. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento» per maggiori informazioni.
doc_url
fornisce un URL al team di documentazione del pacchetto. In documenti HTML, Publican crea un link a questo URL in alto a destra di ogni pagina, attraverso l'immagine image_right.png nella cartella Common_Content/images del brand. Il valore predefinito è https://fedorahosted.org/publican.
docname
specifies the document name. If set, this value overrides the content of the <title> tag in the Book_Info.xml file when you package a document. This value must contain only upper- and lower-case un-accented letters, digits, and the underscore and space characters (‘a–z’, ‘A–Z’, ‘0’–‘9’, and ‘_’ and ‘ ’).
dt_obsoletesil pacchetto reso obsoleto dal pacchetto desktop.
dt_requiresil pacchetto richiesto dal pacchetto desktop, per esempio, il pacchetto del menu di una documentazione. Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
dtdverspecifica la versione del DTD (Document Type Definition) di DocBook XML su cui si basa il progetto. Publican fa riferimento alla versione 4.5. Le specifiche della versione DTD 4.5 di DocBook XML sono disponibili su http://www.docbook.org/specs/docbook-4.5-spec.html.
When you install Publican, you also install a local copy of the DocBook XML DTD version 4.5 and accompanying Extensible Stylesheet Language (XSL). If you set a version of the DTD for which there is no local support, Publican must download the appropriate DTD and XSL from an online source every time that it builds the document. Building your document is delayed while this download takes place. The combined size of the required files is around 70 MB.
typeOverride Type for DocType. Must be a complete string.
This parameter is only permitted in a brand.
dtdverOverride URI for DocType. Must be a complete string.
This parameter is only permitted in a brand.
ec_id
imposta l'ID per un plugin d'aiuto di Eclipse. Ogni plugin deve possedere un unico ID che generalmente segue le convenzioni sui nomi dei pacchetti JAVA (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html). Per impostazione, Publican imposta l'ID con org.prodotto.nomedoc. L'ID impostato determina anche il nome della cartella del plugin, nella cartella plugin.
ec_nameimposta il nome per un plugin d'aiuto di Eclipse. E' un nome leggibile che compare nell'elenco d'aiuto di Eclipse. Il nome non deve essere unico o rispettare particolari convenzioni. Per impostazione, Publican imposta il nome con prodotto nomedoc.
ec_providerimposta il nome del fornitore per un plugin d'aiuto di Eclipse. Può essere un nome di persona, o il nome di un progetto o organizzazione. Questo è visibile agli utenti e non deve essere unico o rispettare particolari convenzioni. Per impostazione, Publican imposta il nome del fornitore con Publican-version di Publican.
editionspecifies the edition number for this document.
The <edition> tag was required by versions of Publican prior to 2.0, which used it to generate the version of a documentation package. This tag is now completely optional and does not affect packaging in any way.
extras_dir
the directory Publican will process extra files from. (Default: extras)
footerspecifies content that will be injected into the bottom of every page on the site.
generate_section_toc_level
controlla il livello di sottosezione nelle tabelle dei contenuti. Con il valore predefinito, 0, Publican genera tabelle contenenti parti, capitoli ed appendici, ma senza sezioni. Se per esempio, il valore è impostato su 2, le tabelle dei contenuti conterranno anche sezioni di "livello 2", come le sezioni 1.1.1, 1.1.2, ed 1.2.1.
Esempio 4.2. Impostare il livello di sezione nelle tabelle dei contenuti
Publican genera le tabelle dei contenuti all'inizio del documento e nelle parti, nei capitoli e in appendice, ma non nelle sezioni.
Publican genera le tabelle dei contenuti anche all'inizio delle sezioni di "livello 1", come le sezioni 1.1, 1.2 … 2.1, 2.2 …
Publican genera le tabelle dei contenuti anche all'inizio delle sezioni di "livello 2", come le sezioni 1.1.1, 1.1.2. 1.1.3 … 1.2.1., 1.2.2, 1.2.3 …
ignored_translations
specifica le traduzioni da ignorare, specificando i codici linguistici separati da virgola, per esempio, es-ES,it-IT. Se si crea un libro o il pacchetto di un libro per una lingua filtrata da questo parametro, Publican ignora ogni traduzione in questa lingua, e crea invece il libro o il pacchetto relativo, nella lingua dei sorgenti XML. Fare riferimento alla Sezione 4.6, «Translating a document» ed all'Appendice F, Codici di lingua.
tmp_dir
la cartella di output di Publican. (Per impostazione: tmp)
mainfileoverrides the default Info file. Specifies where Publican looks for info fields. Use the full filename without the path.
licensespecifica la licenza usata dal pacchetto. Per impostazione, Publican seleziona la licenza GFDL (GNU Free Documentation License). Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento».
mainfile
specifica il nome del file XML, contenente il nodo XML radice di <article>, <book> o <set>, e il nome del file .ent corrispondente, con le entità del documento. Per esempio, impostando mainfile: master, Publican cerca il nodo XML radice in master.xml e le entità in master.ent.
Se il parametro mainfile non è impostato, Publican cerca il nodo XML radice in un file che corrisponda al <title> del documento in Article_Info.xml, Book_Info.xml, o Set_Info.xml, e cerca le entità in un file con un nome corrispondente.
menu_category
la categoria del menu del desktop (come definito dal file .menu corrispondente), in cui inserire il documento installato con un pacchetto RPM desktop. Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
os_ver
specifies the operating system for which to build packages. Publican appends the value that you provide here to the RPM packages that it builds. For example, .fc15 for Fedora 15. The default value is .el5, which signifies Red Hat Enterprise Linux 5 and operating systems derived from it. Refer to Sezione 4.8, «Creare il pacchetto di un documento» and Sezione 5.4, «Creare il pacchetto di un brand».
prod_url
fornisce un URL per il prodotto a cui fa riferimento il documento. In documenti HTML, Publican crea un link a questo URL nella parte in alto a sinistra, usando l'immagine image_left.png nella cartella Common_Content/images del brand. Il valore predefinito è https://fedorahosted.org/publican.
product
specifies the product to which this documentation applies. If set, this value overrides the content of the <productname> tag in the Book_Info.xml file when you package a document. This value must include only contain upper- and lower-case un-accented letters, digits, and the underscore and space characters (‘a–z’, ‘A–Z’, ‘0’–‘9’, and ‘_’ and ‘ ’).
release
specifica il numero di rilascio del pacchetto. Se impostato, questo parametro non tiene conto del contenuto del tag <pubsnumber> nel file Book_Info.xml, durante la creazione del pacchetto. Il valore può contenere solo cifre (‘0’–‘9’).
repospecifica il repository da cui prelevare i libri remoti che fanno parte di un set distribuito. Fare riferimento alla Sezione 6.2, «Set distribuiti».
release
override the default Revision History file direction. By default Publican assumes the Revision History is sorted in descending order, newest versions at teh top, if you wish to change this and have the oldest revisions at the top, then set this parameter to asc or ascending.
rev_file
override the default Revision History file. Specifies where Publican looks for revision fields. Use the full filename without the path. When combined with the Publican action add_revision, it enables you to build a book without a Revision_History.xml.
scm
specifica il sistema di controllo versione (o source code management), usato nel repository contenente i libri remoti di un set distribuito. Al momento, Publican può usare solo SVN (Subversion), e quindi il valore predefinito è SVN. Fare riferimento alla Sezione 6.2, «Set distribuiti».
show_remarks
controlla se visualizzare gli elementi <remark> nel documento. Per impostazione, il parametro è impostato sul valore 0 che nasconde i remark. Impostare questo valore su 1 per visualizzare i remark. Nel brand common di Publican, il testo incluso è evidenziato con colore viola.
dtdveroverride the default sort weighting for books in a Publican website. Books are displayed on the website in descending sort order. For example, a book with sort order 10 appears before a book with sort order 5. By default, this value is set to 50.
src_url
specifica l'URL in cui trovare i tarball dei file sorgente. Questo parametro completa il campo Source: nell'intestazione del file spec dell'RPM. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento».
tmp_dir
specifica la cartella dei prodotti di Publican. Per impostazione, il valore è tmp corrispondente ad una cartella di nome tmp, inclusa nella cartella contenente l'articolo o libro.
tmpl_path
specifies the path to Publican templates. By default, this is set to /usr/share/publican/templates.
type
allows a site to override the template used when building the embedded toc using in web_style=1 sites. The template must be in the same directory that toc.tmpl is in. The template name must be must be of the form toc_type+.tmpl
toc_type
specifies the name of a custom TOC template. By default, Publican looks for toc-$toc_type.tmpl in /usr/share/publican/templates. You can override this by setting an alternative path with tmpl_path.
toc_section_depth
controlla fino a che livello rappresentare le sotto-sezioni nel sommario principale dei contenuti. Per impostazione, il valore predefinito è 2. Con questa impostazione, appaiono le sezioni 1.1 ed 1.1.1, ma non la sezione 1.1.1.1 . (Notare che il primo numero indica un capitolo, non una sezione).
Esempio 4.3. Controllare il livello di sezioni nella tabella dei contenuti principale
Publican genera un sommario principale solo di capitoli.
Publican genera un sommario principale solo per i capitoli e le sezioni di "livello 1", come 1, 1.1, 1.2, 1.3 … 9, 9.1, 9.2 … ma non per sezioni 1.1.1, 1.1.2 …
Publican genera un sommario principale per i capitoli e le sezioni di "livello 1" e "livello 2", come 1, 1.1, 1.1.1, … 1,2, 1.2.1, 1.2.2 … ma non per le sezioni più interne tipo x.x.x.x .
version
specifica il numero di versione del prodotto a cui fa riferimento il documento. Se impostato, questo parametro non tiene conto del contenuto del tag <productnumber> nel file Book_Info.xml, per la creazione del pacchetto. Il valore può contenere solo cifre ed il carattere punto (‘0’–‘9’ and ‘.’).
web_brew_dist
specifica il target di compilazione brew da usare per la creazione di pacchetti RPM per il web. Brew è il sistema di creazione di pacchetti interno a Red Hat. Per impostazione, questo valore è impostato su docs-5E, rappresentando i pacchetti per la documentazione Red Hat Enterprise Linux 5. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento».
web_formatsuna lista di formati, separati da virgola, da includere nel pacchetto RPM per il web. Fare riferimento alla Sezione 4.8.2, «Il comando publican package».
web_homespecifica che il documento è la home page di un sito web di documentazione, non un documento standard. Fare riferimento al Capitolo 7, Creare un sito web con Publican.
web_home è deprecato
In Publican 2.2, web_home is replaced by web_type: home. Support for web_home will be removed in a future version of Publican.
web_name_labelvisualizza il valore impostato, invece del nome del libro, nel menu di un sito web gestito da Publican. Fare riferimento al Capitolo 7, Creare un sito web con Publican.
web_obsoletesspecifica i pacchetti resi obsoleti da questo RPM per il web. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento».
web_product_labelvisualizza il valore impostato, invece del nome del prodotto, nel menu di un sito web gestito da Publican. Fare riferimento al Capitolo 7, Creare un sito web con Publican.
web_type
sets the web style, which determines the layout and presentation of the website. Valid values are 1 and 2. Style 1 features a navigation pane at the left side of the screen that provides access to all of the documents on the site. Style 2 offers a breadcrumb-like navigation system.
web_type
specifies that the document is descriptive content for a Publican-managed website rather than product documentation. This content includes the home page of the website (web_type: home), product description pages (web_type: product), and version description pages (web_type: version). Refer to Capitolo 7, Creare un sito web con Publican.
web_version_label
visualizza il valore impostato, invece del numero di versione, nel menu di un sito web gestito da Publican. Impostare il valore su UNUSED per una documentazione generale che non si applica ad una particolare versione di un prodotto. Fare riferimento al Capitolo 7, Creare un sito web con Publican.
classpath
Extra options to pass to wkhtmltopdf. e.g. wkhtmltopdf_opts: "-O landscape -s A3"
Eseguire il comando publican help_config nella cartella radice di un libro per un elenco di questi parametri.
Article_Info.xml e Set_Info.xml
Questa descrizione del file Book_Info.xml si applica anche ai file Article_Info.xml e Set_Info.xml. Quindi, per semplificare, nel corso di questa sezione si farà riferimento al file Book_Info.xml.
Questa sezione descrive i pacchetti di documenti distribuiti con il Gestore di pacchetti RPM. Quando si usa il comando publican package, Publican genera un tarball che può essere usato per ricavare un pacchetto, da distribuire con un gestore di pacchetti software differente. Se si esegue publican package su un sistema senza rpmbuild installato, Publican genera ancora il tarball anche se non può creare da esso il pacchetto RPM.
Il file Book_Info.xml contiene i metadati chiave di un libro: ID del libro; titolo; sottotitolo; autore e numero editoriale. Contiene anche nome e versione del prodotto documentato, ed un abstract.
Oltre a costituire gli elementi introduttivi di un libro, questi metadati sono usati anche per creare il pacchetto RPM di un libro. Solitamente, se si distribuisce un libro come un pacchetto RPM, i vari tag inclusi in maniera predefinita in Book_Info.xml devono contenere dati che siano conformi alle richieste del formato RPM. E' possibile non tenere conto di questi tag, usando i campi equivalenti nel file publican.cfg, come discusso in questa sezione.
A meno che non siano specificati nel file publican.cfg, per realizzare l'RPM di un libro, sono necessari i dati di sette tag predefiniti in Book_Info.xml. Per lo più, il nome di file del pacchetto RPM di un libro è costruito come:
nome_prodotto-titolo-numero_prodotto-codice_lingua-edizione-numero_pub.src.rpm
Ogni dato, escluso codice_lingua, è ricavato dal file Book_Info.xml — la lingua è specificata durante la creazione del libro. Come pure <subtitle> e <abstract> usati nel file spec dell'RPM per fornire il campo Summary: nell'intestazione ed il campo %description, rispettivamente.
Appresso, si riporta un esempio di file Book_Info.xml, per un Libro_di_Prova. Seguono i dettagli riguardanti questo file, e le richieste di conformità al formato RPM per ciascun tag.
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE info [ <!ENTITY % BOOK_ENTITIES SYSTEM "Users_Guide.ent"> %BOOK_ENTITIES; <!ENTITY % sgml.features "IGNORE"> <!ENTITY % xml.features "INCLUDE"> <!ENTITY % DOCBOOK_ENTS PUBLIC "-//OASIS//ENTITIES DocBook Character Entities V4.5//EN" "/usr/share/xml/docbook/schema/dtd/4.5/dbcentx.mod"> %DOCBOOK_ENTS; ]> <info conformance="121" version="5.0" xml:lang="it-IT" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"> <title>Guida Utente</title> <subtitle>Pubblicare libri, articoli, relazioni e raccolte di volumi con DocBook XML</subtitle> <productname>publican</productname> <productnumber>4.2</productnumber> <abstract> <para> Questo manuale illustra come installare <application>Publican</application>. Inoltre fornisce istruzioni sull'uso di Publican per creare e pubblicare libri, articoli e raccolte di volumi basati su DocBook XML. Questa guida assume che si sia già familiari con DocBook XML. </para> </abstract> <keywordset> <keyword>publican</keyword> <keyword>docbook</keyword> <keyword>publishing</keyword> </keywordset> <subjectset scheme="libraryofcongress"> <subject> <subjectterm>Electronic Publishing</subjectterm> </subject> <subject> <subjectterm>XML (Computer program language)</subjectterm> </subject> </subjectset> <mediaobject role="logo"> <imageobject> <imagedata fileref="Common_Content/images/title_logo.svg" format="SVG" /> </imageobject> <textobject> <phrase>Team Publican</phrase> </textobject> </mediaobject> <mediaobject role="cover"> <imageobject remap="lrg" role="front-large"> <imagedata fileref="images/cover_thumbnail.png" format="PNG" /> </imageobject> <imageobject remap="s" role="front"> <imagedata fileref="images/cover_thumbnail.png" format="PNG" /> </imageobject> <imageobject remap="xs" role="front-small"> <imagedata fileref="images/cover_thumbnail.png" format="PNG" /> </imageobject> <imageobject remap="cs" role="thumbnail"> <imagedata fileref="images/cover_thumbnail.png" format="PNG" /> </imageobject> </mediaobject> <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> </info>
<bookinfo id="id_libro">, <articleinfo id="id_articolo">, <setinfo id="id_set">L'ID del documento è usato internamente e non viene visualizzato ai lettori. Se si esegue il comando publican clean_ids, ogni ID inserito manualmente, inclusi questi, viene modificato in un formato Nome_Doc-Titolo, dove Titolo è il titolo associato al libro, articolo, sezione o capitolo.
<productname>nomeprodotto</productname>
Il nome del prodotto o gruppo di prodotto cui si riferisce il libro, articolo, o set, per esempio: Red Hat Enterprise Linux o JBoss Enterprise Application Platform. Quando si crea il pacchetto RPM di un libro, il valore nel tag <productname> viene usato come parte del nome di file dell'RPM.
Per non tenere conto di questo tag, usare il parametro product nel file publican.cfg, in particolare se il nome_prodotto contiene caratteri non-latini, caratteri accentati o caratteri di punteggiatura diversi dal trattino basso.
Publican usa i dati in questo tag per generare gli elementi del nome di file per i pacchetti RPM, a meno che non siano superati dai dati nel file publican.cfg. Se i dati nel tag non sono superati da quelli in publican.cfg, questo tag può contenere solo caratteri non accentati minuscoli e maiuscoli, cifre, il segno meno, il trattino-basso, il punto ed il carattere somma (‘a–z’, ‘A–Z’, ‘0’–‘9’, ‘-’, ‘.’, ‘_’, e ‘+’).
<title>titolo</title>
Abbastanza ovvio, il titolo del documento (per esempio <title>Server Configuration Guide</title>). Il titolo compare sotto il nome del prodotto in entrambe le presentazioni, HTML e PDF. Un titolo è necessario per la creazione del pacchetto RPM. Quando si crea l'RPM di un libro, il titolo è usato come parte integrante nel nome di file del pacchetto.
I nomi dei pacchetti RPM possono contenere solo particolari caratteri ASCII. Se il titolo di un documento contiene caratteri non latini, caratteri latini accentati o di punteggiatura (escluso il trattino basso), usare il parametro docname nel file publican.cfg per impostare il nome del documento in caratteri ASCII. Compilando il documento, il titolo risultante è quello impostato con il tag <title>, mentre per il nome di pacchetto del documento, il valore usato è quello impostato con il parametro docname.
Publican usa i dati in questo tag per generare gli elementi del nome di file per i pacchetti RPM, a meno che non siano superati dai dati nel file publican.cfg. Se i dati nel tag non sono superati da quelli in publican.cfg, questo tag può contenere solo caratteri non accentati minuscoli e maiuscoli, cifre, il segno meno, il trattino-basso, il punto ed il carattere somma (‘a–z’, ‘A–Z’, ‘0’–‘9’, ‘-’, ‘.’, ‘_’, e ‘+’).
Per impostazione, Publican usa il contenuto di <title> per individuare il file contenente il nodo XML radice: <article>, <book> o <set>. Per esempio, se si imposta il titolo <title>Server Configuration Guide</title>, Publican si aspetta di trovare il nodo XML radice in un file di nome Server_Configuration_Guide.ent. Per usare un nome differente per questi file, impostare il parametro mainfile nel file di configurazione (per impostazione, publican.cfg). Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg».
<subtitle>sottotitolo</subtitle>
Analogamente ovvio come il precedente, il sottotitolo del libro; un titolo alternativo, generalmente esplicativo per il libro (per esempio: Server Configuration Guide: Preparing Red Hat Enterprise Linux for Production Use). Il sottotitolo compare sotto il titolo in entrambe le presentazioni, HTML e PDF. Un sottotitolo è necessario anche per la creazione del pacchetto RPM. In tal caso, il sottotitolo è usato nel Summary del file spec dell'RPM, reso disponibile insieme agli altri campi dello spec file, con il comando rpm -qi.
<productnumber>numeroprodotto</productnumber>Il numero di versione del prodotto cui si riferisce il documento, per esempio ‘5.2’ per Red Hat Enterprise Linux 5.2 e ‘4.3’ per JBoss EAP 4.3.
L'esecuzione del comando publican create --name Nome_Doc --version versione configura propriamente il numero di prodotto.
Per non tenere conto di questo tag, usare il parametro version nel file publican.cfg, in particolare se il termine versione di prodotto, non contiene solo cifre.
Publican usa i dati in questo tag per generare parti del nome di file per i pacchetti RPM, a meno che non siano superati dai dati nel file publican.cfg. Se i dati nel tag non sono superati da quelli in publican.cfg, questo tag può contenere solo cifre ed il carattere punto (‘0–9’ e ‘.’).
<edition>edizione</edition>Il numero di edizione del libro. La prima edizione di un libro dovrebbe coincidere con 1.0 (a meno di usare 0.x per versioni pre-release di un libro). Le edizioni successive dovrebbero incrementare 1.x per indicare ai lettori una nuova edizione del libro. Questo tag imposta il numero di versione nel nome di file di un RPM, creato con publican package.
Per esempio, impostando edition ad 1.2 e compilando il libro con il comando publican package --binary --lang=en-US, si crea un file RPM di nome nomeprodotto-titolo-numeroprodotto-en-US-1.2-0.src.rpm.
L'esecuzione del comando publican create --name Nome_Doc --edition x.y configura propriamente l'edizione.
Per non tenere conto di questo tag, usare il parametro edition nel file publican.cfg, in particolare se il termine edizione non contiene solo cifre.
Publican usa i dati in questo tag per generare parti del nome di file per i pacchetti RPM, a meno che non siano superati dai dati nel file publican.cfg. Se i dati nel tag non sono superati da quelli in publican.cfg, questo tag può contenere solo cifre ed il carattere punto (‘0–9’ e ‘.’).
<pubsnumber>numero_pub</pubsnumber>
Il pubsnumber imposta il numero di release (l'ultima cifra) nel nome di file di un RPM, creato con publican package. Per esempio, impostando il pubsumber a 1 e compilando il libro con il comando publican package --binary --lang=en-US, si crea un file RPM di nome nomeprodotto-titolo-numeroprodotto-en-US-edizione-1.src.rpm.
Per non tenere conto di questo tag, usare il parametro release nel file publican.cfg, in particolare se il numero di release del documento non contiene solo cifre.
Publican usa i dati in questo tag per generare gli elementi del nome di file per i pacchetti RPM, a meno che non siano superati dai dati nel file publican.cfg. Se i dati nel tag non sono superati da quelli in publican.cfg, questo tag può contenere solo cifre (‘0–9’).
<abstract><para>abstract</para></abstract>
Una breve descrizione e sintesi sull'argomento e sulla finalità del libro, generalmente non più lungo di un paragrafo. L'abstract compare prima del sommario dei contenuti nelle presentazioni HTML e nella seconda pagina nelle presentazioni PDF. Se si compila il pacchetto RPM per un libro, il tag abstract imposta il campo Description nel file spec dell'RPM. Ciò rende disponibile l'abstract con il comando rpm -qi.
Si possono aggiungere metadati extra al file Book_Info.xml di un documento, a supporto di specifiche proprietà nei vari formati d'uscita:
<keywordset>, <keyword>
I termini con il tag <keyword> contenuti in un <keywordset>, sono inseriti all'interno di tag <meta name="keywords">, presenti nel tag head dei file HTML e nel campo Keywords delle proprietà di un documento PDF.
<subjectset>, <subject>
I termini con il tag <subject> contenuti in un <subjectset> sono aggiunti al campo Subject delle proprietà di un documento PDF e nei metadati di un e-book in formato EPUB.
Si consideri di usare un vocabolario controllato per la definizione del soggetto di un documento, per esempio, il descrittore di soggetto dell'LCSH (Library of Congress Subject Headings). Si identifichi il vocabolario scelto con l'attributo scheme nel tag <subjectset>, per esempio <subjectset scheme="libraryofcongress">. In tal modo è possibile ricercare tra i descrittori di LCSH, nella pagina Authorities & Vocabularies di Library of Congress: http://id.loc.gov/authorities/search/.
<mediaobject role="cover" id="epub_cover">
Usare un tag <mediaobject> con attributi role="cover" e id="epub_cover" per impostare cover-art per e-book in formato EPUB. Per esempio:
<mediaobject role="cover" id="epub_cover"> <imageobject role="front-large" remap="lrg"> <imagedata width="600px" format="PNG" fileref="images/front_cover.png"/> </imageobject> <imageobject role="front" remap="s"> <imagedata format="PNG" fileref="images/front_cover.png"/> </imageobject> <imageobject role="front-small" remap="xs"> <imagedata format="PNG" fileref="images/front_cover.png"/> </imageobject> <imageobject role="thumbnail" remap="cs"> <imagedata format="PNG" fileref="images/front_cover_thumbnail.png"/> </imageobject> </mediaobject>
Come per le altre immagini in documenti, salvare le cover-art nella sotto-cartella images.
Come già notato, il file predefinito Book_Info.xml usato da Publican, include un tag <edition>.
Se si distribuisce un libro come un pacchetto RPM, i dati di questo tag impostano le prime due cifre del numero di versione del file RPM.
Quindi una edizione '1.0' diventa una versione '1.0'.
Il file Book_Info.xml contiene anche il tag <pubsnumber>. I dati di questo tag modificano il numero di release del pacchetto RPM.
Un libro con edizione 1.0 e pubsumber 5, diventerebbe la versione 1.0 e release 5 (1.0-5).
I tag edition e pubsumber non sono correlati al tag <productnumber>, anch'esso presente in Book_Info.xml: infatti <productnumber> specifica la versione del prodotto documentato o descritto.
Del resto, è naturale avere la II edizione di un libro per una particolare versione di un prodotto.
In bibliografia, due copie di un libro fanno parte della stessa edizione se risultano stampati usando sostanzialmente la stessa composizione tipografica o di pagina. ('Sostanzialmente' sono tollerati solo correzioni tipografiche ed altre correzioni minori).
Diversamente, i collezionisti di libri solitamente si riferiscono alla 'prima edizione' come alla 'prima uscita di stampa'; i bibliografi invece prestano attenzione al testo solitamente situato nelle prime pagine interne di un libro, in cui si specifica per esempio, 'II ristampa' o 'IV edizione'.
Noi raccomandiamo di seguire il metodo seguito dai bibliografi. Quando si usa Publican per ripubblicare un libro da un file XML sostanzialmente identico, incrementare il tag <pubsnumber>. Esso ha una funzione molto simile alla ristampa nella editoria tradizionale.
Per il cambio di <edition>, si raccomanda di usare lo stesso criterio degli editori tradizionali: nel caso di revisione o di riscrittura significativa. Su cosa sia significativo e su quanto debba essere consistente una riscrittura, da richiedere un incremento intero o decimale nel numero di edizione, resta a discrezione dell'editore.
Il file Author_Group.xml non è richiesto ed è la locazione standard in cui inserire autore, editore, grafico ed altri dettagli di merito. Il seguente è un esempio di file Author_Group.xml:
<?xml version="1.0" encoding="utf-8"?> <authorgroup xmlns="http://docbook.org/ns/docbook" version="5.0"> <author> <orgname>FF0000 Headgear Documentation Group</orgname> </author> <author> <personname> <firstname>Dude</firstname> <surname>McDude</surname> </personname> <affiliation> <orgname>My Org</orgname> <orgdiv>Best Div in the place</orgdiv> </affiliation> <email>dude.mcdude@myorg.org</email> </author> </authorgroup>
Il file Author_Group.xml non necessariamente deve contenere tutte queste informazioni: inserire a discrezione quelle richieste.
Gli articoli di DocBook non possono contenere capitoli. Se si usa l'opzione --type=article con il comando publican create, Publican non crea anche un file Chapter.xml. Usare le sezioni per organizzare il contenuto degli articoli.
Fare riferimento alla Guida DocBook: The Definitive Guide di Norman Walsh e Leonard Muellner, disponibile su http://www.docbook.org/tdg/en/html/docbook.html, per i dettagli sui vari modi di interazioni tra set, book, articoli, part, capitoli e sezioni. In particolare, notare che gli articoli possono essere documenti a se stanti, o possono essere incorporati in libri.
Il file Chapter.xml è un modello per creare file di capitoli. Questi file costituiscono il contenuto di un libro. Di seguito si riporta un modello di capitolo (Chapter.xml) creato dal comando publican create. Notare che DOCTYPE è impostato a chapter:
<?xml version='1.0'?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <chapter id="MYBOOK-Test"> <title>Test</title> <para> This is a test paragraph </para> <section id="MYBOOK-Test-Section_1_Test"> <title>Section 1 Test</title> <para> Test of a section </para> </section> <section id="MYBOOK-Test-Section_2_Test"> <title>Section 2 Test</title> <para> Test of a section </para> </section> </chapter>
Il capitolo presenta due sezioni, Section 1 Test e Section 2 Test. Per ulteriori informazioni sui capitoli, fare riferimento a http://docbook.org/tdg/en/html/chapter.html della sopra citata guida.
Il file di capitolo dovrebbe essere rinominato in modo da rispecchiare l'argomento contenuto. Per esempio, un capitolo sull'installazione di un prodotto dovrebbe essere denominato Installation.xml, mentre un capitolo sull'impostazione di un software sarebbe meglio denominato, Setup.xml o Configuration.xml.
Il file Nome_Doc.xml contiene le direttive xi:include per includere gli altri file XML indispensabili al documento, tra cui i capitoli e le sezioni contenute nei vari file XML. Per esempio, il file Nome_Doc.xml di un libro riunisce i capitoli contenuti in distinti file XML.
Ecco un esempio di Nome_Doc.xml che descrive un libro di DocBook — notare il parametro DOCTYPE impostato con book.
Esempio 4.4. Un libro DocBook
<?xml version='1.0'?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <book> <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Chapter.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <index /> </book>
Questo esempio carica i file XML Book_Info.xml, Preface.xml, Chapter.xml e Appendix.xml.
L'ordinamento dei capitoli è importante. La creazione di questo libro, prevede che Book_Info.xml preceda Preface.xml che a sua volta preceda Chapter.xml, e così via.
Il file Nome_Doc.xml non si limita all'uso delle direttive xi:include. Si possono creare documenti anche con un solo file XML. Di seguito si riporta un esempio di libro, usando un singolo file XML:
<book> <chapter> <title>Chapter 1</title> <para> A paragraph in Chapter 1. </para> <section id="section1"> <title>Chapter 1 Section 1</title> <para> A paragraph in Section 1. </para> </section> <section id="section2"> <title>Chapter 1 Section 2</title> <para> A paragraph in Section 2. </para> </section> </chapter> <chapter> <title>Chapter 2</title> <para> A paragraph in Chapter 2. </para> </chapter> </book>
This book contains two chapters. Chapter one contains two sections. Refer to http://docbook.org/tdg/en/html/section.html for further information about sections, and http://docbook.org/tdg/en/html/book.html for further information about books.
Il file Nome_Doc.ent è usato per definire entità locali. Le entità YEAR e HOLDER sono usate per informazioni di copyright. Per impostazione, Publican imposta YEAR con l'anno corrente, ed inserisce un messaggio in HOLDER che richiama di specificare la licenza per il documento. Se mancano entrambe le entità YEAR e HOLDER, il documento non compila.
Altre entità potrebbero essere richieste dal brand applicato al documento. Per esempio, il brand per i documenti Fedora, usa l'entità BOOKID per indicare l'identificativo del documento ai lettori che desiderano inviare commenti.
<?xml version='1.0'?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <book> <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Chapter.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <index /> </book>
Le entità sono convenienti, ma dovrebbero essere usate con particolare attenzione in quei documenti che saranno tradotti. Scrivere per esempio, &FDS; invece di Fedora Directory Server è un vantaggio per il redattore del documento; tuttavia le entità non risultano trasformate nei file PO (Portable Object) usati dai traduttori. Di conseguenza, risulta impossibile una traduzione completa di un documento contenente entità.
Le entità rappresentano degli ostacoli per i traduttori, precludendo la possibilità di realizzare traduzioni di qualità. La natura propria di una entità è di rendere esattamente, in ogni occorrenza del documento ed in ogni lingua, la parola o frase rappresentata. Questa scarsa flessibilità comporta che la parola o gruppo di parole, rappresentate dall'entità, possa essere illeggibile o incomprensibile in certe lingue e non possa modificarsi al cambiare delle regole grammaticali richieste dalla lingua. Inoltre, poiché durante la conversione in PO dei file XML, le entità non vengono trasformate, i traduttori non possono selezionare correttamente, secondo le regole grammaticali della propria lingua, le parole da inserire intorno all'entità.
Se si definisce una entità — <!ENTITY LIFT "Liberty Installation and Formatting Tome"> — nel file XML si può inserire un riferimento all'entità definita, &LIFT; e in ogni compilazione HTML, PDF o semplice testo, si visualizzerà l'entità Liberty Installation and Formatting Tome.
Le entità non vengono trasformate durante la conversione in PO dei file XML. Quindi, i traduttori non vedono mai Liberty Installation and Formatting Tome, ma soltanto &LIFT;, che non possono tradurre.
Si consideri per esempio la traduzione in tedesco, del seguente frammento in lingua inglese:
As noted in the Liberty Installation and Formatting Tome, Chapter 3…
Una traduzione potrebbe essere:
Wie in dem Wälzer für die Installation und Formatierung von Liberty, Kapitel 3, erwähnt…
Poiché non esistono entità, il titolo può essere tradotto in un tedesco corretto. Inoltre, notare in questo contesto linguistico, l'uso di ‘dem’, la forma corretta dell'articolo determinativo ('il') quando riferito a Wälzer ('tomo')
Per contrasto, usando le entità, la stessa frase nel file PO risulta:
#. Tag: para #, no-c-format msgid "As noted in the <citetitle>&LIFT;</citetitle>, Chapter 3…" msgstr ""
La traduzione di ciò, probabilmente sarebbe:
#. Tag: para #, no-c-format msgid "As noted in the <citetitle>&LIFT;</citetitle>, Chapter 3…" msgstr "Wie in <citetitle>&LIFT;</citetitle>, Kapitel 3, erwähnt…"
E nella presentazione si avrebbe:
Wie in Liberty Installation and Formatting Tome, Kapitel 3, erwähnt…
In tal caso, ovviamente il titolo rimane in inglese, incluse le parole come 'Tome' e 'Formatting' che il lettore difficilmente comprende. Inoltre, il traduttore è costretto ad omettere l'articolo definitivo ‘dem’, per un costrutto più generico che si avvicina ad un ibrido tra inglese e tedesco, definito Denglisch o Angleutsch, dai madrelingua tedesca. Molti di coloro che parlano il tedesco, ritengono scorretto questo approccio e quasi tutti un modo poco elegante.
Problemi analoghi emergono con un frammento come questo:
However, a careful reading of the Liberty Installation and Formatting Tome afterword shows that…
Senza testo nascosto da entità, una traduzione in tedesco potrebbe essere:
Jedoch ergibt ein sorgfältiges Lesen des Nachworts für den Wälzer für die Installation und Formatierung von Liberty, dass…
Se, per salvare tempo di scrittura, si fosse usata un'entità, il traduttore si sarebbe trovato con questo:
#. Tag: para #, no-c-format msgid "However, a careful reading of the <citetitle>&LIFT;</citetitle> afterword shows that…" msgstr ""
E la traduzione sarebbe stata differente, in modo sottile ma rilevante:
#. Tag: para #, no-c-format msgid "However, a careful reading of the <citetitle>&LIFT;</citetitle> afterword shows that…" msgstr "Jedoch ergibt ein sorgfältiges Lesen des Nachworts für <citetitle>&LIFT;</citetitle>, dass…"
Presentata al lettore, questa apparirebbe come:
Jedoch ergibt ein sorgfältiges Lesen des Nachworts für Liberty Installation and Formatting Tome, dass…
Di nuovo, notare l'assenza dell'articolo determinativo (den in questo contesto grammaticale). Ciò è poco elegante ma necessario, in quanto il traduttore può solo tentare di indovinare l'articolo (den, die o das), generando molto probabilmente un errore.
Infine, tener presente che anche se un termine è invariabile in inglese, ciò non necessariamente è vero in altre lingue, anche quando si tratta di un nome proprio come quello di un prodotto. In molte lingue, i nomi cambiano la loro forma (flessione) in accordo al ruolo nel periodo (caso grammaticale). Una entità in un file XML, impostata per rappresentare un nome inglese o un sintagma nominale (noun phrase) rende praticamente impossibile una traduzione corretta in tali lingue.
Per esempio, se si scrive un documento che si può applicare a più di un prodotto, si potrebbe essere tentati di impostare una entità come &PRODUCT;. Il vantaggio di questo approccio è che cambiando semplicemente questo valore nel file Nome_Doc.ent, si può facilmente adattare il libro a una documentazione, per esempio, per Red Hat Enterprise Linux, Fedora, o CentOS. Comunque, mentre il nome proprio Fedora non subisce variazioni nella lingua inglese, (per esempio) in ceco, presenta sei forme differenti, una per ciascuno dei possibili ruoli in un periodo:
Tabella 4.1. 'Fedora' in ceco
| Caso | Uso | Forma |
|---|---|---|
| Nominativo | il soggetto di un periodo | Fedora |
| Genitivo | indica possesso | Fedory |
| Accusativo | l'oggetto diretto di un periodo | Fedoru |
| Dativo | l'oggetto indiretto di un periodo | Fedoře |
| Vocativo | rivolto direttamente al soggetto | Fedoro |
| Locativo | riguarda un argomento o luogo | Fedoře |
| Strumentale | riguarda un mezzo | Fedorou |
Per esempio:
Fedora je linuxová distribuce. — Fedora è una distribuzione Linux.
Inštalácia Fedory — Istallazione di Fedora.
Stáhnout Fedoru — Ottieni Fedora.
Přispějte Fedoře — Contribuire a Fedora.
Ahoj, Fedoro! — Ciao Fedora!
Ve Fedoře 10… — In Fedora 14…
S Fedorou získáváte nejnovější… — Con Fedora, puoi ottenere gli ultimi…
Una frase che inizia con S Fedora získáváte nejnovější… rimane comprensibile al lettore ceco, ma risulta sintatticamente scorretta. Lo stesso effetto si può aver con la lingua inglese, infatti anche se i sostantivi hanno perso l'uso delle desinenze intorno al Medio Evo, i pronomi hanno conservato la flessione. La frase, 'Me see she' risulta completamente comprensibile ad un inglese, ma non è la forma che ci si aspetterebbe di leggere, poiché non è corretta la forma dei pronomi me e she. Me è la forma accusativa del pronome, ma poiché è il soggetto del periodo, il pronome dovrebbe assumere la forma nominativa, I. Analogamente, she è il caso nominativo, ma come oggetto diretto del periodo il pronome dovrebbe assumere la forma accusativa, her.
I sostantivi nella maggior parte delle lingue slave come russo, ceco, polacco, serbo e croato, hanno sette differenti casi. I sostantivi nelle lingue Finno–ugriche come finlandese, ungherese ed estone hanno tra quindici e diciassette casi. Altre lingue modificano i sostantivi per altre ragioni. Per esempio, le lingue scandinave flettono i sostantivi per indicare determinazione — se il sostantivo si riferisce ad 'una cosa' o 'alla cosa' — ed alcuni dialetti di queste lingue flettono i sostantivi per determinazione e per declinazione.
Ora si estendano tali problemi a tutte le lingue (più di 40), attualmente supportate da Publican. Oltre alle poche stringhe non tradotte che Publican specifica per impostazione nel file Nome_Doc.ent, le entità possono risultare utili per specificare i numeri di versione dei prodotti. Al di là di ciò, l'uso delle entità sembra quasi un desiderio di inibire e ridurre la qualità delle traduzioni. Inoltre, il lettore del documento, tradotto in una lingua con inflessione di sostantivi (declinazione, determinazione o altro), non sa di certo che l'errore grammaticale è generato dalle entità impostate nell'XML — concludendo, con buona probabilità, che si tratta di incompetenze del traduttore.
Durante la sua elaborazione, il comando publican package individua nella directory dei file XML, il primo file contenente un tag <revhistory>. Successivamente publican usa questo file per compilare la cronologia di revisione del pacchetto RPM.
Salvare le immagini nelle sottocartella images della cartella contenente i file XML. Usare ./images/nome_immagine per inserire le immagini in un libro. Di seguito si riporta un esempio che inserisce l'immagine testimage.png:
<mediaobject> <imageobject> <imagedata fileref="./images/testimage.png" /> </imageobject> <textobject><phrase>alternate text goes here</phrase></textobject> </mediaobject>
Assicurarsi di fornire un <textobject> in modo da rendere accessibile il contenuto alle persone con disabilità visiva. In alcuni Stati, potrebbe essere una responsabilità legislativa permettere questa accessibilità — per esempio negli Stati Uniti alle organizzazioni si richiede di rispettare la Section 508 del Rehabilitation Act of 1973.[1]
Se il libro contiene immagini che occorre localizzare — per esempio, gli screenshot di una interfaccia utente in una altra lingua da quella originale del libro — salvare queste immagini nelle sottocartelle images delle directory linguistiche. Assicurarsi che il file dell'immagine tradotta abbia lo sesso nome del file della lingua originale. Quando si compila un libro per una lingua, Publican usa il file della sottocartella images/ nella directory linguistica pertinente e non quello nella sottocartella images/ della lingua originale.
Publican usa soltanto le immagini nella sottocartella images della cartella contenente i file XML e le corrispondenti immagini nelle sottocartelle images pertinenti alle lingue. Immagini salvate in altre directory non vengono prese in considerazione.
Se il libro contiene pezzi di codice, salvare il file in una sotto-cartella denominata extras/ nella cartella della lingua originale, ed usare un <xi:include> per caricare il file del codice nella struttura XML del documento. Ogni file contenuto nella cartella extras/ non viene analizzato sintatticamente (parsed) come XML da Publican.
Certain characters are reserved in XML, in particular, & and <. If you insert code samples directly into the XML of your document, you must escape these characters, either by marking them as CDATA or by replacing them with entities (& and < respectively).[2] If you place these files in the extras/ directory, you do not need to escape these characters. This approach saves time, reduces the chances of introducing errors into either the document XML or the code itself, and makes future maintenance of the document and the code easier.
Per includere nel documento, un pezzo di codice contenuto nella cartella extras/, seguire questa procedura:
Creare la cartella extras
mkdir en-US/extrasCopiare il file del codice nella cartella extras
cp ~/samples/foo.c en-US/extras/.
Nel file XML, includere il file di codice in un tag xi:include
<programlisting> <xi:include parse="text" href="extras/foo.c" xmlns:xi="http://www.w3.org/2001/XInclude" /> </programlisting>
Ora si può modificare il file en-US/extras/foo.c nel proprio editor preferito, senza doversi preoccupare di eventuali effetti nell'XML.
Lo stesso approccio funziona annotando il codice con callout. Per esempio:
<programlistingco> <areaspec> <area id="orbit-for-parameter" coords='4 75'/> <area id="orbit-for-magnitude" coords='12 75'/> </areaspec> <programlisting language="Fortran"><xi:include parse="text" href="extras/orbit.for" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting> <calloutlist> <callout id="callout-for-parameter" arearefs="orbit-for-parameter"> <para> The <firstterm>standard gravitational parameter</firstterm> (μ) is a derived value, the product of Newton's gravitational constant (G) and the mass of the primary body. </para> </callout> <callout id="callout-for-magnitude" arearefs="orbit-for-magnitude"> <para> Since the mass of the orbiting body is many orders of magnitude smaller than the mass of the primary body, the mass of the orbiting body is ignored in this calculation. </para> </callout> </calloutlist> </programlistingco>
Notare gli elementi <area> che definiscono la posizione dei callout che compaiono nel codice. Gli attributi in coords specificano un numero di riga ed un numero di colonna, separati da uno spazio. In questo esempio, i callout sono applicati alle righe 4 e 12 del codice, entrambi allineati sulla colonna 75. Anche se questo approccio prevede di adattare gli attributi coords ad ogni modifica apportata al codice, ciò evita di combinare tag <coords> nel codice.
[2] Refer to section 2.4 "Character Data and Markup" in the XML 1.0 standard, available from http://www.w3.org/TR/2008/REC-xml-20081126/.
Publican permette di includere file arbitrari all'interno di un documento. Questi file vengono inclusi nel pacchetto RPM compilato da Publican e vengono installati sul sistema dell'utente insieme al documento. Per esempio, si possono includere file multimediali di tutorial a complemento del documento, o file di codice sorgente o altro materiale utile agli utenti per lavorare con gli esempi o i tutorial.
Per distribuire file arbitrari con un documento, includerli in una cartella denominata files, e salvarla nella cartella della lingua originale (p.e. en-US) del libro (p.e. My_Book).
Nella cartella My_Book:
mkdir en-US/files
Copiare i file nella cartella files:
cp arbitrary_files en-US/filesIl comando publican rename permette di rinominare facilmente un documento con un nuovo titolo o di modificare il nome o la versione di prodotto, a cui si riferisce il documento. Il comando accetta fino a tre opzioni:
--name nuovo_titolomodifica il titolo del documento. Per esempio, per rinominare Server Deployment Guide il documento Server Configuration Guide, spostarsi nella directory radice del documento ed eseguire:
publican rename --name "Server Deployment Guide"
Nello specifico, il comando cambia il contenuto del tag <title> in Article_Info.xml, Book_Info.xml o Set_Info.xml, ed imposta un valore nel parametro mainfile in publican.cfg, in modo che publican possa trovare il nodo XML radice e le entità relative al documento.
Notare che il comando publican rename non modifica il nome di nessun file. Quindi, il nodo XML radice e le entità del documento sono localizzate sempre nei file relativi al titolo originale del documento — Server_Configuration_Guide, nel precedente esempio.
--product nuovo_prodottomodifica il nome del prodotto cui si applica il documento. Per esempio, se il prodotto era ForceRivet ed ora è denominato PendantFarm, spostarsi nella directory radice del documento ed eseguire:
publican rename --product PendantFarm
Il comando modifica il contenuto del tag <productname> in Article_Info.xml, Book_Info.xml o Set_Info.xml.
--version nuova_versionemodifica la versione di prodotto cui si applica il documento. Per esempio, se la versione precedente era 1.0 ma ora è cambiata in 2.0 , spostarsi nella directory radice del documento ed eseguire:
publican rename --version 2.0
Il comando modifica il contenuto del tag <productnumber> in Article_Info.xml, Book_Info.xml o Set_Info.xml.
In un comando, è possibile usare una loro qualsiasi combinazione. Per esempio:
publican rename --name "Server Deployment Guide" --product PendantFarm --version 2.0Supporto per la localizzazione di documenti è stata una considerazione chiave del progetto di Publican. Il workflow di traduzione generale dei documenti sviluppati in Publican procede come segue:
Completare l'XML di un documento.
Questa versione XML del documento dovrebbe essere considerata ‘frozen’. Se il documento si trova in un repository con controllo di versione, a questo punto, la versione verrebbe spostata in una cartella separata o branch. In tal modo i redattori possono iniziare a lavorare su versioni successive del documento in un branch, e fornire una base stabile per traduzione in un altro branch.
Optional but recommended: drop the document to translation. Run:
$ publican trans_drop
Publican creates a new subdirectory, named trans_drop/. The trans_drop/ subdirectory contains a snapshot of the source files of the document. When the trans_drop/ directory is present in a documentation project, Publican uses its content as the basis for the commands documented later in this procedure.
Generare i file POT (Portable Object Template) dai file XML:
$ publican update_pot
Se è la prima volta che si creano i file POT per il documento, Publican crea una nuova sottocartella, denominata pot. La sottocartella pot contiene un file pot per ciascun file XML nel documento. Se Publican ha creato i file POT precedentemente, Publican aggiorna i file POT esistenti per rispecchiare i cambiamenti apportati ai file XML dall'ultimo aggiornamento dei file POT.
Publican genera un file POT per ogni file XML presente della cartella dei file XML, che siano usati o meno nel documento. Se si trasformano in POT file XML non usati, si spreca il tempo e lo sforzo dei volontari traduttori, e si spreca denaro per le traduzioni commissionate a pagamento.
Usare il comando publican print_unused per visualizzare l'elenco dei file XML non usati nel documento.
Generare dai file POT, i file PO (Portable Object) per poter avviare la traduzione in una particolare lingua.
$ publican update_po --langs=codice_linguadove codice_lingua è il codice per la lingua target. Fare riferimento all'Appendice F, Codici di lingua per maggiori informazioni su questi codici. Si possono fornire codici linguistici multipli, separati da virgole, in modo da generare i file PO per più lingue. Per esempio:
$ publican update_po --langs=hi-IN,it-IT,ru-RU,zh-CN
If this is the first time that PO files have been created for a particular language, Publican creates a new subdirectory, named with the language code that you specified with the --langs= option. This subdirectory holds a PO file for each POT file in pot subdirectory, plus a Revision_History.xml file that tracks the history of this particular translation. When created for the first time, the Revision_History.xml file records the date on which the PO files for this translation were created, and the version of the source language XML (taken from the source language's Revision_History.xml file) on which this translation is therefore based.
If Publican has created PO files for this language previously, Publican updates the existing PO files to reflect any changes in the POT files since the PO files were last updated, and adds a new entry to the translation's Revision_History.xml file to record the date on which the PO files for this translation were refreshed, and the version of the source language XML on which the revision is based. You can update existing PO files in every subdirectory with the --langs=all option:
$ publican update_po --langs=all
Publican genera un file PO per ogni file POT presente della cartella pot, a prescindere se il file POT corrisponda o meno ad un file XML usato nel documento, o corrisponda ad un file XML esistente. Se si trasformano in file PO, i POT da file XML non usati od eliminati, si spreca il tempo e lo sforzo dei volontari traduttori, e si spreca denaro per le traduzioni commissionate a pagamento.
Quando si generano i file PO, Publican mostra un avviso per i file POT che non presentano un corrispondente file XML, tuttavia genera comunque il file PO. Comunque, Publican non avvisa se esiste un file POT corrispondente ad un file XML non usato nel documento.
Tradurre le stringhe contenute nei file PO.
If you are updating a previously published translation of this revision in the source language, use Publican's publican add_revision command to describe your changes or corrections. Publican updates the Revision_History.xml file for you.
If the document has changed in its original language, use the publican trans_drop, publican update_pot, and publican update_po commands as described earlier in this procedure instead.
Creare il documento per la lingua desiderata, per esempio:
$ publican build --formats=html,html-single,pdf --langs=it-IT,nb-NOo il pacchetto per la lingua desiderata, per esempio:
$ publican package --lang=it-IT
E' possibile creare il documento in tutte le lingue di cui si dispone una traduzione, usando l'opzione --langs=all, mentre i pacchetti vanno compilati individualmente. Fare riferimento alla Sezione 4.7, «Creare un documento» ed alla Sezione 4.8, «Creare il pacchetto di un documento» per maggiori informazioni.
Translation takes place after a book has been finalized. You do not need to know who will translate your book in order to give them credit. Create $translation/Author_Group.xml and add a valid DocBook authorgroup. The translator can add their details to this file and Publican will append it to $source_lang/Author_Group.xml when the book is build. This allows authors to finalize the original text without needing to know who will translate the book.
DocBook automatically collates and sorts <glossentry> elements into a book's glossary; and <primary>, <secondary>, and <tertiary> <indexterm> elements into a book's index. Entries are sorted automatically, and although this system works well for languages written with an alphabet, abugida, or syllabic script, languages written with logograms sort less well.
To manually adjust the sort order of a glossary entry or index entry, manually add DocBook's sortas attribute to the XML element. For example, to ensure that the Japanese word 暗号化 sorts correctly in an index, specify:
#. Tag: indexterm #, no-c-format msgid "<primary>encryption</primary>" msgstr "<primary sortas="あんごうか">暗号化</primary>"
Similarly, to ensure that the Japanese word 暗号化 sorts correctly in a glossary, specify:
#. Tag: glossentry #, no-c-format msgid "<glossterm>encryption</glossterm>" msgstr "<glossterm sortas="あんごうか">暗号化</glossterm>"
I parametri impostati nel file di configurazione del documento (per impostazione publican.cfg), permettono di controllare molti aspetti riguardanti la presentazione di un documento — fare riferimento a Sezione 4.1.1, «Il file publican.cfg».
Se si mantengono versioni multiple di un documento, si può creare un file di configurazione per ciascuna versione. Quando si crea un documento, si può usare l'opzione --config per specificare il file da usare per una particolare compilazione, per esempio:
publican build --formats html,pdf --langs en-US,de-DE,it-IT --config community.cfgPer creare un documento:
Verificare che nel file Nome_Doc.ent, siano state configurate le entità YEAR e HOLDER, come descritto nella Sezione 4.1.6, «Nome_Doc.ent».
Spostarsi nella cartella radice del documento. Per esempio, se il documento ha il nome Libro_di_Prova e si trova in ~/libri/, eseguire il seguente comando:
cd ~/libri/Libro_di_ProvaEseguire un test, per evitare che ci siano errori di compilazione nel linguaggio desiderato, per esempio:
publican build --formats=test --langs=it-ITEseguire il seguente comando per creare il libro:
publican build --formats=formati --langs=lingue
Sostituire formati con la lista dei formati d'uscita, separati da virgole, per esempio html,html-single,pdf. Sostituire lingue con la lista dei codici linguistici, separati da virgole, per esempio en-US,sv-SE,it-IT,ko-KR.
Formati per l'azione build
htmlPublican presenta il documento in multiple pagine HTML, con ciascun capitolo e le principali sezioni su pagine separate. Publican crea un indice all'inizio del documento e posiziona controlli di navigazione su ogni pagina.
Usare i parametri chunk_first e chunk_section depth nel file publican.cfg, per controllare il tipo di suddivisione delle sezioni in questo formato d'uscita.
html-singlePublican presenta il documento in una singola pagina HTML con la tabella dei contenuti posta in cima alla pagina.
html-desktopPublican presenta il documento in una singola pagina HTML con la la tabella dei contenuti posta in un pannello separato a sinistra del documento.
manPublican presenta il documento in pagine di manuale (o "man page"), in uso nei Sistemi Operativi Linux, Unix e simili.
pdfPublican presenta il documento in un file PDF.
testPublican controlla la validità della struttura XML del libro, senza effettuare nessuna trasformazione.
txtPublican presenta il documento in un singolo file di testo.
epubPublican presenta il documento in un e-book in formato EPUB.
eclipse
Publican presenta il documento come un plugin d'aiuto di Eclipse. Vedere la Sezione 4.1.1, «Il file publican.cfg» per i dettagli sui parametri d'impostazione ec_id, ec_name ed ec_provider.
I seguenti esempi mostrano alcuni comandi comunemente usati con publican build:
Elenca le opzioni disponibili in publican build per creare un libro.
Controlla che il libro compili correttamente. Compilare con --formats=test prima di eseguire ogni altro comando publican build, e prima di riportarlo su un repository di controllo versione, da cui altri contributori possano scaricarlo.
Compila il libro in formato HTML su pagine multiple. Il documento in HTML viene salvato nella directory Nome_Doc/tmp/lingua/html/. Ogni capitolo e ogni sezione principale viene disposto in un file HTML separato. E' possibile controllare il livello di suddivisione delle sotto-sezioni da presentare su pagine HTML separate, con il parametro chunk-section-depth in publican.cfg — fare riferimento alla Sezione 4.1.1, «Il file publican.cfg».
Crea il libro in formato HTML su una pagina singola. Il documento è un unico file HTML salvato nella directory Nome_Doc/tmp/lingua/html-single/.
Crea il libro in formato PDF. Publican si appoggia ad una applicazione esterna, FOP per rendere il PDF. Quindi, la compilazione per PDF potrebbe non essere disponibile su tutti i sistemi, dipendendo dalla disponibilità di FOP. Il documento è un unico file PDF salvato nella directory Nome_Doc/tmp/lingua/pdf/.
Crea il libro nei formati HTML su pagine multiple e su pagina singola, e PDF.
Publican controlla la validità della struttura XML con il DTD (Document Type Definition) prima di compilare il contenuto. Tuttavia in certe situazioni, come quando un documento è in fase di sviluppo, si potrebbe voler saltare la validazione durante la compilazione, soprattutto se il documento contiene riferimenti incrociati (<xref>) a sezioni del documento che ancora non esistono. Per saltare la validazione, eseguire publican build con l'opzione --novalid. I riferimenti a contenuto non esistente, nel documento creato, appaiono con tre punti interrogativi, ???.
Poiché il documento non risulta validato con il DTD, la qualità della presentazione prodotta usando l'opzione --novalid è quantomeno sospetta. Non pubblicare i documenti compilati con l'opzione --novalid.
Questa sezione descrive i pacchetti di documenti distribuiti con il Gestore di pacchetti RPM. Quando si usa il comando publican package, Publican genera un tarball che può essere usato per ricavare un pacchetto, da distribuire con un gestore di pacchetti software differente. Se si esegue publican package su un sistema senza rpmbuild installato, Publican genera ancora il tarball anche se non può creare da esso il pacchetto RPM.
I parametri impostati nel file di configurazione del documento (per impostazione publican.cfg) permettono di controllare molti aspetti riguardanti il pacchetto di un documento (Sezione 4.1.1, «Il file publican.cfg»).
Se si mantengono versioni multiple di un documento, si può creare un file di configurazione per ciascuna versione. Quando si crea il pacchetto di un documento, si può usare l'opzione --config per specificare il file da usare per una particolare compilazione, per esempio:
publican package --lang it-IT --config community.cfgPublican non solo crea documenti, ma può creare anche pacchetti RPM di questi contenuti, da distribuire su workstation o server web. I pacchetti RPM sono usati per distribuire software nei computer con sistemi operativi Linux che usano un Gestore di pacchetti RPM. Tra questi sistemi operativi si annoverano Red Hat Enterprise Linux, Fedora, Mandriva Linux, SUSE Linux Enterprise, openSUSE, Turbolinux e Yellow Dog Linux, per citarne alcuni.
Publican può produrre sia pacchetti RPM di sorgenti (pacchetti SRPM) sia pacchetti RPM di binari. Inoltre, sia i pacchetti SRPM sia i pacchetti RPM binari possono essere configurati per essere portati su workstation o server web.
Un pacchetto SRPM contiene il codice sorgente usato per generare il software, invece del software vero e proprio. Per usare un pacchetto SRPM, un sistema deve compilare il codice sorgente in software — o in questo caso in documenti. I pacchetti SRPM generati da Publican contengono i file XML dei documenti ed un file spec, invece di documenti completati (HTML, PDF, EPUB, ecc). Con la versione attuale di RPM Package Manager, non è possibile installare direttamente documentazione da un pacchetto SRPM.
Al contrario, i pacchetti RPM binari contengono software — o in questo caso, un documento — pronto per essere salvato nel file system del computer ed essere immediatamente usato. I contenuti di un pacchetto RPM binario non necessitano di essere compilati dal sistema su cui vengono installati e perciò, il sistema non ha bisogno di installare Publican. L'installazione su un webserver di documentazione, generata da Publican, necessita di Publican, ma in questo caso non per la compilazione del codice sorgente. Fare riferimento alla Sezione 4.8.1.2, «Pacchetti per il desktop e pacchetti per il web» per una descrizione sulle differenze tra documentazione installata per uso locale (RPM per desktop) e documentazione installata per servire contenuti web (RPM per il web).
Publican può creare pacchetti di documenti che possono essere consultati su una workstation (pacchetto RPM desktop) o che possono essere installati su un server web e resi pubblici sul World Wide Web (pacchetto RPM web). Il pacchetto RPM desktop generato da Publican, e il pacchetto RPM web dello stesso documento differiscono per il fatto che il pacchetto RPM desktop installa solo la documentazione per l'uso sul computer locale, mentre l'RPM web installa anche il contenuto necessario a servire il World Wide Web.
I pacchetti RPM (binari) desktop di documenti creati con Publican, contengono la documentazione in formato HTML, su pagina singola. I documenti distribuiti con questi pacchetti, vengono installati in una sotto-cartella di /usr/share/doc/, secondo la specifica FHS (Filesystem Hierarchy Standard) della ‘Miscellaneous documentation’.[3] Il pacchetto RPM desktop contiene anche un file desktop, salvato in /usr/share/applications/. Questo file abilita gli ambienti desktop come GNOME e KDE, ad aggiungere il documento al menu del desktop, facilitando l'accesso agli utenti. In GNOME, per impostazione predefinita, la voce viene inserita sotto il menu → . Se si desidera personalizzare il posizionamento della voce nel menu, occorre creare un pacchetto per il menu dei documenti, che fornisce i file .directory e .menu ed occorre impostare nel file publican.cfg, i parametri dt_requires, per richiedere l'uso del pacchetto per il menu dei documenti, ed il parametro menu_category per fornire la categoria di menu appropriata. Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
Per impostazione, i pacchetti RPM web dei documenti di Publican, contengono la documentazione in formato HTML, su pagina singola e pagine multiple, e nei formati EPUB e PDF. I formati inclusi variano se:
si pubblica documentazione in una lingua, al momento priva di supporto per la presentazione in PDF. Publican si basa su FOP per generare il PDF. Allo stato attuale, FOP non supporta la scrittura sinistrorsa, come d'uso nella lingua araba, iraniana o ebraica. Inoltre, poiché allo stato attuale, FOP non è in grado di specificare i font carattere per carattere, una deficienza di font in scritture indo-arie, tra cui anche alcuni glifi latini, impediscono a Publican di generare presentazioni PDF in lingue indo-arie. Per impostazione, Publican non include i file PDF nei pacchetti web generati per la lingua araba, iraniana, ebraica o altra lingua indo-aria.
il libro o brand contiene il parametro web_formats. Il valore di questo parametro, scavalca i formati creati, in modo predefinito, da Publican. Per esempio, per pubblicare un documento solo nei formati HTML su pagina singola, PDF e testo, impostare web_formats: html-single,pdf,txt.
Il contenuto dei pacchetti è installato in sotto-cartelle di /var/www/html/, una comune radice di documenti per server web. Notare che un pacchetto SRPM web genera sia il pacchetto RPM binario per il web sia il pacchetto RPM binario per il desktop.
Usare il comando publican package --lang=Codice_Lingua per creare il pacchetto del documento, da distribuire nella lingua specificata con l'opzione --lang. Fare riferimento all'Appendice F, Codici di lingua per maggiori ragguagli sull'uso dei codici linguistici.
Se si esegue publican package senza altre opzioni oltre alla obbligatoria opzione --lang, Publican genera un pacchetto SRPM web. La lista completa delle opzioni per publican package è la seguente:
--lang linguaspecifica la lingua per cui creare il pacchetto della documentazione.
Se la traduzione in una particolare lingua è incompleta alla scadenza della release, si consideri di segnare la lingua con il parametro ignored_translations nel file publican.cfg del documento. Il pacchetto viene creato con un nome appropriato per la lingua, ma contiene la documentazione nella lingua originale del XML, invece di una traduzione parziale. A traduzione completata, rimuovere il parametro ignored_translations, incrementare il numero di release del campo Project-Id-Version, nel file Book_Info.po per la lingua, e rigenerare il pacchetto. Al momento della distribuzione del pacchetto revisionato, esso sostituisce il pacchetto originale non tradotto.
--config nome_file
specifica di usare un file di configurazione diverso dal predefinito, publican.cfg.
--desktopspecifica di creare un pacchetto RPM desktop invece di un pacchetto RPM web.
--brewspecifica di trasferire il pacchetto completato su Brew. Brew è il sistema di compilazione usato all'interno di Red Hat; questa opzione non ha effetto al di fuori di Red Hat.
--scratch
quando usato con le opzioni --brew e --desktop, specifica di compilare il pacchetto SRPM come uno scratch build (compilazione di lavoro) da trasferire su Brew. Gli scratch build sono usati per verificare la correttezza strutturale del pacchetto SRPM, senza aggiornare il database dei pacchetti con il pacchetto risultante.
--short_sighted
specifica di creare il pacchetto senza includere il numero di versione del software (version nel file publican.cfg), nel nome del pacchetto.
Molta documentazione per software è versione specifica. Nella migliore delle ipotesi, le procedure descritte nella documentazione per una versione di un prodotto potrebbero non essere d'aiuto per installare, configurare o usare una versione differente del prodotto. Nella peggiore, le procedure descritte per un prodotto potrebbero essere fuorvianti o addirittura dannose se applicate ad una versione differente.
Se si distribuisce documentazione attraverso pacchetti RPM, senza numeri di versione nei nomi dei pacchetti, il Gestore dei Pacchetti RPM sostituisce automaticamente, sui sistemi degli utenti, la documentazione esistente con l'ultima versione disponibile; gli utenti non potrebbero avere accesso a più di una versione alla volta. Assicurarsi di volere realmente questo risultato.
--binaryspecifica di compilare il pacchetto come un pacchetto RPM binario.
Dopo aver eseguito il comando publican package, Publican salva i pacchetti SRPM completati nella cartella tmp/rpm del documento, e i pacchetti RPM binari nella cartella tmp/rpm/noarch.
Per impostazione, i pacchetti di documentazione generati da Publican, sono denominati
nomeprodotto-titolo-numeroprodotto-[web]-lingua-edizione-numeropubblicazione..
build_target.noarch.estensione_file
Publican usa le informazioni nel file di configurazione (publican.cfg per impostazione predefinita), del documento per fornire i vari parametri nel nome di file, e poi le informazioni nel file Book_Info.xml per altre informazioni non presenti nel file di configurazione. Fare riferimento alla Sezione 4.1, «I file nella directory del libro» per i dettagli su questi file di configurazione. Inoltre:
i pacchetti RPM per il web includono l'elemento -web- tra la versione del prodotto ed il codice della lingua.
i pacchetti SRPM hanno l'estensione .src.rpm mentre i pacchetti RPM binari l'estensione .rpm.
i pacchetti RPM binari includono build_target.noarch prima della estensione del file, dove build_target rappresenta sistema operativo e versione relativa, per cui il pacchetto è stato compilato, come specificato dal parametro os_ver, nel file publican.cfg. L'elemento noarch specifica che il pacchetto può essere installato su ogni sistema, indipendentemente dall'architettura di sistema.
l'uso dell'opzione --short_sighted, rimuove il termine -numeroprodotto- dal nome del pacchetto.
i pacchetti di documenti tradotti, prendono i numeri di release dal parametro Project-Id-Version nei file Article_Info.po o Book_Info.po. Questo numero è specifico alla particolare lingua e non ha alcuna relazione con i numeri di release dello stesso documento, nella lingua originale o in altra lingua.
I seguenti esempi mostrano alcune opzioni comuni, riferite alla II edizione, VI revisione del documento Foomaster 9 Configuration Guide.
genera un pacchetto SRPM per desktop di nome Foomaster-Configuration_Guide-9-web-it-IT-2-6.src.rpm, contenente i sorgenti della documentazione in italiano ed uno spec file.
genera un pacchetto SRPM per desktop di nome Foomaster-Configuration_Guide-9-it-IT-2-6.src.rpm, contenente la documentazione in italiano e uno spec file.
genera sia un pacchetto RPM per web di nome Foomaster-Configuration_Guide-9-web-it-IT-2-6.el5.noarch.rpm sia un pacchetto RPM binario per desktop di nome Foomaster-Configuration_Guide-9-it-IT-2-6.el5.noarch.rpm, contenenti la documentazione in italiano, compilati per il sistema operativo Red Hat Enterprise Linux 5.
genera un pacchetto RPM binario per desktop di nome Foomaster-Configuration_Guide-9-it-IT-2-6.el5.noarch.rpm, contenente la documentazione in italiano, compilati per il sistema operativo Red Hat Enterprise Linux 5.
genera un pacchetto SRPM per desktop di nome Foomaster-Configuration_Guide-it-IT-2-6.src.rpm, contenente la documentazione in italiano. Questo pacchetto sostituisce ogni precedente versione della Configuration Guide di Foomaster, esistente su un sistema. In tal caso, gli utenti non possono avere accesso contemporaneamente alla Foomaster 8 Configuration Guide ed alla Foomaster 9 Configuration Guide.
In alcuni casi occorre mantenere multiple versioni di un libro; per esempio, un HOWTO per il prodotto FOO può avere una versione upstream ed una versione enterprise, con piccole differenze tra loro.
Publican semplifica la gestione delle differenze tra versioni multiple di un libro, permettendo di usare una sorgente unica per tutte le versioni. Il tagging condizionale garantisce che il contenuto di una versione specifica, compaia soltanto nella versione stabilita; ossia, permette di condizionare il contenuto.
Per condizionare il contenuto di un libro, usare il tag condition. Per esempio, si supponga che il libro How To Use Product Foo abbia una versione "upstream", una versione "enterprise" e una versione "beta".
<para condition="upstream"> <application>Foo</application> starts automatically when you boot the system. </para> <para condition="enterprise"> <application>Foo</application> only starts automatically when you boot the system when installed together with <application>Bar</application>. </para> <para condition="beta"> <application>Foo</application> does not start automatically when you boot the system. </para> <para condition="beta,enterprise"> To make <application>Foo</application> start automatically at boot time, edit the <filename>/etc/init.d/foo</filename> file. </para>
Per compilare una versione specifica (e quindi catturare solo il contenuto relativo a questa versione), aggiungere il parametro condition: versione al file publican.cfg ed eseguire il comando publican build, ormai noto. Per esempio, aggiungendo condition: upstream al file publican.cfg dell'HOWTO How To Use Product Foo, e poi eseguendo:
$ publican build --formats=pdf --langs=en-USPublican filtra i contenuti con i tag condizionali, escluso il tag con l'attributo condition="upstream" e compila l'How To Use Product Foo in un file PDF in lingua inglese statunitense.
Se il nodo di root di un file XML viene escluso da un tag condizionale, il documento non compila, poiché file vuoti non sono file XML validi. Per esempio, se il file Installation_and_configuration_on_Fedora.xml contiene un solo capitolo:
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <chapter id="chap-Installation_and_configuration_on_Fedora" condition="Fedora"> <title>Installation and configuration on Fedora</title> [text of chapter] </chapter>
ed il capitolo è incluso in User_Guide.xml con un tag <xi:include>, il documento non compila se è presente l'impostazione condition: Ubuntu nel file publican.cfg.
Per escludere il capitolo, aggiungere un attributo condizionale al tag <xi:include> in User_Guide.xml, e non al tag <chapter> in Installation_and_configuration_on_Fedora.xml.
Se un <xref> punta ad un contenuto escluso nella compilazione da un tag condizionale, la compilazione fallisce. Per esempio, con l'impostazione condition: upstream nel file publican.cfg, il comando publican build --formats=pdf --langs=en-US fallisce se il libro ha un tag <xref linkend="betasection"> che punta alla <section id="betasection" condition="beta">.
Usare il tagging condizionale con una certa cautela soprattutto nei libri che si presuma vengano tradotti, poiché ciò crea ulteriori difficoltà ai traduttori.
Il tagging condizionale crea difficoltà ai traduttori in due modi: oscura il contesto nei file PO (Portable Object) e rende più ardua la rilettura/correzione del documento, a quei traduttori non molto familiari con i tag condizionali.
I file PO includono tutti i tag presenti in XML, a prescindere dalle condizioni. Per esempio, se un traduttore apre il file PO, relativo all'How To Use Product Foo della Sezione 4.9, «Tagging condizionale», egli vede:
#. Tag: para #, no-c-format msgid "<application>Foo</application> starts automatically when you boot the system." msgstr "" #. Tag: para #, no-c-format msgid "<application>Foo</application> only starts automatically when you boot the system when installed together with <application>Bar</application>." msgstr "" #. Tag: para #, no-c-format msgid "<application>Foo</application> does not start automatically when you boot the system." msgstr "" #. Tag: para #, no-c-format msgid "To make <application>Foo</application> start automatically at boot time, edit the <filename>/etc/init.d/foo</filename> file." msgstr ""
Poiché i file PO non includono gli attributi dei tag, non è per nulla ovvio indicare ai traduttori che questi paragrafi sono tra loro alternativi e che il redattore non intende realizzare un flusso continuo da un pa