The CentOS Artwork Repository started during a discussion about how to automate the slide images of Anaconda, at CentOS Developers mailing list (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 and the CentOS Artwork Repository 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. 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. This way, the rendition script main's goal becomes into: automating 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 render.sh to centos-art.sh and became a collection of functionalities where rendition was just one among others (e.g., documentation and localization). The centos-art.sh was initially conceived to automate frequent tasks inside the repository based in the idea of Unix toolbox: to create small and specialized tools that do one thing well. This way, functionalities inside 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 centos-art.sh script. Common functionalities are loaded when 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 centos-art.sh script from different locations. The centos-art command-line interface was used instead. The centos-art command-line interface is a symbolic link stored inside the ~/bin directory that point to centos-art.sh script. As default configuration, inside The CentOS Distribution, the path to ~/bin is included in the search path for commands (see PATH environment variable). This way, using the centos-art command-line interface, it is possible for us to execute the centos-art.sh script from virtually anywhere inside the workstation, just as we frequently do with regular commands. Start using GNU getopt as default option parser inside the 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 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 centos-art.sh script. Additionally, the texi2html program was used to produced customized XHTML output in conjunction with CSS from The CentOS Webenv. Around 2011, the centos-art.sh script was redesigned to start translating XML-based files (e.g., SVG and Docbook files) through xml2po program and shell scripts (e.g., Bash scripts) through GNU 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 render, help and locale functionalities were consolidated as the most frequent tasks performed inside the repository. Additionally, the prepare and 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 render and locale functionalities. The render functionality uses the xsltproc command-line XSLT parser in conjunction with the styles provided by the docbook-style-xsl package, both of them included inside The CentOS Distribution. The locale functionality creates the localized portable object (PO) the render functionality needs to produce localized transformations of DocBook XML DTD instances. To build DocBook documentation, it was considered the idea of using concepts behind repository directory structure as base, not the opposite (as I've been doing with Texinfo backend, so far). Producing documentation through DocBook XML as default documentation backend consolidates render and locale even more. In this configuration, once the DocBook files are written, you use locale functionality to localize the DocBook files in your prefered language and later, using render functionality, you produce the XTHML and PDF outputs as specified in a XSLT or DSL customization layer.