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.