diff --git a/Manuals/Userguide/Introduction/history.docbook b/Manuals/Userguide/Introduction/history.docbook index c1b0fe1..8bdef8e 100644 --- a/Manuals/Userguide/Introduction/history.docbook +++ b/Manuals/Userguide/Introduction/history.docbook @@ -2,147 +2,223 @@ History - The CentOS Artwork Repository started around 2008 during a - discussion about how to automate the slide images of Anaconda, at - CentOS Developers mailing list (centos-devel@centos.org). 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 —together 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 (https://projects.centos.org/trac/artwork/) and - the CentOS Artwork Repository - (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. - - The concepts about corporate identity began to be - considered. As referece, it was used the book Corporate - Identity by Wally Olins (1989) and Wikipedia related links - (e.g., ). This way, the rendition script main's goal becomes to: - 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 - inside by mean of flat text files. Later, documentation in flat - text files was moved onto LaTeX format and this way The - CentOS Artwork Repository 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., documenting and localizing). - - The centos-art.sh was initialy conceived - to organize automation of most frequent tasks inside the - repository based in the conceptual idea of Unix toolbox: - create small and specialized tools that do one thing - well. This way, functionalities inside - centos-art.sh were 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. - - There was no need to have links all around the - repository if a command-line interface could be created (through - symbolic links, in the ~/bin directory) and be called - anywhere inside the repository as it would be a regular - command. - - The centos-art.sh script was redesigned - to handle command-line options trough getopt - option parser. - - The repository directory structure was updated to improve - the implementation of concepts related to corporate visual - identity. Specially in the area related to themes which were - divided into design models and - artistic motifs to eliminate the content - duplication produced by having both image structure and image - visual style in the same file. Now, both - centos-art.sh and repository directory - structure are able to produce themes as result of arbitrary - combinations between design models (structures) and artistic - motifs (visual styles). - - In the documentation area, the documentation files 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, copied) interactively - throuch centos-art.sh. Additionally, the - texi2html program was used to produced XHTML - output customized by CSS from The CentOS Webenv. - - Around 2011, the centos-art.sh script was - redesigned to start translating SVG and other XML-based files - (e.g., XHTML and Docbook files) through the - xml2po program and shell scripts files (e.g., - Bash scripts) through GNU gettext tools. This - configuration provided a stronger interface for graphic designers, - translators and programmers to produce localized content. The SED - files are no longer used to handle translations. - - The render, help and - locale functionalities were consolidated as the most - frequent tasks performed inside the repository. Additionally, the - prepare and tuneup functionalities are - maintained as useful tasks. - - The centos-art.sh script is updated to - organize functionalities in two groups: the administrative - functionalities and the productive - functionalities. The administrative functionalities cover - actions like: copying, deleting and renaming directory structures - inside the repository. Also, preparing your workstation for using - centos-art.sh script, making backups of the - distribution theme currently installed, installing themes created - inside repository and restoring themes from backup. On the other - hand, the productive functionalities cover actions like: content - rendition, content localization, content documentation and content - maintainance. + + 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. + + + + 2009's + + + 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. + + + + + 2010's + + + 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. + + + + + 2011's + + + 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. + + + + Redesign help functionality to start using + DocBook XML as default documentation backend. Produciing + documentation through DocBook XML as default documentation + backend consolidates render and + locale even more. In this configuration, once the + DocBook files are written, we use locale + functionality to localize the DocBook files in your prefered + language and later, using render functionality, + we produce the XTHML and PDF outputs as specified in the + XSLT customization driver we defined. + +