diff --git a/Manuals/Repository/Docbook/Introduction.ent b/Manuals/Repository/Docbook/Introduction.ent index b6449a7..2cf6456 100644 --- a/Manuals/Repository/Docbook/Introduction.ent +++ b/Manuals/Repository/Docbook/Introduction.ent @@ -1,7 +1,13 @@ + + + + + + diff --git a/Manuals/Repository/Docbook/Introduction/History.docbook b/Manuals/Repository/Docbook/Introduction/History.docbook index 56f5ca4..1408bdb 100644 --- a/Manuals/Repository/Docbook/Introduction/History.docbook +++ b/Manuals/Repository/Docbook/Introduction/History.docbook @@ -39,194 +39,8 @@ 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 to: automate the production process 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. - - - - 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. - - - + &intro-history-2009; + &intro-history-2010; + &intro-history-2011; diff --git a/Manuals/Repository/Docbook/Introduction/History/2009.docbook b/Manuals/Repository/Docbook/Introduction/History/2009.docbook new file mode 100644 index 0000000..b36f18b --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/History/2009.docbook @@ -0,0 +1,55 @@ + + + 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 to: automate the production process 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. + + diff --git a/Manuals/Repository/Docbook/Introduction/History/2010.docbook b/Manuals/Repository/Docbook/Introduction/History/2010.docbook new file mode 100644 index 0000000..dab0efe --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/History/2010.docbook @@ -0,0 +1,80 @@ + + + 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. + + + diff --git a/Manuals/Repository/Docbook/Introduction/History/2011.docbook b/Manuals/Repository/Docbook/Introduction/History/2011.docbook new file mode 100644 index 0000000..867d75e --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/History/2011.docbook @@ -0,0 +1,57 @@ + + + 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. + + + + 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. + + +