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 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 which refer to @command{centos-art.sh} script.  The

@command{centos-art} command-line interface is used instead. The

@command{centos-art} command-line interface is a symbolic link stored

inside the @file{~/bin} directory pointing to @command{centos-art.sh}

script. Inside The CentOS Distribution, the @file{~/bin} path is set

as default in the @env{PATH} environment variable which is evaluated

by the shell to know where executable files are stored in before

execute anyone. 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.

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.