render(1)

=========

Name

----

render - Standardize production tasks based on configuration files.

Synopsis

--------

centos-art.sh render [OPTIONS] [DIRECTORY ...]

Description

-----------

When you execute the *render* module, 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 *centos-art.sh* 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 *centos-art.sh* 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 *centos-art.sh* 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 *centos-art.sh*

    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 *centos-art.sh*

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: