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, I 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, I 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.

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.

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 initialy conceived to organize
automation of most frequent tasks inside the repository based in the
conceptual 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 links from all around the
repository to @command{centos-art.sh} script.  Instead the
@command{centos-art} command-line was created. This is, a symbolic
links in the @file{~/bin} directory which can be called from anywhere
inside the repository, just as it would be a regular command. The
symbolic links inside the repository were removed and the
@command{centos-art} command-line interface was used instead.

Option parsing became too complicated for the current implemented way
of parsing positional parameters passed to @command{centos-art.sh}
script from the command-line.  The GNU @command{getopt} option parser
was considered, studied, and implemented in @command{centos-art.sh}
script as default option parser.

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.

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.  When no localized PO
exists for a DocBook XML DTD instance, it is produced in English
language.