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 @@
<!ENTITY intro SYSTEM "Introduction.docbook">
+
<!ENTITY intro-history SYSTEM "Introduction/History.docbook">
+<!ENTITY intro-history-2009 SYSTEM "Introduction/History/2009.docbook">
+<!ENTITY intro-history-2010 SYSTEM "Introduction/History/2010.docbook">
+<!ENTITY intro-history-2011 SYSTEM "Introduction/History/2011.docbook">
+
<!ENTITY intro-copying SYSTEM "Introduction/Copying.docbook">
<!ENTITY intro-copying-preamble SYSTEM "Introduction/Copying/preamble.docbook">
+
<!ENTITY intro-docconvs SYSTEM "Introduction/Docconvs.docbook">
<!ENTITY intro-usage SYSTEM "Introduction/Repoconvs.docbook">
<!ENTITY intro-feedback SYSTEM "Introduction/Feedback.docbook">
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.
</para>
- <sect1>
- <title>2009's</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- Corporate identity concepts began to be considered. As
- referece, it was used the book "Corporate Identity" by Wally
- Olins (1989) and <ulink
- url="http://en.wikipedia.org/Corporate_identity">Wikipedia</ulink>
- related links. This way, the rendition script main's goal
- becomes to: <emphasis>automate the production process of a
- monolithic corporate visual identity structure, based on the
- mission and the release schema of The CentOS
- Project</emphasis>.
- </para>
-
- <para>
- 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.
- </para>
- </sect1>
-
- <sect1>
- <title>2010's</title>
-
- <para>
- Around 2010, the rendition script changed its name from
- <command>render.sh</command> to
- <command>centos-art.sh</command> and became a collection of
- functionalities where rendition was just one among others
- (e.g., documentation and localization).
- </para>
-
- <para>
- The <command>centos-art.sh</command> 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
- <command>centos-art.sh</command> 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 <quote>common
- functionalities</quote> and <quote>specific
- functionalities</quote> inside
- <command>centos-art.sh</command> script. Common
- functionalities are loaded when
- <command>centos-art.sh</command> script is initiated and are
- available to specific functionalities.
- </para>
-
- <para>
- Suddenly, no need was found to keep all the links spreaded
- around the repository in order to execute the
- <command>centos-art.sh</command> 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 <filename
- class="directory">~/bin</filename> directory that point to
- <command>centos-art.sh</command> script. As default
- configuration, inside The CentOS Distribution, the path to
- <filename class="directory">~/bin</filename> 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
- <command>centos-art.sh</command> script from virtually
- anywhere inside the workstation, just as we frequently do with
- regular commands.
- </para>
-
- <para>
- Start using GNU getopt as default option parser inside the
- <command>centos-art.sh</command> script.
- </para>
-
- <para>
- 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</command> is able to
- produce themes as result of arbitrary combinations between
- design models (structures) and artistic motifs (visual
- styles).
- </para>
-
- <para>
- 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</command> script.
- Additionally, the texi2html program was used to produced
- customized XHTML output in conjunction with CSS from The
- CentOS Webenv.
- </para>
- </sect1>
-
- <sect1>
- <title>2011's</title>
-
- <para>
- Around 2011, the <command>centos-art.sh</command> script was
- redesigned to start translating XML-based files (e.g., SVG and
- Docbook files) through <command>xml2po</command> 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.
- </para>
-
- <para>
- The <code>render</code>, <code>help</code> and
- <code>locale</code> functionalities were consolidated as the
- most frequent tasks performed inside the repository.
- Additionally, the prepare and tuneup functionalities are also
- maintained as useful tasks.
- </para>
-
- <para>
- In the documentation area, support for producing localized
- transformations of DocBook XML DTD instances was added through
- the <code>render</code> and locale functionalities. The
- <code>render</code> functionality uses the xsltproc
- command-line <acronym>XSLT</acronym> parser in conjunction
- with the styles provided by the
- <package>docbook-style-xsl</package> package, both of them
- included inside The CentOS Distribution. The locale
- functionality creates the localized portable object
- (<acronym>PO</acronym>) the <code>render</code> functionality
- needs to produce localized transformations of DocBook XML DTD
- instances.
- </para>
-
- <para>
- 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).
- </para>
-
- <para>
- Producing documentation through DocBook XML as default
- documentation backend consolidates <code>render</code> and
- <code>locale</code> even more. In this configuration, once
- the DocBook files are written, you use <code>locale</code>
- functionality to localize the DocBook files in your prefered
- language and later, using <code>render</code> functionality,
- you produce the XTHML and PDF outputs as specified in a XSLT
- or DSL customization layer.
- </para>
-
- </sect1>
+ &intro-history-2009;
+ &intro-history-2010;
+ &intro-history-2011;
</chapter>
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 @@
+<sect1>
+
+ <title>2009's</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Corporate identity concepts began to be considered. As
+ referece, it was used the book "Corporate Identity" by Wally
+ Olins (1989) and <ulink
+ url="http://en.wikipedia.org/Corporate_identity">Wikipedia</ulink>
+ related links. This way, the rendition script main's goal
+ becomes to: <emphasis>automate the production process of a
+ monolithic corporate visual identity structure, based on the
+ mission and the release schema of The CentOS
+ Project</emphasis>.
+ </para>
+
+ <para>
+ 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.
+ </para>
+</sect1>
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 @@
+<sect1>
+
+ <title>2010's</title>
+
+ <para>
+ Around 2010, the rendition script changed its name from
+ <command>render.sh</command> to
+ <command>centos-art.sh</command> and became a collection of
+ functionalities where rendition was just one among others
+ (e.g., documentation and localization).
+ </para>
+
+ <para>
+ The <command>centos-art.sh</command> 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
+ <command>centos-art.sh</command> 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 <quote>common
+ functionalities</quote> and <quote>specific
+ functionalities</quote> inside
+ <command>centos-art.sh</command> script. Common
+ functionalities are loaded when
+ <command>centos-art.sh</command> script is initiated and are
+ available to specific functionalities.
+ </para>
+
+ <para>
+ Suddenly, no need was found to keep all the links spreaded
+ around the repository in order to execute the
+ <command>centos-art.sh</command> 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 <filename
+ class="directory">~/bin</filename> directory that point to
+ <command>centos-art.sh</command> script. As default
+ configuration, inside The CentOS Distribution, the path to
+ <filename class="directory">~/bin</filename> 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
+ <command>centos-art.sh</command> script from virtually
+ anywhere inside the workstation, just as we frequently do with
+ regular commands.
+ </para>
+
+ <para>
+ Start using GNU getopt as default option parser inside the
+ <command>centos-art.sh</command> script.
+ </para>
+
+ <para>
+ 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</command> is able to
+ produce themes as result of arbitrary combinations between
+ design models (structures) and artistic motifs (visual
+ styles).
+ </para>
+
+ <para>
+ 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</command> script.
+ Additionally, the texi2html program was used to produced
+ customized XHTML output in conjunction with CSS from The
+ CentOS Webenv.
+ </para>
+
+</sect1>
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 @@
+<sect1>
+
+ <title>2011's</title>
+
+ <para>
+ Around 2011, the <command>centos-art.sh</command> script was
+ redesigned to start translating XML-based files (e.g., SVG and
+ Docbook files) through <command>xml2po</command> 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.
+ </para>
+
+ <para>
+ The <function>render</function>, <function>help</function> and
+ <function>locale</function> functionalities were consolidated
+ as the most frequent tasks performed inside the repository.
+ Additionally, the prepare and tuneup functionalities are also
+ maintained as useful tasks.
+ </para>
+
+ <para>
+ In the documentation area, support for producing localized
+ transformations of DocBook XML DTD instances was added through
+ the <function>render</function> and locale functionalities.
+ The <function>render</function> functionality uses the
+ xsltproc command-line <acronym>XSLT</acronym> parser in
+ conjunction with the styles provided by the
+ <package>docbook-style-xsl</package> package, both of them
+ included inside The CentOS Distribution. The locale
+ functionality creates the localized portable object
+ (<acronym>PO</acronym>) the <function>render</function>
+ functionality needs to produce localized transformations of
+ DocBook XML DTD instances.
+ </para>
+
+ <para>
+ 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).
+ </para>
+
+ <para>
+ Producing documentation through DocBook XML as default
+ documentation backend consolidates <function>render</function>
+ and <function>locale</function> even more. In this
+ configuration, once the DocBook files are written, you use
+ <function>locale</function> functionality to localize the
+ DocBook files in your prefered language and later, using
+ <function>render</function> functionality, you produce the
+ XTHML and PDF outputs as specified in a XSLT or DSL
+ customization layer.
+ </para>
+
+</sect1>