The CentOS Artwork Repository started during a discussion about how to
automate the slide images of Anaconda, at CentOS Developers mailing
list (@email{centos-devel@@centos.org}) around 2008. In such
discussion, Ralph Angenendt rose up his hand to ask ---Do you have
something to show?---.

To answer the question, Alain Reguera Delgado suggested a bash script
which combined SVG and SED files in order to produce PNG images in
different languages ---in conjunction with the proposition of creating
a Subversion repository where translations and image production could
be distributed inside The CentOS Community---.

Karanbirn Sighn considered the idea intresting and provided the
infrastructure necessary to support the effort. This way the CentOS
Artwork SIG (@url{https://projects.centos.org/trac/artwork/}) and the
CentOS Artwork Repository
(@url{https://projects.centos.org/svn/artwork/}) were officially
created.

Once the CentOS Artwork Repository was available, Alain Reguera
Delgado uploaded the bash script for rendering Anaconda slides; Ralph
Angenendt documented it very well; and people started to download
working copies of CentOS Artwork Repository to produce slide images in
their own languages.

@subheading 2009

Around 2009, the rendition script was at a very rustic state where
only slide images could be produced, so it was redesigned to extend
the image production to other areas, different from slide images. In
this configuration, one SVG file was used as input to produce a
translated instance of it which, in turn, was used to produce one
translated PNG image as output. The SVG translated instance was
created through SED replacement commands. The translated PNG image was
created from the SVG translated instance using Inkscape command-line
interface.

The repository directory structure was prepared to receive the
rendition script using design templates and translation files in the
same location. There was one directory structure for each artwork that
needed to be produced. In this configuration, if you would want to
produce the same artwork with a different visual style or structure,
it was needed to create a new directory structure for it because both
the image structure and the image visual style were together in the
design template.

The rendition script was moved to a common place and linked from
different directory structures. There was no need to have the same
code in different directory structures if it could be in just one
place and then be linked from different locations.

Corporate identity concepts began to be considered. As referece, it
was used the book ``Corporate Identity'' by Wally Olins (1989) and
Wikipedia related links (e.g.,
@url{http://en.wikipedia.org/Corporate_identity}). This way, the
rendition script main's goal becomes into: automate production of a
monolithic corporate visual identity structure, based on the mission
and the release schema of The CentOS Project.

The repository directory structures began to be documented by mean of
flat text files. Later, documentation in flat text files was moved
onto LaTeX format and this way the ``The CentOS Artwork Repository''
documentation manual is initiated.

@subheading 2010

Around 2010, the rendition script changed its name from
@command{render.sh} to @command{centos-art.sh} and became a collection
of functionalities where rendition was just one among others (e.g.,
documenting and localizing).

The @command{centos-art.sh} was initially conceived to automate
frequent tasks inside the repository based in the idea of Unix
toolbox: @emph{to create small and specialized tools that do one thing
well}. This way, functionalities inside @command{centos-art.sh} began
to be identified and separated one another. For example, when images
were rendered, there was no need to load functionalities related to
documentation manual. This layout moved us onto ``common
functionalities'' and ``specific functionalities'' inside
@command{centos-art.sh} script. Common functionalities are loaded when
@command{centos-art.sh} script is initiated and are available to
specific functionalities.

Suddenly, no need was found to keep all the links spreaded around the
repository in order to execute the @command{centos-art.sh} script from
different locations.  The @command{centos-art} command-line interface
was used instead. The @command{centos-art} command-line interface is a
symbolic link stored inside the @file{~/bin} directory that point to
@command{centos-art.sh} script. As default configuration, inside The
CentOS Distribution, the path to @file{~/bin} is included in the
search path for commands (see @env{PATH} environment variable).  This
way, using the @command{centos-art} command-line interface, it is
possible for us to execute the @command{centos-art.sh} script from
virtually anywhere inside the workstation, just as we frequently do
with regular commands.

Start using GNU @command{getopt} as default option parser inside the
@command{centos-art.sh} script.

The repository directory structure was updated to improve the
implementation of corporate visual identity concepts.  Specially in
the area related to themes. Having both structure and style in the
same file introduced content duplication when producing art works.
Because of this reason, they were divided out to separate directory
structures: the design models and artistic motifs directory
structures.  From this point on, the @command{centos-art.sh} is able
to produce themes as result of arbitrary combinations between design
models (structures) and artistic motifs (visual styles).

In the documentation area, the documents in LaTeX format were migrated
to Texinfo format. In this configuration, each directory structure in
the repository has a documentation entry associated in a Texinfo
structure which can be read, edited and administered (e.g., renamed,
deleted and copied) interactively through @command{centos-art.sh}
script.  Additionally, the @command{texi2html} program was used to
produced customized XHTML output in conjunction with CSS from The
CentOS Webenv.

@subheading 2011

Around 2011, the @command{centos-art.sh} script was redesigned to
start translating XML-based files (e.g., SVG and Docbook files)
through @command{xml2po} program and shell scripts (e.g., Bash
scripts) through GNU @command{gettext} tools. This configuration
provided a stronger localization interface for graphic designers,
translators and programmers. The SED replacement files are no longer
used to handle localization.

The @code{render}, @code{help} and @code{locale} functionalities were
consolidated as the most frequent tasks performed inside the
repository. Additionally, the @code{prepare} and @code{tuneup}
functionalities are also maintained as useful tasks.

In the documentation area, support for producing localized
transformations of DocBook XML DTD instances was added through the
@code{render} and @code{locale} functionalities. The @code{render}
functionality uses the @command{xsltproc} command-line XSLT parser in
conjunction with the styles provided by the @file{docbook-style-xsl}
package, both of them included inside The CentOS Distribution. The
@code{locale} functionality creates the localized @acronym{PO,Portable
Objects} the @code{render} functionality needs to produce localized
transformations of DocBook XML DTD instances.