Product SiteDocumentation Site

Publican 3.2

Guida Utente

Pubblicare libri, articoli, relazioni e raccolte di volumi con DocBook XML

Team Publican

Don Domingo

Red Hat Engineering Content Services

Brian Forté

Red Hat Engineering Content Services

Rüdiger Landmann

Red Hat Engineering Content Services

Joshua Oakes

Red Hat Engineering Content Services

Joshua Wulf

Red Hat Engineering Content Services

A cura di

Brian Forté

Red Hat Engineering Content Services

A cura di

Rüdiger Landmann

Red Hat Engineering Content Services

Jeff Fearn

Extensive review, rough drafts, persistent annoyances. 
Red Hat, Engineering Operations Logo

Josef Hruška

Checking the Czech examples in Entities and translation 
Fedora Localization Project

Nota Legale

Copyright © 2010 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.
Prefazione
1. Convenzioni del documento
1.1. Convenzioni tipografiche
1.2. Convenzioni del documento
1.3. Note ed avvertimenti
2. Occorrono commenti!
Introduzione
1. Installare Publican
1.1. Sistemi Operativi Linux
1.1.1. Fedora
1.1.2. Red Hat Enterprise Linux 5
1.1.3. Ubuntu
1.1.4. Debian
1.1.5. OpenSuse 12
1.2. Sistemi Operativi Windows
1.3. OSX Lion
2. Publican defaults
2.1. Publican default examples
3. Comandi di Publican
3.1. Opzioni di comando
3.2. Azioni
4. Creare un documento
4.1. I file nella directory del libro
4.1.1. Il file publican.cfg
4.1.2. Book_Info.xml
4.1.3. Author_Group.xml
4.1.4. Chapter.xml
4.1.5. Nome_Doc.xml
4.1.6. Nome_Doc.ent
4.1.7. Revision_History.xml
4.2. Aggiungere immagini
4.3. Aggiungere codice
4.4. Aggiungere file
4.5. Rinominare un documento
4.6. Preparare un documento per la traduzione
4.6.1. Translation Author Group
4.7. Creare un documento
4.7.1. Compilare un documento senza controllo di validità
4.8. Creare il pacchetto di un documento
4.8.1. Tipi di pacchetti RPM
4.8.2. The $ publican package command
4.9. Tagging condizionale
4.9.1. Tagging condizionale e traduzione
4.10. Software pre-release e documentazione draft
4.10.1. Denotare il software pre-release
4.10.2. Denotare la documentazione draft
4.10.3. Denotare come draft la documentazione per software pre-release
5. Branding
5.1. Installare un brand
5.2. Creare un brand
5.3. File nella directory brand
5.3.1. Il file publican.cfg
5.3.2. I file defaults.cfg e overrides.cfg
5.3.3. File publican-brand.spec
5.3.4. README
5.3.5. COPYING
5.3.6. Common Content per il brand
5.3.7. La sotto-cartella css
5.3.8. La sotto-cartella images
5.3.9. The brand_dir option
5.4. Creare il pacchetto di un brand
6. Usare i set
6.1. Set a sé stanti
6.2. Set distribuiti
7. Creare un sito web con Publican
7.1. Creare manualmente un sito web
7.1.1. Creare la struttura del sito web
7.1.2. Creare, installare ed aggiornare la home page
7.1.3. Creare, installare ed aggiornare pagine di prodotto e di versione
7.1.4. Installare, aggiornare e rimuovere documenti
7.2. Creare un sito web usando pacchetti RPM
7.2.1. Creare la struttura del sito web
7.2.2. Creare, installare ed aggiornare la home page
7.2.3. Creare, installare ed aggiornare pagine di prodotto e di versione
7.2.4. Installare, aggiornare e rimuovere documenti
7.3. Submitting Your Sitemap to Search Engines
7.3.1. Submitting Your Sitemap to Google.
7.3.2. Submitting Your Sitemap to Bing.
8. Import book into Drupal
8.1. How to build a CSV file for Drupal import
8.2. The publican.cfg file
8.3. Drupal Import Guide
8.3.1. How to add a menu block
8.3.2. Setting up Node import
8.3.3. How to import book
8.3.4. How to update book
9. Frequently Asked Questions
A. Elementi ed attributi non permessi
A.1. Elementi non permessi
A.2. Attributi non permessi
B. Sommario dei comandi
B.1. Comandi interni
C. Parametri di publican.cfg
D. Alphabetical index of publican.cfg parameters
E. Contenuto del file dump di un sito
E.1. Ricavare gli URL dai file dump
F. File spec d'esempio per il pacchetto desktop-menu
G. Codici di lingua
H. Revision History

Prefazione

1. Convenzioni del documento

Questo manuale utilizza numerose convenzioni per evidenziare parole e frasi, ponendo attenzione su informazioni specifiche.
Nelle edizioni PDF e cartacea questo manuale utilizza caratteri presenti nel set Font Liberation. Il set Font Liberation viene anche utilizzato nelle edizioni HTML se il set stesso è stato installato sul vostro sistema. In caso contrario, verranno mostrati caratteri alternativi ma equivalenti. Da notare: Red Hat Enterprise Linux 5 e versioni più recenti, includono per default il set Font Liberation.

1.1. Convenzioni tipografiche

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_novel nella 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 filesystem per file system, file per file, e dir per 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:
Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, select the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
Per inserire un carattere speciale in un file gedit selezionare ApplicazioniAccessoriMappa del carattere dalla barra del menu principale. Selezionare successivamente CercaTrova… dal menu Mappa del carattere, digitare il nome desiderato nel campo Cerca e selezionare Successivo. 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 Copia. Ritornare sul documento e selezionare ModificaIncolla 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.com ed 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.

1.2. Convenzioni del documento

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"));
   }
}

1.3. Note ed avvertimenti

E per finire, tre stili vengono usati per richiamare l'attenzione su informazioni che in caso contrario potrebbero essere ignorate.

Nota

Una nota è un suggerimento o un approccio alternativo per il compito da svolgere. Non dovrebbe verificarsi alcuna conseguenza negativa se la nota viene ignorata, ma al tempo stesso potreste non usufruire di qualche trucco in grado di facilitarvi il compito.

Importante

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.

Avvertimento

Un Avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati.

2. Occorrono commenti!

Se in questo manuale si trovano errori tipografici, oppure se si hanno suggerimenti su come migliorare questo manuale, noi saremmo lieti di ascoltarli! Si prega di inviare un report in Bugzilla.
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.

Introduzione

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à.

Capitolo 1. Installare Publican

1.1. Sistemi Operativi Linux

Importante — Disponibilità nei repository

Le procedure indicate in questa sezione assumono che Publican e le sue varie dipendenze siano disponibili nei repository cui ha accesso il proprio sistema.

1.1.1. Fedora

  1. Aprire un terminale
  2. Diventare utente root: su -
  3. Eseguire il seguente comando per installare il pacchetto publican ed il pacchetto publican-doc della documentazione:
    $  yum install publican publican-doc
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.

1.1.2. Red Hat Enterprise Linux 5

Importante — Software non supportato

Publican non fa parte della distribuzione Red Hat Enterprise Linux. Quindi Red Hat non offre supporto per Publican.

Importante — Dipendenze disponibili soltanto all'interno di Red Hat

L'installazione di Publican su Red Hat Enterprise Linux 5, richiede un numero di dipendenze che attualmente sono disponibili solo nei repository yum interni a Red Hat.
  1. Aprire un terminale
  2. Diventare utente root: su -
  3. Eseguire il seguente comando per installare il pacchetto publican ed il pacchetto publican-doc della documentazione:
    $  yum install publican publican-doc
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.

1.1.3. Ubuntu

Importante — Novità in 10.4 "Lucid Lynx"

Publican fa il suo ingresso in Ubuntu 10.4 "Lucid Lynx".
  1. Aprire un terminale
  2. Eseguire il seguente comando per installare il pacchetto publican:
    $ sudo apt-get install publican

1.1.4. Debian

Avviso — Completare questa procedura

Completare ogni passaggio di questa procedura. Se non si effettuano, come qui indicate, le operazioni di ripristino alle modifiche apportate al file /etc/apt/sources.list, il sistema potrebbe diventare instabile.
Publican non è disponibile nella corrente versione stabile di Debian (version 5.0, "Lenny"), ma è disponibile nella corrente versione di test ("Squeeze"). Per installare Publican su un computer che esegue Debian, occorre abilitare temporaneamente l'accesso al repository squeeze. Abilitando l'accesso a questo repository, si autorizza il computer ad installare nuovo software e nuove versioni di software, rispetto alla corrente versione stabile di Debian. Tuttavia, non tutto il software disponibile nel repository di test ha già superato il controllo di qualità. Quindi, se dopo l'installazione di Publican non si disabilita l'accesso a questo repository, al successivo aggiornamento del sistema, i pacchetti software esistenti verranno sostituiti con nuove versioni scaricate dal repository, e molto probabilmente risulteranno essere versioni non ancora testate.
  1. Aprire un terminale
  2. Con un editor di testo aprire il file /etc/apt/sources.list. Per esempio, per modificare il file con gedit, eseguire:
    $ sudo gedit /etc/apt/sources.list
  3. Aggiungere la seguente riga alla fine del file:
    deb http://ftp.debian.org/debian/ squeeze main
    
    
  4. Salvare il file e chiudere l'editor.
  5. Eseguire il seguente comando per aggiornare la lista dei pacchetti disponibili nel sistema:
    $ sudo apt-get update
  6. Eseguire il seguente comando per installare il pacchetto publican:
    $ sudo apt-get install publican
  7. Riaprire il file /etc/apt/sources.list e rimuovere la riga precedentemente inserita.
Notare che finché la release "Squeeze" non viene rilasciata come versione stabile di Debian, occorre manualmente abilitare e disabilitare l'accesso al repository di test come fin qui descritto, ogniqualvolta diventa disponibile, nel repository di test, una nuova versione di Publican. Per informazioni aggiornate sullo status di Publican per Debian, visitare http://packages.debian.org/squeeze/publican, contenente il numero di versione di Publican disponibile nel repository (versione 2.1 al tempo di scrittura di questo documento).
Nel momento in cui "Squeeze" diventa la versione stabile di Debian, per installare Publican su sistemi che eseguono questa versione del sistema operativo, non occorre più abilitare o disabilitare l'accesso a repository extra.

1.1.5. OpenSuse 12

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.
  1. Open a terminal session.
  2. 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

    Nota

    Liberation-fonts is most likely already installed, but it is required. Zypper will not reinstall it if it is already present.
  3. 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 
  4. Download the source code:
    $ cd ~ mkdir -p SourceCode/publican cd SourceCode/publican svn checkout http://svn.fedorahosted.org/svn/publican/branches/publican-2x ./ 
  5. 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.yml
     Please inform the author.
    
    Created MYMETA.yml and MYMETA.json
    Creating 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 build
  6. Test 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: 5
     Non-zero exit status: 1
    t/pod-coverage.t (Wstat: 256 Tests: 9 Failed: 1)
     Failed test: 7
     Non-zero exit status: 1
    Files=10, Tests=68, 420 wallclock secs ( 0.31 usr 0.17 sys + 246.87 cusr 18.73 csys = 266.08 CPU)
    Result: FAIL
    Failed 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.
  7. 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.

    Nota

    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 

    Nota

    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.
  8. 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.
  9. 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

    Nota

    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 choose
    Variable '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.

1.2. Sistemi Operativi Windows

  1. Scaricare il programma di installazione di Publican da https://fedorahosted.org/releases/p/u/publican/.
  2. Spostarsi nella cartella in cui si è scaricato l'eseguibile Publican-Installer-versione.exe.
  3. Fare doppio click sul file Publican-Installer-versione.exe.
  4. 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 I Agree su ciascuna di esse, altrimenti premere Cancel.
  5. 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 Next, per continuare.
  6. 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.
  7. Dopo aver impostato la cartella di destinazione, premere Install.
    A questo punto, durante l'installazione di Publican, viene visualizzata una barra di progressione. Per visualizzare i dettagli sul progresso di installazione, premere Show details.
  8. Una volta completato, il programma di installazione visualizza il messaggio Completed.
    Premere Close per chiudere il programma di installazione.

1.3. OSX Lion

Test
  1. Install Xcode from Mac App store.

    Nota

    Xcode is about 4GB. Be prepared to wait. It has things you need, though.
  2. 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.
  3. Aprire un terminale
  4. Install dependencies for publican, which are available as ports:
    $sudo port install docbook-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 
    
  5. 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
  6. Install FOP if you want PDFs to work:
    $ sudo port install fop
    $ echo "FOP_OPTS='-Xms50m -Xmx700m'" > ~/.foprc
  7. Check out Publican Main branch. This command should be run from your user home directory, for instance /Users/yourusername
    $ git clone git://git.fedorahosted.org/publican.git
  8. Change directories:
    $ cd publican/publican
  9. 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
  10. Run the following command to install Publican and put all of its bits into /opt/local:
    $ sudo ./Build install

Procedura 1.1. Create and build a book

  1. $ publican create --name=testbook
  2. $ cd testbook
  3. $ publican build --formats=html --langs=en-US
  4. Open the tmp/en-US/html/index.html file in a browser to prove that it built correctly.

Procedura 1.2. Install a brand

  1. 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
  2. Either check out the SVN for your brand, or get a pre-built brand from a friend.
    1. The SVN location for the brands supplied by Red Hat is http://svn.fedorahosted.org/svn/publican
    2. If you use a pre-built brand, extract it as necessary.
  3. If you got the brand from SVN, build it.
    $ cd publican/publican-jboss
    $ publican build --formats=xml --langs=all --publish
  4. 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.

Capitolo 2. Publican defaults

Users can set their own default values for Publican in ~/.publican.cfg. Currently, Publican supports the following values:
  • firstname
  • surname
  • email
  • formats
  • lang
  • langs

Nota

This file is completely different to publican.cfg that is used to build a book. It does not accept the same parameters.

2.1. Publican default examples

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 build
Setting 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"

Capitolo 3. Comandi di Publican

Publican is a command-line tool. To use Publican on a computer with a Linux operating system, you must either start a terminal emulator program (such as GNOME Terminal or Konsole) or switch to a virtual console. To use Publican on a computer with a Windows operating system, run the $ cmd command from the Start menu to open a command prompt.
I comandi di Publican hanno uno dei seguenti formati:
$ publican command_option
The command_option is any of several options for the $ publican command itself.
$ publican action action_options
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.
$ publican command_option action action_options
Alcune opzioni_comando influenzano il risultato di una azione, come quando si richiede, per esempio, a Publican di usare nell'output la colorazione ANSI.

3.1. Opzioni di comando

The options for the $ publican command are:
--help
Questa opzione visualizza i formati del comando ed un sommario delle azioni valide, descritte in questo capitolo.
--man
Questa opzione visualizza la pagina di man su Publican integrando le informazioni dell'opzione --help, oltre a fornire informazioni su licenze e dipendenze.
--help_actions
Questa opzione visualizza un elenco di azioni valide di Publican.
-v
Questa opzione visualizza il numero di versione di una installazione di Publican.
--config file
Questa opzione specifica per un documento, un file di configurazione alternativo al file predefinito publican.cfg.
--nocolours
Questa opzione disabilita la colorazione ANSI nei messaggi di log di Publican.
--quiet
Questa opzione disabilita tutti i messaggi di log.

3.2. Azioni

Publican è in grado di effettuare le seguenti elaborazioni:
add_revision
adds an entry in Revision_History.xml.
build
trasforma i file XML in altri formati (per esempio: PDF, HTML su pagina singola o HTML su pagine multiple). Fare riferimento alla Sezione 4.7, «Creare un documento» per maggiori dettagli ed una descrizione delle opzioni disponibili.
clean
removes all files and folders in the tmp/ subdirectory. The tmp/ subdirectory is created after running the $ publican build command to build a document, such as publican build --formats=html --langs=en-US.
clean_ids
changes all IDs to a standard format. This format is Book_Name-title. For example, a section with a title of First Section in a book named Test_Book will have the following ID after you run $ publican clean_ids: <section id="Test_Book-First_Section">

Warning — $ publican clean_ids

To make translation easier, $ publican clean_ids uses the first four characters of the tag as a prefix for the ID. Consequently, you must check out the latest versions of the XML source and translations before running this command.
If you do not have the current versions of the PO files checked out before running $ publican clean_ids, the XML and PO files will no longer be in synchrony with each other. In this case, all links in the PO files must be manually updated.

Importante — Possono verificarsi conflitti tra ID

The $ publican clean_ids command is intended to facilitate building a DocBook structure around documents ported from other formats such as HTML. However, publican clean_ids is file-based and and only has access to information in the XML file that it is currently processing and to the document name. Therefore, nodes of the same type that have the same title receive the same IDs. These duplicate IDs will prevent the document from building.
Use the $ publican clean_ids command to assist you in laying out your document, but expect that some manual adjustment to IDs might be necessary. We recommend that you do not run publican clean_ids on an already well established document.
clean_set
rimuove le copie locali di libri remoti facenti parte di un set distribuito. Vedere la Sezione 6.2, «Set distribuiti» per i dettagli sull'uso di set distribuiti.
create
crea un nuovo libro, articolo o un nuovo set. Vedere il Capitolo 4, Creare un documento per i dettagli su come creare un libro o articolo, ed il Capitolo 6, Usare i set per i dettagli sull'uso dei set.
create_brand
crea un nuovo brand. Fare riferimento alla Sezione 5.2, «Creare un brand» per i dettagli.
create_site
crea un sito web di documentazione. Fare riferimento al Capitolo 7, Creare un sito web con Publican per i dettagli.
help_config
visualizza un elenco di parametri di configurazione del file publican.cfg, contenuto in ciascun libro o brand. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per maggiori dettagli.
install_book
installa un documento su un sito web di documentazione. Vedere il Capitolo 7, Creare un sito web con Publican per i dettagli.
install_brand
configura l'installazione di un brand. Fare riferimento alla Sezione 5.1, «Installare un brand» per i dettagli.
lang_stats --lang=codice_lingua
genera un report statistico di traduzione per la lingua specificata da codice_lingua. Per ogni file PO generato da Publican, una tabella mostra il numero delle stringhe non tradotte in tutti i msgid; il numero delle stringhe fuzzy (conteggia le stringhe contenute in msgid, il cui contenuto è variato dall'ultima generazione dei POT), ed il numero delle stringhe tradotte, coincidente, a traduzione avvenuta, con il numero delle stringhe contenute nel msgid.
migrate_site
migrates a website database from Publican 2.x to Publican 3.
package
crea un pacchetto un RPM di un libro, articolo, set o brand. Vedere la Sezione 4.8, «Creare il pacchetto di un documento» e la Sezione 5.4, «Creare il pacchetto di un brand» per maggiori dettagli.
print_banned
visualizza l'elenco dei tag di DocBook non raccomandati da Publican. Vedere l'Appendice A, Elementi ed attributi non permessi per una discussione sull'uso di tag non raccomandati.
print_known
visualizza l'elenco dei tag di DocBook supportati da Publican. I tag supportati sono quelli che hanno superato una minima verifica di qualità per l'uso in Publican. Fare riferimento all'Appendice A, Elementi ed attributi non permessi.
print_tree
visualizza la struttura ad albero dei file XML inclusi, con il tag <xi:include>, in un libro, articolo o set.
print_unused
prints a list of the XML files not included with the <xi:include> tag in a book, article, or set.
publican print_unused_images
visualizza l'elenco dei file XML non inclusi, con il tag <xi:include>, in un libro, articolo o set.
remove_book
rimuove un documento da un sito web di documentazione. Vedere il Capitolo 7, Creare un sito web con Publican per i dettagli.
rename
renames a Publican book.
site_stats
genera un report statistico di un sito web di documentazione.
update_po
aggiorna i file PO (Portable Object). Vedere la Sezione 4.6, «Preparare un documento per la traduzione» per maggiori dettagli.
update_pot
aggiorna i file POT (Portable Object Template). Vedere la Sezione 4.6, «Preparare un documento per la traduzione» per maggiori dettagli.
update_site
aggiorna i template del sito web di documentazione. Consultare il Capitolo 7, Creare un sito web con Publican per i dettagli.

Capitolo 4. Creare un documento

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.
Use the $ publican create command to create a new document, including all the necessary files for the document.
The $ publican create command accepts several options, detailed in this chapter. When an option can accept a value, separate the option from the value with a space or an equals sign; for example, publican create --name New_Book or publican create --name=New_Book.
--help
print a list of all $ publican create command options.
--name Nome_Doc
set Doc_Name as the name of the book or article. This variable must not contain any spaces. For example, the command $ create_book --name Test_Book creates a book named Test_Book with all the necessary files to build the book, and sets the BOOKID in the Test_Book.ent file.
--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 G, Codici di lingua per i dettagli sui codici linguistici.
--version versione
imposta il numero di versione del prodotto descritto dal libro. Per esempio, per Red Hat Enterprise Linux 5.1 si userà 5.1. Il valore predefinito è 0.1. L'opzione --version imposta il tag <productnumber> nel file Book_Info.xml o nel file Article_Info.xml. Per maggiori informazioni vedere la 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.
Before running the $ publican create command, use the $ cd command to change into the directory where you want the book to be created. For example, to create a book named Test_Book in the my_books/ directory, run the following commands:
$ cd my_books/ 
$ publican create --name Test_Book
Per visualizzare i risultati di questo comando su un computer con Sistema Operativo Linux, eseguire il comando:
$ ls
Il 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.cfg

4.1. I file nella directory del libro

If you run the command $ publican create --name Test_Book --lang en-US, Publican creates a directory structure and required files, similar to the following:
  • 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

4.1.1. Il file publican.cfg

Nota — Personalizzare l'output

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 en-US,de-DE,hu-HU --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
specifies the language of the source XML files, for example, en-US, as set by the --lang option for $ publican create.
type
specifies the type of document — a DocBook <article>, DocBook <book>, or DocBook <set>, as set by the --type option for $ publican create.
brand
sets the brand of the document, for example, RedHat, fedora, JBoss, oVirt or GIMP , as set by the --brand option for $ publican create. If you do not specify a brand, Publican uses its default brand. Refer to Capitolo 5, Branding for more information.

Parametri avanzati

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">.

Usare con cautela

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.

parametro arch in nodi radice

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>

and this chapter is included in User_Guide.xml with an <xi:include> tag, the document will not build with $ condition: x86 set in the publican.cfg file.
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.

xrefs e parametro arch

If an <xref> points to content not included in the build due to the arch attribute, the build will fail. For example, with arch: x86 set in the publican.cfg file, $ publican build --formats=pdf --langs=en-US will fail if the book has the tag <xref linkend="Itanium_installation"> pointing to <section id="Itanium_installation" arch="IA64">.
books
specifica 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, «The $ publican package command» 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

chunk_section_depth: 0
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, …
chunk_section_depth: 1
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 …
chunk_section_depth: 2
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 …
chunk_section_depth: 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 …
chunk_section_depth: 4 (predefinito)
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.
condition
specifica, prima di una trasformazione, le condizioni per escludere file XML. Vedere la Sezione 4.9, «Tagging condizionale» per maggiori informazioni.

Nodi root e tag condizionale

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>

and this chapter is included in User_Guide.xml with an <xi:include> tag, the document will not build with $ condition: Ubuntu set in the publican.cfg file.
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.

xref e tag condizionale

If an <xref> points to content not included in the build due to conditional tagging, the build will fail. For example, with $ condition: upstream set in the publican.cfg file, $ publican build --formats=pdf --langs=en-US will fail if the book has the tag <xref linkend="betasection"> pointing to <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_lang
imposta 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.
src_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
specifica il nome del documento. Se impostato, questo parametro non tiene conto del contenuto del tag <title> nel file Book_Info.xml in fase di costruzione del pacchetto del documento. Questo valore può contenere solo lettere maiuscole/minuscole non accentate, cifre, il carattere trattino basso ed il carattere spazio (‘a–z’, ‘A–Z’, ‘0’–‘9’, e ‘_’ e ‘ ’).
dt_obsoletes
il pacchetto reso obsoleto dal pacchetto desktop.
dt_requires
il 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».
dtdver
specifica 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.

Un DTD differente potrebbe rallentare la compilazione

Quando si installa Publican, si installa anche una copia locale della definizione DTD versione 4.5 di DocBook XML in accompagnamento ad XSL (Extensible Stylesheet Language). Se si imposta una versione di DTD per cui non risulta disponibile una versione locale, Publican deve scaricare DTD ed XSL appropriati da una sorgente in rete, ad ogni compilazione di un documento. In tal caso la compilazione del documento risulta ritardata dal completamento di questo scaricamento. La dimensione complessiva dei file è di circa 70 MB.
dtd_type
Override Type for DocType. Must be a complete string.

Nota

This parameter is only permitted in a brand.
dtd_uri
Override URI for DocType. Must be a complete string.

Nota

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_name
imposta 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_provider
imposta 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.
edition
specifica il numero di edizione del documento. Se impostato, questo parametro non tiene conto del contenuto del tag <edition> nel file Book_Info.xml in fase di costruzione del pacchetto. Questo valore può contenere solo cifre ed il carattere punto (‘0’–‘9’ e ‘.’).
extras_dir
the directory Publican will process extra files from. (Default: extras)
footer
specifies 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

generate_section_toc_level: 0 (predefinito)
Publican genera le tabelle dei contenuti all'inizio del documento e nelle parti, nei capitoli e in appendice, ma non nelle sezioni.
generate_section_toc_level: 1
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 …
generate_section_toc_level: 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, «Preparare un documento per la traduzione» ed all'Appendice G, Codici di lingua.
img_dir
the directory Publican will process images from. (Default: images)
mainfile
overrides the default Info file. Specifies where Publican looks for info fields. Use the full filename without the path.
license
specifica 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».
max_image_width
per le immagini in un documento, specifica la massima larghezza possibile, in pixel. Per impostazione, Publican ridimensiona le immagini più larghe di 444 pixel fino ad adattarle a questo limite. Il limite di 444 pixel assicura che le immagini non eccedano nel margine destro delle pagine HTML e si adattino all'interno delle pagine PDF. Fare riferimento alla Sezione 4.2, «Aggiungere immagini» per maggiori informazioni sull'uso delle immagini.

Importante — 444 pixel è la massima larghezza di sicurezza

Non usare il parametro max_image_width se le immagini contengono importanti informazioni. Le immagini più larghe di 444 pixel potrebbero presentarsi male nei documenti HTML e PDF e rendersi inusabili, in quanto superando i margini esse verrebbero rappresentate incomplete.
Viceversa, le immagini più larghe di 444 pixel che vengono scalate in un browser web o in un visualizzatore PDF, perdono in qualità.
Per preservare la qualità delle immagini, si raccomanda di tagliare o scalare le immagini ad una larghezza inferiore a 444 pixel, prima di includerle in 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
specifica il sistema operativo per cui costruire il pacchetto. Publican appende questo valore al nome del pacchetto RPM. Per esempio, .fc15 for Fedora 15. Il valore predefinito è .el5, che significa Red Hat Enterprise Linux 5 e sistemi operativi derivati. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento» ed alla 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
specifica il prodotto cui fa riferimento il documento. Se impostato, questo parametro non tiene conto del contenuto del tag <productname> nel file Book_Info.xml, durante la creazione del pacchetto. Questo valore può contenere solo lettere maiuscole/minuscole non accentate, cifre, il carattere trattino basso ed il carattere spazio (‘a–z’, ‘A–Z’, ‘0’–‘9’, e ‘_’ e ‘ ’).
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’).
repo
specifica 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. 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.
dtdver
override 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.
toc_js
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

toc_section_depth: 0
Publican genera un sommario principale solo di capitoli.
toc_section_depth: 1
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 …
toc_section_depth: 2 (predefinito)
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_formats
una lista di formati, separati da virgola, da includere nel pacchetto RPM per il web. Fare riferimento alla Sezione 4.8.2, «The $ publican package command».
web_home
specifica 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.

Importante — web_home è deprecato

In Publican 2.2, web_home è stato sostituito da web_type: home. Supporto a web_home verrà interrotto nelle future versioni di Publican.
web_name_label
visualizza 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_obsoletes
specifica i pacchetti resi obsoleti da questo RPM per il web. Fare riferimento alla Sezione 4.8, «Creare il pacchetto di un documento».
web_product_label
visualizza 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_style
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
specifica che si tratta di un documento descrittivo per un sito web gestito da Publican, e non del documento di un prodotto. Il contenuto include la home page del sito web (web_type: home), pagine descrittive di prodotto (web_type: product), e pagine descrittive di versione (web_type: version). Fare riferimento al 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.
wkhtmltopdf_opts
Extra options to pass to wkhtmltopdf. e.g. wkhtmltopdf_opts: "-O landscape -s A3"

Aiuto da riga di comando

Run the $ publican help_config command in the root directory of a book for a summary of these parameters.

4.1.2. Book_Info.xml

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.

Altri pacchetti non RPM

This section discusses packaging documents for distribution through the RPM Package Manager. However, when you use the $ publican package command, Publican generates a tarball that you can use to build a package to distribute through different package manager software. If you run publican package on a computer on which rpmbuild is not installed, Publican still generates the tarball, even though it cannot then generate an RPM package from that tarball.
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 bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY PRODUCT "Publican">
<!ENTITY BOOKID "publican">
<!ENTITY FORMAL-RHI "Red Hat, Inc.">
<!ENTITY HOLDER "Red Hat, Inc">
<!ENTITY YEAR "2010">
<!ENTITY D_B "DocBook">

]>
<bookinfo conformance="121" id="book-Users_Guide-Users_Guide">
	<title>Guida Utente</title>
	 <subtitle>Pubblicare libri, articoli, relazioni e raccolte di volumi con DocBook XML</subtitle>
	 <productname>Publican</productname>
	 <productnumber>3.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>
	 <corpauthor>
		<inlinemediaobject>
			<imageobject>
				<imagedata fileref="Common_Content/images/title_logo.svg" format="SVG" />
			</imageobject>
			 <textobject>
				<phrase>Team Publican</phrase>
			</textobject>

		</inlinemediaobject>

	</corpauthor>
	 <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" />
</bookinfo>


		

<bookinfo id="id_libro">, <articleinfo id="id_articolo">, <setinfo id="id_set">
The document ID is used internally and is not displayed to readers when the book is built. If you run the $ publican clean_ids command, any manually entered ID, including this one, changes to a Doc_Name-Title format, where Title is the title of the associated book, article, section, or chapter.
<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.

Caratteri permessi

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.

Caratteri permessi

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.
Running the $ publican create --name Doc_Name --version version command correctly configures the product number.
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.

Caratteri permessi

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>
This is the edition number of the book. The first edition of the book should be 1.0 (unless you use 0.x for pre-release versions of a book). Subsequent editions should increment the 1.x to indicate to readers that the book is a new edition. The edition changes the version number in the file name when building a book with the $ publican package command.
For example, setting the edition to 1.2 and building the book using the $ publican package --binary --lang=en-US command creates an RPM file named productname-title-productnumber-en-US-1.2-0.src.rpm.
Running the $ publican create --name Doc_Name --edition x.y command correctly configures the edition.
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.

Caratteri permessi

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>
The pubsnumber sets the release number (the last digit in the file name) when building a book with the $ publican package command. For example, setting the pubsnumber to 1 and building the book using the publican package --binary --lang=en-US command creates an RPM file named productname-title-productnumber-en-US-edition-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.

Caratteri permessi

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">
\t<imageobject role="front-large" remap="lrg">
\t\t<imagedata width="600px" format="PNG" fileref="images/front_cover.png"/>
\t</imageobject>
\t<imageobject role="front" remap="s">
\t\t<imagedata format="PNG" fileref="images/front_cover.png"/>
\t</imageobject>
\t<imageobject role="front-small" remap="xs">
\t\t<imagedata format="PNG" fileref="images/front_cover.png"/>
\t</imageobject>
\t<imageobject role="thumbnail" remap="cs">
\t\t<imagedata format="PNG" fileref="images/front_cover_thumbnail.png"/>
\t</imageobject>
</mediaobject>

Come per le altre immagini in documenti, salvare le cover-art nella sotto-cartella images.

4.1.2.1. Pacchetti RPM, edizioni, ristampe e versioni

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.

4.1.3. Author_Group.xml

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'?>
<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>

<authorgroup>
	<corpauthor>FF0000 Headgear Documentation Group</corpauthor>
	<author>
		<firstname>Dude</firstname>
		<surname>McDude</surname>
		<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.

4.1.4. Chapter.xml

Articoli e Capitoli

DocBook articles cannot contain chapters. If you use the --type=article option with $ publican create, Publican does not create a Chapter.xml file. Use sections to organize content within articles.
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.
The Chapter.xml file is a template for creating chapter files. Chapter files contain the content that make up a book. The following is a chapter template (Chapter.xml) that is created by the $ publican create command. Note the DOCTYPE is set to 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.

Nota

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.

4.1.5. Nome_Doc.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.

Importante

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>
\tA paragraph in Chapter 1.
</para>
<section id="section1">
<title>Chapter 1 Section 1</title>
\t<para>
\t\tA paragraph in Section 1.
\t</para>
</section>
<section id="section2">
<title>Chapter 1 Section 2</title>
\t<para>
\t\tA paragraph in Section 2.
\t</para>
</section>
</chapter>

<chapter>
<title>Chapter 2</title>
<para>
\tA paragraph in Chapter 2.
</para>
</chapter>

</book>

Questo libro contiene due capitoli, in cui il I capitolo è costituito da due sezioni. Per ulteriori informazioni su sezioni e book vedere rispettivamente, http://docbook.org/tdg/en/html/section.html e http://docbook.org/tdg/en/html/book.html.

4.1.6. Nome_Doc.ent

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.
<!ENTITY PRODUCT "MYPRODUCT">
<!ENTITY BOOKID "MYBOOK">
<!ENTITY YEAR "2008">
<!ENTITY HOLDER "YOUR NAME GOES HERE">


		

4.1.6.1. Entità e traduzione

Usare le entità con particolare attenzione

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.

4.1.7. Revision_History.xml

The $ publican package command searches for the first XML file in the document's XML directory containing a <revhistory> tag. Publican then uses that file to build the RPM revision history.

4.2. Aggiungere immagini

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>
\t<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.
Immagini grandi si presentano male in HTML perché spesso invadono il margine destro del testo. Analogamente, le immagini più larghe di 444 pixel, spesso si estendono al di là del margine destro delle pagine PDF e risultano tagliate, lasciando visibile solo la parte sinistra dell'immagine. Per questo, per impostazione, Publican crea presentazioni HTML e PDF istruendo i browser web e i visualizzatori PDF a scalare le immagini più larghe di 444 pixel. Notare, comunque, che le immagini scalate in questo modo perdono significativamente in qualità. Per migliori risultati, scalare o tagliare le immagini in un software di modifica immagini in modo da garantire una larghezza non superiore a 444 pixel, prima di inserirle in un documento.
Per non tenere conto della limitazione di 444 px impostate da Publican, specificare la larghezza di un'immagine nel tag <imagedata>. Per esempio, per impostare una larghezza di 670 pixel:
<imagedata fileref=".images/image.png" width="670px">
In tal caso, rivedere accuratamente la presentazione per preservare gli standard di qualità richiesti.

Locazioni delle immagini

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.

File PNG in documenti PDF

Publican dipende da un'applicazione esterna, FOP, per creare documenti PDF. Al momento, alcune versioni di FOP contengono un bug che altera i colori in certe immagini in formato PNG. Nello specifico, le immagini PNG a 32-bit vengono visualizzate correttamente, mentre quelle a 24-bit presentano problemi.
Se si nota che Publican produce un file PDF contenente immagini con colori alterati, convertire i file PNG originali nel formato PNG a 32-bit aggiungendo un canale alpha all'immagine e poi ricompilare il libro. Se il software di elaborazione immagine, non include un'opzione specifica denominata Aggiungi canale alpha, usare l'opzione Aggiungi trasparenza.

4.3. Aggiungere codice

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.
Alcuni caratteri sono riservati in XML, in particolare, & e <. Se si inserisce un pezzo di codice direttamente in un file XML di un documento, occorre fare l'escaping di questi caratteri, rendendoli CDATA o sostituendoli con entità (&amp; e &lt; rispettivamente).[2] Posizionando questi file nella cartella extras/, non occorre alcun escaping di questi caratteri. Questo approccio risparmia tempo, riduce la possibilità di introdurre errori nell'XML e nel codice; oltre a semplificare il mantenimento del documento e del codice.
Per includere nel documento, un pezzo di codice contenuto nella cartella extras/, seguire questa procedura:
  1. Creare la cartella extras
    $ mkdir en-US/extras
  2. Copiare il file del codice nella cartella extras
    $ cp ~/samples/foo.c en-US/extras/.
  3. 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>
  4. 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>
\t<areaspec>
\t\t<area id="orbit-for-parameter" coords='4 75'/>
\t\t<area id="orbit-for-magnitude" coords='12 75'/>
\t</areaspec>
\t<programlisting language="Fortran"><xi:include parse="text" href="extras/orbit.for"
\txmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
\t<calloutlist>
\t\t<callout id="callout-for-parameter" arearefs="orbit-for-parameter">
\t\t\t<para>
\t\t\t\tThe <firstterm>standard gravitational parameter</firstterm>
\t\t\t\t(μ) is a derived value, the product of Newton's gravitational 
\t\t\t\tconstant (G) and the mass of the primary body.
\t\t\t</para>
\t\t</callout>
\t\t<callout id="callout-for-magnitude" arearefs="orbit-for-magnitude">
\t\t\t<para>
\t\t\t\tSince the mass of the orbiting body is many orders of magnitude 
\t\t\t\tsmaller than the mass of the primary body, the mass of the 
\t\t\t\torbiting body is ignored in this calculation.
\t\t\t</para>
\t\t</callout>
\t</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.

4.4. Aggiungere file

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/files

4.5. Rinominare un documento

The $ publican rename command makes it easy for you to rename a document to give it a new title, or to change the name or version of the product to which the document applies. The command accepts up to three options:
--name nuovo_titolo
modifica 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.
Note that the $ publican rename command does not change any file names. Therefore, the root XML node and the document entities are still located in files named after the original title of the document — Server_Configuration_Guide in the previous example.
--product nuovo_prodotto
modifica 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_versione
modifica 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.0

4.6. Preparare un documento per la traduzione

Supporto 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:
  1. 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.
  2. 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.

    Rimuovere i file XML non usati

    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.
    Use the $ publican print_unused command to generate a list of XML files that are not used in your document.
  3. Generare dai file POT, i file PO (Portable Object) per poter avviare la traduzione in una particolare lingua.
    $ publican update_po --langs=language_code
    dove codice_lingua è il codice per la lingua target. Fare riferimento all'Appendice G, 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,pt-BR,ru-RU,zh-CN
    Se è la prima volta che i file PO vengono creati per una lingua, Publican crea una nuova sottocartella, il cui nome coincide con il codice linguistico specificato con l'opzione --langs=. La sottocartella contiene un file PO per ciascun file POT nella sottocartella pot. Se Publican ha creato i file PO precedentemente, Publican aggiorna i file PO esistenti per rispecchiare i cambiamenti apportati ai file POT dall'ultimo aggiornamento dei file PO. E' possibile aggiornare i file PO esistenti in tutte le sottocartelle, usando l'opzione --langs=all:
    $ publican update_po --langs=all

    Rimuovere i file POT non usati

    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.
  4. Tradurre le stringhe contenute nei file PO.
  5. Creare il documento per la lingua desiderata, per esempio:
    $ publican build --formats=html,html-single,pdf --langs=is-IS,nb-NO
    o il pacchetto per la lingua desiderata, per esempio:
    $ publican package --lang=is-IS
    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.

    Importante — impostare Project-Id-Version per il pacchetto

    Il numero di release dei pacchetti RPM per i documenti tradotti viene impostato con il parametro Project-Id-Version nel file Article_Info.po o Book_Info.po. Per esempio, la release 3 di un libro in lingua giapponese avrebbe la seguente impostazione nel file ja-JP/Book_Info.po:
    "Project-Id-Version: 3
    "
    Notare che il numero di release di un pacchetto in una certa lingua non condivide nessuna relazione con il numero di rilascio del pacchetto relativo allo stesso documento in lingua originale o in altra lingua. Questo numero si riferisce esclusivamente ad una lingua.

4.6.1. Translation Author Group

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.

4.7. Creare un documento

Nota — Personalizzare la presentazione

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,hu-HU --config community.cfg
Per creare un documento:
  1. 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».
  2. 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 ~/books/Test_Book
  3. Eseguire un test, per evitare che ci siano errori di compilazione nel linguaggio desiderato, per esempio:
    $ publican build --formats=test --langs=en-US
  4. Eseguire il seguente comando per creare il libro:
    $ publican build --formats=formats --langs=languages
    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

html
Publican 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-single
Publican presenta il documento in una singola pagina HTML con la tabella dei contenuti posta in cima alla pagina.
html-desktop
Publican presenta il documento in una singola pagina HTML con la la tabella dei contenuti posta in un pannello separato a sinistra del documento.
man
Publican presenta il documento in pagine di manuale (o "man page"), in uso nei Sistemi Operativi Linux, Unix e simili.
pdf
Publican presenta il documento in un file PDF.
test
Publican controlla la validità della struttura XML del libro, senza effettuare nessuna trasformazione.
txt
Publican presenta il documento in un singolo file di testo.
epub
Publican 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.
The following examples demonstrate commonly used $ publican build commands:
$ publican build --help
List available $ publican build options for building a book.
$ publican build --formats=test --langs=languages
Check that the book can be built correctly. Build --formats=test before running any other $ publican build command, and before checking a book back into a version-controlled repository from which other contributors might download it.
$ publican build --formats=html --langs=languages
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».
$ publican build --formats=html-single --langs=languages
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/.
$ publican build --formats=pdf --langs=languages
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/.
$ publican build --formats=html,html-single,pdf --langs=languages
Crea il libro nei formati HTML su pagine multiple e su pagina singola, e PDF.

4.7.1. Compilare un documento senza controllo di validità

Publican validates your XML against the DocBook document type definition (DTD) before it builds the content. However, while a document is under development, you might sometimes want to skip validation while building, especially if the document contains cross-references (<xref>s) to sections of the document that do not yet exist. To skip validation, run $ publican build with the --novalid option. Cross-references to non-existent content appear in the built document as three question marks: ???.
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.

4.8. Creare il pacchetto di un documento

Altri pacchetti non RPM

This section discusses packaging documents for distribution through the RPM Package Manager. However, when you use the $ publican package command, Publican generates a tarball that you can use to build a package to distribute through different package manager software. If you run publican package on a computer on which rpmbuild is not installed, Publican still generates the tarball, even though it cannot then generate an RPM package from that tarball.

Nota — Personalizzare l'output

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 hi-IN --config community.cfg
Publican 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.

4.8.1. Tipi di pacchetti RPM

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.

4.8.1.1. Pacchetti RPM di sorgenti e pacchetti RPM di binari

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).

4.8.1.2. Pacchetti per il desktop e pacchetti 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 SistemaDocumentazione. 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.
  • your book or your brand contains the web_formats parameter. The value of this parameter overrides the default formats that Publican packages. For example, to publish the document only as single-page HTML, PDF, and text, set 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.

4.8.1.3. Voci nel menu del desktop per i documenti

Per impostazione, i pacchetti RPM dei documenti di Publican per il desktop, appaiono negli ambienti GNOME, sotto il menu SistemaDocumentazione. All'aumentare del numero di documenti installati, questo menu diventa intricato e di difficile navigazione. Ciò porta ad un menu con molti documenti per differenti prodotti ed in alcuni casi, in diverse lingue, che crea non poca confusione.
Per raggruppare i documenti per un prodotto, in un sotto-menu separato, nel menu SistemaDocumentazione di GNOME, occorre:
  • creare e distribuire un pacchetto desktop-menu (per il menu del desktop), che crea il sotto-menu.
  • specificare nel documento, la category del menu, ed opzionalmente, nel pacchetto di documentazione, specificare una direttiva require per richiedere anche l'installazione del pacchetto desktop-menu.
Notare che il menu Documentazione non raggruppa le voci in sotto-menu finché non sono presenti due o più documenti appartenenti al sotto-menu. Il primo documento compare sotto SistemaDocumentazione.
4.8.1.3.1. Creare un pacchetto desktop-menu
Un pacchetto desktop-menu consiste di:
  • un file desktop entry (.directory) che fornisce i metadati sul nuovo sotto-menu.
  • un file desktop menu (.menu) che definisce la posizione del sotto-menu nel menu Documentazione.
La struttura del file .directory, per documentazione generata da Publican, è la seguente:
  • il group header [Desktop Entry]
  • il parametro Name, impostato con il nome del sotto-menu da posizionare nel menu Documentazione.
  • opzionalmente, le localizzazioni per il parametro Name, nel formato Name[codice_lingua], dove codice_lingua è un codice linguistico in formato glibc, non nel formato XML usato da Publican.
  • il parametro Comment, impostato con una descrizione del sotto-menu.
  • opzionalmente, le localizzazioni per il parametro Comment, nel formato Comment[codice_lingua], dove codice_lingua è un codice linguistico in formato glibc, non nel formato XML usato da Publican.
  • il parametro Type, imposto a Directory.
  • il parametro Encoding, impostato a UTF-8.

Esempio 4.5. Esempio di file .directory

Il seguente file, menu-example.directory mostra la struttura di un file di desktop entry:
[Desktop Entry]
Name=Example
Name[fr]=Exemple
Name[it]=Esempio
Comment=Example Documentation menu
Comment[fr]=Exemple d'une menu de documentation
Comment[it]=Esempio di un menù di documentazione
Type=Directory
Encoding=UTF-8

Il file di desktop entry, è salvato in /usr/share/desktop-directories/
Per una descrizione completa di come funzionano le desktop entry, fare riferimento alla Desktop Entry Specification, disponibile su http://standards.freedesktop.org/entry-spec/latest/
Un file di desktop menu, è un file XML che contiene:
  • un DTD (Document Type Declaration), per la Desktop Menu Specification di freedesktop.org:
    <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
    "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">
  • un elemento radice, <Menu>, contenente:
    • un elemento <Name> contenente Documentation
    • un altro elemento <Menu> che a sua volta, contiene:
      • un elemento <Name> contenente Documentation (come l'elemento radice)
      • un elemento <Directory> contenente il nome del file di desktop entry creato, per esempio:
        <Directory>menu-example.directory</Directory>
      • un elemento <Includes> contenente X-nome_categoria, dove nome_categoria è un identificatore per i documenti da raggruppare nel sotto-menu. Per esempio:
        <Includes>X-Example-Docs</Includes>

Esempio 4.6. Esempio di file .menu

Il seguente file, menu-example.menu mostra la struttura di un file di desktop menu.
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
 "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">
<Menu>
	<Name>Documentation</Name>
	<Menu>
		<Name>Documentation</Name>
		<Menu>
			<Name>Example</Name>
			<Directory>menu-example.directory</Directory>
			<Include>
				<Category>X-Example-Docs</Category>
			</Include>
		</Menu>
	</Menu> 
</Menu> 

Il file di desktop menu è salvato in /etc/xdg/menus/settings-merged/
Per una descrizione completa di come funzionano i desktop menu, fare riferimento alla Desktop Menu Specification, disponibile su http://standards.freedesktop.org/desktop-menu-spec/latest/
4.8.1.3.2. Impostare un categoria di desktop menu
Per posizionare un documento in un sotto-menu di SistemaDocumentazione, impostare il parametro menu_category nel proprio file publican.cfg, in modo da corrispondere al contenuto dell'elemento <Includes> nel relativo file di desktop menu. Per esempio, si consideri il file di desktop menu, contenente l'elemento:
<Includes>X-Example-Docs</Includes>
Per posizionare un documento nel sotto-menu definito da questo file di desktop menu, il file publican.cfg del documento, dovrebbe contenere:
menu_category: X-Example-Docs

Importante

Publican will process the string in menu_category and replace __LANG__ with the current language. This allows menus to be customized on a per language basis.
menu_category: X-Example-Docs-__LANG__
Notare che si può includere questo parametro nel file defaults.cfg o nel file overrides.cfg di un brand, cosicché tutti i documenti creati con il brand siano automaticamente raggruppati nel sotto-menu, senza dover impostare il parametro menu_category in ogni documento.
Se si distribuiscono i file di desktop menu e di desktop entry in un pacchetto RPM, si può impostare che i pacchetti RPM di documenti richiedano il pacchetto di desktop-menu. Impostando questa dipendenza, il pacchetto di desktop-menu è installato automaticamente sul sistema degli utenti, durante l'installazione del pacchetto di documentazione, in modo da apparire nel sotto-menu creato per il progetto. Impostare la dipendenza con il parametro dt_requires, nel file publican.cfg del documento. Per esempio, se si distribuisce un pacchetto di desktop-menu di nome foodocs-menu, impostare:
dt_requires: foodocs-menu
Notare che si può includere il parametro nel file defaults.cfg o nel file overrides.cfg di un brand, cosicché tutti i documenti creati con il brand richiedano lo stesso pacchetto di desktop-menu.

4.8.2. The $ publican package command

Use the $ publican package --lang=Language_Code command to package documents for distribution in the language that you specify with the --lang option. Refer to Appendice G, Codici di lingua for more information about language codes.
If you run $ publican package with no options other than the mandatory --lang option, Publican produces a web SRPM package. The full range of options for publican package is as follows:
--lang lingua
specifica la lingua per cui creare il pacchetto della documentazione.

Traduzioni incomplete

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.
--desktop
specifica di creare un pacchetto RPM desktop invece di un pacchetto RPM web.
--brew
specifica 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.

Omettere il numero di versione del software

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.
--binary
specifica di compilare il pacchetto come un pacchetto RPM binario.
After you run the $ publican package command, Publican outputs completed SRPM packages to the document's tmp/rpm directory, and completed binary RPM packages to the document's tmp/rpm/noarch directory.
Per impostazione, i pacchetti di documentazione generati da Publican, sono denominati

nomeprodotto-titolo-numeroprodotto-[web]-lingua-edizione-numeropubblicazionebuild_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.

4.8.2.1. The $ publican package command — Example usage

I seguenti esempi mostrano alcune opzioni comuni, riferite alla II edizione, VI revisione del documento Foomaster 9 Configuration Guide.
$ publican package --lang=cs-CZ
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.
$ publican package --desktop --lang=cs-CZ
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.
$ publican package --binary --lang=cs-CZ
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.
$ publican package --desktop --binary --lang=cs-CZ
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.
$ publican package --desktop --short_sighted --lang=cs-CZ
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.

4.9. Tagging condizionale

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.
To conditionalize content in a book, use the tag attribute $ condition. For example, let's say the book How To Use Product Foo has an "upstream", "enterprise", and "beta" version:
<para condition="upstream">
\t<application>Foo</application> starts automatically when you boot the system.
</para>
\t
<para condition="enterprise">
\t<application>Foo</application> only starts automatically when you boot the system when installed together with <application>Bar</application>.
</para>\t
\t
<para condition="beta">
\t<application>Foo</application> does not start automatically when you boot the system.
</para>
\t
<para condition="beta,enterprise">
\tTo make <application>Foo</application> start automatically at boot time, edit the <filename>/etc/init.d/foo</filename> file.
</para>
To build a specific version (and thereby capture all content conditionalized for that version), add the $ condition: version parameter to the publican.cfg file and run the $ publican build command as normal. For example, if you add condition: upstream to the publican.cfg file of How To Use Product Foo and run:
$ publican build --formats=pdf --langs=en-US
Publican 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.

Nodi root e tag condizionale

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>

and this chapter is included in User_Guide.xml with an <xi:include> tag, the document will not build with $ condition: Ubuntu set in the publican.cfg file.
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.

xref e tag condizionale

If an <xref> points to content not included in the build due to conditional tagging, the build will fail. For example, with $ condition: upstream set in the publican.cfg file, $ publican build --formats=pdf --langs=en-US will fail if the book has the tag <xref linkend="betasection"> pointing to <section id="betasection" condition="beta">.

4.9.1. Tagging condizionale e traduzione

Usare con cautela il tagging condizionale

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 paragrafo al successivo.
In questo esempio, i soli paragrafi in cui il senso scorre logicamente da un paragrafo al successivo è tra il terzo e il quarto. Poiché entrambi i paragrafi sono presenti nella versione beta del libro, essi (si spera), sono i soli ad avere senso. Quindi, l'uso dei tag condizionali costringe i traduttori a lavorare su brevi pezzi di brani, senza possibilità di seguire il contesto globale del discorso, da un paragrafo al successivo. In queste condizioni, ne risente la qualità della traduzione, aumentando di conseguenza il tempo richiesto — ed anche il costo della traduzione.
Inoltre, a meno che i traduttori non sappiano come configurare il file publican.cfg di Publican e non siano a conoscenza dei tag condizionali, essi non riuscirebbero a rivedere il documento finale tradotto. Se i traduttori non sono informati sull'uso di questi tag, quando procedono a rivedere un documento, rimarrebbero sorpresi nel non riuscire a trovare il testo che hanno tradotto e che facilmente trovano nei file PO. Quindi, se occorre usare i tag condizionali, ricordarsi di informare i propri traduttori del loro uso, fornendo loro il necessario supporto.
In alternativa ai tag condizionali, si consideri di mantenere versioni separate di un libro, in rami separati di un repository con controllo di versione. In tal modo, è anche possibile condividere file XML e PO tra i vari rami; inoltre alcuni sistemi di controllo versione permettono di condividere correttamente le modifiche tra branch.
If you maintain two versions of a book in the same repository, we recommend using a separate config file for each version. For example, the upstream.cfg file might contain the condition condition: upstream and the enterprise.cfg file might contain the condition condition: enterprise. You could then specify the version of the document to build or package with the --config; for example, $ publican package --lang en-US --config upstream.cfg. Using two separate config files saves you from having to edit the one config file each time you build or package a document.

4.10. Software pre-release e documentazione draft

La documentazione completata per software pre-release non coincide con la documentazione draft (bozza).
Un documento draft è una versione incompleta di un libro o articolo, ed il cui stato incompleto non è correlato allo stato del software documentato.
Tuttavia in ogni caso, è importante comunicare chiaramente lo stato del software, della documentazioni o di entrambi a tutti gli interessati: utenti, sviluppatori, lettori e revisori.

4.10.1. Denotare il software pre-release

La documentazione per software pre-release, soprattutto quello distribuito a tester, clienti e partner, dovrebbe portare un contrassegno, a denotare lo status beta del software.
Per creare il contrassegno, seguire la seguente procedura:
  1. Aggiungere il numero di versione del software pre-release, o un informazione di stato equivalente, al tag <subtitle> nel file Book_Info.xml. Inserire questa informazione tra tag <remark>. Per esempio:
    <subtitle>Using Red Hat Enterprise Warp Drive<remark> Version 1.1, Beta 2</remark></subtitle>
    
    
  2. Aggiungere show_remarks al file publican.cfg ed impostarlo ad '1':
    show_remarks: 1
    
    
Compilando il libro con questo tag <remark> e con l'impostazione show_remarks, si definisce in modo chiaro ed inequivocabile la natura pre-release del software. Le compilazioni PDF visualizzano il contrassegno sulla copertina e sulla pagina del titolo. Le compilazioni HTML (sia su pagina singola sia su pagine multiple), visualizzano il contrassegno sulla pagina iniziale del file index.html.
Poiché questo approccio non modifica le informazioni nel file Book_Info.xml usato per generare gli RPM, esso garantisce anche che non ci sia alcuna ambiguità nelle operazioni del sottosistema RPM.

Importante

Rimane una responsabilità del redattore rimuovere il tag <remark> con il suo contenuto e rimuovere o disattivare l'attributo show_remarks quando la documentazione viene aggiornata con la versione di release del software.

4.10.2. Denotare la documentazione draft

La documentazione incompleta resa disponibile per revisione dovrebbe essere indicata chiaramente come tale.
  • Per far comparire il contrassegno draft ad un documento, aggiungere l'attributo status="draft" al tag <article>, <book> o <set> nel nodo radice del documento. Per esempio:
    <book status="draft">
    
    
Per impostazione, il nodo radice coincide con il tag <book> nel file Nome_Doc.xml.
Nel caso di un articolo o set di volumi, il nodo radice coincide con il tag <article> o <set>, rispettivamente, nel file Nome_Doc.xml.
L'aggiunta dell'attributo status="draft" causa la comparsa su ciascuna pagina del documento del contrassegno draft.
Anche se si modificano solo brevi porzioni di un documento da revisionare, contrassegnare le pagine come draft incoraggia i lettori a riportare gli errori ed i refusi intercettati. Serve anche ad assicurare che lettori occasionali evitino di far danni scambiando un draft per una versione finale.

4.10.3. Denotare come draft la documentazione per software pre-release

Per denotare propriamente la documentazione incompleta relativa a software pre-release, seguire entrambe le procedure indicate in precedenza.


[1] Fare riferimento a http://www.section508.gov/
[2] Fare riferimento alla sezione 2.4 "Character Data and Markup" dello standard XML 1.0, disponibile su http://www.w3.org/TR/2008/REC-xml-20081126/.

Capitolo 5. Branding

I brand sono collezioni di file usati da Publican per applicare alle presentazioni HTML e PDF, un look ed uno stile consistente. Essi forniscono modelli testuali con cui iniziare un documento, immagini come loghi ed elementi stilistici come schemi di colore. Publican viene distribuito con un unico brand, common/. I team che realizzano documentazione possono produrre e distribuire brand ai loro contributori, sia mediante pacchetti (per esempio pacchetti RPM), sia mediante archivi (per esempio file tarball o ZIP).

5.1. Installare un brand

In Fedora, i brand Publican per documenti Fedora, Genome e oVirt sono disponibili come pacchetti RPM. Analogamente, Red Hat distribuisce pacchetti RPM contenenti brand di Publican per documenti GIMP, JBoss e Red Hat. Accedendo ai repository dedicati, è possibile installare questi brand su computer che eseguono Red Hat Enterprise Linux o Fedora — o un sistema operativo derivato — con il comando yum install publican-brand o con un gestore grafico di pacchetti come PackageKit.
Se si usa Publican su un sistema operativo che non utilizza pacchetti RPM, il progetto di documentazione può fornire il proprio brand in un altro formato. Qualunque sia il formato di distribuzione del brand, i file di brand devono trovarsi in una sotto-cartella della cartella Common_Content di Publican. Per impostazione, questa cartella si trova in /usr/share/publican/Common_Content nei Sistemi Operativi Linux, e in %SystemDrive%/%ProgramFiles%/Publican/Common_Content nei sistemi operativi Windows — tipicamente C:/Program Files/Publican/Common_Content.
Ciascun brand attualmente disponibile, viene distribuito sotto una licenza specifica per brand, come indicato di seguito.
Installare il brand:
  1. Se il brand è distribuito come un archivio, per esempio, un file tarball o ZIP, estrarre il brand in una nuova cartella.
  2. Spostarsi nella cartella contenente il brand estratto:
    $ cd publican-brand
    dove brand è il nome del brand.
  3. Compilare il brand:
    $ publican build --formats xml --langs all --publish
  4. Installare il brand:
    $ sudo publican install_brand --path path
    dove path è il percorso ai file Common Content di Publican. Per esempio, su un sistema Linux, eseguire:
    $ sudo publican install_brand --path /usr/share/publican/Common_Content
    o su un sistema Windows, eseguire:
    $ publican install_brand --path "C:/Program Files/Publican/Common_Content"

Tabella 5.1. Brand correnti e relativi pacchetti

Brand Licenza sui file in Common Content Licenza predefinita sui documenti Pacchetto Commento
common CC0 1.0 GFDL Version 1.2 publican Licenza GPL compatibile. Nessuna opzione.
RedHat CC-BY-SA 3.0 CC-BY-SA 3.0 publican-redhat
Fedora CC-BY-SA 3.0 CC-BY-SA 3.0 publican-fedora
JBoss CC-BY-SA 3.0 CC-BY-SA 3.0 publican-jboss Nessuna opzione.
oVirt OPL 1.0 OPL 1.0 publican-ovirt Nessuna opzione.
GIMP GFDL Version 1.2 GFDL Version 1.2 publican-gimp Coincidente con la licenza sulla documentazione GIMP esistente.
Genome OPL 1.0 OPL 1.0 publican-genome Nessuna opzione.

Notare, nel brand common, la differenza di licenza tra i file di common content (CC0) e la licenza predefinita (GFDL), impostata sui libri generati con il brand common. La licenza CC0 consente di re-distribuire e licenziare i file (inclusi i file CSS e le immagini), che fanno parte del common brand per soddisfare alle proprie esigenze progettuali. Publican suggerisce la licenza GFDL per la documentazione, per impostazione predefinita, poiché Publican è sviluppato in primo luogo per creare documentazione per software. La licenza GFDL è compatibile con la licenza GPL, che è la licenza più comunemente usata per il software open-source.

5.2. Creare un brand

Use the $ create_brand action to create a new brand. When you create a new brand, you must give it a name and specify the original language for the brand's XML files. The --name option provides the name, and the --lang option specifies the language. The complete command is therefore:
$ publican create_brand --name=brand --lang=language_code
Publican crea una nuova sotto-cartella di nome publican-brand, dove brand è il brand specificato con l'opzione --name.
Per esempio, per creare un brand di nome Acme, con i file XML in Common Content redatti in inglese statunitense, eseguire:
$ publican create_brand --name=Acme --lang=en-US
In tal caso, Publican crea il brand nella sotto-cartella publican-Acme.
Per configurare il nuovo brand, individuare il termine SETUP nei file predefiniti creati da Publican e modificare i file inserendo i necessari dettagli. Sui Sistemi Operativi Linux, la ricerca in questi file, del termine SETUP può essere effettuata con il comando:
$ grep -r 'SETUP' *

5.3. File nella directory brand

Running the $ publican create_brand --name=brand --lang=language_code command creates a directory structure and the required files. The brand directory initially contains:
  • COPYING
  • defaults.cfg
  • overrides.cfg
  • publican.cfg
  • publican-brand.spec, dove brand è il nome del brand.
  • README
  • una sotto-cartella contenente i file XML di brand, fogli di stile CSS e immagini predefinite. La sotto-cartella ha lo stesso nome del codice linguistico della lingua originale del brand (per esempio, en-US). Questi file sono:
    • Feedback.xml
    • Legal_Notice.xml
    • la sotto-cartella css, contenente:
      • overrides.css
    • la sotto-cartella images, contenente 43 immagini in formato raster o bitmap (PNG) e vettoriale (SVG).

5.3.1. Il file publican.cfg

Il file publican.cfg, in un brand, svolge una funzione simile al file publican.cfg in un documento — configura un certo numero di opzioni di base per definire il brand.
version
specifies the version number for the brand. When you create the brand with $ publican create_brand, the version number is set to 0.1. Update the version number here in the brand publican.cfg file and in the publican-brand.spec file when you prepare a new version of the brand.
Notare che questo parametro non è correlato al numero di versione dei documenti creati con questo brand. Per esempio, Fedora 12 Installation Guide ha la versione impostata a 12 nel proprio file publican.cfg, ma potrebbe essere compilato con la versione 1.0 del brand publican-fedora.
xml_lang
specifies the language of the source XML files for the brand's Common Content, for example, en-US, as set by the --lang option for $ publican create_brand.
release
specifies the release number for the brand. When you create the brand with $ publican create_brand, the release number is set to 0. Update the version number here in the brand publican.cfg file and in the publican-brand.spec file when you prepare a new release of an existing version of the brand.
type
impostato a type: brand, questo parametro identifica il contenuto nella cartella come un brand invece che come un libro, articolo o set.
brand
specifies the name of the brand, as set by the --name option for $ publican create_brand.
type
the full path for the Publican site configuration file for non standard RPM websites.
web_dir
the full path to where files will be installed. You must also set wwwdir in publican-brand.spec.
web_req
the name of the RPM package that will supply the Publican site config file.

5.3.2. I file defaults.cfg e overrides.cfg

Ogni documento creato in Publican, ha un file publican.cfg nella cartella radice, per configurare le opzioni di creazione dei documenti. Fare riferimento alla Sezione 4.1.1, «Il file publican.cfg» per una completa descrizione di queste opzioni. I file defaults.cfg e overrides.cfg in un brand, forniscono valori predefiniti ai parametri, che è possibile impostare nel file publican.cfg di un documento.
Quando si compila un documento con un particolare brand, Publican dapprima applica i valori nel file defaults.cfg del brand e poi i valori impostati nel file publican.cfg del documento. Quindi i valori di publican.cfg hanno la precedenza su quelli impostati nel file defaults.cfg del brand.
Poi Publican applica i valori impostati nel file overrides.cfg del brand, per cui quest'ultimo non tiene conto dei valori impostati in defaults.cfg del brand e in publican.cfg del documento.
Usare il file defaults.cfg per impostare valori da applicare per routine al brand e per consentire ai redattori di modificarli nei libri; usare il file overrides.cfg per impostare quei valori che non si desidera vengano modificati dai redattori.
You can add a list of banned tags or attributes using banned_tags and banned_attrs respectively to either defaults.cfg or overrides.cfg. These will be listed by the Publican action print_banned.

5.3.3. File publican-brand.spec

Alcuni Sistemi Operativi Linux, usano un Gestore di pacchetti RPM per distribuire software, sotto forma di pacchetti RPM. In termini generali, un pacchetto RPM contiene i file di software compressi in un archivio, insieme ad un file spec che indica al Gestore di pacchetti RPM come e dove installare questi file.
Quando si crea un brand, Publican genera lo schema di un file spec di RPM per il brand. Il file spec generato (automaticamente), fornisce uno schema di partenza da cui creare il pacchetto RPM con cui distribuire il brand. Fare riferimento alla Sezione 5.4, «Creare il pacchetto di un brand» per sapere come configurare il file spec e come usarlo per produrre un pacchetto RPM.

5.3.4. README

Il file README contiene una breve descrizione del pacchetto di brand.

5.3.5. COPYING

Il file COPYING contiene i dettagli riguardanti la licenza o COPYRIGHT sul pacchetto e presumibilmente il testo della stessa licenza.

5.3.6. Common Content per il brand

All'interno della cartella del brand, si trova una sotto-cartella denominata con il nome della lingua predefinita dei file XML, come impostata con l'opzione --lang al momento della creazione del brand. Questa cartella contiene i file XML e le immagini, che si sovrappongono al Common Content predefinito fornito con Publican. La personalizzazione di questi file permette ad un brand di acquisire il suo aspetto distintivo, con il suo schema di colori e i suoi loghi.

5.3.6.1. Feedback.xml

Il file Feedback.xml è incluso, per impostazione predefinita, nella prefazione di ogni libro prodotto con Publican. Con questo file si invitano i lettori ad inviare commenti sul documento. Personalizzare questo file inserendo i recapiti del progetto. Se il progetto usa un sistema di tracciamento di bug come Bugzilla, JIRA o Trac si potrebbe includere qui questo tipo di informazione.

5.3.6.2. Legal_Notice.xml

Il file Legal_Notice.xml contiene le informazioni legali che appaiono all'inizio di ogni documento prodotto con Publican. Inserire i dettagli riguardanti la propria licenza sul diritto d'autore in questo file. Tipicamente, ciò potrebbe includere il nome della licenza, con un breve descrizione ed un link ai dettagli completi sulla licenza.

5.3.7. La sotto-cartella css

La sotto-cartella css contiene un solo file: overrides.css.

5.3.7.1. overrides.css

Il file overrides.css imposta l'apparenza stilistica del brand. I valori in questo file sopravanzano i valori nel file Common_Content/common/lingua_xml/css/common.css di Publican.

5.3.8. La sotto-cartella images

La sotto-cartella images contiene 43 immagini in formato PNG (Portable Network Graphics) ed SVG (Scalable Vector Graphics). Queste immagini sono segnaposti per varie icone di navigazione, riquadri contenenti note/suggerimenti/avvisi/, e loghi di brand. Essi includono:
image_left
è un logo per il prodotto cui fa riferimento il documento. Esso compare in alto, nell'angolo sinistro delle pagine HTML, in cui contiene un link alla pagina web per il prodotto, come definito nel parametro prod_url del file publican.cfg del documento. Si consideri di impostare prod_url nei file defaults.cfg o overrides.cfg del brand.
image_right
è un logo per il team che ha prodotto la documentazione. Esso compare in alto, nell'angolo destro delle pagine HTML, in cui contiene un link alla pagina web per il team, come definito nel parametro doc_url del file publican.cfg del documento. Se tutta la documentazione per questo brand è prodotta dallo stesso team, si consideri di impostare doc_url nei file defaults.cfg o overrides.cfg del brand.
title_logo
è una versione più grande del logo del prodotto, che compare sulla pagina del titolo nei documenti PDF ed all'inizio nei documenti HTML.
note, important, warning
sono icone che si accompagnano agli avvisi XML <note>, <important> e <warning>.
dot, dot2
sono i punti elenco usati con <listitem> in <itemizedlist>.
stock-go-back, stock-go-forward, stock-go-up, stock-home
sono le icone di navigazione per le pagine HTML.
h1-bg
è uno sfondo per l'intestazione, contenente il nome del prodotto, come appare all'inizio di un documento HTML.
watermark_draft
è un contrassegno che appare nelle pagine di documentazione in draft (bozza). Fare riferimento alla Sezione 4.10.2, «Denotare la documentazione draft».

5.3.9. The brand_dir option

The Publican build option brand_dir allows you to specify the location of brand files. These files do not have to be part of an installed brand.
You can ship custom XSL in a folder named xsl in your brand: it sits at the same level as the various language files for your brand. Publican uses any XSL that it finds in that directory to override the XSL templates that we ship in the common brand (which in turn override the XSL templates that the DocBook project ships).

Importante

Brands that supply XSL files need to change the relative path to a URI.

5.4. Creare il pacchetto di un brand

Altri pacchetti non RPM

This section discusses packaging documents for distribution through the RPM Package Manager. However, when you use the $ publican package command, Publican generates a tarball that you can use to build a package to distribute through different package manager software. If you run publican package on a computer on which rpmbuild is not installed, Publican still generates the tarball, even though it cannot then generate an RPM package from that tarball.
Dopo aver creato un brand (come descritto nella Sezione 5.2, «Creare un brand»), Publican permette di distribuire il brand ai membri di un team di documentazione come pacchetti RPM. I pacchetti RPM vengono impiegati per distribuire software ai computer con sistemi operativi Linux che usano un Gestore di pacchetti RPM. Tra questi sistemi operativi figurano Red Hat Enterprise Linux, Fedora, Mandriva Linux, SUSE Linux Enterprise, openSUSE, Turbolinux e Yellow Dog Linux, per citarne solo alcuni.
Publican è in grado di produrre sia pacchetti RPM di sorgenti (pacchetti SRPM) sia pacchetti RPM di binari. Come parte del processo, crea anche il file spec — il file contenente i dettagli di come configurare ed installare il pacchetto.
Un pacchetto SRPM contiene il codice sorgente da cui generare il software, invece del software stesso. Per usare un pacchetto SRPM, un sistema deve compilare il codice sorgente trasformandolo in software. I pacchetti SRPM di brand creati con Publican, contengono file di configurazione, file XML e file di immagini che definiscono il brand nella propria lingua originale, più i file PO che generano i file di Common Content nelle varie lingue. Non è possibile installare direttamente i documenti da un pacchetto SRPM con la versione attuale di RPM Package Manager.
Al contrario, i pacchetti RPM di binari contengono software — in questo caso, un brand di Publican — pronto per essere salvato nel file system del computer ed immediatamente usato. I contenuti del pacchetto RPM binario non devono essere prima compilati sul sistema da installare, e quindi il sistema non deve aver Publican, installato.
To package a brand, use the $ publican package command in the brand directory. When used without any further options, Publican produces an SRPM package. The options for packaging a brand are as follows:
--binary
specifica di compilare il pacchetto come un pacchetto RPM binario.
--brew
specifica di inviare su Brew il pacchetto completato. Brew è il sistema di compilazione interno a Red Hat; questa opzione non ha senso all'esterno di Red Hat.
--scratch
se usato insieme all'opzione --brew, specifica di compilare il pacchetto SRPM da inviare su Brew, come uno scratch build (compilazione di prova). Uno scratch build è usato per verificare la correttezza strutturale del pacchetto SRPM, senza aggiornare il database dei pacchetti con il pacchetto risultante.
Le opzioni --lang, --desktop e --short_sighted che si applicano quando si crea il pacchetto di un libro (descritto nella Sezione 4.8, «Creare il pacchetto di un documento») non hanno senso nel caso dei brand. In particolare, notare che sebbene l'opzione --lang sia necessaria per la creazione del pacchetto di un libro, essa non occorre quando si crea il pacchetto di un brand.
Per impostazione predefinita, i pacchetti di brand di Publican sono denominati:
publican-brand-versione-release.build_target.noarch.estensione_file
Publican usa le informazioni nel file publican.cfg per fornire i vari parametri nel nome di file. Fare riferimento alla Sezione 5.3.1, «Il file publican.cfg» per i dettagli sulla configurazione di questo file. Inoltre:
  • i pacchetti SRPM hanno estensione .src.rpm mentre i pacchetti RPM di binari hanno estensione .rpm
  • i pacchetti RPM di binari include prima dell'estensione, l'elemento build_target.noarch, dove build_target rappresenta il sistema operativo e la versione, per cui il pacchetto viene compilato, come impostato dal parametro os_ver nel file publican.cfg. L'elemento noarch specifica che il pacchetto può essere installato su ogni sistema, a prescindere dall'architettura.

Capitolo 6. Usare i set

A set is a collection of books, published as a single output. The Services Plan for example is a set comprised of many books such as the Developer Guide, Engineering Content Services Guide and the Engineering Operations Guide to name just a few. The $ create_book command creates a template for a set by setting the type parameter to Set.
Esistono due tipi di set:
  • set a sé stanti
  • set distribuiti

6.1. Set a sé stanti

Un set a sé stante contiene i file XML di ogni libro, i quali si trovano all'interno della cartella del set. I set a sé stanti sono sempre costruiti come un set; non è possibile costruire i singoli libri senza effettuare modifiche.
Il seguente procedimento indica come creare un set a sé stante di nome My Set, salvato nella cartella books/My_Set/. Il set è composto da due libri, Book A e Book B, entrambi creati manualmente all'interno della cartella books/My_Set/en-US.

Procedura 6.1. Creare un set a sé stante

  1. In una shell, eseguire il seguente comando nella cartella books/ per creare un set denominato My_Set con brand in stile Red Hat e in cui i file XML vengono redatti in inglese americano.
    publican create --type=Set --name=My_Set --brand=RedHat --lang=en-US
    
    
  2. $ cd into the My_Set/en-US directory and create two directories (not books) called Book_A and Book_B.
    $ cd My_Set/en-US
    $ mkdir Book_A Book_B
  3. $ cd into the books/My_Set/en-US/Book_A directory. Create and edit the Book_A.xml, Book_Info.xml, and any other xml files required for your book such as those required for individual chapters. Ensure that Book_A.xml contains the correct xi:include references to all of your xml files in the directory. For example, if Book A contained Book_Info.xml and Chapter_1.xml, the Book_A.xml file would look like this:
    <?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" [
    ]>
    \t  
    <book>
    \t  <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
    \t  <xi:include href="Chapter_1.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
    </book>
    
    
  4. Usare lo stesso procedimento per il Book_B, salvato nella cartella books/My_Set/en-US/Book_B, come indicato sopra.
  5. Modificare il file books/My_Set/en-US/My_Set.xml. Per ciascun libro nel set, aggiungere un riferimento xi:include al file XML principale del libro. Il file XML principale per il Book A è Book_A.xml e quello per il Book B, Book_B.xml. Il file My_Set.xml dovrebbe assomigliare a:
    <?xml version="1.0"?>
    <!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" 
    "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
    ]>
    
    <set>
    	<xi:include href="Set_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="Book_A/Book_A.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    	<xi:include href="Book_B/Book_B.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    	<xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    </set>
    
    				
    
    
  6. Per rendere valido il set, occorre effettuare la seguente modifica:
    1. In My_Set.xml, togliere il commento alle seguenti righe:
      <remark>NOTE: the href does not contain a language! This is CORRECT!</remark>
      <remark><xi:include href="My_Other_Book/My_Other_Book.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></remark>
      <setindex></setindex>
      
    2. In Preface.xml e Book_Info.xml di ogni libro, aggiungere ../../ all'inizio di ogni stringa Common_Content, presente. Per esempio:
      <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
      
      Quindi si ha:
      <xi:include href="../../Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
      
      Ciò perché in un set a sé stante, la cartella Common Content si trova due cartelle più in là rispetto a dove di solito cerca Publican, perciò occorre inserirlo manualmente. Per compilare i libri singolarmente, senza costruire l'intero set, saltare questo passaggio.
  7. Test your set by running the $ publican build --formats=test --langs=en-US command.
Se si usano libri pre-esistenti, occorre riorganizzarli in modo che i file XML siano al livello del set e tutte le immagini siano all'interno della cartella delle immagini, nello stesso livello. Per esempio:
   -- My_Set
    |-- en-US
    |   |-- Author_Group.xml
    |   |-- Book_A.ent
    |   |-- Book_A.xml
    |   |-- Book_B.ent
    |   |-- Book_B.xml
    |   |-- Book_Info_A.xml
    |   |-- Book_Info_B.xml
    |   |-- chapter_A.xml
    |   |-- chapter_B.xml
    |   |-- images
    |   |   |-- icon.svg
    |   |   `-- image1.png
    |   |-- My_Set.ent
    |   |-- My_Set.xml
    |   |-- Preface.xml
    |   |-- Revision_History.xml
    |   `-- Set_Info.xml
    `-- publican.cfg

I file XML possono trovarsi anche all'interno di sotto-cartelle separate. E lo stesso vale per la cartella delle immagini. Per esempio:
   -- My_Set
    |-- en-US
    |   |-- Author_Group.xml
    |   |-- Book_A
    |   |   |-- Book_A.ent
    |   |   |-- Book_A.xml
    |   |   |-- Book_Info.xml
    |   |   `-- chapter.xml
    |   |-- Book_B
    |   |   |-- Book_B.ent
    |   |   |-- Book_B.xml
    |   |   |-- Book_Info.xml
    |   |   `-- chapter.xml
    |   |-- images
    |   |   |-- icon.svg
    |   |   `-- image1.png
    |   |-- My_Set.ent
    |   |-- My_Set.xml
    |   |-- Preface.xml
    |   |-- Revision_History.xml
    |   `-- Set_Info.xml
    `-- publican.cfg

6.2. Set distribuiti

Un set distribuito contiene libri localizzati in un repository di controllo versione. Sebbene esistano diversi sistemi di controllo versione, questa versione di Publican supporta solo un sistema: SVN (Subversion). Impostando, nel file publican.cfg, la locazione del repository e i titoli dei libri contenuti nel set, ogni libro può essere esportato per creare il set completo. Il seguente procedimento, indica come creare un set denominato My Set contenente il Book A ed il Book B.

Importante

Di seguito so assume che il Book A ed il Book B siano già esistenti e disponibili in un repository SVN. Al momento, Publican supporta solo SVN.

Procedura 6.2. Creare un set

  1. In una shell, eseguire il seguente comando, per creare un set denominato My_Set con brand in stile Red Hat e in cui i file XML vengono redatti in inglese americano.
    $ publican create --type=Set --name=My_Set --brand=RedHat  --lang=en-US
    
    
  2. Aggiungere le seguenti righe al file publican.cfg:
    books: Book_A Book_B
    repo: http://PATH-TO-YOUR-SVN-REPOSITORY
    scm: SVN
    
    
    Il percorso al repository deve indirizzare per primo, la cartella del libro.
  3. Modificare il file My_Set.xml. Per ciascun libro del set, aggiungere un riferimento xi:include al file XML principale del libro. Il file XML principale per il Book A è Book_A.xml e quello per il Book B, Book_B.xml. Il file My_Set.xml dovrebbe assomigliare a:
    <?xml version="1.0"?>
    <!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" 
    "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
    ]>
    
    <set>
    	<xi:include href="Set_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="Book_A/Book_A.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    	<xi:include href="Book_B/Book_B.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    	<xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
    </set>
    
    				
    
    
  4. Per rendere valido il set, occorre togliere il commento alle seguenti righe in My_Set.xml:
    <remark>NOTE: the href does not contain a language! This is CORRECT!</remark>
    <remark><xi:include href="My_Other_Book/My_Other_Book.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></remark>
    <setindex></setindex>
    
  5. Test your set by running the $ publican build --formats=test --langs=en-US command.

    Importante

    When building a set, the $ publican clean_ids command will be run over each book because of the constraint that IDs must be unique across all books. Be careful of creating IDs that rely on content that may not be available when building books independently of the set.

Capitolo 7. Creare un sito web con Publican

Publican non solo crea documenti per pubblicazione ma può creare e gestire anche un sito web di documentazione. Se occorre mantenere una raccolta di documenti, si può usare Publican per creare un sito sul sistema locale e poi caricare il sito su un server web. Tuttavia questo approccio non è molto scalabile, per cui nei progetti di documentazione basati su team, Publican permette di creare pacchetti RPM di documentazione da installare sul server web. Per installare su un server i pacchetti RPM creati con Publican, occorre che sul server sia installato Publican (versione 2.1 o superiore) e l'applicazione rpm. Se si crea e mantiene il sito su una workstation e poi lo si carica su un server web per pubblicazione, allora non occorre che Publican ed rpm siano installati sul server web.
Il sito web creato da Publican consiste di quattro parti: la struttura del sito, una home page, pagine descrittive su prodotto e versione, e i documenti pubblicati sul sito. La struttura del sito, a sua volta consiste di:
  • un file di configurazione
  • un file di database SQLite
  • una sottocartella per i documenti pubblicati, contenente:
    • index.html — una pagina indice che indirizza alle versioni localizzate di una home page per il sito.
    • interactive.css — un foglio di stile CSS contenente gli stili per il menu di navigazione, per le pagine map e per le statistiche sul sito.
    • opds.xml — un catalogo OPDS (Open Publication Distribution System) per permettere ai lettori di eBook compatibili di individuare facilmente i documenti sul sito.
    • Sitemap — A Sitemap is a list of the URLs from your website and metadata about them, like update history, change frequency, and importance relative to other URLs in the site. A Sitemap can be supplied to many major search engines, where it is used to help their crawlers index your site more intelligently. A Sitemap does not guarantee that your site will be ranked higher in search results. However, it does help search engines to return the most relevant results from your website in response to user queries. For more information on Sitemaps, visit sitemaps.org.
    • site_overrides.css — un foglio di stile CSS alternativo a quelli presenti in interactive.css, per offrire stili specifici per il sito. Questo file non è creato dal processo di creazione del sito, ma deve essere aggiunto manualmente, successivamente o fornito dalla home page del sito.
    • toc.js — uno script JavaScript che in base all'impostazione nel browser, indirizza i visitatori al contenuto in lingua locale e che controlla la presentazione del menu di navigazione.
    • subdirectories for each language in which you publish. Initially, this contains opds.xml and toc.html. Later it also contains opds-product.xml:
      • opds.xml — un catalogo OPDS di documenti EPUB in questa lingua.
      • opds-prodotto.xml — un catalogo OPDS di documenti EPUB per ogni prodotto da pubblicare in questa lingua. All'interno di ogni catalogo, per versioni differenti dello stesso prodotto, la documentazione è suddivisa in <category>.
      • toc.html — l'indice ai contenuti per la lingua, inizialmente senza alcun link a documento.
      • Una sotto-cartella per ciascun prodotto da pubblicare in questa lingua.
Opzionalmente, la struttura del sito può contenere anche un file dump — un file XML che fornisce il dettaglio completo sul contenuto del sito per servire altri servizi, come feed web o ricerca personalizzata di pagine. La struttura potrebbe contenere anche una versione zippata del file dump. Fare riferimento alla Sezione 7.1.1, «Creare la struttura del sito web» ed alla Sezione 7.2.1, «Creare la struttura del sito web» per i dettagli sulla creazione di un file dump; mentre per una descrizione del contenuto di un file dump, vedere l'Appendice E, Contenuto del file dump di un sito.

7.1. Creare manualmente un sito web

7.1.1. Creare la struttura del sito web

Per creare la struttura del sito web:
  1. Sulla propria macchina, creare una nuova cartella, in cui poi spostarsi. Per esempio, su un sistema Linux, eseguire:
    $ mkdir ~/docsite
    $ cd ~/docsite
  2. Run $ publican create_site, specifying the following parameters:
    • --site_config — il nome del file di configurazione, per il sito, con estensione .cfg
    • --db_file — il nome del file di database SQLite, per il sito, con estensione .db
    • --toc_path — il percorso alla cartella in cui saranno salvati i documenti
    Su un computer con sistema operativo diverso da Linux, impostare anche:
    • --temp_path — il percorso alla cartella templates/ nella directory di installazione di Publican. Sui computer con sistemi operativi Windows, il percorso tipicamente coincide con %SystemDrive%\%ProgramFiles%\Publican\templates.
    Per esempio:
    $ publican create_site --site_config foomaster.cfg --db_file foomaster.db --toc_path html/docs
    E' possibile assegnare dei nomi ai file di configurazione e di database del sito per un miglior riconoscimento del sito di appartenenza. Per esempio, per il sito di documentazione FooMaster, si potrebbe assegnare a questi file, rispettivamente, i nomi foomaster.cfg e foomaster.db. Il parametro --toc_path può essere impostato a piacere.
  3. Modificare il file di configurazione specificando il nome del sito, il web host ed opzionalmente, impostare i parametri di ricerca, la lingua predefinita, le impostazioni del file dump e quelle di aggiornamento per il sito:
    1. Specificare il titolo con il parametro title, per esempio:
      title: "Foomaster Documentation"
      Normalmente, i visitatori del sito non visualizzano questo titolo perché il JavaScript del sito li reindirizza alla homepage. Comunque il titolo è facilmente individuato ed indicizzato dai motori di ricerca.
    2. Specificare con il parametro host, il web host indicando l'URL completo, incluso il protocollo. Per esempio:
      host: http://docs.example.com
      Publican usa il valore impostato in host per costruire gli URL nel file XML, Sitemap, usato dai motori di ricerca e per limitare le ricerche dalla casella relativa nel menu di navigazione, soltanto ai documenti presenti nel sito.
    3. Opzionalmente, costruire un motore di ricerca da usare con la casella di ricerca nel menu di navigazione, e specificare l'intero contenuto del <form> HTML con il parametro search. Se non si specifica alcun criterio di ricerca, Publican crea una ricerca basata su Google, limitando la ricerca all'host specificato dal parametro host.
      Per esempio, per costruire una ricerca basata su Yahoo!, limitatamente all'host docs.example.com, impostare:
      search: '<form target="_top" method="get" action="http://search.yahoo.com/search"> <div class="search"> <input type="text" name="p" value="" /> <input type="hidden" name="vs" value="docs.example.com" /> <input type="submit" value="###Search###" /> </div> </form>'
      Fare riferimento alla documentazione del motore di ricerca scelto, per i dettagli su come creare criteri di ricerca personalizzati.
      Se nel codice di un pulsante di ricerca, si imposta value="###Search###", Publican visualizza il termine Search sul pulsante, ovviamente tradotto in ogni lingua supportata da Publican.

      Importante — il parametro search non è validato

      Publican non controlla la validità del parametro search, ma crea il valore di questo parametro nel menu di navigazione, così come specificato. Prestare particolare attenzione nell'usare questa proprietà.
    4. Opzionalmente, impostare la lingua predefinita del sito web. Publican crea un menu di navigazione distinto e tradotto, per ogni lingua in cui si pubblica la documentazione. Comunque, se un documento non è disponibile in una particolare lingua, Publican indirizza i visitatori alla versione in lingua originale del documento. Per specificare la lingua predefinita, originale del sito, impostare il parametro def_lang con il codice linguistico relativo. Per esempio:
      def_lang: it-IT
      Impostando il parametro def_lang con il codice it-IT, i visitatori che visualizzano il menu di navigazione, per esempio in spagnolo, vengono diretti alla versione italiana del documento se non è presente una traduzione in spagnolo.
    5. Optionally, configure a dump file for the website. Publican can output an XML file that provides complete site content details for delivery of other services, such as web feeds or customised search pages. The file is updated whenever a book is installed or removed from the site, or the $ publican update_site command is run. Configure the dump, dump_file, and zip_dump parameters as follows:
      dump
      Impostare dump: 1 per abilitare la funzione di file dump. Il parametro, in modo predefinito, è impostato su 0 (disattivato).
      dump_file
      Impostare dump_file: nome per specificare il nome del file dump e la cartella in cui salvare il file. Il parametro, in modo predefinito, è impostato su /var/www/html/DUMP.xml.
      zip_dump
      Impostare zip_dump: 1 per creare anche una versione zippata del file XML. Il parametro, in modo predefinito, è impostato su 0 (disattivato).
      Fare riferimento all'Appendice E, Contenuto del file dump di un sito per una descrizione del contenuto del file dump.
    6. Opzionalmente, specificare con il parametro manual_toc_update, che le tabelle dei contenuti sono aggiornate manualmente, per esempio:
      manual_toc_update: 1
      Normally, Publican updates the site's tables of contents every time a documentation package is added or removed. On a site with a large number of documents on it (more than a few hundred), or where documents are updated very frequently (dozens of updates per week), this process is very demanding on a server. On a large or busy site, we recommend that you set this parameter and then periodically update the tables of contents with the $ publican update_site command.
    7. Optionally, override the default JavaScript for the site with the toc_js parameter, for example:
      toc_js: "mybrand/scripts/megafoo.js"
      This file will be symlinked as toc_path/toc.js with the $ publican update_site command. This path should be relative to the toc_path parameter.
  4. Creare un file vuoto di nome site_overrides.css nella cartella specificata con l'opzione doc_path (la cartella che contiene il foglio di stile interactive.css e le cartelle linguistiche). Se si desidera usare degli stili specifici alternativi a quelli forniti da interactive.css, aggiungere un file site_overrides.css al documento che fornisce la home page del sito — vedere la Sezione 7.1.2, «Creare, installare ed aggiornare la home page». Se non si usa uno stile specifico, il file vuoto aggiunto impedirà la comparsa dell'errore 404 sul server. Su un sistema Linux, spostarsi nella cartella specificata con l'opzione doc_path ed eseguire:
    $ touch site_overrides.css
  5. Build and install each brand, including the Publican common brand.
    1. Change into the directory that holds the source for the brand.
      $ cd brandsrc_dir
    2. Build the brand.
      $ publican build --formats=xml --langs=all --publish
    3. Install the brand on your website.
      $ publican install_brand --web --path=path_to_site_root_dir
      Perform these steps for all brands.
  6. Update the site.
    $ publican update_site
Per aggiornare la struttura del sito, eseguire:
$ publican update_site --site_config path_to_site_configuration_file.cfg

7.1.2. Creare, installare ed aggiornare la home page

La home page generata da Publican è la pagina di localizzazione a cui sono indirizzati i visitatori dallo JavaScript del sito e che fornisce lo stile alla struttura del sito web. La home page è strutturata come un <article> DocBook ma con un parametro ulteriore web_type: home nel proprio file publican.cfg. Nella sua struttura e presentazione, la home page assomiglia ad un articolo di Publican. Per creare la home page:
  1. Change into a convenient directory and run the following $ publican create command:
    $ publican create --type Article --name page_name
    Per esempio:
    $ publican create --type Article --name Home_Page
    La maggior parte dei brand (incluso il brand common), presentano il nome del documento in grandi lettere a colori in cima alla pagina, al di sotto del banner contenente il nome del prodotto (l'opzione --name imposta il tag <title>). Quindi, per impostazione, il valore impostato con l'opzione --name viene presentata in primo piano ai visitatori del sito; nel precedente esempio, i visitatori vengono salutati con le parole Home Page sotto il banner del prodotto.
  2. Spostarsi nella cartella dell'articolo:
    $ cd page_name
    Per esempio:
    $ cd Home_Page
  3. Scollegare il file Article_Info.xml dal file XML radice.
    Il contenuto del file Article_Info.xml serve a ben poco alla home page del sito web. Quindi, modificare il file XML radice relativo alla home page, rimuovendo il tag <xi:include> che collega Article_Info.xml. Ora Publican usa ancora le informazioni in Article_Info.xml per creare pacchetti, ma senza includerlo nella home pagina stessa.
  4. Modificare il file publican.cfg.
    Come minimo, aggiungere il parametro web_type ed impostarlo a home:
    web_type: home
    Il parametro web_type: home indica di elaborare questo documento non come una documentazione di prodotto. Questa è l'unica modifica necessaria al file publican.cfg. Altre modifiche opzionali al file publican.cfg, frequentemente utili a siti web creati con Publican includono:
    brand
    Per assegnare alla home page lo stile dei propri documenti, aggiungere:
    brand: nome_di_brand
    docname, product
    Se il tag <title> o <product> impostati nel file Article_Info includono caratteri diversi dai caratteri di base, come caratteri accentati, impostare come occorre i parametri docname e product.
  5. Modificare il contenuto del file nome_pagina.xml (per esempio, Home_Page.xml) come ogni altro documento DocBook.
    Se si rimuove il tag <xi:include> che collega a Article_Info.xml, specificare un titolo per la pagina nel formato seguente:
    <title role="producttitle">FooMaster Documentation</title>
  6. If you publish documentation in more than one language, create a set of POT files and a set of PO files for each language with the $ publican update_pot and publican update_po commands.
  7. Per personalizzare il logo in cima al menu di navigazione, contenente un link alla home page, creare una immagine PNG 290 px × 100 px, di nome web_logo.png. Salvare l'immagine nella cartella images/ della directory dei file XML del documento, per esempio, en-US/images/.
  8. Se si desidera usare degli stili specifici alternativi a quelli forniti da interactive.css nel sito web, aggiungere gli stili a un file site_overrides.css e salvarlo nella radice dei file sorgenti (la cartella che contiene il file publican.cfg e le cartelle linguistiche).
  9. Creare la home page in formato HTML su singola pagina con l'opzione --embedtoc ed installarla nella struttura del sito. Per esempio:
    $ publican build --publish --formats html-single --embedtoc --langs all 
    $ publican install_book --site_config ~/docsite/foomaster.cfg --lang Language_Code
    Note that you can build all languages at the same time, but must install the home page for each language with a separate $ publican install_book command.

7.1.3. Creare, installare ed aggiornare pagine di prodotto e di versione

Le pagine di prodotto e le pagine di versione generate con Publican, sono pagine localizzabili che offrono una panoramica generale, rispettivamente, su un prodotto o una versione. I visitatori accedono a queste pagine cliccando su prodotto o versione nel menu di navigazione. Le pagine sono strutturate come un <article> DocBook con un ulteriore parametro web_type: product o web_type: version nel proprio file publican.cfg. Nella loro struttura e presentazione, le pagine prodotto e quelle di versione sono pressoché identiche ad ogni altro articolo prodotto con Publican. Per creare una pagina prodotto o di versione:
  1. Change into a convenient directory and run the following $ publican create command:
    $ publican create --type Article --name page_name
    Per esempio, per una pagina prodotto si avrebbe:
    $ publican create --type Article --name FooMaster
    o per una pagina di versione:
    $ publican create --type Article --name FooMaster_3
  2. Spostarsi nella cartella dell'articolo:
    $ cd page_name
    Per esempio:
    $ cd FooMaster
  3. Scollegare il file Article_Info.xml dal file XML radice.
    Il contenuto del file Article_Info.xml serve a ben poco alle pagine prodotto o versione. Quindi, modificare il file XML radice relativo alla pagina, rimuovendo il tag <xi:include> che collega Article_Info.xml. Ora Publican usa ancora le informazioni in Article_Info.xml per creare pacchetti, ma senza includerlo nella home pagina stessa.
  4. Modificare il file publican.cfg.
    Come minimo, aggiungere il parametro web_type ed impostarlo a product o version:
    web_type: product
    o
    web_type: version
    Il parametro web_type indica di elaborare questo documento non come una documentazione di prodotto. Questa è l'unica modifica necessaria al file publican.cfg. Altre modifiche opzionali al file publican.cfg, frequentemente utili a pagine prodotto o di versione includono:
    brand
    Per assegnare alla home page lo stile dei propri documenti, aggiungere:
    brand: nome_di_brand
    docname, product
    Se il tag <title> o <product> impostati nel file Article_Info includono caratteri diversi dai caratteri di base non accentati, impostare come occorre i parametri docname e product.
  5. Modificare il contenuto del file nome_pagina.xml (per esempio, FooMaster.xml) come ogni altro documento DocBook.
    Se si rimuove il tag <xi:include> che collega a Article_Info.xml, specificare un titolo per la pagina nel formato seguente:
    <title role="producttitle">FooMaster Documentation</title>
  6. If you publish documentation in more than one language, create a set of POT files and a set of PO files for each language with the $ publican update_pot and publican update_po commands.
  7. Creare la pagina prodotto o di versione in formato HTML su singola pagina con l'opzione --embedtoc ed installarla nella struttura del sito. Per esempio:
    $ publican build --publish --formats html-single --embedtoc --langs all 
    $ publican install_book --site_config ~/docsite/foomaster.cfg --lang Language_Code
    Note that you can build all languages at the same time, but must install the product page or version page for each language with a separate $ publican install_book command.

7.1.4. Installare, aggiornare e rimuovere documenti

Per installare un documento su un sito web da creare manualmente, spostarsi nella cartella contenente il sorgente del documento ed eseguire:
$ publican build --embedtoc --formats=list_of_formats --langs=language_codes --publish 
$ publican install_book --site_config path_to_site_configuration_file.cfg --lang language_code
Note that you can run a single $ publican build command for all languages that you want to publish, but must run a separate publican install_book for each language. You must include html as one of the formats in the publican build command; optionally, include any or all of the following formats in a comma-separated list: html-single, pdf, and epub.
Per aggiornare un documento, spostarsi nella cartella contenente i sorgenti del documento ed eseguire gli stessi comandi relativi ad una prima installazione di un documento. In tal modo, Publican sostituisce la precedente con la nuova versione.
Per rimuovere un documento, spostarsi nella cartella contenente i sorgenti del documento ed eseguire:
$ publican remove_book --site_config path_to_site_configuration_file.cfg --lang language_code
Una volta installati i documenti, il sito è pronto per essere caricato sul server web attraverso un qualsiasi metodo solitamente usato, come scp, rsync o un client FTP.

7.2. Creare un sito web usando pacchetti RPM

7.2.1. Creare la struttura del sito web

Avviso — Questa procedura sostituisce i file

Quando si costruisce la struttura del sito web, Publican salva i file nella cartella /var/www/html/docs. Quindi usando questa procedura, i file esistenti nella cartella vengono sovrascritti.
Sul server web, effettuare i seguenti passaggi. Occorre accedere con un account con privilegi di root.
  1. Autenticarsi sul server web.
  2. Diventare utente root:
    $ su -
  3. Installare Publican. Per esempio, su un server con Sistema Operativo Fedora, eseguire:
    # yum install publican-web publican-$brand-web
  4. Modificare il file /etc/publican-website.cfg, specificando il nome del sito, il web host ed opzionalmente impostare i parametri di ricerca, la lingua predefinita e il file dump per il sito:
    1. Specificare il titolo con il parametro title, per esempio:
      title: "Foomaster Documentation"
      Normalmente, i visitatori del sito non visualizzano questo titolo perché rediretti alla home page dallo JavaScript del sito. Comunque questo titolo è individuato ed indicizzato dai motori di ricerca.
    2. Specificare il web host con il parametro host come un URL completo, includente il protocollo. Per esempio:
      host: http://docs.example.com
      Publican usa il valore impostato in host per costruire gli URL nel file XML, Sitemap, usato dai motori di ricerca e per limitare le ricerche dalla casella relativa nel menu di navigazione, soltanto ai documenti presenti nel sito.
    3. Opzionalmente, costruire un motore di ricerca da usare con la casella ricerca nel menu di navigazione, e specificare l'intero contenuto del <form> HTML con il parametro search. Se non si specifica alcun criterio di ricerca, Publican crea una ricerca basata su Google, limitando la ricerca all'host specificato nel parametro host.
      Per esempio, per costruire una ricerca basata su Yahoo!, limitatamente all'host docs.example.com, impostare:
      search: '<form target="_top" method="get" action="http://search.yahoo.com/search"> <div class="search"> <input type="text" name="p" value="" /> <input type="hidden" name="vs" value="docs.example.com" /> <input type="submit" value="###Search###" /> </div> </form>'
      Fare riferimento alla documentazione del motore di ricerca scelto, per i dettagli su come creare criteri di ricerca personalizzati.
      Se nel codice di un pulsante di ricerca, si imposta value="###Search###", Publican visualizza il termine Search sul pulsante, ovviamente tradotto in ogni lingua supportata da Publican.

      Importante — il parametro search non è validato

      Publican non controlla la validità del parametro search, ma crea il valore di questo parametro nel menu di navigazione, così come specificato. Prestare particolare attenzione nell'usare questa proprietà.
    4. Opzionalmente, impostare la lingua predefinita del sito web. Publican crea un menu di navigazione distinto e tradotto, per ogni lingua in cui si pubblica la documentazione. Comunque, se un documento non è disponibile in una particolare lingua, Publican indirizza i visitatori alla versione in lingua originale del documento. Per specificare la lingua predefinita, originale del sito, impostare il parametro def_lang con il codice linguistico relativo. Per esempio:
      def_lang: it-IT
      Impostando il parametro def_lang con il codice it-IT, i visitatori che visualizzano il menu di navigazione, per esempio in spagnolo, vengono diretti alla versione italiana del documento se non è presente una traduzione in spagnolo.
    5. Optionally, configure a dump file for the website. Publican can output an XML file that provides complete site content details for delivery of other services, such as web feeds or customised search pages. The file is updated whenever a book is installed or removed from the site, or the $ publican update_site command is run. Configure the dump, dump_file, and zip_dump parameters as follows:
      dump
      Impostare dump: 1 per abilitare la funzione di file dump. Il parametro, in modo predefinito, è impostato su 0 (disattivato).
      dump_file
      Impostare dump_file: nome per specificare il nome del file dump e la cartella in cui salvare il file. Il parametro, in modo predefinito, è impostato su /var/www/html/DUMP.xml.
      zip_dump
      Impostare zip_dump: 1 per creare anche una versione zippata del file XML. Il parametro, in modo predefinito, è impostato su 0 (disattivato).
      Fare riferimento all'Appendice E, Contenuto del file dump di un sito per una descrizione del contenuto del file dump.
  5. Creare un file vuoto di nome site_overrides.css. Se si desidera usare degli stili specifici alternativi a quelli forniti da interactive.css, aggiungere un file site_overrides.css al documento che fornisce la home page del sito — vedere la Sezione 7.2.2, «Creare, installare ed aggiornare la home page». Se non si usa uno stile specifico, il file vuoto aggiunto impedirà la comparsa dell'errore 404 sul server. Su un sistema Linux, eseguire:
    # touch /var/www/html/docs/site_overrides.css
Per dire a Publican di aggiornare la struttura del sito, eseguire:
$ publican update_site

7.2.2. Creare, installare ed aggiornare la home page

La home page generata da Publican è la pagina di localizzazione a cui sono indirizzati i visitatori dallo JavaScript del sito e che fornisce lo stile alla struttura del sito web. La home page è strutturata come un <article> DocBook ma con un parametro ulteriore web_type: home nel proprio file publican.cfg. Nella sua struttura e presentazione, la home page assomiglia ad un articolo di Publican, il cui pacchetto viene creato allo stesso modo.
  1. Usando il procedimento indicato nella Sezione 7.1.2, «Creare, installare ed aggiornare la home page», su una macchina creare una home page.
  2. Nella cartella contenente la home page creata, eseguire:
    $ publican package --binary
    Publican builds an RPM package and places it in the /tmp/rpms/noarch/ directory of the home page. By default, Publican builds the RPM package for the operating system within which you are running Publican. To build an RPM package to install on a server that runs a different operating system, set the os_ver parameter in the home page's publican.cfg file.
  3. Caricare il pacchetto sul server web ed installarlo con rpm -i o yum localinstall, oppure salvare il pacchetto in un repository e configurare il server perché possa installarlo dal repository eseguendo il comando yum install.
Per aggiornare la home page, creare un nuovo pacchetto con un numero più alto di <edition> o di <pubsnumber>, presenti in Article_Info.xml. Publican usa questi valori per impostare i numeri di versione e di release del pacchetto RPM. In tal modo, quando si installa il pacchetto sul server, yum può sostituire la versione precedente con la nuova, sia usando yum localinstall per un pacchetto locale, sia yum update per un pacchetto scaricato da un repository.

7.2.3. Creare, installare ed aggiornare pagine di prodotto e di versione

Le pagine di prodotto e le pagine di versione generate con Publican, sono pagine localizzabili che offrono una panoramica generale, rispettivamente, su un prodotto o una versione. I visitatori accedono a queste pagine cliccando su prodotto o versione nel menu di navigazione. Le pagine sono strutturate come un <article> DocBook con un ulteriore parametro web_type: product o web_type: version nel proprio file publican.cfg. Nella loro struttura e presentazione, le pagine prodotto e quelle di versione sono pressoché identiche ad ogni altro articolo prodotto con Publican, i cui pacchetti vengono creati allo stesso modo.
  1. On a workstation, create a product or version page using the procedure described in Sezione 7.1.3, «Creare, installare ed aggiornare pagine di prodotto e di versione».
  2. Nella cartella contenente la pagina prodotto o di versione, eseguire:
    $ publican package --binary
    Publican builds an RPM package and places it in the /tmp/rpms/noarch/ directory of the product page or version page. By default, Publican builds the RPM package for the operating system within which you are running Publican. To build an RPM package to install on a server that runs a different operating system, set the os_ver parameter in the publican.cfg file of the product page or version page.
  3. Caricare il pacchetto sul server web ed installarlo con rpm -i o yum localinstall, oppure salvare il pacchetto in un repository e configurare il server perché possa installarlo dal repository eseguendo il comando yum install.
Per aggiornare la pagina prodotto o di versione, creare un nuovo pacchetto con un numero più alto di <edition> o di <pubsnumber>, presenti in Article_Info.xml. Publican usa questi valori per impostare i numeri di versione e di release del pacchetto RPM. In tal modo, quando si installa il pacchetto sul server, yum può sostituire la versione precedente con la nuova, sia usando yum localinstall per un pacchetto locale, sia yum update per un pacchetto scaricato da un repository.

7.2.4. Installare, aggiornare e rimuovere documenti

Sulla workstation, spostarsi nella cartella contenente i sorgenti del documento ed eseguire:
$ publican package --binary --lang language_code
Publican builds an RPM package and places it in the /tmp/rpms/noarch/ directory of the document. By default, Publican builds the RPM package for the operating system within which you are running Publican. To build an RPM package to install on a server that runs a different operating system, set the os_ver parameter in the document's publican.cfg file.
Caricare il pacchetto sul server web ed installarlo con rpm -i o yum localinstall, oppure salvare il pacchetto in un repository e configurare il server perché possa installarlo dal repository eseguendo il comando yum install.
Per aggiornare un documento, creare un nuovo pacchetto con un numero più alto di <edition> o di <pubsnumber>, presenti in Book_Info.xml o in Article_Info.xml. Publican usa questi valori per impostare i numeri di versione e di release del pacchetto RPM. In tal modo, quando si installa il pacchetto sul server, yum può sostituire la versione precedente con la nuova, sia usando yum localinstall per un pacchetto locale, sia yum update per un pacchetto scaricato da un repository.
Rimuovere un documento dal server web, con il comando rpm -e o yum erase.
On large or busy sites, we recommend that you set the manual_toc_update parameter in the site's configuration file. With this parameter set, you must run the $ publican update_site command after installing, updating, or removing documents. Refer to Sezione 7.1.1, «Creare la struttura del sito web» for more information.

7.3. Submitting Your Sitemap to Search Engines

A Publican website includes an XML Sitemap file. The Sitemap can be submitted to many major search engines, in order to help them index your website more intelligently and thoroughly. Each search engine has its own submission procedure. This section includes documentation on how to submit a Sitemap to Google and Bing.

7.3.1. Submitting Your Sitemap to Google.

Procedura 7.1. To Submit Your Sitemap to Google:

  1. Sign up for a Google account at Google Webmaster Tools. If you already have a Google account, you can use it.
  2. Sign in to your Google Webmaster Tools account at this URL: http://www.google.com/webmasters/tools/home.
  3. First you must verify you are the owner of your Publican site. Click the Add A Site button.
  4. A dialog box is displayed for you to Add a site with. Enter the URL of your Publican site in the text entry field and click Continue.
  5. Follow the instructions that display and upload the HTML file that Google provides to the document root of your website.
  6. When you have confirmed that the provided HTML file has been uploaded to the required location by accessing it in a web browser, click the Verify button.
  7. When you have successfully verified the ownership of your Publican website to Google, return to the Webmaster Tools home page. Your Publican site is listed. Click on it.
  8. You are taken to the Webmaster Tools configuration page for your Publican site. On the left side of the page there is a menu. Click on the Site configuration menu entry to expand it. Its expanded contents includes a Sitemaps entry. Click it.
  9. You are taken to a Sitemap submission page. Click the Submit a Sitemap button.
  10. A text entry field displays, including the base URL of your Publican site, with room to enter the URL of your Sitemap XML file. Enter its location and click the Submit Sitemap button. The details of the Sitemap are displayed in a table.
  11. Result
    The Sitemap for your Publican site has been successfully submitted to Google.

7.3.2. Submitting Your Sitemap to Bing.

Procedura 7.2. To Submit Your Sitemap to Bing:

  1. Sign up for a Bing Webmaster Tools account at Bing Webmaster Tools. If you already have a Windows LiveID account, you can use it.
  2. Sign in to your Bing Webmaster Tools account at this URL: http://www.bing.com/toolbox/webmaster/.
  3. Click the Add Site button.
  4. The Add Site dialog box is displayed. Enter the URL of your Publican site in the text entry field and click Submit.
  5. The Verify Ownership dialog displays, with three options. Follow the instructions given when the Option 1: Place an XML file on your web server has been expanded. Upload the BingSiteAuth.xml file that Bing provides to the document root of your website.
  6. When you have confirmed that the provided BingSiteAuth.xml file has been uploaded to the required location by accessing it in a web browser, click the Verify button.
  7. When you have successfully verified your ownership of your Publican website to Bing, return to the Bing Webmaster Tools home page. Your Publican site is listed. Click on it.
  8. Select the Crawl tab.
  9. Select Sitemaps and then Add Feed.
  10. The Add Feed dialog displays. Enter the URL of your Sitemap file and click Submit. The details of the Sitemap are displayed.
  11. Result:
    The Sitemap for your Publican site has been successfully submitted to Bing.

Capitolo 8. Import book into Drupal

Publican 3.1 has a new functionality which allow user to create and import a book into Drupal. All xml files in a book are transformed into a single CSV file which will later be used to import into Drupal.

8.1. How to build a CSV file for Drupal import

The CSV File consists of information that tells Drupal how to import the book. Each row in the CSV file represents a html page.
Use the $ publican build command to create the CSV file for Drupal import. Before running the command, use the cd command to change into the directory where your book is located. For example, if you have a book call "User_Guide" in your home directory, then run the following command.
$ cd User_Guide/
$ publican build --langs en-US --formats=drupal-book
After running the command, you will see CSV file is created in the tmp/en-US/drupal-book/ directory.
Publican stores all the output files in /tmp/en-US/drupal-book/ directory. This directory contains the following files:
  • CSV file - The naming convention of the file is $product-$version-$docname-$lang-$edition.csv
  • en-US directory - contains all the html images.
  • tar.gz file - the archive of both CSV file and en-US directory.

Important — Use version control system

After running the $ publican build --langs en-US --formats=drupal-book command, you will notice that the xml files in the en-US directory had been changed. This is because Publican added a 'Conformance' attribute for every xml tag that has id. This attribute contains a number which is unique across xml files in the book. If you are using a version control system like git for your xml files, then you need to commit the changes so that the number won't get reset when other users run it. These unique numbers are very important, because they are use as the url path in drupal. Besides, Publican also created a database file name max_unique_id.db in the en-US directory. This database file is use to track the current maximum unique number in the book, so that Publican can know where you are up to and add a new unique number for your newly created Chapter or Section. Therefore, it is very important to add the database file to the version control and commit it if there is any change. If you add a new section in the xml, don't set the 'Comformance' attribute yourself as that will make the database outdated. Just leave it for publican to set it.

8.2. The publican.cfg file

Below are some parameters that can be configure in the publican.cfg file for Drupal import:
drupal_author
specfies the author who should be shown in drupal book page. The name must be a valid Drupal username. 'Redhat' is the default author. Set this parameter in the publican.cfg file to override it.

Important — Setting Author

The author must have permission to manage (create, update, delete) nodes in Drupal. If the default author is used, make sure you had created an account with username 'Redhat' in Drupal.
drupal_menu_title
override the bookname that will be shown in the Drupal menu. If nothing is set, publican will use the default value which is "$product $version $docname". For example, Publican 3.1 User_Guide.
drupal_menu_block
specfies which menu block the book should show in Drupal. The default value is "user-guide".

Important — Setting menu block

The menu block must exist in Drupal. For more information about adding a menu block in Drupal. Please refer to Sezione 8.3.1, «How to add a menu block».
drupal_image_path
specfies the directory where the images should be stored in drupal server. The default value is "sites/default/files/".

8.3. Drupal Import Guide

Before you can import a book, you need to install a module call 'Node Import' in Drupal. This module allows Drupal to import and update content from CSV or TSV files. To install this module, simply go to drupal site and follow the instructions on the website to download it. Once this is done, then you need to copy the downloaded module to the 'modules' directory on the Drupal server. For example if your Drupal is located in /var/www/html/drupal/ directory, then you should copy the module to /var/www/html/drupal/sites/all/modules/ directory. To enable the installed module, login to the Drupal site and go to Administer -> Site building -> Modules . In the Development section, tick the checkbox and click Save configuration button to activate the Node Import Module.

Important — Enable Drupal Core Modules

You also need to enable the following Drupal core modules:
  • Book
  • Menu
  • Path

Permission to install Module

Please consult your web adminstrator if you don't have permission to install module in drupal.

8.3.1. How to add a menu block

You can specify which menu the book should be showing in Drupal. If the specified menu block doesn't exist, Drupal will throw all the imported contents in the primary link. Therefore, if you wish to list your book in a menu block, make sure you create one before importing the book. To add a new menu block, simply login to your Drupal site and go to Administer -> Menus -> Add menu .
  • Menu name - The unique name for the menu. This is the value that you should set for the drupal_menu_block parameter in publican.cfg.
  • Title - The title of the menu. It will be displayed on top of the menu block.

8.3.2. Setting up Node import

  • Import directory - Where the CSV files to be imported are stored. The default path is sites/default/files/imports/ .
  • FTP settings
    • Allow FTP uploads - Make sure the checkbox is checked, so that the new CSV file can be auto-detected when it is uploaded into the import directory.
    • File owner - The CSV file that you uploaded to the import directory will be assigned ownership to this user.

      Important — File Ownership

      Users will only be allowed to use files they have uploaded themselves and files owned by anonymous. If you leave this field blank, all files uploaded by FTP will be owned by anonymous and so all users will see those files as being available for them. If you enter a username here, files that are uploaded using FTP will be owned by that user and only that user will be able to see those uploaded files. It is recommended to leave this field blank.
  • Allowed extensions - The allowed import file's extension. Other extensions will be ignore by the module.
  • Default settings
    • Content type - The default content type that will be used for quick import. Make sure the Book Page content type is checked.
    • First row contains column names - This tells the node import module that the first row of the csv file is the headers.

8.3.3. How to import book

Procedura 8.1. To import book into Drupal:

  1. Upload the CSV file to import Directory in the Drupal Server
  2. Upload en-US directory to the "sites/default/files/" directory in the Drupal server. This value can be overriden in the publican.cfg. For more details, please read Sezione 8.2, «The publican.cfg file»
  3. Login to the Drupal website, and go to Administer -> Content management -> Import content. You will see the CSV file that you just uploaded is showing in the 'Pending Tasks" table and it is ready to import.
  4. Click Import now to start importing book. You will be redirect to the next page which is showing the import progress. When the progress bar hit 100%, that means the import is done!
  5. The book link should be showing in the specified menu block now.

8.3.4. How to update book

Simply repeat the steps in Sezione 8.3.3, «How to import book» to update the book.

Warning — Section Chunking

If you update the book with smaller chunks, than the missing chunks will be deleted by Drupal and the URL path for the deleted chunks will be deleted as well.

Capitolo 9. Frequently Asked Questions

Domanda: Come si aggiunge una lingua ad un libro?
Domanda: What if I do not want to use the country code? For example, can I run $ publican update_po --langs=es,de,fr?
Domanda: Come si aggiornano tutti i file PO?
Domanda: Come si ottiene l'elenco completo delle opzioni di build di Publican?
Domanda: Come si ottiene l'elenco completo dei parametri configurabili nel file publican.cfg?
Domanda: Dove si trovano i file comuni di Publican?
Domanda: E' possibile includere nei tarball e nei pacchetti RPM un file qualsiasi?
Domanda: Perché Publican segnala con warning i tag sconosciuti?
Domanda: I documenti HTML vengono creati regolarmente, ma provando a creare documenti PDF, si solleva un'eccezione java.lang.NullPointerException senza produzione di file PDF. Cos'è che non va?
Domanda: Un errore segnala che Batik non è presente nel classpath eppure Batik è installato! Cos'è che non va?
Domanda: Creando un file PDF si solleva un'eccezione Exception in thread "main" java.lang.OutOfMemoryError: Java heap space. Cos'è che non va?
Domanda: Versioni precedenti di Publican rimuovevano i tag <para> vuoti. E le versioni di Publican correnti?
Domanda: Che fine ha fatto il controllo ortografico?
Domanda: Perché quando si creano file PDF, i tag <segmentedlist> non funzionano?
Domanda: Come mai, nei PDF, si altera il colore delle immagini?
Domanda: Creando un documento, si ottiene un errore del tipo ‘undefined language’ — cos'è che non va?
Domanda: Come abilitare il completamento dei comandi bash per Publican?
Domanda: Why am I having trouble building my large book?
Domanda: Perché Jeff chiama Isaac ‘Ivan’?
Domanda:
Come si aggiunge una lingua ad un libro?
Risposta:
Run $ publican update_po --langs=language, where language is the code for the new language that you want to add. You can add more than one language at a time, with the language codes separated by commas. For example, publican update_po --langs=ja-JP creates the Japanese language directory and Japanese PO files, and publican update_po --langs=ja-JP,ko-KR creates directories and PO files for both Japanese and Korean.
Domanda:
What if I do not want to use the country code? For example, can I run $ publican update_po --langs=es,de,fr?
Risposta:
Anche così il comando funziona. Tuttavia, se si omette il codice di nazione, il risultato potrebbe essere indefinito nel caso in cui Publican o un brand abbia definizioni per varietà nazionali di una lingua — come nel caso di zh-CN (cinese semplificato della Repubblica Popolare Cinese) e zh-TW (cinese tradizionale della Repubblica di Cina, o Taiwan). Anche nel caso sia definita correntemente una sola varietà linguista, è sempre opportuno includere anche il codice di nazione, cosicché un futuro aggiornamento di Publican non trasformi inaspettatamente un documento in lingua tedesca (de-DE) nel Common Content dello Schweizerdeutsch (de-CH) o svizzero tedesco.
Domanda:
Come si aggiornano tutti i file PO?
Risposta:
Run the $ publican update_po --langs=all command.
Domanda:
Come si ottiene l'elenco completo delle opzioni di build di Publican?
Risposta:
Run the $ publican build --help command.
Domanda:
Come si ottiene l'elenco completo dei parametri configurabili nel file publican.cfg?
Risposta:
Run the $ publican help_config command in a directory that holds any Publican document.
Domanda:
Dove si trovano i file comuni di Publican?
Risposta:
Per impostazione, nella directory /usr/share/publican/ nei Sistemi Operativi Linux e in %SystemDrive%/%ProgramFiles%/publican/Common_Content nei sistemi operativi Windows — tipicamente, C:/Program Files/publican/Common_Content.
Domanda:
E' possibile includere nei tarball e nei pacchetti RPM un file qualsiasi?
Risposta:
Certo. Creando una sotto-cartella denominata files nella cartella del linguaggio originale, essa viene inclusa in tutti i tarball o pacchetti SRPM creati da Publican.

Importante

La cartella files non è disponibile durante la fase di validazione, per cui non è possibile xi:include o inglobare diversamente, i file contenuti in questa cartella nell'XML.
Domanda:
Perché Publican segnala con warning i tag sconosciuti?
Risposta:
Questi warning informano che si sta usando dei tag il cui effetto non è stato testato per attrattiva, conformità a XHTML 1.0 Strict o conformità a Section 508 (Standard d'Accessibilità USA).
Domanda:
I documenti HTML vengono creati regolarmente, ma provando a creare documenti PDF, si solleva un'eccezione java.lang.NullPointerException senza produzione di file PDF. Cos'è che non va?
Risposta:
Try building a PDF version of a different document — perhaps a fresh one that you create with the $ publican create command. If the problem is not just with one particular document, you probably have a mismatch between the Java Runtime Environment (JRE) and the Java Development Kit (JDK) in use on your system. If you have a JDK installed, FOP requires that the JDK is of the same version as the JRE. Furthermore, FOP cannot use the GNU Compiler for Java (GCJ).
Eseguire alternatives --config java e alternatives --config javac per determinare la JRE e JDK in uso, poi selezionare le versioni corrispondenti e quelle prive dell'elemento gcj nel loro nome. Per esempio, la seguente configurazione Java visualizza una JRE ed una JDK corrispondente che consentono di creare file PDF:
$ alternatives --config java

There are 3 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
*  2           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
 + 3           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

Enter to keep the current selection[+], or type selection number:
$ alternatives --config javac

There are 3 programs which provide 'javac'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/javac
   2           /usr/lib/jvm/java-1.6.0-openjdk/bin/javac
   3           /usr/lib/jvm/java-1.5.0-gcj/bin/javac

Enter to keep the current selection[+], or type selection number:
Potrebbe essere necessario installare una JDK extra, nel caso non sia presente una JDK corrispondente alle versioni JRE presenti.
Alcune installazioni Java non configurano correttamente gli ambienti con il comando alternatives. Per questo problema non è stata determinata una soluzione.
Domanda:
Un errore segnala che Batik non è presente nel classpath eppure Batik è installato! Cos'è che non va?
Risposta:
Si ritiene che ciò sia dovuto a problemi di classpath causati dall'utilizzo di differenti versioni di JRE e JDK. Fare riferimento alla domanda precedente di questa FAQ, riguardante l'eccezione java.lang.NullPointerException ed usare il comando alternatives per assicurarsi di avere JRE e JDK corrispondenti.
Domanda:
Creando un file PDF si solleva un'eccezione Exception in thread "main" java.lang.OutOfMemoryError: Java heap space. Cos'è che non va?
Risposta:
The default memory allocated for Java is not big enough to build your PDF. You need to increase the memory allocated to FOP. Before running $ publican build run echo "FOP_OPTS='-Xms50m -Xmx700m'" > ~/.foprc. This sets the initial heap space to 50 MB and allows it to grow to a maximum of 700 MB.
Domanda:
Versioni precedenti di Publican rimuovevano i tag <para> vuoti. E le versioni di Publican correnti?
Risposta:
No. Publican nel passato, rimuoveva i tag <para> vuoti durante la trasformazione dei file XML, in quanto i tag <para> vuoti creavano problemi agli strumenti di traduzione usati in precedenza in Red Hat e nel Fedora Project. Tag <para> vuoti, sono tag validi in DocBook XML ed ora non vengono più rimossi da Publican.
Domanda:
Che fine ha fatto il controllo ortografico?
Risposta:
Precedenti versioni di Publican (fino alla versione 0.45, inclusa) eseguivano un controllo ortografico durante la trasformazione dei file XML. In seguito ai giudizi negativi degli utenti, questa funzione è stata rimossa.
Eseguire il seguente script bash nella cartella radice del documento, per controllare l'ortografia nei file XML con aspell, un controllore ortografico da riga di comando.
#!/bin/sh
# Jeff Fearn 2010

ASPELL_EXCLUDES=programlisting,userinput,screen,filename,command,computeroutput,abbrev,accel,orgname,surname,foreignphrase,acronym,hardware

for file in `find en-US -wholename '*/extras/*' -prune -o -name \*.xml -print`; do
	echo "Processing $file";
	aspell --list --lang=en-US --mode=sgml --add-sgml-skip={$ASPELL_EXCLUDES} < $file  | sort -u;
	echo;
done


Domanda:
Perché quando si creano file PDF, i tag <segmentedlist> non funzionano?
Risposta:
Contare il numero di colonne presenti nei tag <segmentedlist>. Se i <segmentedlist> sono formattati come tabelle, l'XSL di DocBook limita il numero delle colonne a due soltanto, e Publican formatta i <segmentedlist> come tabelle.
Domanda:
Come mai, nei PDF, si altera il colore delle immagini?
Risposta:
Ciò è dovuto ad un bug in FOP che distorce i colori nelle immagini PNG a 24-bit. Convertire le immagini, in immagini PNG a 32-bit per circuire questo problema.
Domanda:
Creando un documento, si ottiene un errore del tipo ‘undefined language’ — cos'è che non va?
Risposta:
In Publican l'evidenza del codice è generato con il modulo Perl, Syntax::Highlight::Engine::Kate. Se in un tag <programlisting> si specifica un linguaggio non riconosciuto da Syntax::Highlight::Engine::Kate, in fase di creazione del libro si riceve un errore. Le prime righe del messaggio d'errore sono simili a:
undefined language: JAVA at /usr/lib/perl5/vendor_perl/5.10.0/Syntax/Highlight/Engine/Kate.pm
line 615.
cannot create plugin for language 'JAVA'
Notare che il modulo Syntax::Highlight::Engine::Kate è molto rigoroso con i nomi dei linguaggi ed è case sensitive. Quindi, <programlisting language="Java"> funziona, ma <programlisting language="java"> e <programlisting language="JAVA"> non funzionano. Il messaggio d'errore specifica il problema relativo all'attributo del linguaggio.
Refer to http://search.cpan.org/dist/Syntax-Highlight-Engine-Kate/lib/Syntax/Highlight/Engine/Kate.pm#PLUGINS for the full list of languages that Syntax::Highlight::Engine::Kate supports, including their expected capitalization and punctuation.
Domanda:
Come abilitare il completamento dei comandi bash per Publican?
Risposta:
Supporto al completamento dei comandi bash è una nuova funzionalità presente in Publican 2.2. Per abilitarla:
  1. Installare il pacchetto o i pacchetti che offrono il completamento dei comando bash per il proprio sistema operativo. Per esempio, in Fedora, eseguire il comando sudo yum install bash-completion.
  2. Aggiungere al proprio file ~/.bashrc:
    # Use bash-completion, if available
    if [ -f /etc/bash_completion ]; then
            . /etc/bash_completion
    fi
    
  3. Riavviare il terminale o eseguire source ~/.bashrc.
Domanda:
Why am I having trouble building my large book?
Risposta:
Probably because the kernel can deal with only a certain number of file handles at a time, and you have exceeded that number. On some linuxes you can run ulimit -n 8192 to change the limit for the current shell.
To make this permanent, open /etc/security/limits.conf and add these two lines:
*                 soft    nofile          8192
*                 hard    nofile          8192
Then save, and log in again for the changes to take effect.
Domanda:
Perché Jeff chiama Isaac ‘Ivan’?
Risposta:
Perché la memoria di Jeff è in mutande!

Elementi ed attributi non permessi

Supportato, non supportato e non permesso

Non tutti gli elementi (tag) ed attributi che funzionano con Publican sono supportati. Nello specifico, non tutti i tag sono stati testati riguardo agli effetti sulla presentazione di un documento in formato HTML o PDF.
Publican funziona con quasi tutti gli elementi e relativi attributi di DocBook 4.5, la maggior parte dei quali sono supportati. Gli elementi ed attributi supportati sono quelli la cui presentazione in HTML e PDF di Publican sono stati testati e conservano un livello di qualità accettabile.
Altri elementi ed attributi non riconosciuti dannosi o ridondanti, ma che non sono stati testati per qualità sono non supportati. Se il contenuto all'interno di un particolare tag DocBook non viene visualizzato correttamente in un documento HTML o PDF, il problema può derivare da una mancanza di test sulla logica di trasformazione del relativo tag. Provare a ricreare il documento e controllare l'output generato da Publican durante la creazione del documento. Publican presenta avvisi sui tag non supportati man mano che vengono elaborati i file XML.
Infine, un ristretto gruppo di elementi ed attributi sono non permessi. Questi elementi ed attributi sono elencati in basso, accompagnati da una spiegazione del motivo del divieto.
Use the command $ publican print_known to print a list of tags that Publican supports, and the command publican print_banned to print a list of tags that are banned in Publican.

A.1. Elementi non permessi

<caution>, <tip>
DocBook XML supporta cinque tipi di avvisi per vari di livelli di severità: <tip>, <note>, <important>, <caution> e <warning>. Complessivamente, essi rappresentano un insieme di distinzioni a grana molto fine. E' improbabile che queste sottili distinzioni possano applicarsi consistentemente in un documento, in specie quando un documento è redatto o mantenuto da più persone. Inoltre, questo livello di granularità può sembrare insignificante ai lettori. Per progetto, Publican disabilita gli elementi <tip> e <caution>, essendo gli elementi più ridondanti del gruppo.
Usare <note> invece di <tip>, ed usare <important> o <warning> invece di <caution>. Alcuni criteri, in base ai quali selezionare i livelli di severità sono indicati nella sezione ‘Convenzioni del Documento’ della Prefazione dei libri prodotti con il brand predefinito di Publican.
<entrytbl>
Publican dipende da un'applicazione esterna, FOP, per rendere documenti PDF. Al momento, FOP non supporta l'annidamento delle tabelle (nested tables), quindi ogni tentativo di creare file PDF da documenti Publican contenenti tabelle annidate fallisce.
L'annidamento delle tabelle è perciò vietato almeno fino a quando non supportato in FOP. Se si prevede di includere una tale tabella, si riconsideri di ristrutturare la struttura dei dati.
<glossdiv>, <glosslist>
Questo tag presenta i termini nei glossari in ordine alfabetico; tuttavia, i termini vengono ordinati secondo la lingua originale dell'XML, a prescindere se i termini siano tradotti in altre lingue. Per esempio, un glossario prodotto con <glossdiv> che in lingua inglese appare come:
A
Apple — an apple is…
G
Grapesgrapes are…
O
Orange — an orange is…
P
Peach — a peach is…
in italiano appare come:
A
Mela — una mela è…
G
Uva — l'uva è…
O
Arancia — un'arancia è…
P
Pera — la pera è…
Quindi tradotto in una lingua che non condivide lo stesso sistema di scrittura della lingua originale in cui è redatto l'XML, il risultato del tag è privo di senso.
<inlinegraphic>
Questo elemento presenta le informazioni contenute in un oggetto grafico, privo di una opzione per una presentazione alternativa in modalità testuale. Perciò questo tag limita l'accesso alle informazioni alle persone con ridotte capacità visive. Negli Stati in cui vige una legislazione che garantisce l'accessibilità ai contenuti elettronici alle persone con ridotte capacità visive, i documenti contenenti questo tag quindi non soddisfano queste richieste. La Section 508 del Rehabilitation Act of 1973[4] è un esempio di tali richieste predisposte alle Agenzie Federali degli Stati Uniti d'America.
Notare che il tag <inlinegraphic> non è valido in DocBook versione 5.
<link>
Il tag <link> offre un generico collegamento ipertestuale e quindi nulla di più dei tag <xref> e <ulink>, rispettivamente, per collegamenti interni ed esterni. Quindi il tag <link> è disabilitato per ridondanza.
<olink>
Il tag <olink> offre riferimenti tra documenti XML. Per usare il tag <olink> per riferimenti ai documenti esterni facenti parte della stessa libreria di file XML, occorre fornire l'URL del documento da collegare. In ambienti che usano il tag <olink>, questi URL possono essere forniti sia con entità XML sia con script server-side. Publican produce documenti di vasta diffusione in cui gli URL sono sempre indispensabili per riferimenti incrociati. Quindi, il tag <olink> non offre alcun vantaggio sul tag <ulink> e perciò per ridondanza, è disabilitato.

A.2. Attributi non permessi

<[element] xreflabel="[ogni_altra_stringa]">
La presenza di un attributo <xreflabel> riduce l'usabilità delle versioni stampate di un libro. Inoltre, i valori dell'attributo non sono visibili ai traduttori, e perciò non sono traducibili.
Per esempio, il seguente pezzo:
<chapter id="ch03" xreflabel="Chapter Three">
\t<title>The Secret to Eternal Life</title>
\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]     

…see <xref linkend="ch03"> for details.

durante la trasformazione in HTML del file XML, il tag <xref> diventa un tag anchor, come indicato di seguito:
…see <a href="#ch03">Chapter Three</a> for details.

Il testo contenuto nel tag anchor coincide con quello nell'attributo <xreflabel>. In questo caso, ciò vuol dire che i lettori delle versioni stampate hanno una perdita di informazione.
Per evitare questo problema si può far coincidere il valore dell'attributo <xreflabel> con il testo contenuto tra i tag <title></title>. Tuttavia questa duplicazione aumenta il rischio di errori di battitura, senza in effetti alcun miglioramento. E riduce anche la quantità di informazione presentata ai lettori delle copie stampate.
Il seguente XML:
<chapter id="ch03" xreflabel="The Secret to Eternal Life">
\t<title>The Secret to Eternal Life</title>
\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]     

…see >xref linkend="ch03"> for details.

viene trasformato in tag anchor HTML come segue:
…see <a href="#ch03">The Secret to Eternal Life</a> for details.

Ciò non è così informativo come il testo presentato senza usare l'attributo <xreflabel>. Il seguente:
<chapter id="ch03">
\t<title>The Secret to Eternal Life</title>
\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]\t\t

…see <xref linkend="ch03"> for details.

trasforma l'elemento <xref> come segue in formato HTML:
…see <a href="#ch03">Chapter 3: The Secret to Eternal Life</a> for details.

Comunque, ancora più importanti, sono i problemi di traduzione causati dal tag <xreflabel>. I valori degli attributi non sono visibili ai traduttori. Di conseguenza, non possono essere tradotti. Si consideri di nuovo il secondo esempio, di cui sopra:
<chapter id="ch03" xreflabel="The Secret to Eternal Life">
\t<title>The Secret to Eternal Life</title>
\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]\t\t

…see <xref linkend="ch03"> for details.

In inglese, <xref> è ancora trasformato in un tag anchor come segue:
…see <a href="#ch03">The Secret to Eternal Life</a> for details.

Mentre i lettori della versione in lingua tedesca, visualizzeranno il seguente HTML:
…Sehen Sie <a href="#ch03">The Secret to Eternal Life</a> für Details.

Rimuovendo l'attributo <xreflabel>, i tag del titolo e del capitolo, appaiono propriamente tradotti al lettore. Cioè il seguente pezzo:
<chapter id="ch03">
\t<title>The Secret to Eternal Life</title>
\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]\t\t

…see <xref linkend="ch03"> for details.

per una traduzione in lingua tedesca, viene visualizzato come:
…Sehen Sie <a href="#ch03">Kapitel 3: Das Geheimnis des ewigen Lebens</a> für Details.

E ciò, senza meravigliarsi più di tanto, è ciò che si vuole ottenere!
Quindi l'attributo xreflabel è vietato.
<[element] endterm="[any_string_here]">
L'attributo endterm permette di presentare il testo relativo all'ipertesto con un nome diverso dalla sezione o capitolo cui punta il collegamento. E ciò riduce l'usabilità della versione stampata del documento e genera difficoltà anche ai traduttori.
Il testo presentato in un elemento (come un <xref>), contenente l'attributo endterm è ricavato dal tag <titleabbrev> nel capitolo o sezione target. Sebbene il contenuto del tag <titleabbrev> sia traducibile nei file PO del documento, esso viene di fatto rimosso dal contesto del tag <xref>. L'assenza di questo contesto rende praticamente impossibile la traduzione di articoli e preposizioni, preservando genere e numero.
Per esempio, il seguente pezzo:
<chapter id="The_Secret">
\t<title>The Secret to Eternal Life</title>
\t<titleabbrev id="final">the final chapter</titleabbrev>

\t<para>The secret to eternal life is…</para>
</chapter>

[more deathless prose here]     

The solution is in <xref linkend="The_Secret" endterm="final"/>.

Come si vede, il testo che precede il tag <xref> presente nella versione inglese del documento è:
The solution is in the final chapter.
Un traduttore vede il tag <titleabbrev> nel file PO come:
#. Tag: titleabbrev
#, no-c-format
msgid "the final chapter"
msgstr ""

e vede il testo contenuto in <xref> in qualche altra parte del file PO (o, addirittura in un PO completamente diverso), come:
#. Tag: para
#, no-c-format
msgid "The solution is in <xref linkend="The_Secret" endterm="final"/>."
msgstr ""

Il traduttore non ha idea di come verrà sostituito il tag <xref linkend="The_Secret" endterm="final"/> durante la creazione del documento, per cui una traduzione in italiano potrebbe leggersi come:
#. Tag: para
#, no-c-format
msgid "The solution is in <xref linkend="The_Secret" endterm="final"/>."
msgstr "La soluzione è in <xref linkend="The_Secret" endterm="final"/>."

Notare la preposizione in.
Se il traduttore di lingua italiana traduce the final chapter in l'ultimo capitolo, il documento risultante si leggerebbe come:
La soluzione è in l'ultimo capitolo.
Il risultato è comprensibile, ma poco elegante, per l'assenza di combinazione tra preposizione ed articolo. Una traduzione più elegante sarebbe stata:
La soluzione è nell'ultimo capitolo.
Senza conoscere il testo che compare al posto di <xref linkend="The_Secret" endterm="final"/>, il traduttore in italiano non sa se usare la preposizione in invariata, o una delle sette possibili combinazioni con l'articolo determinativo: nel, nei, nello, nell', negli, nella o nelle.
Inoltre, notare che la combinazione della preposizione con l'articolo pone anche una problema se inserire la preposizione articolata nel tag <xref> o nel tag <titleabbrev>. E comunque qualunque sia la soluzione scelta dal traduttore, ulteriori problemi si verificano quando l'endterm è presente in altri contesti grammaticali, poiché sarebbe richiesta un'altra preposizione articolata.
A causa di queste difficoltà, in fase di traduzione di endterm, Publican non permette l'uso di questo attributo.


[4] Fare riferimento a http://www.section508.gov/

Sommario dei comandi

Opzioni di comando

$ publican --help
visualizza l'help
$ publican --man
visualizza le pagine di man relative
$ publican --help_actions
visualizza l'elenco delle azioni
$ publican --v
viusalizza il numero di versione di Publican
--config file
specifica un file di configurazione per un documento, in alternativa al file publican.cfg, predefinito
--nocolours
disabilita la colorazione ANSI nei messaggi di log di Publican
--quiet
disables all logging.

Azioni

$ publican add_revision
adds an entry in Revision_History.xml. Options:
--lang=LANG
the language the XML will be written in.
--revnumber=REVNUMBER
revision number to use for a revision.
--date=DATE
date to use for a revision.
--member=MEMBER
an entry to be added to the revision. Can be specified multiple times.
--firstname=FIRSTNAME
firstname to use for a revision.
--surname=SURNAME
surname to use for a revision.
--email=EMAIL
email to use for a revision.
$ publican build
trasforma gli XML in un documento. Opzioni:
--help
display help message.
--config=s
use a nonstandard config file.
--common_config=s
override path to Common_Config directory.
--common_content=s
override path to Common_Content directory.
--nocolours
disable ANSI colorization of logging.
--quiet
disable all logging.
--brand_dir=s
directory to source brand files from.
--formats=FORMATS
comma-separated list of formats to build. For example: html,pdf,html-single,html-desktop,txt,epub (mandatory).
--langs=LANGS
comma-separated list of languages to build. For example: en-US,de-DE,all (mandatory).
--publish
imposta per pubblicazione il contenuto creato
--embedtoc
inserisce la tabella dei contenuti in una presentazione HTML
--novalid
salta il controllo di vaidità DTD durante la creazione di un documento
--src_dir=SRC_DIR
specifies the directory to source Publican files from.
--pdftool=s
Override the tool to use when creating PDFs. Valid options are wkhtmltopdf and fop.
--pub_dir=PUB_DIR
Override the directory to publish files to. Defaults to 'publish'.
$ publican clean
rimuove le cartelle temporanee dalla cartella di un documento
$ publican clean_ids
indenta ordinatamente i file XML e ricrea gli ID degli elementi
$ publican clean_set
rimuove le copie locali di libri remoti, parte di un set
$ publican create
crea un nuovo libro, articolo o set. Opzioni:
--name
il nome del documento (necessario)
--product
il prodotto documentato
--version
la versione del prodotto documentato
--edition
l'edizione del documento
--brand
il brand per il documento
--lang
la lingua in cui gli XML verranno redatti
--type
il tipo di documento — article, book, o set
$ publican create_brand
crea un nuovo brand. Opzioni:
--name
il nome del documento (necessario)
--lang
la lingua in cui gli XML verranno redatti
publican create_site
crea un sito web di documentazione. Opzioni:
--site_config
il nome del file di configurazione del sito da creare (necessario)
--db_file
il nome del file di database del sito da creare (necessario)
--toc_path
percorso alla cartella in cui creare il file toc.html di primo livello (necessario)
--tmpl_path
percorso alla cartella template (/usr/share/publican/templates, per impostazione)
$ publican help_config
visualizza l'elenco dei parametri per il file publican.cfg
publican install_book
installa un documento sul sito web di documentazione
--site_config
il nome del file di configurazione del sito (necessario)
--lang
la lingua del documento da installare (necessario)
$ publican install_brand
configura un brand per installazione. Opzioni:
--path
percorso ai file Common Content di Publican. Per impostazione predefinita, /usr/share/publican/Common_Content nei Sistemi Operativi Linux e %SystemDrive%/%ProgramFiles%/Publican/Common_Content nei sistemi operativi Windows — tipicamente, C:/Program Files/Publican/Common_Content
$ publican lang_stats
genera un rapporto di traduzione per una lingua
--langs
una lista di lingue, separate da virgole
$ publican migrate_site
migrates a website database from Publican 2.x to Publican 3. Options:
--site_config=site_config
website configuration file to use or create.
$ publican package
crea il pacchetto di un documento o di un brand, per distribuzione. Opzioni:
--lang
la lingua in cui creare il pacchetto (necessario per documenti, irrilevante per brand)
--desktop
specifica che il pacchetto RPM di un documento è creato per uso desktop (irrilevante per brand)
--brew
invia il pacchetto al sistema di compilazione Brew (irrilevante al di fuori di Red Hat)
--scratch
usato unsieme all'opzione --brew per specificare uno scratch build (irrilevante al di fuori di Red Hat)
--short_sighted
crea il pacchetto RPM privo del numero di versione di prodotto nel nome di file dell'RPM
--binary
crea il pacchetto RPM binario invece del pacchetto SRPM sorgente
publican print_banned
visualizza l'elenco dei tag DocBook non permessi da Publican
publican print_known
visualizza l'elenco dei tag DocBook supportati da Publican.
$ publican print_tree
viusalizza la struttura ad albero dei file XML di un documento
publican print_unused
prints a list of the XML files not included with the <xi:include> tag in a book, article, or set.
publican print_unused
prints a list of the image files not referenced by an <imagedata> tag in a book, article, or set.
publican remove_book
rimuove un documento da un sito web di documentazione
--site_config
il nome del file di configurazione del sito (necessario)
--lang
il documento in lingua da rimuovere (necessario)
$ publican rename
rinomina un documento. Opzioni:
--name
il nuovo titolo per il documento
--product
il nuovo prodotto cui si riferisce il documento
--version
la nuova versione di prodotto cui si riferisce il documento
publican site_stats --site_config=nome_del_file_di configurazione_del_sito
genera un report statistico di un sito per documentazione. Opzione
--site_config
il nome del file di configurazione del sito (necessario)
$ publican update_pot
aggiorna i file POT in un documento
$ publican update_po
aggiorna i file PO in un documento
--langs
lista delle lingue, separate da virgole, da aggiornare o ‘all’ per aggiornare tutte le lingue (necessario)
--msgmerge
use gettext's msgmerge for POT/PO merging.
publican update_site --site_config=nome_del_file_di_configurazione_del_sito.cfg
rigenera il contenuto modellato di un sito di documentazione. Opzione:
--site_config
il nome del file di configurazione del sito (necessario)

B.1. Comandi interni

Publican usa internamente i comandi di questa sezione. Normalmente non occorre eseguirli direttamente.
publican update_db -add
Aggiunge le voci al database di un sito web generato da Publican, con le seguenti opzioni:
--site_config
il nome del file di configurazione del sito
--lang
la lingua di pubblicazione del documento
--formats
un elenco di formati, separati da virgole, in cui pubblicare il documento, per esempio, pdf,html-single
--name
il titolo del documento
--name_label
il titolo del documento, come dovrebbe apparire nelle tabelle dei contenuti del sito.
--product
il prodotto descritto dal documento
--product_label
il prodotto descritto dal documento, come dovrebbe apparire nelle tabelle dei contenuti del sito.
--version
la versione del prodotto documentato
--version_label
la versione del prodotto descritto dal documento, come dovrebbe apparire nelle tabelle dei contenuti del sito.
--subtitle
il sottotitolo del documento
--abstract
l'abstract del documento
Per esempio:
publican update_db --add --lang en-US --formats html,pdf --name Foo \
--name_label "foo is good" --version 0.1 --version_label UNUSED \
--product Bar --product_label "To the bar" \
--subtitle "A guide to Bar Foo" \
--abstract "There once was a Foo from Bar ..." \
--site_config /usr/share/bar/foo.cfg
publican update_db --del
rimuove le voci dal database di un sito web generato da Publican, con le seguenti opzioni:
--site_config
il nome del file di configurazione del sito
--lang
la lingua di pubblicazione del documento
--name
il titolo del documento
--product
il prodotto descritto dal documento
--version
la versione del prodotto documentato
Per esempio:
publican update_db --del --lang en-US --name Foo --version 0.1 --product Bar \
--site_config /usr/share/bar/foo.cfg

Parametri di publican.cfg

Ogni libro, articolo, documento, set o brand ha un file publican.cfg nella propria cartella radice. I parametri che possono essere configurati nel file publican.cfg sono:
docname
il nome del documento, impostato con l'opzione --name
version
la versione del prodotto, impostata con l'opzione --version
xml_lang
la lingua dei file XML sorgenti, impostata con l'opzione --lang
edition
il numero di edizione della documentazione, impostato con l'opzione --edition
type
il tipo di documento — un <article>, <book> o <set> DocBook, impostato con l'opzione --type
brand
il brand del documento, impostato con l'opzione --brand
product
il prodotto a cui è rivolta la documentazione, impostato con l'opzione --product
arch
l'architettura hardware del computer per il documento
books
una lista di book, separati da virgole, parte di un set remoto
brew_dist
il target usato per compilare il pacchetto RPM desktop in Brew. (Per impostazione: docs-5E)
bridgehead_in_toc
specifica se includere bridgehead nelle tabelle dei contenuti. (Per impostazione: 0bridgehead non sono inclusi)
chunk_first
specifica se visualizzare la prima sezione sulla stessa pagina del parent nelle presentazioni in HTML. (Per impostazione: 0 — la prima sezione inizia su una nuova pagina HTML)
chunk_section_depth
il livello a partire da cui le sottosezioni sono visualizzati su una stessa pagina, nelle presentazioni HTML. (Per impostazione: 4)
classpath
il percorso ai file jar indispensabili a FOP. (Per impostazione, nei Sistemi Oprativi 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
il percorso all'installazione di Publican. (Per impostazione nei Sistemi Operativi Linux: /usr/share/publican; nei sistemi operativi Windows: %SystemDrive%/%ProgramFiles%/publican — solitamente C:/Program Files/publican)
common_content
il percorso ai file Common Content di Publican. (Per impostazione nei Sistemi Operativi Linux: /usr/share/publican/Common_Content: nei sistemi operativi Windows: %SystemDrive%/%ProgramFiles%/publican/Common_Content — solitamente C:/Program Files/publican/Common_Content)
condition
condizioni di filtraggio degli XML prima della trasformazione
confidential
contrassegna un documento come confidenziale. (Per impostazione: 0 — non confidenziale)
confidential_text
imposta il testo con cui contrassegnare come confidenziale un documento. (Per impostazione: CONFIDENTIAL)
debug
specifica se visualizzare il messaggi di debug generati da Publican. (Per impostazione: 0 — messaggi disabilitati)
def_lang
la lingua predefinita per il sito web gestito via Publican. Le tabelle dei contenuti, per le altre lingue, sono collegate ai documenti in lingua predefinita in assenza di traduzioni. (Per impostazione: en-US — inglese degli Stati Uniti d'America)
doc_url
URL del team di documentazione del pacchetto. (Per impostazione: https://fedorahosted.org/publican)
dt_obsoletes
un pacchetto che il pacchetto desktop rende obsoleto
dt_requires
un pacchetto richiesto dal pacchetto desktop, per esempio, un pacchetto di menu del desktop, per documentazione. Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
dtdver
la versione del DTD (Document Type Definition) di DocBook XML su cui si basa il progetto. (Per impostazione: 4.5)
dtd_type
Override Type for DocType. Must be a complete string.

Nota

This parameter is only permitted in a brand.
dtd_uri
Override URI for DocType. Must be a complete string.

Nota

This parameter is only permitted in a brand.
ec_id
l'ID del plugin d'aiuto di Eclipse. (Per impostazione: prodotto.nomedoc)
ec_name
il nome del plugin d'aiuto di Eclipse. (Per impostazione: prodotto nomedoc)
ec_provider
il nome del fornitore del plugin d'aiuto di Eclipse. (Per impostazione: Publican-versione Publican)
extras_dir
the directory Publican will process extra files from. (Default: extras)
generate_section_toc_level
il livello di profondità delle sezioni per cui generare una tabella di contenuti. (Per impostazione: 0 — nessun indice nelle sezioni)
ignored_translations
traduzioni da ignorare
img_dir
the directory Publican will process images from. (Default: images)
mainfile
override the default Info file. Use the full filename without the path.
license
la licenza usata dal pacchetto. (Per impostazione: GNU Free Documentation License)
mainfile
il nome del file XML contenente il nodo XML radice di <article>, <book> o <set>, ed il nome del file .ent corrispondente, che contiene le entità del documento. Per esempio, se si imposta mainfile: master, Publican cerca il nodo XML radice in master.xml e le entità del documento in master.ent.
Se mainfile non è impostato, Publican cerca il nodo XML radice in un file che corrisponde al <title> del documento in Article_Info.xml, Book_Info.xml o Set_Info.xml, e poi cerca le entità in un file con il nome corrispondente.
max_image_width
la larghezza massima consentita alle immagini nel documento, se non specificato diversamente con il tag <imagedata> per una certa immagine. (Per impostazione: 444 — larghezza di 444 pixel)

Importante — 444 pixel è la massima larghezza di sicurezza

Non usare il parametro max_image_width se le immagini contengono importanti informazioni. Le immagini più larghe di 444 pixel potrebbero presentarsi male nei documenti HTML e PDF e rendersi inusabili, in quanto superando i margini esse verrebbero rappresentate incomplete.
Viceversa, le immagini più larghe di 444 pixel che vengono scalate in un browser web o in un visualizzatore PDF, perdono in qualità.
Per preservare la qualità delle immagini, si raccomanda di tagliare o scalare le immagini ad una larghezza inferiore a 444 pixel, prima di includerle in un documento.
menu_category
la categoria del desktop menu (come definito dal file .menu corrispondente), in cui far comparire un documento quando installato da un pacchetto RPM per desktop. Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
src_url
the operating system for which to build packages.
prod_url
URL del prodotto cui si applica il documento. (Per impostazione: https://fedorahosted.org/publican)
release
il numero di release del pacchetto. (Per impostazione: il valore in xml_lang, ricavato dal tag title in xml_lang/TYPE_Info.xml o Project-Id-Version in lang/TYPE_Info.po)
repo
il repository da cui scaricare libri remoti, parte di un set distribuito.
release
override the default Revision History file. Use the full filename without the path.
scm
il sistema controllo di versione usato nel repository che contiene i libri remoti, parte di un set distribuito. (Per impostazione: SVN)
show_remarks
specifica se visualizzare gli avvisi nelle presentazioni. (Per impostazione: 0 — avvisi non visibili)
os_ver
override the default sort weighting for books in a Publican website. Defaults to 50.
src_url
URL in cui trovare i tarball dei file sorgenti
tmp_dir
la cartella di output di Publican. (Per impostazione: tmp)
--toc_path
path to the directory in which to create the top-level toc.html file (mandatory).
toc_section_depth
la profondità di livello delle sezioni incluse nella tabella dei contenuti. (Per impostazione: 2)
--tmpl_path
path to the template directory (by default, /usr/share/publican/templates).
web_brew_dist
il target di compilazione brew da usare per il pacchetto RPM web. (Per impostazione: docs-5E)
web_formats
un elenco di formati, separati da virgole, da includere nel pacchetto RPM per web. Vedere la Sezione 4.8.2, «The $ publican package command».
web_home
specifica che il documento è la home page di un sito di documentazione, non un documento standard

Importante — web_home è deprecato

In Publican 2.2, web_home è sostituito da web_type: home. Supporto a web_home sarà interrotto in future versioni di Publican.
web_name_label
sostituisce il nome di book che appare nel menu di un sito web gestito da Publican
web_obsoletes
pacchetti resi obsoleti dal pacchetto RPM web
web_product_label
sostituisce il nome di prodotto che appare nel menu di un sito web gestito da Publican
web_type
specifica che il documento è un contenuto descrittivo di un sito web gestito da Publican e non una documentazione di prodotto. Questo contenuto include la home page del sito (web_type: home), pagine descrittive di prodotto (web_type: product) e di versione (web_type: version). Vedere il Capitolo 7, Creare un sito web con Publican.
web_version_label
sostituisce il numero di versione che appare nel menu di un sito web gestito da Publican
wkhtmltopdf_opts
Extra options to pass to wkhtmltopdf. e.g. wkhtmltopdf_opts: "-O landscape -s A3"

Alphabetical index of publican.cfg parameters

publican.cfg parameters

arch
filters output by computer architecture. For example, if you set arch: x86_64 in the publican.cfg file, Publican will only include XML elements tagged with the equivalent attribute, such as <para arch="x86_64">.

Use with caution

As with conditional tagging more generally, arch can cause great difficulties when translating documents. Refer to Sezione 4.9.1, «Tagging condizionale e traduzione» for an explanation of the issues.

arch set for root nodes

If the root node of an XML file is excluded by the arch attribute, your document will not build, because empty files are not valid XML. For example, if Installation_and_configuration-PPC.xml contains a single chapter:
<?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>

and this chapter is included in User_Guide.xml with an <xi:include> tag, the document will not build with $ condition: x86 set in the publican.cfg file.
To exclude this chapter, add the arch attribute to the <xi:include> tag in User_Guide.xml, not to the <chapter> tag in Installation_and_configuration-PPC.xml.

xrefs and the arch attribute

If an <xref> points to content not included in the build due to the arch attribute, the build will fail. For example, with arch: x86 set in the publican.cfg file, $ publican build --formats=pdf --langs=en-US will fail if the book has the tag <xref linkend="Itanium_installation"> pointing to <section id="Itanium_installation" arch="IA64">.
books
specifies a space-separated list of books used in a remote set. Refer to Sezione 6.2, «Set distribuiti» for more information on distributed sets.
brand
sets the brand of the document, for example, RedHat, fedora, JBoss, oVirt or GIMP , as set by the --brand option for $ publican create. If you do not specify a brand, Publican uses its default brand. Refer to Capitolo 5, Branding for more information.
brew_dist
specifies the build target to use for building the desktop RPM package in Brew, Red Hat's internal build system. This parameter defaults to docs-5E. Refer to Sezione 4.8.2, «The $ publican package command» and Sezione 5.4, «Creare il pacchetto di un brand» for more information on building RPM packages.
bridgehead_in_toc
specifies whether the contents of <bridgehead> elements (free-floating titles) should be included among other titles (such as section titles and chapter titles) in tables of contents. To enable this feature, set bridgehead_in_toc: 1. Otherwise, the parameter defaults to 0, and <bridgehead>s are not included in tables of contents.
chunk_first
controls whether the first section should appear on a new page when rendered in HTML. To make the first section appear on a new HTML page, set this parameter to chunk_first: 1. Otherwise, the parameter defaults to 0, and the first section appears on the same page of its chapter.
chunk_section_depth
controls the section depth at which Publican no longer splits sub-subsections onto a new page when rendering HTML. By default, this value is set to 4.

Esempio D.1. Controlling the section depth with chunk_section_depth

chunk_section_depth: 0
no section split. All sections with their sub-sections appear on the same page of the chapter they belong. The page succession is chapter 1, chapter 2, chapter 3, …
chunk_section_depth: 1
the split is at "level 1" section. Each level section one with its sub-sections, appear on a new page. The page succession is chapter 1, 1.2, 1.3, 1.4 … chapter 2, 2.1, 2.2, 2.3 …
chunk_section_depth: 2
the split is at "level 2" section. The page succession is chapter 1, 1.2, 1.2.2, 1.2.3, 1.2.4 … 1.3, 1.3.2, 1.3.3 …
chunk_section_depth: 3
the split is at "level 3" section. The page succession is chapter 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 …
chunk_section_depth: 4 (default)
the split is at "level 4" section. The page succession is chapter 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
sets the path to the Java archive (jar) files for FOP. Publican relies on Apache FOP — a Java application — to render documents as PDF files. The default path for FOP's jar files on a computer with a Linux operating system is: /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
sets the path to the Publican installation. The default location on a computer with a Linux operating system is /usr/share/publican. On a computer with a Windows operating system, the default location is %SystemDrive%/%ProgramFiles%/publican — most usually C:/Program Files/publican.
common_content
sets the path to the Publican common content files. These files provide default formatting, plus some boilerplate text and generic graphics. The default location on a computer with a Linux operating system is /usr/share/publican/Common_Content. On a computer with a Windows operating system, the default location is %SystemDrive%/%ProgramFiles%/publican/Common_Content — most usually C:/Program Files/publican/Common_Content.
condition
specifies conditions on which to prune XML before transformation. Refer to Sezione 4.9, «Tagging condizionale» for more information.

Nodi root e tag condizionale

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>

and this chapter is included in User_Guide.xml with an <xi:include> tag, the document will not build with $ condition: Ubuntu set in the publican.cfg file.
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.

xref e tag condizionale

If an <xref> points to content not included in the build due to conditional tagging, the build will fail. For example, with $ condition: upstream set in the publican.cfg file, $ publican build --formats=pdf --langs=en-US will fail if the book has the tag <xref linkend="betasection"> pointing to <section id="betasection" condition="beta">.
confidential
marks a document as confidential. When this parameter is set to 1, Publican adds the text specified by the confidential_text parameter (by default, CONFIDENTIAL) to the foot of each HTML page and the head of every page in a PDF document. The default value is 0 (no header or footer).
confidential_text
specifies the text to use when the confidential parameter is set to 1. The default text is CONFIDENTIAL.
debug
controls whether Publican should display debugging messages as it works. When set to its default of 0, Publican does not display debugging messages. Change this value to 1 to view these messages.
def_lang
sets the default language for a Publican-managed website. Tables of contents for languages other than the default language will link to documents in the default language when translations are not available. Refer to Sezione 4.8, «Creare il pacchetto di un documento».
doc_url
provides a URL for the documentation team for this package. In HTML output, Publican links to this URL at the top right of each page, through the image_right.png image in the Common_Content/images directory for the brand. This parameter defaults to 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_obsoletes
a package that a desktop package obsoletes.
dt_requires
a package that the desktop package requires, for example, a documentation menu package. Refer to Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti».
dtdver
specifies the version of the DocBook XML Document Type Definition (DTD) on which this project is based. Publican defaults to version 4.5. The specification for DocBook XML DTD version 4.5 is available from http://www.docbook.org/specs/docbook-4.5-spec.html.

A different DTD might slow your build

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.
dtd_type
Override Type for DocType. Must be a complete string.

Nota

This parameter is only permitted in a brand.
dtd_uri
Override URI for DocType. Must be a complete string.

Nota

This parameter is only permitted in a brand.
ec_id
sets the ID for an Eclipse help plugin. Every Eclipse help plugin must have a unique ID, and these generally follow Java package naming conventions — refer to http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html. By default, Publican sets the ID to org.product.docname. The ID that you set here also determines the directory name for this plugin in the plugin directory.
ec_name
sets the name of an Eclipse help plugin. This is the human-readable name visible in the help list in Eclipse. This name does not need to be unique or to follow a special convention. By default, Publican sets the name to product docname.
ec_provider
sets the provider name for an Eclipse help plugin. This should be your name, or the name of your project or organization. This name is presented to users and does not need to be unique or follow a special convention. By default, Publican sets the provider name to Publican-Publican version.
edition
specifies the edition number for this document. If set, this value overrides the content of the <edition> tag in the Book_Info.xml file when you package a document. This value must include only digits and the period (‘0’–‘9’ and ‘.’).
extras_dir
the directory Publican will process extra files from. (Default: extras)
footer
specifies content that will be injected into the bottom of every page on the site.
generate_section_toc_level
controls the section depth at which Publican will generate a table of contents. At the default value of 0, Publican will generate tables of contents at the start of the document and in parts, chapters, and appendixes, but not in sections. If (for example) the value is set to 1, tables of contents also appear in each "level 1" section, such as sections 1.1, 1.2, 2.1, and 2.2. If set to 2, tables of contents also appear in "level 2" sections, such as sections 1.1.1, 1.1.2, and 1.2.1.

Esempio D.2. Setting the section depth at which tables of contents appear

generate_section_toc_level: 0 (default)
Publican will generate tables of contents at the start of the document and in parts, chapters, and appendixes, but not in sections.
generate_section_toc_level: 1
Publican will generate tables of contents also at the start of each "level 1" section, such as sections 1.1, 1.2 … 2.1, 2.2 …
generate_section_toc_level: 2
Publican will generate tables of contents also at the start of each "level 2" section, such as as sections 1.1.1, 1.1.2. 1.1.3 … 1.2.1., 1.2.2, 1.2.3 …

ignored_translations
specifies translations to ignore as comma-separated XML language codes; for example, es-ES,it-IT. If you build or package a book for a language filtered by this parameter, Publican ignores any translations that exist for this language, and builds or packages the book in the language of the original XML instead. Refer to Sezione 4.6, «Preparare un documento per la traduzione», and to Appendice G, Codici di lingua.
img_dir
the directory Publican will process images from. (Default: images)
info_file
overrides the default Info file. Specifies where Publican looks for info fields. Use the full filename without the path.
license
specifies the license this package uses. By default, Publican selects the GNU Free Documentation License (GFDL). Refer to Sezione 4.8, «Creare il pacchetto di un documento».
max_image_width
specifies the maximum width allowable for images in the document in pixels. By default, Publican scales down any images wider than 444 pixels so that they fit within this limit. Keeping images no wider than 444 pixels ensures that they present no wider than the right-hand margin of the text in HTML output and that they fit within the pages of PDF output. Refer to Sezione 4.2, «Aggiungere immagini» for more information on using images.

Importante — 444 pixel è la massima larghezza di sicurezza

Non usare il parametro max_image_width se le immagini contengono importanti informazioni. Le immagini più larghe di 444 pixel potrebbero presentarsi male nei documenti HTML e PDF e rendersi inusabili, in quanto superando i margini esse verrebbero rappresentate incomplete.
Viceversa, le immagini più larghe di 444 pixel che vengono scalate in un browser web o in un visualizzatore PDF, perdono in qualità.
Per preservare la qualità delle immagini, si raccomanda di tagliare o scalare le immagini ad una larghezza inferiore a 444 pixel, prima di includerle in un documento.
mainfile
specifies the name of the XML file in your document that contains the root XML node <article>, <book>, or <set>, and the name of the corresponding .ent file that contains the document's entities. For example, if you set mainfile: master, Publican looks for the root XML node in master.xml and the document entities in master.ent.
If mainfile is not set, Publican looks for the root XML node in a file that matches the <title> of the document set in the Article_Info.xml, Book_Info.xml, or Set_Info.xml file, and looks for the document entities in a file with a corresponding name.
menu_category
the desktop menu category (as defined by a corresponding .menu file) in which a document should appear when installed from a desktop RPM package. Refer to 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
provides a URL for the product to which this document applies. In HTML output, Publican links to this URL at the top left of each page, through the image_left.png image in the Common_Content/images directory for the brand. This parameter defaults to 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
specifies the release number of this package. If set, this value overrides the value of <pubsnumber> in the Book_Info.xml file when you package a document. This value must include only digits (‘0’–‘9’).
repo
specifies the repository from which to fetch remote books that form part of a distributed set. Refer to Sezione 6.2, «Set distribuiti».
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
specifies the version control (or source code management) system used in the repository in that stores the remote books in a distributed set. At present, Publican can use only Subversion (SVN), and therefore uses SVN as its default setting. Refer to Sezione 6.2, «Set distribuiti».
show_remarks
controls whether to display DocBook <remark>s in transformed output. By default, this value is set to 0, which causes Publican to hide remarks. Set this value to 1 to display remarks. In Publican's common brand, displayed remarks are highlighted in magenta.
sort_order
override 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
specifies the URL at which to find tarballs of source files. This parameter provides the Source: field in the header of an RPM spec file. Refer to Sezione 4.8, «Creare il pacchetto di un documento».
tmp_dir
specifies the directory for Publican output. By default, this is set to tmp, which creates a directory named tmp inside the directory that holds your article or book.
tmpl_path
specifies the path to Publican templates. By default, this is set to /usr/share/publican/templates.
toc_js
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
controls the depth of sections that Publican includes in the main table of contents. By default, this value is set to 2. With the default setting, sections 1.1 and 1.1.1 will appear in the main table of contents, but section 1.1.1.1 will not. (Note that the first digit in these examples represents a chapter, not a section).

Esempio D.3. Controlling the depth of sections in the main table of contents

toc_section_depth: 0
Publican will generate a main table of contents only for chapters.
toc_section_depth: 1
Publican will generate a main table of contents only for chapters and "level 1" sections, such as 1, 1.1, 1.2, 1.3 … 9, 9.1, 9.2 … but not for sections 1.1.1, 1.1.2 …
toc_section_depth: 2 (default)
Publican will generate tables of contents for chapters and "level 1 and "level 2" sections, such as 1, 1.1, 1.1.1, … 1,2, 1.2.1, 1.2.2 … but not for deeper sections x.x.x.x .

type
specifies the type of document — a DocBook <article>, DocBook <book>, or DocBook <set>, as set by the --type option for $ publican create.
version
specifies the version number of that product to which this document applies. If set, this value overrides the content of the <productnumber> tag in the Book_Info.xml file when you package a document. This value must include only digits and the period (‘0’–‘9’ and ‘.’).
web_brew_dist
specifies the brew build target to use for building the web RPM packages. Brew is the internal build system used by Red Hat. By default, this value is set to docs-5E, representing documentation packages for Red Hat Enterprise Linux 5. Refer to Sezione 4.8, «Creare il pacchetto di un documento».
web_formats
a comma-separated list of formats to include in the web RPM package. Refer to Sezione 4.8.2, «The $ publican package command».
web_home
specifies that the document is the home page of a documentation website, not a standard document. Refer to Capitolo 7, Creare un sito web con Publican.

Important — web_home is deprecated

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_label
overrides the book name as it appears on the menu of a Publican-managed website. Refer to Capitolo 7, Creare un sito web con Publican.
web_obsoletes
specifies packages that the web RPM obsoletes. Refer to Sezione 4.8, «Creare il pacchetto di un documento».
web_product_label
overrides the product name as it appears on the menu of a Publican-managed website. Refer to Capitolo 7, Creare un sito web con Publican.
web_style
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
overrides the version number as it appears on the menu of a Publican-managed website. Set this value to UNUSED for general documentation that does not apply to any particular version of a product. Refer to Capitolo 7, Creare un sito web con Publican.
wkhtmltopdf_opts
Extra options to pass to wkhtmltopdf. e.g. wkhtmltopdf_opts: "-O landscape -s A3"
xml_lang
specifies the language of the source XML files, for example, en-US, as set by the --lang option for $ publican create.

Contenuto del file dump di un sito

Il file dump di un sito web generato da Publican contiene i dettagli di alcune configurazioni di base, insieme con i dettagli di ogni documento pubblicato sul sito. I dettagli di configurazione del sito sono:
<host>
L'URL alla radice del sito di documentazione, come impostato dal parametro host, nel file di configurazione del sito.
<def_lang>
La lingua predefinita della documentazione sul sito web, come impostato dal parametro def_lang, nel file di configurazione del sito.
Ogni documento, in ogni lingua, in ogni formato ha un record separato. Questi record contengono i seguenti dati:
<name>
Il titolo del documento, generato dal tag <title> in Book_Info.xml, Article_Info.xml o Set_Info.xml, superato dal parametro docname nel file publican.cfg. Ogni spazio presente nel titolo è sostituito con un carattere trattino basso.
<ID>
Un numero ID unico per il documento, in un certo formato e lingua.
<abstract>
Una breve descrizione generale del contenuto del documento, generato dal tag <abstract> in Book_Info.xml, Article_Info.xml o Set_Info.xml. Publican usa questo stesso contenuto per generare la sezione %description del file spec, usato per creare il pacchetto RPM di un documento. Se l'<abstract> è tradotto, questo campo contiene il testo tradotto.
<format>
Il formato in cui il documento è prodotto — html per html in pagine multiple, html-single per html in pagina singola, pdf per PDF ed epub per EPUB.
<language>
Il codice linguistico per il documento. Fare riferimento all'Appendice G, Codici di lingua, per maggiori informazioni su questi codici in XML.
<name_label>
Il nome del documento che appare nella tabella dei contenuti del sito. Il nome può essere impostato con il parametro web_name_label nel file publican.cfg del documento. Diversamente, il campo è vuoto per un documento in lingua originale o contiene il titolo del documento tradotto. Ogni spazio presente nel nome è sostituito con il carattere trattino basso.
<product>
Il prodotto descritto dal documento, generato dal tag <productname> in Book_Info.xml, Article_Info.xml o Set_Info.xml, se non generato dal parametro product nel file publican.cfg. Ogni spazio presente nel nome è sostituito con il carattere trattino basso.
<product_label>
Il nome del prodotto che appare nella tabella dei contenuti del sito. Il nome può essere impostato con il parametro web_product_label nel file publican.cfg del documento. Diversamente, il campo è vuoto per un documento in lingua originale o contiene il titolo del documento tradotto. Ogni spazio presente nel nome è sostituito con il carattere trattino basso.
Se il nome di prodotto è impostato con UNUSED, non viene visualizzata alcuna intestazione nella tabella dei contenuti del sito.
<subtitle>
Un'unica riga descrittiva del contenuto del documento, generato dal tag <subtitle> in Book_Info.xml, Article_Info.xml o Set_Info.xml. Publican usa questo stesso contenuto per generare la sezione Summary del file spec, usato per creare il pacchetto RPM di un documento. Se il <subtitle> è tradotto, questo campo contiene il testo tradotto.
<update_date>
La data di più recente installazione del documento, sul sito, nel formato YYYY-MM-DD.
<version>
La versione del prodotto descritto dal documento (non la versione del documento), generata dal tag <productnumber> in Book_Info.xml, Article_Info.xml o Set_Info.xml, se non generata dal parametro version nel file publican.cfg.
<version_label>
La versione del prodotto che compare nella tabella dei contenuti del sito. La versione può essere impostata con il parametro web_version_label nel file publican.cfg del documento.
Se la versione è impostata con UNUSED, non viene visualizzata alcuna intestazione per questa versione del prodotto, nella tabella dei contenuti del sito.

Esempio E.1. Record d'esempio da un file DUMP.xml

Questi due record da un file DUMP.xml, visualizzano lo stesso libro, Red Hat Enterprise Linux 5 Installation Guide, in due formati e due lingue differenti — una versione PDF in lingua inglese ed una versione HTML multi-pagine, in lingua francese.
  <record>
    <name>Installation_Guide</name>
    <ID>22</ID>
    <abstract>This manual explains how to boot the Red Hat Enterprise Linux 5 installation program (anaconda) and to install Red Hat Enterprise Linux 5 on 32-bit and 64-bit x86 systems, 64-bit POWER systems, and IBM System z. It also covers advanced installation methods such as kickstart installations, PXE installations, and installations over VNC. Finally, it describes common post-installation tasks and explains how to troubleshoot installation problems.</abstract>
    <format>pdf</format>
    <language>en-US</language>
    <name_label>Installation_Guide</name_label>
    <product>Red_Hat_Enterprise_Linux</product>
    <product_label>Red_Hat_Enterprise_Linux</product_label>
    <subtitle>Installing Red Hat Enterprise Linux 5 for all architectures</subtitle>
    <update_date>2010-10-07</update_date>
    <version>5</version>
    <version_label></version_label>
  </record>
  <record>
    <name>Installation_Guide</name>
    <ID>149</ID>
    <abstract>Ce manuel explique comment lancer le programme d'installation Red Hat Enterprise Linux 5 et comment installer Red Hat Enterprise Linux 5 sur les systèmes x86 32-bit et 64-bit, sur les systèmes POWER 64-bit, et sur les systèmes IBM System z. Il couvre aussi des méthodes d'installation avancées telles que les installations kickstart, PXE, et les installations au moyen de VNC. Finalement, ce manuel décrit les tâches communes post-installation et explique comment résoudre les problèmes liés à une installation.</abstract>
    <format>html</format>
    <language>fr-FR</language>
    <name_label>Guide_d'installation</name_label>
    <product>Red_Hat_Enterprise_Linux</product>
    <product_label>Red_Hat_Enterprise_Linux</product_label>
    <subtitle>Installation de Red Hat Enterprise Linux 5 pour toutes les architectures</subtitle>
    <update_date>2010-10-19</update_date>
    <version>5</version>
    <version_label></version_label>
  </record>

E.1. Ricavare gli URL dai file dump

Usando i seguenti campi, si può ricavare l'URL di ogni documento sul sito:
  • <host>
  • <name>
  • <format>
  • <language>
  • <product>
  • <version>
HTML multi-pagine
<host>/<language>/<product>/<version>/<format>/<name>/index.html
Per esempio, http://docs.fedoraproject.org/en-US/Fedora/14/html/Accessibility_Guide/index.html
HTML singola-pagina
<host>/<language>/<product>/<version>/<format>/<name>/index.html
Per esempio, http://docs.fedoraproject.org/en-US/Fedora/14/html-single/Accessibility_Guide/index.html
PDF
<host>/<language>/<product>/<version>/<format>/<name>/<product>-<version>-<name>-<language>.pdf
Per esempio, http://docs.fedoraproject.org/en-US/Fedora/14/pdf/Accessibility_Guide/Fedora-14-Accessibility_Guide-en-US.pdf
EPUB
<host>/<language>/<product>/<version>/<format>/<name>/<product>-<version>-<name>-<language>.epub
Per esempio, http://docs.fedoraproject.org/en-US/Fedora/14/pdf/Accessibility_Guide/Fedora-14-Accessibility_Guide-en-US.epub
Notare che i campi <product_label>, <version_label> e <name_label> sono privi di significato per gli URL, anche quando sono esplicitamente rimossi dalla tabella dei contenuti con l'impostazione UNUSED.

File spec d'esempio per il pacchetto desktop-menu

Il seguente file spec è un esempio di come creare un pacchetto RPM contenente un file di >desktop entry (file .directory) ed un file di desktop menu (file .menu). Fare riferimento alla Sezione 4.8.1.3, «Voci nel menu del desktop per i documenti», per la struttura di questi file.
Questo esempio assume che si sia creato un file desktop-entry, menu-example.directory ed un file desktop-menu, menu-example.menu, con un file README localizzati in una cartella di nome menu-example-0, archiviata come menu-example-0.tgz.
Una volta creato, il pacchetto risultante avrà nome menu-example.
Name:		menu-example
Version:	0
Release:	8%{?dist}.t1
Summary:	Example of how to do a documentation menu package
Group:		Development/Tools
License:	GPLv2+
URL:		http://engineering.redhat.com
Source0:	%{name}-%{version}.tgz
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:      noarch

%description
Example of how to do a documentation menu package

%prep
%setup -q

%build

%install
rm -rf %{buildroot}
mkdir -p $RPM_BUILD_ROOT%{_datadir}/desktop-directories
mkdir -p $RPM_BUILD_ROOT/etc/xdg/menus/settings-merged

install -m644 menu-example.directory $RPM_BUILD_ROOT%{_datadir}/desktop-directories/menu-example.directory
install -m644 menu-example.menu $RPM_BUILD_ROOT%{_sysconfdir}/xdg/menus/settings-merged/menu-example.menu

%{_fixperms} $RPM_BUILD_ROOT/*

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
%doc README
%{_datadir}/desktop-directories/menu-example.directory
%config(noreplace) %{_sysconfdir}/xdg/menus/settings-merged/menu-example.menu

%changelog
* Tue Nov 23 2010 Jeff Fearn <jfearn@redhat.com> 0-8
- Creation

Codici di lingua

Subtag di nazione

L'unica parte del tag linguistico XML, obbligatorio in Publican, è il subtag linguistico. Tuttavia, Publican è progettato con l'assunzione che l'identificazione delle lingue includa regolarmente anche i subtag nazionali. In molte lingue, ortografia e vocaboli variano significativamente da nazione a nazione. Se non si specifica la varietà nazionale di una lingua, in cui il documento viene redatto o in cui viene tradotto, si potrebbero ottenere risultati inaspettati, alla creazione del documento in Publican.

Altri codici linguistici

Il sistema di codici nello standard XML, usato per identificare le lingue, non è l'unico sistema di codici linguistici, attualmente in uso nel mondo. Tuttavia, poiché Publican si sforza di essere compatibile con lo standard XML, questi sono gli unici codici supportati da Publican. In particolare, notare che i codici usati nei prodotti GNU (notabili per l'uso del carattere trattino basso e del simbolo @ per separare gli elementi — per esempio, en_GB o sr_RS@latin), non sono compatibili con lo standard XML e perciò non funzionano con Publican.
Publican è uno strumento di pubblicazione basato su XML e perciò progettato per l'uso di codici linguistici — o tag — delineati dal W3C (World Wide Web Consortium)[5] nelle specifiche XML. Questi codici sono definiti nel documento BCP 47: Tags for Identifying Languages,[6] dell'IETF (Internet Engineering Task Force).
I tag linguistici sono creati a partire da uno o più subtag, separati da trattini. In ordine di presentazione all'interno di un tag linguistico, questi subtag sono:
lingua-script-regione-variante
Il BCP 47 permette anche, con l'uso di subtag extension e subtag private-use, di creare notevoli tag linguistici per casi speciali. Un subtag extension consente una regolazione calibrata di subtag esistenti, ma che occorre registrare presso l'IETF (attualmente non esiste nessun tag registrato). Un subtag private-use è preceduto da x- e non necessita di registrazione. Subtag private-use a parte, un subtag è valido se è presente nel registro dei subtag mantenuti dall'IETF, attraverso l'autorità IANA (Internet Assigned Numbers Authority).[7] Sebbene Publican accetti ogni tag linguistico valido, secondo le regole stabilite nel BCP 47, esso è progettato con l'assunzione che i tag linguistici, per i documenti, assumano la forma lingua-nazione. Di seguito si riporta una breve descrizione dei subtag:
subtag lingua
Il subtag linguistico è composto da due o più lettere minuscole ed è l'unica parte obbligatoria di ogni tag linguistico. Per le principali lingue parlate, il subtag linguistico è un codice di due lettere identico ai codici linguistici specificati nell'ISO 639-1, [8] per esempio it (italiano), hi (hindi), es (spagnolo) ed en (inglese). Dove non esiste un codice di due lettere nell'ISO 639-1, il subtag linguistico solitamente è identico al codice specificato nell'ISO 639-2,[9] per esempio bal (baluchi: lingua iranica), apk (kiowa apache: lingua apache delle pianure) e tpi (Tok Pisin: lingua della Papua Nuova Guinea). Infine, un piccolo numero di subtag linguistici presenti nel registro presso l'IANA, sono privi di codici corrispondenti sia in ISO 639-1 sia in ISO 639-2, come i subtag per le lingue inventate qya (quenya: lingua elfica inventata da J.R.R.Tolkien) e tlh (klingon: lingua extraterrestre della serie Star Trek), e per la lingua occulta i-enochian (enochiano: lingua degli angeli inventata da E.Kelley). Quest'ultimo esempio, mostra anche un ristretto numero di subtag linguistici eccezionalmente inseriti nel registro, senza corrispondere al modello delle due o tre lettere derivato dagli standard ISO 639.

Subtag estesi di lingua

Il documento RFC 5646: Tags for Identifying Languages[10] pubblicato nel settembre del 2009, permette ai subtag estesi di lingua di aderire al subtag linguistico. I subtag estesi sono codici di tre lettere, rappresentanti lingue, che condividono una stretta relazione con una lingua già rappresentata da un subtag linguistico. Per esempio, yue, rappresentante la lingua cantonese, deve essere usato sempre con il subtag associato (cinese), quindi: zh-yue. L'IETF non riconosce l'RFC 5646 come la "Miglior Regola d'Arte", e nemmeno questi tag fanno già parte dello standard XML.
subtag script
Il subtag di script è composto da quattro lettere — la prima maiuscola le altre minuscole — e definisce un sistema di scrittura o alfabeto. Questi codici sono identici alle quattro lettere di codice specificati in ISO 15924.[11] Il subtag di script è usato per identificare le lingue che comunemente usano più di un sistema di scrittura; il subtag viene omesso quando non aggiunge alcun valore distintivo al tag linguistico globale. Per esempio, sr-Latn rappresenta la lingua serba scritta con l'alfabeto latino, mentre sr-Cyrl rappresenta ancora la lingua serba ma scritta con l'alfabeto cirillico; quindi az-Arab e az-Cyrl rappresentano la lingua azera (dell'Azerbaijani), scritta rispettivamente, in alfabeto arabo e cirillico. D'altro canto, l'italiano non ha bisogno di specificare it-Latn in quanto, comunemente nel mondo, l'italiano è scritto solo con l'alfabeto latino.
subtag regione
Il subtag di regione è composto da due lettere maiuscole (per le regioni che coincidono con i confini nazionali) o da tre cifre (per altre aree, come le regioni trans-nazionali). I tag di due lettere sono identici a quelli definiti in ISO 3166-1[12], per esempio IT (Italia), TZ (Tanzania) e VE (Venezuela). I tag di tre cifre si basano su quelli definiti in UN M.49, [13] per esempio, 015 (Nord Africa), 061 (Polynesia) e 419 (America latina e Caraibi).
subtag variante
I subtag di variante, composti da lettere maiuscole, minuscole e cifre, identificano varianti riconoscibili, ben definite di una lingua o di una scrittura. I subtag di variante che iniziano con una lettera devono essere lunghi almeno cinque caratteri, mentre quelli che iniziano con una cifra, lunghi almeno quattro caratteri. I principali subtag di variante possono essere usati solo in combinazione con subtag specifici oppure in combinazione di subtag. I subtag di variante non si armonizzano con gli altri standard; essi sono il risultato di una registrazione separata, presso l'IETF, da parte di una persona o gruppo interessato.
Nello standard attuale, i dialetti di varie lingue sono designati con subtag di variante, per esempio, nedis denota un dialetto sloveno del Natisone o Nadiza. Questo subtag deve essere usato in congiunzione con il subtag della lingua slovena, quindi si ha sl-nedis. Nel settembre 2009, l'IETF ha pubblicato un RFC (Request for Comments) che tra le altre cose, propone di rappresentare i dialetti con i subtag di lingua estesa, da aggiungere ai subtag di lingua.[14]
I principali subtag di variante contrassegnano una particolare ortografia, la maggior parte usualmente dopo una riforma ufficiale di ortografia o dopo un significativo lavoro di documentazione sulla lingua. Esempi (con i relativi subtag di lingua) comprendono: fr-1606nicot (per la lingua francese come documentata da Jean Nicot nel 1606), de-1901 (per la lingua tedesca la cui ortografia è stata codificata dal 2nd Orthographic Conference nel 1901) e be-1959acad (per la lingua bielorussa come codificata dall'Orthography Commission nel 1959).
Infine, alcuni tag di variante denotano una particolare variante di un sistema di scrittura o di traslitterazione. Per esempio, zh-Latn-wadegile rappresenta la lingua cinese scritta con l'alfabeto latino, in accordo la sistema di traslitterazione sviluppato da Thomas Wade ed Herbert Giles; ja-Latn-hepburn la lingua giapponese scritta con l'alfabeto latino, usando il sistema di traslitterazione di James Curtis Hepburn.
Publican include supporto per le seguenti lingue:
  • ar-SA — arabo
  • as-IN — assamese
  • ast-ES — asturiano
  • bg-BG — bulgaro
  • bn-IN — bengalese
  • bs-BA — bosniaco
  • ca-ES — catalano
  • cs-CZ — ceco
  • da-DK — danese
  • de-CH — tedesco (Svizzera)
  • de-DE — tedesco (Germania)
  • el-GR — greco
  • es-ES — spagnolo
  • fa-IR — iraniano
  • fi-FI — finlandese
  • fr-FR — francese
  • gu-IN — gujarati
  • he-IL — ebraico
  • hi-IN — hindi
  • hr-HR — croato
  • hu-HU — ungherese
  • id-ID — indonesiano
  • is-IS — islandese
  • it-IT — italiano
  • ja-JP — giapponese
  • kn-IN — kannada
  • ko-KR — coreano
  • lv-LV — lettone
  • ml-IN — malayalam
  • mr-IN — marathi
  • nb-NO — norvegese (ortografia Bokmål)
  • nl-NL — olandese
  • or-IN — oriya
  • pa-IN — punjabi
  • pl-PL — polacco
  • pt-BR — portoghese (Brasile)
  • pt-PT — portogehse (Portogallo)
  • ru-RU — russo
  • si-LK — singalese
  • sk-SK — slovacco
  • sr-Cyrl-RS — serbo (alfabeto cirillico)
  • sr-Latn-RS — serbo (alfabeto latino)
  • sv-SE — svedese
  • ta-IN — tamil
  • te-IN — telugu
  • th-TH — thailandese o thai
  • uk-UA — ucraino
  • zh-CN — cinese (Repubblica Popolare Cinese, alfabeto Han semplificato)
  • zh-TW — cinese (Repubblica di Cina, alfabeto Han tradizionale)

Revision History

Diario delle Revisioni
Revisione 3.2-1Thu Jul 11 2013Zac Dover
Added command prompts to all commands - BZ#880456
Added quotes around the web_formats list - BZ#839141
Replaced a broken link to kate plugins page on CPAN with a working link - BZ#973461
Updated web site instructions - BZ#979224
Revisione 3.2-0.1Wed Jul 10 2013Jeff Fearn
I file della traduzione sono sincronizzati con con le versioni 3.2-0 dei sorgenti XML
Revisione 3.2-0Thu Jul 11 2013Jeff Fearn
Publican 3.2.0
Document site config option 'toc_js'
Document build option --pdftool
Document build option --pub_dir
Revisione 3.1-0.2Mon Jul 8 2013Jeff Fearn
I file della traduzione sono sincronizzati con con le versioni 3.1-0 dei sorgenti XML
Revisione 3.1-0.1Fri Mar 8 2013Ruediger Landmann
Translation files synchronised with XML sources 3.1-0
Revisione 3.1-0Tue Jan 8 2013Norman Dunbar
Add Section on Installing Publican on OpenSuse 12
Revisione 3.0-0Mon Feb 20 2012Jeff Fearn
Publican 3.0
Revisione 2.7-1Tue Sep 6 2011Rebecca Newton
Integrata la documentazione sull'uso di <set> a sé stanti
Revisione 2.6-1Mon Jul 18 2011Rüdiger Landmann
Documentato il nuovo parametro manual_toc_update -- BZ#719573
Documentato la nuova azione update_db -- BZ#661948
Documentato la nuova azione rename -- BZ#694698
Documentato il nuovo parametro mainfile -- BZ#688585
Incluso avviso sui file di configurazione multipli per libri condizionati -- BZ#657132
Corretto i comandi d'esempio -- BZ#663211
Incorporato correzioni di rilettura di Luigi Votta BZ#657576
Revisione 2.4-1Wed Dec 1 2010Rüdiger Landmann
Incorporato correzioni di rilettura di Luigi Votta BZ#657576
Documentato per lingue note, i problemi con PDF
Documentato il parametro web_formats
Documentato la creazione dei desktop-menu
Documentato site_overrides.css
Revisione 2.3-0Mon Oct 25 2010Rüdiger Landmann
Documentato il file dump di sito web
Documentato il comando bump
Aggiornato l'informazione sulla larghezza immagini
Revisione 2.3-0Tue Oct 5 2010Rüdiger Landmann
Aggiornato l'inclusione di più lingue in lang_stats
Corretto i dettagli su web_logo.png BZ#638153
Corretto l'elenco dei caratteri usabili nel nome di prodotto e nel titolo di documento
Documentato il nuovo parametro web_type e ricollocato i parametri web_host e web_search nel file di config di sito
Descritto i cataloghi OPDS
Documentato le pagine di prodotto e di versione
Documentato la presentazione delle pagine di man
Documentato il parametro bridgehead_in_toc
Correzione -- def_langs è un parametro del file config di sito, non un parametro del file di config di home page
Revisione 2.2-0Thu Aug 19 2010Rüdiger Landmann
Espanso gli esempi di codice BZ#604255
Chiarito l'uso di clean_ids BZ#612819
Documentato --novalid BZ#616142
Revisione 2.1-1Fri Jul 16 2010Rüdiger Landmann
Corretto e chiarificato le istruzioni su sito web BZ#614259
Chiarificato l'uso di Product-Version-Id per i pacchetti
Revisione 1.6-1Mon May 24 2010Rüdiger Landmann
Aggiornato le istruzioni di installazioni per Ubuntu
Revisione 1.6-0Fri May 7 2010Rüdiger Landmann
Rivisto la nomenclatura di azioni ed opzioni
Documentato le azioni print_known, print_banned, e print_unused
Corretto ed espanso la documentazione su installazione di brand
Documentato i parametri max_image_width e confidential_text
Documentato il formato dei plugin di aiuto di Eclipse e i parametri supportati
Revisione 1.5-0Fri Feb 26 2010Rüdiger Landmann
Documentato le opzioni di --config
Revisione 1.4-0Wed Feb 17 2010Jeff Fearn
Rimosso obsoleto riferimento al path al file di catalogo di DocBook BZ#565498
Documentato le opzioni di CVS
Revisione 1.3-0Mon Dec 7 2009Rüdiger Landmann
Aggiunto una FAQ sulla evidenza degli errori nel codice
Aggiunto una sezione sui formati validi
Aggiornato l'elenco degli autori
Aggiunto istruzioni di installazione per Debian; istruzioni di installazione più specifiche per Ubuntu BZ#542711
Metadati nel file Book_Info.xml
Revisione 1.2-0Fri Nov 27 2009Jeff Fearn
Documentato l'azione lang_stats BZ#540696
Revisione 1.1-1Thu Nov 26 2009Jeff Fearn
Risolto le condizioni d'uso di errati doc BZ#540691
Revisione 1.1-0Thu Oct 22 2009Rüdiger Landmann
Risolto varie piccole inconsistenze e pulizia generale
Revisione 1.0-0Tue Oct 13 2009Rüdiger Landmann
Aggiornato per Publican 1.0
Revisione 0.5-0Thu Dec 18 2008Jeff Fearn
Aggiunto appendice per i parametri di Makefile
Aggiunto una FAQ sullo spazio di heap in Java
Revisione 0.4-0Tue Nov 25 2008Brian Forté
Aggiunto la sezione "Pre-release and draft documentation"
Revisione 0.3-0Fri Oct 10 2008Don Domingo
Aggiunto la sezione "Conditional Tagging"
Revisione 0.2-0Fri Sep 05 2008Brian Forté
Modifiche generali e aggiornato alla release Publican 0.36. Aggiunto anche una nuova sezione al capitolo 3.3.
Revisione 0.1-1Fri Jun 06 2008Murray McAllister
Aggiornato il capitolo Branding con una nota sull'aggiunta dei brand oVirt e GIMP
Revisione 0.1-0Fri May 16 2008Jeff Fearn
Aggiornato FAQ
Revisione 0.0-0Thu Dec 13 2007Murray McAllister
Contenuto iniziale alla release