tcar-render(1)
==============
Name
----
tcar-render - Standardize production tasks based on configuration files.
Synopsis
--------
tcar render [OPTIONS] [DIRECTORY ...]
Description
-----------
When you execute the *render* command, it looks for configuration
files inside the ``DIRECTORY'' specified in the command-line and
processes them in the order they were found. When no ``DIRECTORY'' is
specified to *tcar* script, the *render* module looks for
configuration files inside the current directory it was executed from.
If no configuration file is found, the *render* module will end its
execution with an error message.
Options
-------
The *render* module accepts the following options:
*--help*::
Print module's documentation.
*--version*::
Print module's version.
*--filter="REGEX"*::
This option reduces the number of section blocks inside
configuration files the *render* module will take for processing.
``REGEX'' is a regular expression pattern matching one or more
section names inside the configuration files found under
``DIRECTORY''.
Configuration Files
-------------------
The configuration files are regular files with the +.conf+ extension.
The name of configuration files is frequently chosen for helping you
to remember what the configuration files are for and, in some cases,
for producing section blocks in specific order.
The format used in configuration files use section blocks in the form
+[section-name]+. Each section block ends when the next section block
begins or at the end of the file. Section blocks contain one or more
variable definitions in the form +option = "value"+. In the specific
case of *render* module, the +section-name+ is an alphanumeric value
and points to the final file or directory you want to save the
processing results in. The configuration variables describe how to
produce the file or directory specified as +section-name+. Name
values in the +section-name+ don't accept variables or any kind of
expansion in it, but configuration values do. Commentaries are
introduced by using the +#+ character at the beginning of lines.
Commentaries defined this way are excluded from processing so you can
use them freely.
The configuration files are processed from top to bottom. This is a
very important aspect to consider in situations where you need to
grantee specific priority for content production (e.g., you have
several files in a configuration file and need to produce some of them
before others). So, because configuration files are processed from top
to bottom, section blocks set first in the configuration file are
processed first and section blocks set later are processed later.
The configuration files can be divided in separated configuration
files to produce specific section blocks with a given priority. For
example, if you have the file ``render.conf'', you can divide its
content in ``render-1.conf'', ``render-2.conf'' to produce section
blocks inside ``render-1.conf'' first and ``render-2.conf'' later.
This sort of division might be very useful when the configuration file
begins to grow, or you want to control the order in which specific
groups of files are produced inside ``DIRECTORY''.
Inside configuration files, configuration variables can take different
meanings based on the section contexts. The context of a section block
is defined by the *render-type* variables.
*render-type*::
Optional. This variable specifies the type of content rendition
the *render* module will perform. This variable can take one of
the following values: ``archive'', ``asciidoc'', ``compress'',
``images'', ``palette'', and ``svg''. When this variable is not
set, the *render* module tries to determine the type of rendition
based on the file extension of the first file passed through
*render-from* variable. If no valid value is found there either,
the *render* module ends with an error message.
*render-from*::
Required. This variable specifies the file name of the source file
(design model) used to produce the final file specified in the
section line. This option can receive absolute paths and relative
paths. Absolute paths begin with a slash (``/'') character while
relative paths begin with the dot slash (``./'') characters or no
character at all. This variable can receive more than one value by
using either path expansion in one variable definition, or several
variables definitions.
Using Paths
~~~~~~~~~~~
When you provide absolute paths inside configuration files, there
isn't confusion about the location where the file is or should be.
However, it introduces rigidity to directory structures inside the
working copy when it is necessary to move directories from one place
to another inside the working copy. To eliminate this mobility
restrictions, relative paths can be used to create modular directory
structures.
When you use relative paths inside configuration files, paths are
relative to the location where the configuration file is stored in.
This way it is possible to move whole directory structures without
touching the configuration file and still have a render-able
structures inside the working copy. However, relative paths get
limited in situations where the production process needs files outside
the directory where the configuration file is stored in. In such
cases, a combination of relative and absolute paths is the solution to
apply.
When we need to use absolute paths to several files in the same
directory (e.g., we are combining them all to produce a new image) but
outside the current directory the configuration file is stored in, it
is possible to use a list of absolute paths one beside another
separated by space or we can use path expansion which is shorter and
easier to read. Path expansion is interpreted when you enclose a list
of file names in curly brackets using comma as separator without
spaces (e.g., +/some/dir/{file1,file2,file3}+). In order for path
expansion to work correctly, all the file names you put inside the
curly brackets' list must exist in the location specified first.
Using Environment Variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The configuration files let you to use environment variables inside
them. This might result very useful when you need to provide absolute
paths based on variable information (e.g., the current locale
information). Some of the most important environment variables used
by *tcar* script -and its configuration files- are described
below:
+TCAR_BASEDIR+::
This variable contains the absolute path to your repository's
working copy. The value of this variable is defined as read-only
inside *tcar* script and cannot be modified later. As a
matter of convenience, users make use of their ``~/.bash_profile''
file to define this variable there and, this way, skip the
sometimes annoyance absolute path questioning the *tcar*
script does in order to know the absolute path of the working copy
it is going to work with.
+
Whenever you set absolute paths inside configuration files to refer
locations inside your working copy, it is necessary that you use the
+TCAR_BASEDIR+ environment variable in front of each path definition
you set.
+TCAR_SCRIPT_LANG_LL+::
This variable contains the language part of the current locale
information. For instance, if the current locale is
``en_US.UTF-8'', the value of this variable would be ``en''.
+TCAR_SCRIPT_LANG_CC+::
This variable contains the country part of the current locale
information. For instance, if the current locale is
``en_US.UTF-8'', the value of this variable would be ``US''.
+TCAR_SCRIPT_LANG_LC+::
This variable contains the current locale information in ll_CC
format (e.g., es_ES).
+LANG+::
This variable contains the environment's current locale
information.
Rendering Archives
~~~~~~~~~~~~~~~~~~
When the *render-type* variable is set to +archive+, the *render*
module takes the list of files set through *render-from* variable and
applies the value of *command* to them all in order to produce the
final file specified in the section line. When the command variable is
not specified, the +/bin/tar --remove-files -czf+ command is used as
default.
Rendering Image Files
~~~~~~~~~~~~~~~~~~~~~
When the *render-type* variable is set to +svg+, the section block is
interpreted for rendering image files. When rendering image files, the
*render-from* variable must point to a SVG files (either compressed or
uncompressed). The following following complementary variables are
also accepted:
*render-flow*::
Optional. This variable specifies the rendition flow to follow
when transforming SVG files into PNG images. This variable can
take either +base+ or +extended+ as value. The +base+ rendition
flow takes one SVG file and produces just one PNG image for it.
The +extended+ value applies the +base+ rendition flow and then
transform the final PNG image to different heights, formats,
foreground colors and background colors. By default, when this
variable is not set, the +base+ rendition flow is used.
*export-id*::
Optional. This variable specifies the export id you want to use as
reference to produce PNG images from SVG files. The export-id is
an attribute you specified as unique value to an objects inside
the SVG file in order to export that object only but not the rest
in the SVG file. If this variable is not provided or it is empty,
the drawing area of the SVG file is used as reference to produce
the final PNG image.
*heights*::
Optional. This variable is available only for +extended+ rendition
flow and specifies the different image heights you want to create
copies of the final PNG image. The values specified in this
variable are separated by white space and should be understandable
by ImageMagick tool set. When this variable is not provided, the
*render* module will create copies of final PNG image for several
standard heights.
*formats*::
Optional. This variable is available only for +extended+ rendition
flow and specifies the different image formats you want to create
copies of the final PNG image. The values specified in this
variable are separated by white space and should be supported by
ImageMagick tool set. When this variable is not provided or set
in the configuration file, the *render* module will create copies
of final PNG image for several standard formats.
+
[TIP]
To see the list of possible image formats supported by ImageMagick
tool set, run the following command: *+identify -list format+*.
*fgcolors*::
Optional. This variable is available only for +extended+ rendition
flow and specifies the different foreground colors you want to
create copies of the final PNG image. To do this, the image you
want to copy should be rendered with black color (000000) so the
color replacement can be performed. The values specified in this
variable are separated by white space and should be understandable
by ImageMagick tool set. When this variable is not provided the
black foreground (+000000+) is used.
*bgcolors*::
Optional. This variable is available only for +extended+ rendition
flow and specifies the different background colors you want to
create copies of the final PNG image. This variable uses
Inkscape's _--export-background_ and _--export-background-opacity_
options to control the background information of final PNG images.
Possible values to this variable take the form +XXXXXX-X+, where
the first six +X+ represent a color in hexadecimal format and the
final +X+ might be 1 or 0. 1 for full opacity and 0 for full
transparency. Intermediate values between 0 and 1 (e.g., 0.55)
can be given to control the background opacity. When this variable
is not provided, white background full transparency (+ffffff-0+)
is used as default value.
*command*::
Optional. This variable specifies the command used to modify the
production of final images. During the rendition process, images
are produced inside a temporal directory, and later moved to its
final location using the command specified as value in this
variable. When this variable is not specified, it can take one of
two values based on the amount of files passed through
*render-from* variable. When just one file is passed through the
*render-from* variable, the default value for this variable is
+/bin/cp+, but when there are reference to more than one file, the
value of this option is +/usr/bin/convert +append+ which combines
all images into the final images.
*comment*::
Optional. This variable contains a sentence describing the image
you are creating. This information is written in the +comment+
field of PNG images. When this variable is empty, no comment
information will be written to the final PNG image files.
*brand*::
Optional. This variable describes the branding information applied
to final images. The value of this variable has the form
+FILENAME:GEOMETRY+, where +FILENAME+ is the absolute path to the
PNG image you want to apply as brand and, +GEOMETRY+ takes the
form +xHEIGHT+X+Y+. In order to apply brand information to final
images correctly, the brand images files you want to apply must be
available. In case they don't exist the *render* module ends its
execution with an error message.
Rendering Image Files From Other Image Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To render image files from other image files, the *render-type*
variable must be set to ``images'' and one or more image files must be
provided in the *render-from* variable. When the *render* module finds
a section block with this characteristics, it applies the value of
*command* variable to all files found in *render-from* variable to
produce the final file specified in the section name.
When the *command* variable is not specified, the ``/usr/bin/convert
-append'' command is used as default. This command takes all the
images passed through *render-from* and appends them from top to
bottom and saves the result in the file you specified in the section
name. When you render files this way, the order in which you define
source files through *render-from* may affect the final result based
in the *command* you provided.
The ``images'' rendition type provides an interface for external image
manipulation programs, like ImageMagick and NetPbm. You can use these
programs to manipulate images in great detail through the
command-line.
Rendering Images With Reduced Number Of Colors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When the *render-type* variable is set to +palette+, the section block
where this variable was defined is interpreted for producing images
with a reduced number of colors. In these cases, the *render-from*
variable must point to an image file. The following complementary
variables are also accepted:
*palette-gpl*::
Required. This variable addresses the palette of colors that will
be use for reducing colors. Generally, the palette of color file
ends with the +.gpl+ extension and is stored in the same directory
of the configuration file. This file can be produced by GIMP and
provides an optimized set of colors for the specific image you
provided in the *render-from* variable.
+
To find the optimized set of colors, you need to open the image
specified in *render-from* in GIMP, reduce its colors to the desired
number using GIMP's Indexed feature and, then, create a new palette by
importing it from the indexed image file. Once you have the palette
this way, you need to edit it using the Palettes dialog to add the
hexadecimal value of each color in the palette to the comment field,
so you have a palette file similar to the following:
+
----------------------------------------------------------------------
GIMP Palette
Name: Syslinux-Default
Columns: 16
#
32 76 141 204c8d
37 82 146 255292
52 94 153 345e99
73 110 162 496ea2
91 124 172 5b7cac
108 136 180 6c88b4
120 146 186 7892ba
131 158 193 839ec1
255 255 255 ffffff
146 170 200 92aac8
162 182 209 a2b6d1
183 199 219 b7c7db
204 216 230 ccd8e6
221 229 238 dde5ee
235 241 245 ebf1f5
246 251 254 f6fbfe
----------------------------------------------------------------------
+
{asciidoc-br}
+
Now that the palette has been created, you can set a path to
*palette-gpl* variable. Even you can set path of *palette-gpl* from
GIMP's palettes directory (+~/.gimp-x.x/palettes/+), it is much more
preferable that you copy the palette file from that location to the
configuration file's DIRECTORY inside the repository and put it under
version control, so others can take benefit of it. The palette file
is an integral part of color specific image reduction so it must be
near the configuration file you use for such actions.
Rendering Documentation Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To render documentation files, the *render-type* variable must be set
to ``asciidoc'' and the *render-from* variable must point to an
Asciidoc file. When the *render* module finds this information in a
section block, it takes the asciidoc file as source and transforms it
into a docbook file using the *asciidoc* program. The docbook file is
created temporarily for further format transformations and removed
later, once the final format has been rendered.
When the *render* module creates the intermediate docbook file, it
considers the current locale information of your environment (e.g., by
reading the LANG environment variable). In case the current locale
information is different to English (e.g., the value of LANG
environment variable doesn't begin with the ``en'' characters), the
docbook file will be localized based on the translation file specified
in the *locale-from* variable, before applying further format
transformations to it. This way, further format transformations from
the temporarily docbook file will end up being localized as well. If
the *locale-from* variable is not present in the section block, the
intermediate docbook file won't be localized which make the final
result to be not localized either.
When you set the *render-type* variable to ``asciidoc'', the section
blocks need to have the *render-flow* variable set to ``article'',
``book'' or ``manpage''. This information defines the way the
intermediate docbook file is produced from the asciidoc file and, by
extension, the possible final results, too.
When *render-flow* variable is set to ``article'' or ``book'', it is
possible to produce final files in ``xhtml'' format but not in
``manpage'' format. This is because man pages require a specific
document structure that both articles and books don't need to have.
When producing articles and books in XHTML format, you can use the
*render-page* variable to control whether to produce the entire book
or article in just one file (``single'') or in separate files linked
one another (``chunks'').
When *render-flow* variable is set to ``manpage'' it is possible to
set the *formats* variable to either ``manpage'' or ``xhtml'' in order
to render the docbook file as man page or XHTML format, respectively.
The final files produced this way are stored in the +man${MANSECT}/+
or +htmlman${MANSECT}+ directories based on the format you choose. If
you are producing man pages to a language different to English, these
directories would be +${LANG}/man${MANSECT}/+ and
+${LANG}/htmlman${MANSECT}+, instead. The structure of these paths is
required in order for *man* command to find the man pages in different
locales. The value of the man's volume section can be set using the
*mansect* variable. If this variable is not set, the value of man's
volume section will be 1.
When *render-flow* variable is not set, the ``article'' value is used
as default value.
When the *formats* variable has the ``xhtml'' value, you need to set
the *images-from* and *styles-from* variables inside the related
section block, no matter what the value of *render-flow* would be. The
value of *images-from* and *styles-from* variables must point to a
directory, inside the working copy, containing the share images and
CSS files used by XHTML documents, respectively. If none of these two
variables are set the directories
+${TCAR_BASEDIR}/Artworks/Icons/Webenv+ and
+${TCAR_BASEDIR}/Artworks/Webenv/Docbook/1.69.1/Css+ will be used for
them.
When the *formats* variable is not set, the ``xhtml'' value is used as
default value.
Rendering Localized Images
--------------------------
To produce localized content, you need to set the *locale-from*
variable in the section block you want to provide translations and
point its value to the translation file where string translations will
take place. Then, you need to check the value of LANG environment
variable to be sure it has the locale information you want to
translate messages for.
If the LANG environment variable has the value you expect, run the
*locale* module on the ``DIRECTORY'' you want to locale content. This
read the source files you specified in *render-from* variable and
would create the translation files (a.k.a., portable objects) you need
to edit to provide the string translations from one language to
another. Verify the translation file exist and edit it to provide the
strings translations. Once the strings have been translated, execute
the *render* module on the ``DIRECTORY''.
When the *render* module finds the *locale-from* variable in a section
block, it uses the *xml2po* program to create a localized instance of
each source file it finds in *render-from* variable. Then, using the
source files' localized instances, it produces the final files based
on *render-type* variable's value.
Examples
--------
Here are some practical configuration examples you can use as
reference to create your own configuration files.
----------------------------------------------------------------------
[Xhtml-single]
render-type = "asciidoc"
render-flow = "article"
render-from = "corporate.asciidoc"
locale-from = "${TCAR_SCRIPT_LANG_LC}/messages.po"
images-from = "${TCAR_BASEDIR}/Artworks/Icons/Webenv"
styles-from = "${TCAR_BASEDIR}/Artworks/Webenv/Docbook/1.69.1/Css"
formats = "xhtml"
render-page = "single"
----------------------------------------------------------------------
{asciidoc-br}
When the *render* module reads this configuration file, it initiates
the +asscidoc+ module which in turn initiates the +xhtml+ module for
transforming the +corporate.asciidoc+ file into +corporate.docbook+ file
using +article+ as document type and
+${TCAR_SCRIPT_LANG_LC}/messages.po+ as source for localization. As
result, the *render* module produces the
+${TCAR_SCRIPTS_LANG_LC}/Xhtml-single/index.html+ file, using the same
directory of the configuration file as base directory.
----------------------------------------------------------------------
[centos-artwork.png]
render-from = "${TCAR_BASEDIR}/Artworks/Brands/Types/Webenv/centos.org/{centos,artwork}.svgz"
formats = "xpm pdf jpg tif"
heights = "16 20 22 24 32 36 38 40 48 64 72 78 96 112 124 128 148 164 196 200 512"
fgcolors = "000000 ffffff"
bgcolors = "ffffff-0"
command = "/usr/bin/convert +append"
----------------------------------------------------------------------
{asciidoc-br}
When the *render* module reads this configuration file, it takes the
+centos.svgz+ and +artwork.svgz+ files as source to produce the
+centos.png+ and +artwork.png+ files considering the first value in
the list of heights, background, foreground colors specified in the
configuration file. Then, it combines the results horizontally to
create the +centos-artwork.png+ file. Later, the +centos-artwork.png+
file is converted to produce one image file for each image format
specified in the configuration file. At this point, all the process
repeats again but for the next height and color values in the list.
{asciidoc-br}
----------------------------------------------------------------------
[syslinux-splash.png]
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Syslinux/syslinux-splash.svgz"
brand = "${TCAR_BASEDIR}/Artworks/Brands/Types/Default/Images/ffffff/ffffff-0/48/centos.png:x48+20+232"
brand = "${TCAR_BASEDIR}/Artworks/Brands/Types/Numbers/Images/ffffff/ffffff-0/96/5.png:x96+300+184"
[syslinux-splash.lss]
render-from = "syslinux-splash.png"
render-type = "palette"
palette-gpl = "colors.gpl"
----------------------------------------------------------------------
{asciidoc-br}
When the *render* module reads this configuration file,
----------------------------------------------------------------------
[screenshot.png]
render-type = "svg"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/screenshot.svgz"
render-flow = "base"
brand = "${TCAR_BASEDIR}/Artworks/Brands/Symbols/Default/Images/ffffff/ffffff-0/16/centos.png:x16+5+5"
[800x600.tar.gz]
render-type = "archive"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Motifs/${MOTIF}/Backgrounds/Images/800x600-final.png:background.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/GdmGreeterTheme.desktop"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/GdmGreeterTheme.xml"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-language.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-reboot.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-session.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-shutdown.png"
render-from = "screenshot.png"
command = "/bin/tar -czf"
[1360x768.tar.gz]
render-type = "archive"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Motifs/${MOTIF}/Backgrounds/Images/1360x768-final.png:background.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/GdmGreeterTheme.desktop"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/GdmGreeterTheme.xml"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-language.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-reboot.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-session.png"
render-from = "${TCAR_BASEDIR}/Artworks/Themes/Models/Distro/5/Gdm/icon-shutdown.png"
render-from = "screenshot.png"
command = "/bin/tar --remove-files -czf"
----------------------------------------------------------------------
{asciidoc-br}
When the *render* module reads this configuration file,
Bugs
----
The *render* module has some issues I would like you to be aware of.
Mainly, to see if you could help me find better solutions for them ;)
Rendering Images With Reduced Number Of Colors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The process implemented to reduce image colors through GIMP's palettes
involves too much user intervention compared with ImageMagick's
--colors option that reduces image colors instantly without user
intervention. Nevertheless, the procedure of reducing color through
GIMP's palettes provides more quality to final images than
ImageMagic's --colors option does. Also, using GIMP's palettes let us
create LSS images from PNG images using the same exact information we
used to reduce colors on PNG images. This is very important in order
to have the same result in both image types. Because of these reasons
I prefer GIMP's palettes procedure against others methods like it is
the case of ImageMagick's for producing images with reduced number of
colors.
Rendering PDF Files From Localized Docbook Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Even it is possible to produce PDF files from Docbook files using
current applications inside CentOS-5, there are some production issues
when we use localized docbook files as source to produce localized PDF
files that made me not to implement them as part of *tcar* script by
now.
- When using the XML(DocBook)->XML(FO)->PDF transformation chain, the
result produced by _docbook-style-xsl-1.69.1-5.1_ and
_passivetex-1.25-5.1.1_ doesn't render heading boxes very well on
page's top and page's bottom. The text put inside these boxes seem
to have not enough space in their respective areas.
- Tried using _dblatex-0.2.8-2.el5_ but didn't work for localized docbook files
(i.e., those who has the +lang="lang"+ string in their root
element). If you just remove the language specification string it
just work. We need the language specification in order for internal
document strings like +Abstract+ and +Table of contents+ to be
automatically translated. When the language specific attribute is
present in the root element, dblatex outputs the following:
+
----------------------------------------------------------------------
Build the listings...
XSLT stylesheets DocBook - LaTeX 2e (0.2.8)
===================================================
Processing Revision History
Build 2912-corporate.docbook.pdf
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
pdflatex failed
/usr/share/texmf/tex/latex/dblatex/docbook.sty:160: No counter 'chapter' defined.
/usr/share/texmf/tex/latex/dblatex/docbook.sty:160: leading text: \newfloat{example}{htb}{loe}[chapter]
/usr/share/texmf/tex/latex/dblatex/docbook.sty:164: No counter 'chapter' defined.
/usr/share/texmf/tex/latex/dblatex/docbook.sty:164: leading text: \newfloat{dbequation}{htb}{loe}[chapter]
2912-corporate.docbook_tmp.tex:62: Illegal parameter number in definition of \@the@H@page.
2912-corporate.docbook_tmp.tex:62: leading text: \maketitle
2912-corporate.docbook_tmp.tex:62: Illegal parameter number in definition of \@the@H@page.
2912-corporate.docbook_tmp.tex:62: leading text: \maketitle
2912-corporate.docbook_tmp.tex:62: Illegal parameter number in definition of \@the@H@page.
2912-corporate.docbook_tmp.tex:62: leading text: \maketitle
Error: pdflatex compilation failed
----------------------------------------------------------------------
Reporting Bugs
--------------
Report bugs on the *automation* category of *centos-artwork* project
at the https://centos.org.cu/bugs/[The CentOS Bugs] website.
Author
------
Written by mailto:al@centos.org.cu[Alain Reguera Delgado], 2009-2013
Copyright
---------
Copyright (C) 2009-2013 The CentOS Project
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
// vim: set syntax=asciidoc: