Product SiteDocumentation Site

Chapter 3. Creating a document

3.1. Files in the book directory
3.1.1. The publican.cfg file
3.1.2. Book_Info.xml
3.1.3. Author_Group.xml
3.1.4. Chapter.xml
3.1.5. Doc_Name.xml
3.1.6. Doc_Name.ent
3.1.7. Revision_History.xml
3.2. Adding images
3.3. Preparing a document for translation
3.4. Building a document
3.4.1. Building a document created with Publican 0
3.5. Packaging a book
3.5.1. Types of RPM packages
3.5.2. The publican package command
3.6. Conditional tagging
3.6.1. Conditional tagging and translation
3.7. Pre-release software and draft documentation
3.7.1. Denoting pre-release software
3.7.2. Denoting draft documentation
3.7.3. Denoting draft documentation of pre-release software
This chapter describes creating books and articles: the main configuration files, example document files, and how to build a document.
Use the publican create command to create a new document, including all the necessary files for the document.
The following is a list of valid options that you can append to the publican create command. For example, publican create --help, publican create --name New_Book, and so on:
--help
print a list of all publican create command options.
--name Doc_Name
replace Doc_Name with 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 Language_Code
replace Language_Code with the language code of the language in which the book or article will be authored. If you do not specify a language, Publican defaults to en-US (American English). The --lang option sets the xml_lang in the publican.cfg file. Refer to Section 3.1.1, “The publican.cfg file” for more information on publican.cfg parameters and Appendix D, Language codes for more detail on language codes.
--version version
replace version with the version number of the product that the book describes. For example, for Red Hat Enterprise Linux 5.1 you would use 5.1. The default version is 0.1. The --version option sets the <pubsnumber> tag in the Book_Info.xml or Article_Info.xml file. For more information refer to Section 3.1.2, “Book_Info.xml”.
--edition edition
replace edition with the edition number of the book. This number indicates to users when a new edition of the book is released. The initial general availability (GA) release of the book should be edition 1.0. The default value is 0. The --edition option sets the <edition> tag in the Book_Info.xml or Article_Info.xml file. For more information refer to Section 3.1.2, “Book_Info.xml”.
--product Product_Name
replace Product_Name with the product name. This variable must not contain any spaces. For example, set this to Fedora for core Fedora documentation, and the name of the product for other products, for example, Fedora_Directory_Server. The --product option sets the <product name> tag in the Book_Info.xml or Article_Info.xml and the PRODUCT in the Doc_Name.ent file.
--type Article --name Article_Name
create an article instead of a book. Replace Article_Name with the article name. This variable must not contain any spaces. The --type option sets the type in the publican.cfg file. Refer to Section 3.1.1, “The publican.cfg file” for more information on publican.cfg parameters.
--type Set --name Set_Name
create a set of documents instead of a book. Replace Set_Name with the set name. This variable must not contain any spaces. The --type option sets the type in the publican.cfg file. Refer to Section 3.1.1, “The publican.cfg file” for more information on publican.cfg parameters and to Chapter 5, Using sets for details on using sets.
--brand brand
replace brand with RedHat, fedora, JBoss, oVirt, or GIMP. The --type option sets the brand in the publican.cfg file. Refer to Section 3.1.1, “The publican.cfg file” for more information on publican.cfg parameters. This option requires the appropriate Publican brand package to be installed. For example, to build Red Hat branded books, you must install the publican-redhat package. Refer to Section 4.1, “Installing a brand” for instructions on installing brand packages for Publican. If you do not specify a brand, Publican uses its built-in, default brand. Refer to Chapter 4, Branding for more information.
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
To see the results of this command on a computer with a Linux operating system, run the following:
ls
The output should be similar to the following:
en-US publican.cfg

3.1. Files in the book directory

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
  • en-US (directory)
    • Test_Book.xml
    • Test_Book.ent
    • Revision_History.xml
    • Preface.xml
    • Chapter.xml
    • Book_Info.xml
    • Author_Group.xml
    • images (directory)
      • icon.svg

3.1.1. The publican.cfg file

The publican.cfg file configures build options, and is located in the root of the book directory. The following is an example publican.cfg file, with a description of publican.cfg parameters following afterwards:
# Config::Simple 4.59
# Mon Sep 28 16:38:14 2009

xml_lang: en-US
type: Book
brand: common



Default parameters
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 Chapter 4, Branding for more information.
Advanced 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 Section 3.6.1, “Conditional tagging and translation” 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 Section 5.2, “Distributed sets” for more information on distributed sets.
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 Section 3.5.2, “The publican package command” and Section 4.4, “Packaging a brand” for more information on building RPM packages.
catalogs
sets the path to the DocBook catalog files. The default location on a computer with a Linux operating system is /usr/share/publican/xsl. On a computer with a Windows operating system, the default location is %SystemDrive%/%ProgramFiles%/publican/DocBook_DTD — most usually C:/Program Files/publican/DocBook_DTD.
chunk_first
controls whether the first section should appear on the same page as its parent when rendered in HTML. To make the first section appear on the same page as its parent, set this parameter to chunk_first: 1. Otherwise, the parameter defaults to 0, and the first section starts a new HTML page.
chunk_section_depth
controls the point at which Publican no longer splits sub-subsections onto a new page when rendering HTML. By default, this value is set to 4.
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 Section 3.6, “Conditional tagging” for more information.

Root nodes and conditional tagging

If the root node of an XML file is excluded with a conditional, your document will not build, because empty files are not valid XML. For example, if Installation_and_configuration_on_Fedora.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_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.
To exclude this chapter, add a condition to the <xi:include> tag in User_Guide.xml, not to the <chapter> tag in Installation_and_configuration_on_Fedora.xml.

xrefs and conditional tagging

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 a prominent footer marked Confidential to each page. The default value is 0 (no footer).
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.
doc_url
provides a URL for the documentation team for this package. In multi-page 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 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 ‘ ’).
dt_obsoletes
specifies the desktop packages that this package obsoletes. Refer to Section 3.5, “Packaging a book”.
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.
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 ‘.’).
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.
ignored_translations
specifies translations to ignore. If you build or package a book in a language specified 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 Section 3.3, “Preparing a document for translation”.
license
specifies the license this package uses. By default, Publican selects the GNU Free Documentation License (GFDL). Refer to Section 3.5, “Packaging a book”.
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, the default value is .el5, which signifies Red Hat Enterprise Linux 5 and operating systems derived from it. Refer to Section 3.5, “Packaging a book” and Section 4.4, “Packaging a brand”.
prod_url
provides a URL for the product to which this document applies. In multi-page 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 Section 5.2, “Distributed sets”.
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 Section 5.2, “Distributed sets”.
show_remarks
controls whether to display remarks 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.
show_unknown
controls whether Publican reports unknown tags when processing XML. By default, this value is set to 1, so Publican reports unknown tags. Set this value to 0 to hide this output. Publican ignores this parameter in strict mode.
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 Section 3.5, “Packaging a book”.
strict
sets Publican to use strict mode, which prevents the use of tags that are unusable for professional output and translation. By default, the strict parameter is set of 0, which disables strict mode. To enable strict mode, set this parameter to 1 Strict mode is no longer enforced.
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.
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).
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 Section 3.5, “Packaging a book”.
web_obsoletes
specifies packages that the web RPM obsoletes. Refer to Section 3.5, “Packaging a book”.Refer to Section 3.5, “Packaging a book”.

Help from the command line

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

3.1.2. Book_Info.xml

Article_Info.xml and Set_Info.xml

This description of the Book_Info.xml file applies to Article_Info.xml and Set_Info.xml files too. However, for the sake of simplicity, the file is referred to as Book_Info.xml throughout this section.

Packages other than RPM packages

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.
The Book_Info.xml file contains the key metadata concerning a book: the book's ID; title; subtitle; author and edition number. It also contains the name and version of the product that is documented, and an abstract.
Aside from constituting much of a book's front matter, this metadata is also used when building books as RPM packages. Usually, if you distribute a book as an RPM package, several of the tags included by default in Book_Info.xml must have appropriate data within them, and that data must conform to the requirements of the RPM format. You can override the data in these tags by using equivalent fields in the publican.cfg file, as discussed in this section.
Unless overridden in the publican.cfg file, data from seven of the default tags in Book_Info.xml is required to build books as RPMs. Most immediately, the file name of a book built as an RPM package is constructed as follows: productname-title-productnumber-language-edition-pubsnumber.src.rpm. Everything but language above is pulled from Book_Info.xml — you specify language when you build the book. As well, the <subtitle> and <abstract> are used in the RPM spec file, to provide the Summary: field in the header and the %description field, respectively.
An example Book_Info.xml file, for the Test_Book book, is presented below. Details regarding this file, and what the RPM format requirements are for each tag, follow.
<?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 % BOOK_ENTITIES SYSTEM "Users_Guide.ent">
%BOOK_ENTITIES;
]>
<bookinfo id="book-Users_Guide-Users_Guide" lang="en-US">
	<title>Users Guide</title>
	<subtitle>Publishing books, articles, papers and multi-volume sets with DocBook XML</subtitle>
	<productname>Publican</productname>
	<productnumber>1.3</productnumber>
	<edition>1.3</edition>
	<pubsnumber>0</pubsnumber>
	<abstract>
		<para>
This book will help you install Publican. It also provides
instructions for using Publican to create and publish DocBook
XML-based books, articles and book sets. This guide assumes that
you are already familiar with 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 id="epub_cover" role="cover">
		<imageobject remap="lrg" role="front-large">
			<imagedata fileref="images/cover_thumbnail.png" format="PNG" width="444" />
		</imageobject>
		<imageobject remap="s" role="front">
			<imagedata fileref="images/cover_thumbnail.png" format="PNG" width="444" />
		</imageobject>
		<imageobject remap="xs" role="front-small">
			<imagedata fileref="images/cover_thumbnail.png" format="PNG" width="444" />
		</imageobject>
		<imageobject remap="cs" role="thumbnail">
			<imagedata fileref="images/cover_thumbnail.png" format="PNG" width="444" />
		</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="book_id">, <articleinfo id="article_id">, <setinfo id="set_id">
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>productname</productname>
The name of the product or product stream to which the book, article, or set applies, for example: Red Hat Enterprise Linux or JBoss Enterprise Application Platform. When building a book as an RPM package, data in the <productname> tag is used as part of the file name of the package.
Override this tag with the product variable in the publican.cfg file if the name of your product contains non-Latin characters, accented Latin characters, or punctuation marks other than the underscore.

Permitted characters

Publican uses data in this tag to generate part of the file name for RPM packages, unless overridden by data in the publican.cfg file. If you do not override this tag in the publican.cfg file, this tag must only contain upper- and lower-case un-accented letters, digits, and the underscore and space characters (‘a–z’, ‘A–Z’, ‘0’–‘9’, and ‘_’ and ‘ ’) if you plan to build packages with Publican.
<title>title</title>
Obviously enough, the title of the document (for example, Server Configuration Guide). The title appears under the product name in both HTML and PDF editions. A title is required to build an RPM package. When building a book as an RPM package the title is used as the part of the file name of the package.
Override this tag with the docname variable in the publican.cfg file if the title of your document contains non-Latin characters, accented Latin characters, or punctuation marks other than the underscore.

Permitted characters

Publican uses data in this tag to generate part of the file name for RPM packages, unless overridden by data in the publican.cfg file. If you do not override this tag in the publican.cfg file, this tag must only contain upper- and lower-case un-accented letters, digits, and the underscore and space characters (‘a–z’, ‘A–Z’, ‘0’–‘9’, and ‘_’ and ‘ ’) if you plan to build packages with Publican.
<subtitle>subtitle</subtitle>
Again, plainly enough, the subtitle tag contains a book's subtitle: an alternative, and commonly explanatory title for the book (for example: Server Configuration Guide: Preparing Red Hat Enterprise Linux for Production Use). The subtitle appears under the title in both HTML and PDF editions. A subtitle is also required to make a book available as an RPM package. When building a book as an RPM package, the subtitle is used as the Summary in the RPM spec file. The rpm -qi returns the contents of several spec file fields, including the Summary field.
<productnumber>productnumber</productnumber>
The version number of the product the book covers, for example ‘5.2’ for Red Hat Enterprise Linux 5.2 and ‘4.3’ for JBoss EAP 4.3.
Running the publican create --name Doc_Name --version version command correctly configures the product number.
Override this tag with the version variable in the publican.cfg file if the product version is anything other than a number.

Permitted characters

Publican uses data in this tag to generate part of the file name for RPM packages, unless overridden by data in the publican.cfg file. If you do not override this tag in the publican.cfg file, this tag must only contain numbers and the period (‘0–9’ and ‘.’) if you plan to build packages with Publican.
<edition>edition</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.
Override this tag with the edition variable in the publican.cfg file if the edition of your document is identified by anything other than a number.

Permitted characters

Publican uses data in this tag to generate part of the file name for RPM packages, unless overridden by data in the publican.cfg file. If you do not override this tag in the publican.cfg file, this tag must only contain numbers and the period (‘0–9’ and ‘.’) if you plan to build packages with Publican.
<pubsnumber>pubsnumber</pubsnumber>
The pubsnumber changes the release number (the last digit) 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.
Override this tag with the release variable in the publican.cfg file if the release number of your document contains anything other than whole numbers.

Permitted characters

Publican uses data in this tag to generate part of the file name for RPM packages, unless overridden by data in the publican.cfg file. If you do not override this tag in the publican.cfg file, this tag must only contain numbers (‘0–9’) if you plan to build packages with Publican.
<abstract><para>abstract</para></abstract>
A short overview and summary of the book's subject and purpose, traditionally no more than a paragraph long. The abstract appears before the table of contents in HTML editions and on the second page of PDF editions. When a book is built as an RPM package, the abstract sets the Description field of the RPM's spec file. This makes the abstract for a package available via the rpm -qi command.
You can add extra metadata to the Book_Info.xml file of a document, to support specific features in various output formats:
<keywordset>, <keyword>
Terms tagged with <keyword> and placed within a <keywordset> are added to a <meta name="keywords"> entry in the head of HTML files and to the Keywords field of the properties of a PDF document.
<subjectset>, <subject>
Terms tagged with <subject> and placed within a <subjectset> are added to the Subject field of the properties of a PDF document and in the metadata of an ebook in EPUB format.
Consider using a controlled vocabulary when defining the subject of your document, for example, the Library of Congress Subject Headings (LCSH). Identify the chosen vocabulary with the scheme attibute in the <subjectset> tag, for example, <subjectset scheme="libraryofcongress">. You can search for LCSH subject headings through the Library of Congress Authorities & Vocabularies page: http://id.loc.gov/authorities/search/.
<mediaobject role="cover" id="epub_cover">
Use a <mediaobject> tag with the role="cover" and id="epub_cover" attributes to set cover art for an ebook in EPUB format. For example:
<mediaobject role="cover" id="epub_cover">
	<imageobject role="front-large" remap="lrg">
		<imagedata width="600px" format="PNG" fileref="images/front_cover.png"/>
	</imageobject>
	<imageobject role="front" remap="s">
		<imagedata format="PNG" fileref="images/front_cover.png"/>
	</imageobject>
	<imageobject role="front-small" remap="xs">
		<imagedata format="PNG" fileref="images/front_cover.png"/>
	</imageobject>
	<imageobject role="thumbnail" remap="cs">
		<imagedata format="PNG" fileref="images/front_cover_thumbnail.png"/>
	</imageobject>
</mediaobject>
As with all the other images in your document, place the cover images in the images subdirectory.

3.1.2.1. RPM packages, editions, impressions and versions

As noted above, the default Book_Info.xml used by Publican includes an <edition> tag.
If you distribute a book as an RPM package, the data placed within this tag sets 'the first two digits of the version number in the RPM file name.
So, an edition of '1.0' becomes a version of '1.0'.
Book_Info.xml also includes the <pubsnumber> tag. Any data placed within this tag changes the release number of RPM-packaged books.
A book with an edition of 1.0 and a pubsnumber of 5, would be version 1.0, release 5 (1.0-5).
The edition and pubsnumber are not tied to the <productnumber> tag also found in Book_Info.xml: <productnumber> denotes the version number of the product being documented or otherwise written about.
It is entirely possible to have a 2nd edition of a book pertaining to a particular version of a product.
In bibliography, two copies of a book are the same edition if they are printed using substantially the same type-set master plates or pages. ('Substantially' offers some allowance for typo corrections and other inconsequential changes.)
Book collectors routinely conflate 'first edition' with 'first print run', while bibliographers pay attention to the text commonly placed in the front matter of a book, which calls a 2nd print run off the same (or substantially the same) plates a '1st edition, 2nd impression' or '1st edition, 2nd printing'.
We recommend following bibliographic practice in this regard. When using Publican to re-publish a book from 'substantially the same XML', increment the <pubsnumber> tag, not the <edition> tag. It functions as a near-equivalent to the impression or printing number of traditional publishing.
As for changing the edition number, we recommend changing this in the same circumstances traditional publishers change the edition of a work: when it is revised and re-written significantly. What constitutes significant, and how much re-writing is needed to increment an edition number by a whole number and how much is needed to increment it by one-tenth of a whole number, is a matter of editorial discretion.

3.1.3. Author_Group.xml

Author_Group.xml is not required but is the standard place to record author, editor, artist and other credit details. The following is an example Author_Group.xml file:
<?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>

Author_Group.xml does not have to contain all of the above information: include as much or as little as required.

3.1.4. Chapter.xml

Articles and chapters

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.
Refer to DocBook: The Definitive Guide by Norman Walsh and Leonard Muellner available at http://www.docbook.org/tdg/en/html/docbook.html for details of the different ways that sets, books, articles, parts, chapters, and sections interact. In particular, note that articles can be stand-alone documents, or can be incorporated into books.
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>


This chapter has two sections, Section 1 Test and Section 2 Test. Refer to http://docbook.org/tdg/en/html/chapter.html for further information about chapters.

Note

The chapter file should be renamed to reflect the chapter subject. For example, a chapter on product installation could be named Installation.xml, whereas a chapter on setting up a piece of software would be better called Setup.xml or Configuration.xml.

3.1.5. Doc_Name.xml

The Doc_Name.xml file contains xi:include directives to include the other necessary XML files for the document, including chapters or sections contained in other XML files. For example, a book's Doc_Name.xml file brings together chapters that are contained in separate XML files.
The following is an example Doc_Name.xml file that describes a DocBook book — note the DOCTYPE is set to book.
<?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>


This example loads the Book_Info.xml, Preface.xml, Chapter.xml, and Appendix.xml XML files.

Important

The order in which chapters are listed matters. When this example book is built, Book_Info.xml will precede Preface.xml which will precede Chapter.xml, and so on.
The Doc_Name.xml file is not limited to using xi:include directives. You can create documents with a single XML file. The following is an example of a book created using a single XML file:
<book>

<chapter>
<title>Chapter 1</title>
<para>
	A paragraph in Chapter 1.
</para>
<section id="section1">
<title>Chapter 1 Section 1</title>
	<para>
		A paragraph in Section 1.
	</para>
</section>
<section id="section2">
<title>Chapter 1 Section 2</title>
	<para>
		A paragraph in Section 2.
	</para>
</section>
</chapter>

<chapter>
<title>Chapter 2</title>
<para>
	A paragraph in Chapter 2.
</para>
</chapter>

</book>
This book contains two chapters. Chapter one contains two sections. Refer to http://docbook.org/tdg/en/html/section.html for further information about sections, and http://docbook.org/tdg/en/html/book.html for further information about books.

3.1.6. Doc_Name.ent

The Doc_Name.ent file is used to define local entities. The YEAR and HOLDER entities are used for copyright information. By default, Publican sets YEAR to the current year, and inserts a message into HOLDER to remind you to specify the copyright holder for the document. If the YEAR and HOLDER entities are missing altogether, the document will not build.
Other entities might be required by the brand applied to your document. For example, the Publican brand for Fedora documents uses the entity BOOKID to specify how readers should refer to a document when they submit feedback about it.
<!ENTITY PRODUCT "MYPRODUCT">
<!ENTITY BOOKID "MYBOOK">
<!ENTITY YEAR "2008">
<!ENTITY HOLDER "YOUR NAME GOES HERE">


3.1.6.1. Entities and translation

Use entities with extreme caution

Entities offer convenience but they should be used with extreme caution in documents that will be translated. Writing (for example) &FDS; instead of Fedora Directory Server saves the writer time but transformed entities do not appear in the portable object (PO) files that translators use. Complete translations of documents containing entities are, as a consequence, impossible.
Entities present special obstacles to translators and can preclude the production of high-quality translations. The very nature of an entity is that the word or phrase represented by the entity is rendered exactly the same way every time that it occurs in the document, in every language. This inflexibility means that the word or word group represented by the entity might be illegible or incomprehensible in the target language and that the word or word group represented by the entity cannot change when the grammatical rules of the target language require them to change. Furthermore, because entities are not transformed when XML is converted to PO, translators cannot select the correct words that surround the entity, as required by the grammatical rules of the target language.
If you define an entity — <!ENTITY LIFT "Liberty Installation and Formatting Tome"> — you can enter &LIFT; in your XML and it will appear as Liberty Installation and Formatting Tome every time the book is built as HTML, PDF or text.
Entities are not transformed when XML is converted to PO, however. Consequently, translators never see Liberty Installation and Formatting Tome. Instead they see &LIFT;, which they cannot translate.
Consider something as simple as the following English sentence fragment being translated into a related language: German.
As noted in the Liberty Installation and Formatting Tome, Chapter 3…
A translation of this might be as follows:
Wie in dem Wälzer für die Installation und Formatierung von Liberty, Kapitel 3, erwähnt…
Because there is no text missing, the title can be translated into elegant German. Also, note the use of ‘dem’, the correct form of the definite article ('the') when referring to a Wälzer ('tome') in this grammatical context.
By contrast, if entities are used, the entry in the PO file says:
#. Tag: para
#, no-c-format
msgid "As noted in the <citetitle>&LIFT;</citetitle>, Chapter 3…"
msgstr ""
The translation of this would probably run thus:
#. 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…"
And the presentation would be thus:
Wie in Liberty Installation and Formatting Tome, Kapitel 3, erwähnt…
This, of course, leaves the title in English, including words like 'Tome' and 'Formatting' that readers are unlikely to understand. Also, the translator is forced to omit the definite article ‘dem’, a more general construction that comes close to a hybrid of English and German that German speakers call Denglisch or Angleutsch. Many German speakers consider this approach incorrect and almost all consider it inelegant.
Equivalent problems emerge with a fragment such as this:
However, a careful reading of the Liberty Installation and Formatting Tome afterword shows that…
With no text hidden behind an entity, a German translation of this might be:
Jedoch ergibt ein sorgfältiges Lesen des Nachworts für den Wälzer für die Installation und Formatierung von Liberty, dass…
If an entity was used to save the writer time, the translator has to deal with this:
#. Tag: para
#, no-c-format
msgid "However, a careful reading of the <citetitle>&LIFT;</citetitle> afterword shows that…"
msgstr ""
And the translation would be subtly but importantly different:
#. 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…"
When presented to a reader, this would appear as follows:
Jedoch ergibt ein sorgfältiges Lesen des Nachworts für Liberty Installation and Formatting Tome, dass…
Again, note the missing definite article (den in this grammatical context). This is inelegant but necessary since the translator can otherwise only guess which form of the definite article (den, die or das) to use, which would inevitably lead to error.
Finally, consider that although a particular word never changes its form in English, this is not necessarily true of other languages, even when the word is a proper noun such as the name of a product. In many languages, nouns change (inflect) their form according to their role in a sentence (their grammatical case). An XML entity set to represent an English noun or noun phrase therefore makes correct translation impossible in such languages.
For example, if you write a document that could apply to more than one product, you might be tempted to set an entity such as &PRODUCT;. The advantage of this approach is that by simply changing this value in the Doc_Name.ent file, you could easily adjust the book to document (for example) Red Hat Enterprise Linux, Fedora, or CentOS. However, while the proper noun Fedora never varies in English, it has six different forms in Czech, depending on one of seven ways that you can use it in a sentence:
Case Usage Form
Nominative the subject of a sentence Fedora
Genitive indicates possession Fedory
Accusative the direct object of a sentence Fedoru
Dative the indirect object of a sentence Fedoře
Vocative the subject of direct address Fedoro
Locative relates to a location Fedoře
Instrumental relates to a method Fedorou
Table 3.1. 'Fedora' in Czech

For example:
  • Fedora je linuxová distribuce. — Fedora is a Linux distribution.
  • Inštalácia Fedory — Installation of Fedora
  • Stáhnout Fedoru — Get Fedora
  • Přispějte Fedoře — Contribute to Fedora
  • Ahoj, Fedoro! — Hello Fedora!
  • Ve Fedoře 10… — In Fedora 10…
  • S Fedorou získáváte nejnovější… — With Fedora, you get the latest…
A sentence that begins S Fedora získáváte nejnovější… remains comprehensible to Czech readers, but the result is not grammatically correct. The same effect can be simulated in English, because although English nouns lost their case endings during the Middle Ages, English pronouns are still inflected. The sentence, 'Me see she' is completely comprehensible to English speakers, but is not what they expect to read, because the form of the pronouns me and she is not correct. Me is the accusative form of the pronoun, but because it is the subject of the sentence, the pronoun should take the nominative form, I. Similarly, she is nominative case, but as the direct object of the sentence the pronoun should take its accusative form, her.
Nouns in most Slavic languages like Russian, Ukrainian, Czech, Polish, Serbian, and Croatian have seven different cases. Nouns in Finno–Ugaric languages such as Finnish, Hungarian, and Estonian have between fifteen and seventeen cases. Other languages alter nouns for other reasons. For example, Scandinavian languages inflect nouns to indicate definiteness — whether the noun refers to 'a thing' or 'the thing' — and some dialects of those languages inflect nouns both for definiteness and for grammatical case.
Now multiply such problems by the more than 40 languages that Publican currently supports. Other than the few non-translated strings that Publican specifies by default in the Doc_Name.ent file, entities might prove useful for version numbers of products. Beyond that, the use of entities is tantamount to a conscious effort to inhibit and reduce the quality of translations. Furthermore, readers of your document in a language that inflects nouns (whether for case, definiteness, or other reasons) will not know that the bad grammar is the result of XML entities that you set — they will probably assume that the translator is incompetent.

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