diff --git a/Manuals/Repository/Filesystem/branches/chapter-intro.texi b/Manuals/Repository/Filesystem/branches/chapter-intro.texi
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Manuals/Repository/Filesystem/branches/chapter-intro.texi
diff --git a/Manuals/Repository/Filesystem/branches/chapter-menu.texi b/Manuals/Repository/Filesystem/branches/chapter-menu.texi
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/Manuals/Repository/Filesystem/branches/chapter-menu.texi
@@ -0,0 +1 @@
+
diff --git a/Manuals/Repository/Filesystem/branches/chapter-nodes.texi b/Manuals/Repository/Filesystem/branches/chapter-nodes.texi
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/Manuals/Repository/Filesystem/branches/chapter-nodes.texi
@@ -0,0 +1 @@
+
diff --git a/Manuals/Repository/Filesystem/branches/chapter.texi b/Manuals/Repository/Filesystem/branches/chapter.texi
new file mode 100644
index 0000000..e053279
--- /dev/null
+++ b/Manuals/Repository/Filesystem/branches/chapter.texi
@@ -0,0 +1,6 @@
+@node branches
+@chapter branches
+@cindex branches
+@include branches/chapter-intro.texi
+@include branches/chapter-menu.texi
+@include branches/chapter-nodes.texi
diff --git a/Manuals/Repository/Filesystem/tags/chapter-intro.texi b/Manuals/Repository/Filesystem/tags/chapter-intro.texi
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Manuals/Repository/Filesystem/tags/chapter-intro.texi
diff --git a/Manuals/Repository/Filesystem/tags/chapter-menu.texi b/Manuals/Repository/Filesystem/tags/chapter-menu.texi
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/Manuals/Repository/Filesystem/tags/chapter-menu.texi
@@ -0,0 +1 @@
+
diff --git a/Manuals/Repository/Filesystem/tags/chapter-nodes.texi b/Manuals/Repository/Filesystem/tags/chapter-nodes.texi
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/Manuals/Repository/Filesystem/tags/chapter-nodes.texi
@@ -0,0 +1 @@
+
diff --git a/Manuals/Repository/Filesystem/tags/chapter.texi b/Manuals/Repository/Filesystem/tags/chapter.texi
new file mode 100644
index 0000000..2b05ba0
--- /dev/null
+++ b/Manuals/Repository/Filesystem/tags/chapter.texi
@@ -0,0 +1,6 @@
+@node tags
+@chapter tags
+@cindex tags
+@include tags/chapter-intro.texi
+@include tags/chapter-menu.texi
+@include tags/chapter-nodes.texi
diff --git a/Manuals/Repository/Filesystem/trunk/Identity.texi b/Manuals/Repository/Filesystem/trunk/Identity.texi
new file mode 100644
index 0000000..65f22ca
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity.texi
@@ -0,0 +1,126 @@
+@subsection Goals
+
+The @file{trunk/Identity} directory exists to organize CentOS
+corporate identity artworks.
+
+@subsection Description
+
+The CentOS Project corporate identity is the ``persona'' of the
+organization known as The CentOS Project. The CentOS Project
+corporate identity plays a significant role in the way the CentOS
+Project, as organization, presents itself to both internal and
+external stakeholders. In general terms, the CentOS Project corporate
+visual identity expresses the values and ambitions of the CentOS
+Project organization, its business, and its characteristics.
+
+The CentOS Project corporate identity provides visibility,
+recognizability, reputation, structure and identification to the
+CentOS Project organization by means of corporate design, corporate
+communication, and corporate behaviour.
+
+The CentOS Project settles down its corporate visual identity on a
+``monolithic corporate visual identity structure''. In this structure
+The CentOS Project uses one unique name (The CentOS Brand) and one
+unique visual style (The CentOS Default Theme) in all its
+manifestations.
+
+@table @strong
+
+@item The CentOS Brands
+The CentOS brand is the name or trademark that conncects the producer
+with their products. In this case, the producer is The CentOS Project
+and the products are the CentOS distributions, the CentOS web sites,
+the CentOS promotion stuff, etc.
+
+@xref{trunk Identity Brands}, for more information.
+
+@item The CentOS Themes
+
+The CentOS themes are a set of image files connected all together by
+one unique visual style. Each theme is organized in different visual
+manifestations, in order to cover each visual manifestation of The
+CentOS Project (i.e., distributions, websites, promotion stuff, etc.).
+@xref{trunk Identity Themes}, for more information.
+@end table
+
+Inside a monolithic corporate visual identity structure, internal and
+external stakeholders use to feel a strong sensation of uniformity,
+orientation, and identification with the organization. No matter if
+you are visiting websites, using the distribution, or acting on social
+events, the one unique name and one unique visual style conect them
+all to say: Hey! we are all parts of the CentOS project. And,
+probably, some vister will say: Can I join the party? Yes you can, it
+is free. :)
+
+@subsection Usage
+
+To produce identity artworks, use the following commands:
+
+@table @samp
+@item centos-art render 'path/to/dir'
+
+When @samp{path/to/dir} refers to one renderable directory under
+@file{trunk/Identity}, this command renders identity artworks using
+both related design models and related translation files.
+
+@item centos-art render 'path/to/dir' --filter='pattern'
+
+When @samp{path/to/dir} refers to one renderable directory under
+@file{trunk/Identity}, this command renders identity artworks using
+both related design models and related translation files that match
+the regular expression passed in @samp{--filter='pattern'} argument.
+
+To control the number of files produced by @command{centos-art}
+command, you need to look into the translation path and provide a
+regular expression pattern that matches the translation path, or
+paths, related to the file, or files, you want to produce.
+
+The regular expression pattern you provide to @command{centos-art}
+command is applied to the translation path from its very beginning.
+It is not the same to say @samp{5/en/01-welcome} that
+@samp{01-welcome}, the frist expression matches but the last one does
+not.
+
+When using @samp{--filter='pattern'} you don't need to specify the
+file extension. It is removed from translation path before applying
+the pattern, so it doesn't count here.
+@end table
+
+@subsection File name convenctions
+
+As file name convenction, inside CentOS Artwork Repository, both
+text-based and image-based file name produced by @command{centos-art.sh}
+script has the same name of their translation files without
+the @samp{.sed} extension. The file extension is set as follow:
+
+@subsubsection When text-based files are rendered
+
+Text-based files end up having the same extension of their design
+template file.
+
+@subsubsection When image-based files are rendered
+
+Image-based files always end up having the @file{.png} extension.
+
+@quotation
+@strong{Tip} Once @file{.png} images are created, other image formats
+may be created using the @command{renderFormats} post-rendering
+action, inside the image-based related pre-rendering configuration
+script.
+
+@xref{trunk Scripts Bash}, for more information.
+@end quotation
+
+@subsection See also
+
+@menu
+@comment --- Removed(* trunk Translations::) ---
+@end menu
+
+@subsection References
+
+@itemize
+@item @url{http://en.wikipedia.org/Corporate_identity} (and related
+links).
+@end itemize
+
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi b/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi b/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi
new file mode 100644
index 0000000..ef6730a
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi
@@ -0,0 +1,79 @@
+@subsection Goals
+
+This section exists to organize digital typographies used by the
+CentOS project.
+
+@subsection Description
+
+@subsection Usage
+
+The CentOS corporate identity is attached to @samp{DejaVu LGC}
+font-family. Whatever artwork you design for CentOS project, that
+requires typography usage, must be done using @samp{DejaVu LGC}
+font-family.
+
+@table @strong
+@item Recommendation-1:
+
+For screen desings (e.g., anything that final destination will never
+be printed on paper or any medium outside computer screens) use
+@samp{DejaVu LGC Sans} font-family.
+
+@item Recommendation-2:
+
+For non-screen designs (e.g., anything that final desition will be
+printed on paper or any other medium outside computer screens) use
+@samp{DejaVu LGC Serif} font-family. As convenction files described in
+this rule are stored under @samp{Stationery} directories.
+@end table
+
+The only execption for the two recommendations above is the typography
+used inside CentOS logo. The CentOS logo is the main visual
+representation of the CentOS project so the typography used in it must
+be the same always, no matter where it be shown. It also has to be
+clear enough to dismiss any confussion between similar typefaces
+(e.g., the number one (1) sometimes is confuesed with the letter
+@samp{el} (l) or letter @samp{ai} (i)).
+
+As CentOS logo typography convenction, the word @samp{CentOS} uses
+@samp{Denmark} typography as base, both for the word @samp{CentOS} and
+the phrase @samp{Community Enterprise Operating System}. The phrase
+size of CentOS logo is half the size in poits the word @samp{CentOS}
+has and it below @samp{CentOS} word and aligned with it on the left.
+The distance between @samp{CentOS} word and phrase @samp{Community
+Enterprise Operating System} have the size in points the phrase has.
+
+When the CentOS release brand is built, use @samp{Denmark} typography
+for the release number. The release number size is two times larger
+(in height) than default @samp{CentOS} word. The separation between
+release number and @samp{CentOS} word is twice the size in points of
+separation between @samp{CentOS} word and phrase @samp{Community
+Enterprise Operating System}.
+
+Another component inside CentOS logo is the trademark symbol (TM).
+This symbol specifies that the CentOS logo must be consider a product
+brand, even it is not a registered one. The trademark symbol uses
+DejaVu LGC Sans Regular typography. The trademark symbol is aligned
+right-top on the outter side of @samp{CentOS} word. The trademark
+symbol must not exceed haf the distance, in points, between
+@samp{CentOS} word and the release number on its right.
+
+It would be very convenient for the CentOS Project and its community
+to to make a registered trademark (®) of CentOS logo. To make a
+register trademark of CentOS Logo prevents legal complications in the
+market place of brands. It grants the consistency, through time, of
+CentOS project corporate visual identity.
+
+@quotation
+@strong{Note} The information about trademarks and corporate identity
+is my personal interpretation of
+@url{http://en.wikipedia.org/Corporate_identity} and
+@url{http://en.wikipedia.org/Trademark} description. If you have
+practical experiences with these affairs, please serve yourself to
+improve this section with your reasons.
+@end quotation
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi b/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi b/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models.texi
new file mode 100644
index 0000000..3973252
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models.texi
@@ -0,0 +1,19 @@
+@subsection Goals
+
+This section exists to organize design models.
+
+@subsection Description
+
+Design models are representative designs useful to understand how
+to build artworks.
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+* trunk Identity Models Html::
+* trunk Identity Models Css::
+* trunk Identity Models Tpl::
+* trunk Identity Models Xcf::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi
new file mode 100644
index 0000000..5639459
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi
@@ -0,0 +1,21 @@
+@subsection Goals
+
+This directory exists to provide common style sheets (CSS) definitions
+to HTML design models.
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi
new file mode 100644
index 0000000..ec9b88b
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi
@@ -0,0 +1,23 @@
+@subsection Goals
+
+@itemize
+@item Provide images related to CentOS web interface.
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+* trunk Identity Models Tpl Promo Web::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi
new file mode 100644
index 0000000..56b7f37
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi
@@ -0,0 +1,329 @@
+@subsection Goals
+
+Organize scalable vector graphics (svg) to help describe the CentOS
+web environment.
+
+@subsection The CentOS web environment
+
+Inside CentOS corporate identity, the CentOS web environment is
+considered a promotion component. The CentOS web environment is formed
+by a central web application ---to cover base needs (e.g., per-major
+release information like release notes, lifetime, downloads,
+documentation, support, security advisories, bugs, etc.)--- and many
+different free web applications ---to cover specific needs (e.g.,
+wiki, mailing lists, etc.)---.
+
+The CentOS web environment is addressed to solve the following issues:
+
+@itemize
+@item One unique name and one unique visual style to all web
+applications used inside the web environment.
+
+@item One-step navigation to web applications inside the environment.
+
+@item High degree of customization to change the visual style of all
+web applications with few changes (e.g, updating just two or three
+images plus common style sheet [CSS] definitions).
+@end itemize
+
+The CentOS project is attached to a monolithic corporate visual
+identity (@pxref{trunk Identity}), where all visual manifestations
+have one unique name and one unique visual style. This way, the CentOS
+web environment has one unique name (the CentOS brand) and one unique
+visual style (the CentOS default theme) for all its visual
+manifestations, the web applications in this case.
+
+Since a maintainance point of view, achiving the one unique visual
+style inside CentOS web environment is not a simple task. The CentOS
+web environment is built upon many different web applications which
+have different visual styles and different internal ways to customize
+their own visual styles. For example: MoinMoin, the web application
+used to support the CentOS wiki (@url{http://wiki.centos.org/}) is
+highly customizable but Mailman (in its 2.x.x serie), the web
+application used to support the CentOS mailing list, doesn't
+support@footnote{The theme support of Mailman may be introduced in
+mailman-3.x.x release.} a customization system that separates
+presentation from logic, similar to that used by MoinMoin.
+
+This visual style diversity complicates our goal of one unique visual
+style for all web applications. So, if we want one unique visual style
+for all web applications used, it is innevitable to modify the web
+applications in order to implement the CentOS one unique visual style
+customization in them. Direct modification of upstream applications is
+not convenient because upstream applications come with their one
+visual style and administrators take the risk of loosing all
+customization changes the next time the application be updated (since
+not all upstream web applications, used in CentOS web environment,
+separate presentation from logic).
+
+To solve the ``one unique visual style'' issue, installation and
+actualization of web applications ---used inside CentOS web
+environment--- need to be independent from upstream web applications
+development line; in a way that CentOS web environment administrators
+can install and update web applications freely without risk of loosing
+the one unique visual style customization changes.
+
+At the surface of this issue we can see the need of one specific yum
+repository to store CentOS web environment customized web applications.
+
+@subsubsection Design model (without ads)
+
+@subsubsection Design model (with ads)
+
+@subsubsection HTML definitions
+
+@subsubsection Controlling visual style
+
+Inside CentOS web environment, the visual style is controlled by the
+following compenents:
+
+@table @strong
+@item Webenv header background
+@verbatim
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
+@end verbatim
+
+@item CSS definitions
+@verbatim
+trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css
+@end verbatim
+@end table
+
+@subsubsection Producing visual style
+
+The visual style of CentOS web environment is defined in the following
+files:
+
+@verbatim
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg
+@end verbatim
+
+As graphic designer you use @file{1024x250.xcf} file to produce
+@file{1024x250-bg.png} file. Later, inside @file{1024x250.svg} file,
+you use the @file{1024x250-bg.png} file as background layer to draw
+your vectorial design. When you consider you artwork ready, use the
+@command{centos-art.sh} script, as described below, to produce the
+visual style controller images of CentOS web environment.
+
+@verbatim
+centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250'
+@end verbatim
+
+Once you have rendered required image files, changing the visual style
+of CentOS web environment is a matter of replacing old image files
+with new ones, inside webenv repository file system structure. The
+visual style changes will take effect the next time customization line
+of CentOS web applications be packaged, uploded, and installed from
+[webenv] or [webenv-test] repositories.
+
+@subsubsection Navigation
+
+Inside CentOS web environment, the one-step navegation between web
+applications is addressed using the web environment navigation bar.
+The web environment navigation bar contains links to main applications
+and is always visible no matter where you are inside the web
+environment.
+
+@subsubsection Development and release cycle
+
+The CentOS web environment development and relase cycle is described
+below:
+
+@table @strong
+
+@item Download
+
+The first action is download the source code of web applications we
+want to use inside CentOS web environment.
+
+@quotation
+@strong{Important} The source location from which web application are
+downloaded is very important. Use SRPMs from CentOS @strong{[base]}
+and @strong{[updates]} repositories as first choise, and third party
+repositories (e.g. RPMForge, EPEL, etc.) as last resource.
+@end quotation
+
+@item Prepare
+
+Once web application source code has been downloaded, our duty is
+organize its files inside @samp{webenv} version controlled repository.
+
+When preparing the structure keep in mind that different web
+applications have different visual styles, and also different ways to
+implement it. A convenient way to organize the file system structure
+would be create one development line for each web application we use
+inside CentOS web environment. For example, consider the following
+file system structure:
+
+@verbatim
+https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+| |-- Sources/
+| | `-- webapp1-0.0.1/
+| |-- Rpms/
+| | `-- webapp1-0.0.1.rpm
+| |-- Srpms/
+| | `-- webapp1-0.0.1.srpm
+| `-- Specs/
+| `-- webapp1-0.0.1.spec
+|-- WebApp2/
+`-- WebAppN/
+@end verbatim
+
+@item Customize
+
+Once web applications have been organized inside the version
+controlled repository file system, use subversion to create the CentOS
+customization development line of web applications source code. For
+example, using the above file system structure, you can create the
+customization development line of @file{webapp1-0.0.1/} with the
+following command:
+
+@verbatim
+svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv
+@end verbatim
+
+The command above creates the following structure:
+
+@verbatim
+https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+| |-- Sources/
+| | |-- webapp1-0.0.1/
+| | `-- webapp1-0.0.1-webenv/
+| |-- Rpms/
+| | `-- webapp1-0.0.1.rpm
+| |-- Srpms/
+| | `-- webapp1-0.0.1.srpm
+| `-- Specs/
+| `-- webapp1-0.0.1.spec
+|-- WebApp2/
+`-- WebAppN/
+@end verbatim
+
+In the above structure, the @file{webapp1-0.0.1-webenv/} directory is
+the place where you customize the visual style of
+@file{webapp1-0.0.1/} web application.
+
+@quotation
+@strong{Tip} Use the @command{diff} command of Subversion between
+CentOS customization and upstream development lines to know what you
+are changing exactly.
+@end quotation
+
+@item Build packages
+
+When web application has been customized, build the web application
+RPM and SRPM using the source location with @samp{-webenv} prefix.
+
+@verbatim
+https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+| |-- Sources/
+| | |-- webapp1-0.0.1/
+| | `-- webapp1-0.0.1-webenv/
+| |-- Rpms/
+| | |-- webapp1-0.0.1.rpm
+| | `-- webapp1-0.0.1-webenv.rpm
+| |-- Srpms/
+| | |-- webapp1-0.0.1.srpm
+| | `-- webapp1-0.0.1-webenv.srpm
+| `-- Specs/
+| |-- webapp1-0.0.1.spec
+| `-- webapp1-0.0.1-webenv.spec
+|-- WebApp2/
+`-- WebAppN/
+@end verbatim
+
+@item Release for testing
+
+When the customized web application has been packaged, make packages
+available for testing and quality assurance. This can be achives using
+a [webenv-test] yum repository.
+
+@quotation
+@strong{Note} The [webenv-test] repository is not shipped inside
+CentOS distribution default yum configuraiton. In order to use
+[webenv-test] repository you need to configure it first.
+@end quotation
+
+If some problem is found to install/update/use the customized version
+of web application, the problem is notified somewhere (a bugtracker
+maybe) and the customization face is repated in order to fix the
+problem. To release the new package add a number after @samp{-webenv}
+prefix. For example, if some problem is found in
+@file{webapp1-0.0.1-webenv.rpm}, when it be fixed the new package will
+be named @file{webapp1-0.0.1-webenv-1.rpm}. If a problem is found in
+@file{webapp1-0.0.1-webenv-1.rpm}, when it be fixed the new package
+will be named @file{webapp1-0.0.1-webenv-2.rpm}, and so on.
+
+The ``customization --- release for testing'' process is repeated
+until CentOS quality assurance team considers the package is ready for
+production.
+
+@item Release for production
+
+When customized web application packages are considered ready for
+production they are moved from [webenv-test] to [webenv] repository.
+This action is commited by CentOS quality assurance team.
+
+@quotation
+@strong{Note} The [webenv] repository is not shipped inside CentOS
+distribution default yum configuraiton. In order to use [webenv]
+repository you need to configure it first.
+@end quotation
+@end table
+
+@subsubsection The [webenv-test] repository
+
+@verbatim
+/etc/yum.repos.d/CentOS-Webenv-test.repo
+@end verbatim
+
+@verbatim
+[webenv-test]
+name=CentOS-$releasever - Webenv-test
+mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test
+#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
+enabled=1
+priority=10
+@end verbatim
+
+@subsubsection The [webenv] repository
+
+@verbatim
+/etc/yum.repos.d/CentOS-Webenv.repo
+@end verbatim
+
+@verbatim
+[webenv]
+name=CentOS-$releasever - Webenv
+mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv
+#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
+enabled=1
+priority=10
+@end verbatim
+
+@subsubsection Priority configuration
+
+Both [webenv] and [webenv-test] repositories update packages inside
+CentOS [base] and CentOS [updates] repositories.
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+* trunk Identity Models Img Promo Web::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Release.texi b/Manuals/Repository/Filesystem/trunk/Identity/Release.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Release.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi
new file mode 100644
index 0000000..01a20c1
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi
@@ -0,0 +1,26 @@
+@subsection Goals
+
+The @file{trunk/Identity/Themes/} directory exists to organize
+production of CentOS themes.
+
+@subsection Description
+
+@subsection Usage
+
+In this location themes are organized in ``Models'' ---to store common
+information--- and ``Motifs''---to store unique information. At
+rendering time, both motifs and models are combined to produce the
+final CentOS themes. CentOS themes can be tagged as ``Default'' or
+``Alternative''. CentOS themes are maintained by CentOS community.
+
+@menu
+* trunk Identity Themes Models::
+* trunk Identity Themes Motifs::
+@end menu
+
+@subsection See also
+
+@menu
+* trunk Identity::
+* trunk::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi
new file mode 100644
index 0000000..b91973a
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi
@@ -0,0 +1,30 @@
+@subsection Goals
+
+@itemize
+@item Organize theme models.
+@end itemize
+
+@subsection Description
+
+Theme models let you modeling characteristics (e.g., dimensions,
+translation markers, position of each element on the display area,
+etc.) common to all themes. Theme models let you reduce the time
+needed when propagating artistic motifs to different visual
+manifestations.
+
+Theme models serves as a central pool of design templates for themes
+to use. This way you can produce themes with different artistic motifs
+but same characteristics.
+
+@subsection Usage
+
+Inside the framework location above, you find theme models organized
+by name. You can add your own theme models to the structure by adding
+a directory to the list. By default you have the `@xref{trunk Identity
+Themes Models Default, Default},' and `@xref{trunk Identity Themes
+Models Alternative, Alternative},' ready-to-use theme models.
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi
new file mode 100644
index 0000000..483226a
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi
@@ -0,0 +1,26 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+CentOS alternative theme models exist for people how want to use a
+different visual style on their installations of CentOS distribution.
+As the visual style is needed for a system already installed
+components like Anaconda are not required inside alternative themes.
+Inside alternative themes you find post-installation visual style only
+(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative
+themes are maintained by CentOS Community.
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi
new file mode 100644
index 0000000..6ce9103
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi
@@ -0,0 +1,27 @@
+@subsection Goals
+
+This location stores CentOS default theme model. The default theme
+model of CentOS is used in all visual manifestations of CentOS Project
+corporate visual identity (e.g., distributions, web sites, promotion,
+etc.).
+
+@subsection Description
+
+@subsection Usage
+
+Changing CentOS default theme is not very convenient because that
+affects the ``recognition'' of CentOS Project. Nevertheless, we are
+interested on seeing your art work propositions. Specially if your
+art work is an improvement to the base idea behind CentOS default
+theme (@strong{Modern}, squares and circles flowing up.).
+
+If you are not happy with CentOS default theme, you can look inside
+CentOS alternative themes and download the one you are interested in.
+If you are not happy with any of the CentOS alternative themes
+available, then go and design your own CentOS alternative theme as
+described in @xref{trunk Identity Themes Motifs, Theme Motifs}.
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi
new file mode 100644
index 0000000..d10a829
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi
@@ -0,0 +1,83 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+It applies to all major releases of CentOS distribution.
+
+@subsubsection One theme for all major releases
+
+Sometimes, specific visual manifestations are formed by common
+components which have internal differences. That is the case of CentOS
+distribution visual manifestation.
+
+Since a visual style point of view, the CentOS distributions share
+common artwork components like Anaconda ---to cover the CentOS
+distribution installation---, BootUp ---to cover the CentOS
+distribution start up---, and Backgrounds ---to cover the CentOS
+distribution desktop---. Now, since a technical point of view, those
+common artwork components are made of software improved constantly.
+So, we need to find a way to keep one unique name and one unique
+visual style in artwork components that have internal difference and
+also remark internal difference as well.
+
+@quotation
+@strong{Important} Remarking the CentOS release schema inside each
+major release of CentOS distribution ---or similar visual
+manifestation--- takes @emph{high attention} inside The CentOS Project
+corporate visual identity. It should be very clear for people which
+major release of CentOS distribution they are using.
+@end quotation
+
+In order to remark the CentOS release schema, the CentOS Artwork SIG
+uses a release-specific brand design named ``The CentOS Release
+Brand''. The CentOS release brand is compossed by the CentOS logotype
+@emph{and} the CentOS major release number (as specified in CentOS
+release schema definition). In this solution, the CentOS release brand
+is set inside all release-specific artworks (e.g., distribution,
+installation media, etc.) in remarkable way. The CentOS release
+brand is the design component that lets us remark the CentOS release
+schema inside the monolithic corporate visual identity structure we
+propose to use.
+
+@subsubsection One theme for each major release
+
+Other way we've been using to remark CentOS release schema is
+applying one unique theme for @emph{each} major release of CentOS
+distribution. That is, if we have 4 major releases of CentOS
+distribution, we need to provide 4 different themes to cover each
+CentOS distribution available.
+
+Inside CentOS Artwork Repository, you can create many themes and that
+is very convenient. But using one unique theme for @emph{each} major
+release of CentOS distribution would bring visual isolation among
+distributions, websites and promotion visual manifestations. If the
+CentOS project would maintain just one CentOS distribution (and many
+experienced graphic designers ready to create beautiful artworks) this
+model would be nice. Indeed, this model looks quite similar to that
+one used by Fedora project, doesn't it. But no, the CentOS project
+maintains near to 4 major releases of CentOS distribution in parallel,
+and that fact makes a huge difference since the corporate visual
+identity point of view.
+
+If we use one unique theme for @emph{each} major release of CentOS
+distribution, which one of those themes, does we use to cover other
+CentOS visual manifestations, like websites and promotion stuff?
+
+In whatever case you choose some release-specific distribution user
+will be visually isolated from other CentOS visual manifestations like
+websites and promotion stuff, even if the CentOS brand is present in
+all visual manifestations. In such a case, probably, users will end up
+asking themselves, why my CentOS distribution has this design and the
+CentOS website another one? Isn't them on the same project? With luck
+the CentOS brand will exonerate user form visual isolation.
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi
new file mode 100644
index 0000000..7bfbe48
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi
@@ -0,0 +1,27 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+It applies to all tangible and non tangible items CentOS uses to
+promote its existence. Clothes, posters, installation media,
+stationery, release countdown images, banners, stickers, are all
+examples of promotion designs.
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi
new file mode 100644
index 0000000..427850f
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi
@@ -0,0 +1,26 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+It applies to all web applications CentOS uses to handle its needs
+(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving
+HTML standards should be consider here.
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi
new file mode 100644
index 0000000..7b8c0e0
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi
@@ -0,0 +1,114 @@
+@subsection Goals
+
+The @file{trunk/Identity/Themes/Motifs} directory exists to:
+
+@itemize
+@item Organize CentOS themes' artistic motifs.
+@end itemize
+
+@subsection Description
+
+The artistic motif of theme is a graphic design component that
+provides the visual style of themes, it is used as pattern to connect
+all visual manifestations inside one unique theme.
+
+Artistic motifs are based on conceptual ideas. Conceptual ideas bring
+the motivation, they are fuel for the engines of human imagination.
+Good conceptual ideas may produce good motivation to produce almost
+anything, and art works don't escape from it.
+
+@table @samp
+@item TreeFlower
+CentOS like trees, has roots, trunk, branches, leaves and flowers. Day
+by day they work together in freedom, ruled by the laws of nature and
+open standards, to show the beauty of its existence.
+@item Modern
+Modern, squares and circles flowing up.
+@end table
+
+If you have new conceptual ideas for CentOS, then you can say that you
+want to create a new artistic motif for CentOS. To create a new
+artistic motif you need to create a directory under
+@file{Identity/Themes/Motifs/} using a name coherent with your
+conceptual idea. That name will be the name of your artistic motif. If
+possible, when creating new conceptual ideas for CentOS, think about
+what CentOS means for you, what does it makes you feel, take your
+time, think deep, and share; you can improve the idea as time goes on.
+
+Once you have defined a name for your theme, you need to create the
+motif structure of your theme. The motif structure is the basic
+direcotry structure you'll use to work your ideas. Here is where you
+organize your graphic design projects.
+
+To add a new motif structure to CentOS Artwork Repository, you need to
+use the @command{centos-art} command line in the
+@file{Identity/Themes/Motifs/} directory as described below:
+
+@example
+centos-art add --motif=ThemeName
+@end example
+
+The previous command will create the basic structure of themes for
+you. The basic structure produced by @command{centos-art} command is
+illustrated in the following figure:
+
+@example
+trunk/Identity/Themes/Motifs/$ThemeName/
+|-- Backgrounds
+| |-- Img
+| `-- Tpl
+|-- Info
+| |-- Img
+| `-- Tpl
+|-- Palettes
+`-- Screenshots
+@end example
+
+@subsection Usage
+
+When designing artistic motifs for CentOS, consider the following
+recommendations:
+
+@itemize
+@item Give a unique (case-sensitive) name to your Motif. This name is
+used as value wherever theme variable (@b{$THEME}) or translation marker
+(@b{=THEME=}) is. Optionally, you can add a description about
+inspiration and concepts behind your work.
+
+@item Use the location @file{trunk/Identity/Themes/Motifs/$THEME/} to
+store your work. If it doesn't exist create it. Note that this require
+you to have previous commit access in CentOS Artwork Repository.
+
+@item The CentOS Project is using the blue color (@b{#204c8d}) as base
+color for its corporate visual identity. Use such base corporate color
+information as much as possible in your artistic motif designs.
+
+@item Try to make your design fit one of the theme models.
+
+@item Feel free to make your art enterprise-level and beautiful.
+
+@item Add the following information on your artwork (both in a visible
+design area and document metadata):
+
+@itemize
+
+@item The name (or logo) of your artistic motif.
+
+@item The copyright sentence: @b{Copyright (C) YEAR YOURNAME}
+
+@item The license under which the work is released. All CentOS Art
+works are released under
+@url{http://creativecommons.org/licenses/by-sa/3.0/,Creative Common
+Share-Alike License 3.0}
+(@url{http://creativecommons.org/licenses/by-sa/3.0/}).
+
+@end itemize
+@end itemize
+
+@subsection See also
+
+@menu
+* trunk Identity Themes::
+* trunk Identity::
+* trunk::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi
new file mode 100644
index 0000000..b9e787a
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi
@@ -0,0 +1,206 @@
+@subsection Goals
+
+This section describes the steps we followed to construct the
+@emph{Flame} artistic motif. This section may be useful for anyone
+interested in reproducing the @emph{Flame} artistic motif, or in
+creating new artistic motifs for The CentOS Project corporate visual
+identity (@pxref{trunk Identity}).
+
+@subsection Description
+
+The @emph{Flame} artistic motif was built using the flame filter of
+Gimp 2.2 in CentOS 5.5.
+
+The flame filter of Gimp can produce stunning, randomly generated
+fractal patterns. The flame filter of Gimp gives us a great oportunity
+to reduce the time used to produce new artistic motifs, because of its
+``randomly generated'' nature. Once the artistic motif be created, it
+is propagated through all visual manifestations of CentOS Project
+corporate visual identity using the @file{centos-art.sh} script
+(@pxref{trunk Scripts Bash}) inside the CentOS Artwork Repository.
+
+To set the time intervals between each new visual style production, we
+could reuse the CentOS distribution major release schema. I.e., we
+could produce a new visual style, every two years, based on a new
+``randomly generated'' flame pattern, and publish the whole corporate
+visual identity (i.e., distribution stuff, promotion stuff, websites
+stuff, etc.) with the new major release of CentOS distribution all
+together at once.
+
+Producing a new visual style is not one day's task. Once we have
+defined the artistic motif, we need to propagate it through all visual
+manifestations of The CentOS Project corporate visual identity. When
+we say that we could produce one new visual style every two years we
+really mean: to work two years long in order to propagate a new visual
+style to all visual manifestations of The CentOS Project corporate
+visual identity.
+
+Obviously, in order to propagate one visual style to all different
+visual manifestations of The CentOS Project corporate visual identity,
+we need first to know which the visual manifestations are. To define
+which visual manifestations are inside The CentOS Project corporate
+visual identity is one of the goals the CentOS Artwork Repository and
+this documentation manual are both aimed to satisfy.
+
+Once we define which the visual manifestation are, it is possible to
+define how to produce them, and this way, organize the automation
+process. Such automation process is one of the goals of
+@file{centos-art.sh} script.
+
+With the combination of both CentOS Artwork Repository and
+@file{centos-art.sh} scripts we define work lines where translators,
+programmers, and graphic designers work together to distribute and
+reduce the amount of time employed to produce The CentOS Project
+monolithic corporate identity.
+
+From a monolithic corporate visual identity point of view, notice that
+we are producing a new visual style for the same theme (i.e.,
+@emph{Flame}). It would be another flame design but still a flame
+design. This idea is very important to be aware of, because we are
+somehow ``refreshing'' the theme, not changing it at all.
+
+This way, as we are ``refreshing'' the theme, we still keep oursleves
+inside the monolithic conception we are trying to be attached to
+(i.e., one unique name, and one unique visual style for all visual
+manifestations).
+
+Producing artistic motifs is a creative process that may consume long
+time, specially for people without experienced knowledge on graphic
+design land. Using ``randomly generated'' conception to produce
+artistic motifs could be, practically, a way for anyone to follow in
+order to produce maintainable artistic motifs in few steps.
+
+Due to the ``randomly generated'' nature of Flame filter, we find that
+@emph{Flame} pattern is not always the same when we use @emph{Flame}
+filter interface.
+
+Using the same pattern design for each visual manifestation is
+essential in order to maintain the visual connection among all visual
+manifestations inside the same theme. Occasionally, we may introduce
+pattern variations in opacity, size, or even position but never change
+the pattern design itself, nor the color information used by images
+considered part of the same theme.
+
+@quotation
+@strong{Important}
+When we design background images, which are considered part of the
+same theme, it is essential to use the same design pattern always.
+This is what makes theme images to be visually connected among
+themeselves, and so, the reason we use to define the word ``theme''
+as: a set of images visually connected among themeselves.
+@end quotation
+
+In order for us to reproduce the same flame pattern always,
+@emph{Flame} filter interface provides the @samp{Save} and @samp{Open}
+options. The @samp{Save} option brings up a file save dialog that
+allows you to save the current Flame settings for the plug-in, so that
+you can recreate them later. The @samp{Open} option brings up a file
+selector that allows you to open a previously saved Flame settings
+file.
+
+The Flame settings we used in our example are saved in the file:
+
+@verbatim
+trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
+@end verbatim
+
+@subsection Construction
+
+@subsubsection Step 1: Set image size
+
+Create an empty image and fill the @samp{Background} layer with black
+(@code{000000}) color. Image dimensions depend on the final
+destination you plan to use the image for. For the sake of our
+construction example we used an image of 640x480 pixels and 300 pixels
+per inch (ppi).
+
+@subsubsection Step 2: Add base color and pattern information
+
+Create a new layer named @samp{Base}, place it over @samp{Background}
+layer and fill it with the base color (@code{7800ff}) you want to have
+your background image set in. Add a mask to @samp{Base} layer using
+radial gradient and blur it. You may need to repeat this step more
+than once in order to achieve a confortable black radial degradation
+on the right side of your design.
+
+Duplicate @samp{Base} layer and name it @samp{Paper}. Place
+@samp{Paper} layer over @samp{Base} layer. Remove content of
+@samp{Paper} layer and fill it with @samp{Paper (100x100)} pattern.
+Once you've done with black radial degradation, reduce the
+@samp{Paper} layer opacity to 20%.
+
+Notice that when we duplicate one layer, the mask information related
+to layer is preserved from previous to next layer. This saves us some
+of the time required to produce different layers with the same mask
+information on them.
+
+Duplicate @samp{Paper} layer and rename it @samp{Stripes}. Remove
+paper pattern from @samp{Stripes} layer. Fill @samp{Stripes} layer
+with @samp{Stripes (48x48)} pattern and reduce the @samp{Stripes}
+layer opacity to 15%.
+
+@subsubsection Step 3: Add flame motif
+
+Create a new layer named @samp{Flame}. Set the foreground
+(@code{003cff}) and background (@code{0084ff}) colors to the gradient
+you want to build the flame motif.
+
+To build flame motif, use the flame filter (@samp{Filters > Render >
+Nature > Flame...}) on @samp{Flame} layer. We used a layer mask, with
+a radial gradient on it to control the boundaries of flame motif on
+@samp{Flame} layer.
+
+Duplicate @samp{Flame} layer and rename it `Flame Blur'. Place `Flame
+Blur' below @samp{Flame} layer. Apply Gussian blur filter
+(@samp{Filters > Blur > Gussian Blur...}) until reaching the desiered
+effect.
+
+The opacity value, in @samp{Flame} layers, may vary from one image to
+another based on the place the image will be finally placed on. For
+example, images used as desktop background have the @samp{Flame} layer
+opacity set at 100% but @samp{Flame Blur} is set to 70%. However, you
+may find that background images used in anaconda progress slides have
+opacity reduced differently, in order to reduce brightness in a way
+that texts could look clean and readable over it.
+
+@subsubsection Step 4: Add foreground color
+
+Create a new layer named @samp{Color}, place it on top of all visible
+layers and fill it with plain color (@code{4c005a}). Reduce
+@samp{Color} layer opacity to 20%. You can use the @samp{Color} layer
+to control the right side color information you want to produce the
+image for.
+
+Duplicate @samp{Flame} layer and create a new layer named
+@samp{Color#1}. Place @samp{Color#1} layer on top of layer named
+@samp{Color}. Remove the mask information from @samp{Color#1} layer
+and recreate a new one using an inverted alpha channel as reference.
+Remove @samp{Color#1} layer content and fill it back with plain black
+(@code{000000}) color. Reduce @samp{Color#1} opacity to 20%. In this
+step we created a mask to protect the flame artistic motif from black
+color, so when we decrement or increment the opacity of layer, the
+flame artistic motif wouldn't be affected, just the environment
+suround it.
+
+When you set color information, remember that the same artistic motif
+needs to be indexed to 14 and 16 colors, in order to produce Grub and
+Syslinux visual manifestations respectively. Using many different
+colors in the artistic motif may reduce the possibility of your design
+to fix all different situations in. Likewise, using more colors in
+one design, and less colors in another design will reduce the
+connectivity among your designs, since color information is relevant
+to visual identity.
+
+When you propagate your artistic motif visual style to different
+visual manifestations of CentOS Project corporate visual identity, it
+is up to you to find out justice and compromise among all possible
+variables you may face.
+
+@subsection See also
+
+@menu
+* trunk Identity Themes Motifs::
+* trunk Identity Themes::
+* trunk Identity::
+* trunk::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi
new file mode 100644
index 0000000..306ab79
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi
@@ -0,0 +1,14 @@
+@subsection Presentation
+
+@subsection Construction
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
new file mode 100644
index 0000000..adda528
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
@@ -0,0 +1,143 @@
+@subsection Goals
+
+@itemize
+@item Organize background images for Modern theme.
+@end itemize
+
+@subsection Description
+
+Inside @file{Motifs} directory, the @file{Backgrounds/} directory is
+used to create vectorial designs using Inkscape and background images
+using Gimp. Later, you can export background images as @file{.png} and
+load them in your vectorial design project using the import feautre of
+Inkscape.
+
+You may need to repeat this technic for different screen resoluions.
+In that case you need to create one file for each screen resolution
+and do the appropriate linking inside .svg to .png files. For example
+if you need to produce background images in 800x600 you need to create
+the following file:
+
+@example
+xcf/800x600.xcf
+@end example
+
+to produce the background image:
+
+@example
+img/800x600-bg.png
+@end example
+
+which is loaded in:
+
+@example
+svg/800x600.svg
+@end example
+
+to produce the final background image:
+
+@example
+img/800x600.png
+@end example
+
+The @file{img/800x600.png} background image is produced automatically
+by means of rendering scripts.
+
+In other cases (e.g. Anaconda), it is possible that you need to make
+some variations to one background image that don't want to appear on
+regular background images of the same resolution. In this case you
+need to create a new and specific background image for that art
+component. For example, if you need to produce the background image
+used by Anconda (800x600) art works you create the file:
+
+@example
+xcf/800x600-anaconda.xcf
+@end example
+
+to produce the background image:
+
+@example
+img/800x600-anaconda-bg.png
+@end example
+
+which is loaded in:
+
+@example
+svg/800x600-anaconda.svg
+@end example
+
+to produce the file:
+
+@example
+img/800x600-anaconda.png
+@end example
+
+The 800x600-anaconda.png file is used by all Anaconda art works
+sharing a common 800x600 screen resolution (e.g., Header, Progress,
+Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors
+and 640x480 pixels so you need to create a 640x480 background image
+for it, and take the color limitation into account when designing it.
+
+Background images without artistic motif are generally used as based
+to build the Background images that do contain the theme artistic
+motif.
+
+Background images are linked (using the @b{import} feature of
+Inkscape) inside almost all theme art works. This structure let you
+make centralized changes on the visual identity and propagate them
+quickly to other areas.
+
+In this structure you design background images for different screen
+resolutions based on the theme artistic motif.
+
+You may create different artistic motifs propositions based
+on the same conceptual idea. The conceptual idea is what defines a
+theme. Artistic motifs are interpretations of that idea.
+
+Inside this directory artistic motifs are organized by name (e.g.,
+TreeFlower, Modern, etc.).
+
+Each artistic motif directory represents just one unique artistic
+motif.
+
+The artistic motif is graphic design used as common pattern to connect
+all visual manifestations inside one unique theme. The artistic motif
+is based on a conceptual idea. Artistic motifs provide visual style
+to themes.
+
+Designing artistic motifs is for anyone interested in creating
+beautiful themes for CentOS. When building a theme for CentOS, the
+first design you need to define is the artistic motif.
+
+
+Inside CentOS Artwork Repository, theme visual styles (Motifs) and
+theme visual structures (Models) are two different working lines.
+When you design an artistic motif for CentOS you concentrate on its
+visual style, and eventualy, use the @command{centos-art} command line
+interface to render the visual style, you are currently producing,
+against an already-made theme model in order to produce the final
+result. Final images are stored under @file{Motifs/} directory using
+the model name, and the model directory structure as reference.
+
+The artistic motif base structure is used by @command{centos-art} to
+produce images automatically. This section describes each directory of
+CentOS artistic motif base structure.
+
+@subsection Usage
+
+The @file{Backgrounds/} directory is probably the core component,
+inside @file{Motifs/} directory structure. Inside @file{Backgrounds/}
+directory you produce background images used by almost all theme
+models (e.g., Distribution, Websites, Promotion, etc.). The
+@file{Backgrounds/} directory can contain subdirectories to help you
+organize the design process.
+
+@subsection See also
+
+@menu
+* trunk Identity Themes Motifs Modern Backgrounds Img::
+* trunk Identity Themes Motifs Modern Backgrounds Tpl::
+* trunk Identity Themes Motifs Modern Backgrounds Xcf::
+@comment --- Removed(* trunk Translations Identity Themes Backgrounds::) ---
+@end menu
+
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
new file mode 100644
index 0000000..fc1ecfb
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
@@ -0,0 +1,19 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+In this directory is where you store all background images (e.g.,
+.png, .jpg, .xpm, etc.). This directory is required by
+@file{centos-art} command line interface.
+
+@subsection See also
+
+@menu
+@end menu
+
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
new file mode 100644
index 0000000..4b3308a
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
@@ -0,0 +1,18 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+In this directory is where you store all the scalable vector graphics
+(e.g., .svg) files. This directory is required by @file{centos-art}
+command line interface.
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
new file mode 100644
index 0000000..b572a3d
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
@@ -0,0 +1,27 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+
+@subsection Usage
+
+In this directory is where you store the project files (e.g, .xcf) of
+Gimp. This directory is not required by @file{centos-art} command
+line interface. If you can create a beautiful background images using
+scalable vector graphics only, then there is no need to use the
+@file{Xcf/} directory to store background projects. Of course, you can
+merge both Gimp and Inkscape power to produce images based on them.
+In this last case you need the @file{Xcf/} directory.
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
new file mode 100644
index 0000000..8735b28
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
@@ -0,0 +1,59 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+To render Anaconda progress slide images using the @emph{Modern}
+artistic motif design, the Default theme model, and available
+translation files (--- @strong{Removed}(pxref:trunk Translations Identity Themes Distro
+Anaconda Progress) ---); use the following commands:
+
+@example
+cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
+centos-art render --identity
+@end example
+
+The above command will create the following structure:
+
+@example
+trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
+|-- 3
+| |-- en
+| | |-- 01-welcome.png
+| | |-- 02-donate.png
+| | `-- 03-yum.png
+| `-- es
+| |-- 01-welcome.png
+| |-- 02-donate.png
+| `-- 03-yum.png
+|-- 4
+| |-- en
+| | |-- 01-welcome.png
+| | |-- 02-donate.png
+| | `-- 03-yum.png
+| `-- es
+| |-- 01-welcome.png
+| |-- 02-donate.png
+| `-- 03-yum.png
+`-- 5
+ |-- en
+ | |-- 01-welcome.png
+ | |-- 02-donate.png
+ | `-- 03-yum.png
+ `-- es
+ |-- 01-welcome.png
+ |-- 02-donate.png
+ `-- 03-yum.png
+@end example
+
+
+@subsection See also
+
+@menu
+@end menu
+
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi
new file mode 100644
index 0000000..79765d1
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi
@@ -0,0 +1,20 @@
+@subsection Goals
+
+@itemize
+@item Organize palette files for Modern theme.
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+Here is where graphic designers define theme palettes for
+color-limited art works. Theme palettes contain the color information
+that rendering functions need, in order to produce images with color
+limitations. Theme palettes contain the unique color information
+required by theme.
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
new file mode 100644
index 0000000..32e0626
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
@@ -0,0 +1,323 @@
+@subsection Goals
+
+This section exists to orgnize backgrounds of @emph{TreeFlower}
+artistic motif.
+
+@subsection Description
+
+@subsubsection Desktop background
+
+Once you have defined the vectorial artistic motif design, use the
+@command{centos-art.sh} script (as described in usage section below)
+to produce the png version of it. With the png version of your
+vectorial design do the following:
+
+Open the png version with GIMP.
+
+Save the png version as a project of GIMP inside
+@file{trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf}
+directory, using the same name of your vectorial design but with the
+@samp{.xcf} extension.
+
+Now use GIMP to improve your design. Here you may add one layer for
+pattern, another for colors, and so on until you find yourself
+confortable with your artwork. For example, the following layer
+distribution (from bottom to top) was used to build revision 285 of
+file @file{1360x768.xcf} using @emph{TreeFlower} artistic motif at
+revision 241.
+
+@table @strong
+@item Layer 1: Background
+
+The first thing we did with GIMP was to create a layer named
+@samp{Background} to store the artistic motif (File > Open as layer).
+This layer is the lowest layer in the image. Later, we started to
+create layers one upon another to change the artistic motif visual
+style.
+
+@item Layer 2: Shadow#1
+
+This layer is above @samp{Background} and contains a linear gradient
+from left (000000) to right (transparent) covering the whole image.
+This layer masks the artistic motif to avoid the effect of linear
+gradient. This layer is 100% of opacity.
+
+@item Layer 3: Shadow#2
+
+This layer is above @samp{Shadow#1} and contains a linear gradient
+from left (000000) to right (transparent) covering just the 70% of the
+whole image aproximatly. This layer doesn't mask the artistic motif
+which make the left part of it fall into the dark of linear gradient.
+This layer is 100% of opacity.
+
+@item Layer 4: Pattern (Paper)
+
+This layer is above @samp{Shadow#2} an contains the paper pattern
+shipped with GIMP 2.2. This layer doesn't mask the artistic motif so
+the pattern is applied over the whole image. This layer is set to 15%
+of opacity.
+
+@item Layer 5: Pattern (Stripes)
+
+This layer is above @samp{Pattern (Paper)} and contains the stripes
+used over the artistic motif. This layer do masks the artistic motif
+so the stripes are only applied to it. This layer is set to 10% of
+opacity.
+
+@item Layer 6: Shadow#3
+
+This layer is above @samp{Pattern (Stripes)} and contains a linear
+gradient from right (6600ff) to left (transparent). This layer masks
+the artistic motif so the linear gradient doesn't affect it. This
+layer is set to 15% of opacity.
+
+@item Layer 7: Shadow#4
+
+This layer is above @samp{Shadow#3} and contains a
+linear gradient from left (000000) to right (transparent). This layer
+do masks the artistic motif so the linear gradient doesn't affect it.
+This layer is set to 10% of opacity.
+
+@item Layer 8: Color#1
+
+This layer is above @samp{Shadow#4} and is filled with orange (ffae00)
+color over the whole image. This layer is set to 10% of opacity.
+
+@item Layer 9: Color#2
+
+This layer is above @samp{Color#1} and is filled with
+blue (010a88) color over the whole image. This layer is set to 10% of
+opacity.
+
+@end table
+
+@quotation
+@strong{Note} There is no definite combination. To get the appropriate
+visual design is a matter of constant testing and personal taste.
+@end quotation
+
+Finally, use @samp{Save as copy ...} option to export the final
+design. To export the final design use the same name of your vectorial
+design plus @samp{-final.png} extension.
+
+You can repeat these steps to create images for other screen
+resolutions.
+
+@subsubsection Anaconda Prompt (syslinux) background
+
+When building syslinux backgrounds it is needed to take into account
+that the final image is reduced to 16 colors. In desktop background
+there is no color limitation but syslinux does have. The goal of this
+section is achieving a final syslinux background as close as possible
+to desktop backgrounds using 16 colors only.
+
+Another point to consider is the forground and background definition
+used by syslinux. The syslinux documentation says that the color set
+in position 0 is the background and color set in position 7 is the
+forground. The final palette of color used by our background will
+match that specification. For great contrast we'll use black as
+background and white as forground. At this poing we have black
+(000000) and white (ffffff) colors in our syslinux palette, which left
+us with 14 colors to play with.
+
+Let's begin with @file{Xcf/640x300.xcf} layer distribution from bottom
+to top:
+
+@table @strong
+@item Layer 1: Background
+
+This layer is the lowest layer in the image composition and contains
+the artistic motif image rendered for the same resolution (i.e.,
+@file{Img/Png/640x300.png}). This layer is set to 100% of opacity.
+
+@item Layer 2: Pattern (Paper)
+
+This layer is placed above @samp{Background} layer and contains the
+paper pattern shipped with GIMP 2.2. This layer doesn't mask the
+artistic motif. This layer is set to 30% of opacity.
+
+@item Layer 3: Pattern (Stripes)
+
+This layer is placed above @samp{Pattern (Paper)} layer and contains
+the stripes pattern shipped with GIMP 2.2. This layer does mask the
+artistic motif in order to apply the stripes over it only. The
+background is not affected by the stripes pattern just the artistic
+motif. This layer is set to 20% of opacity.
+
+@item Layer 4: Shadow#1
+
+This layer is placed above @samp{Pattern (Stripes)} layer and fills
+the entire layer area with violet (6600ff) color. This layer do mask
+the artistic motif in order to applied the violet color to the
+background area outside the artistic motif only. This layer is set to
+15% of opacity.
+
+@item Layer 5: Color#1
+
+This layer is above @samp{Shadow#1} and is filled with orange (ffae00)
+color to cover the whole image. This layer is set to 10% of opacity.
+
+@item Layer 6: Color#2
+
+This layer is above @samp{Color#1} and is filled with blue (010a88)
+color to cover the whole image. This layer is set to 10% of opacity.
+
+@item Layer 7: Shadow#2
+
+This layer is above @samp{Color#1} and contains a linear gradient from
+left (000000) to right (transparent) covering 70% of the image
+approximately.
+
+@end table
+
+At this point we have the composition and should look like the desktop
+backgrounds. Compared with desktop backgrounds there are some
+differences in opacity. This is because in our testings the final
+color information found with this composition produces an acceptable
+16 color image. Of course this is something we haven't seen yet.
+
+To define the color information of our current coposition, save the
+syslinux background composition we've done using @samp{File > Save as
+Copy ...} option in the following location:
+
+@verbatim
+trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png
+@end verbatim
+
+Now, create the final png version of syslinux backgrounds using the
+following command:
+
+@verbatim
+centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt
+@end verbatim
+
+This command will create syslinux-splash final images for all major
+releases of CentOS distribution the repository has been configured to.
+The important files here are @file{syslinux-splash.png}, other
+files may contain the wrong information because we haven't defined yet
+the correct color information to use.
+
+Open one @file{syslinux-splash.png} file with GIMP and use the
+@samp{Image > Mode > Indexed} to reduce image colors up to 16 colors,
+using the @samp{Generate optimum palette} feature of GIMP. If the
+image looks aceptable after reducing colors, use the @samp{Palettes}
+menu (Ctrl+P) of GIMP to import a new palette from file and name it
+@samp{CentOS-TreeFlower-Syslinux}. Once you've saved the palette, the
+color information is stored at:
+
+@verbatim
+~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
+@end verbatim
+
+You need to edit @file{CentOS-TreeFlower-Syslinux.gpl} file in order
+to set the appropriate order of colors. Remember black (000000) in
+position 0, and white (ffffff) in position 7. Other positions are
+irrelevant. When editing this file you may find that color reduction
+did not set black and white colors to their respective values exactly.
+Change that manually. For example, consider the following palette:
+
+@verbatim
+GIMP Palette
+Name: CentOS-TreeFlower-Syslinux
+Columns: 16
+#
+ 0 0 0 Background (black)
+ 23 20 35 Untitled
+ 34 25 48 Untitled
+ 37 35 60 Untitled
+ 47 36 68 Untitled
+ 37 54 86 Untitled
+ 60 48 90 Untitled
+255 255 255 Foreground (white)
+ 66 54 99 Untitled
+ 74 61 98 Untitled
+ 49 78 126 Untitled
+ 43 87 151 Untitled
+ 92 89 95 Untitled
+ 54 104 183 Untitled
+158 153 156 Untitled
+201 196 195 Untitled
+@end verbatim
+
+Update the @samp{Palettes} menu to get the new color positions from
+the file you just edited and open the palette with double click.
+
+Update the @file{syslinux.gpl} file copying the following file:
+
+@verbatim
+~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
+@end verbatim
+
+to
+
+@verbatim
+trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl
+@end verbatim
+
+With the @samp{CentOS-TreeFlower-Syslinux} palette opened in the
+@samp{Palette Editor}, open (Ctrl+O) the following file:
+
+@verbatim
+trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm
+@end verbatim
+
+and replace its color information with that one in
+@samp{CentOS-TreeFlower-Syslinux} palette. When you are replacing
+color information inside @file{syslilnux.ppm}, remember to keep the
+order of colors just as they are in the
+@samp{CentOS-TreeFlower-Palette} palette.
+
+The @file{syslinux.ppm} file is 16 pixels width and 1 pixel height, so
+you probably need to zoom it a bit to set the color information in
+their place when using the pen tool with the brush @samp{Circle (01)
+(1 x 1)}.
+
+Once you've updated the @samp{syslinux.ppm} file, it is time to update
+the following file:
+
+@verbatim
+trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex
+@end verbatim
+
+The @file{syslinux.hex} file contains the color information in
+hexadecimal notation. The color information in hexadecimal notation
+is required by @command{ppmtolss16} command. The @command{ppmtolss16}
+command produces the final LSS16 image format that is used by syslinux
+program inside CentOS distribution.
+
+The color information inside @file{syslinux.hex} must match the one in
+@file{syslinux.ppm} and @file{syslinux.gpl}. For example, based on
+@file{CentOS-TreeFlower-Syslinux} palette of colors above, consider
+the following @file{syslinux.hex} file:
+
+@verbatim
+#000000=0
+#171423=1
+#221930=2
+#25233c=3
+#2f2444=4
+#253656=5
+#3c305a=6
+#ffffff=7
+#423663=8
+#4a3d62=9
+#314e7e=10
+#2b5797=11
+#5c595f=12
+#3668b7=13
+#9e999c=14
+#c9c4c3=15
+@end verbatim
+
+@subsubsection Grub background
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi b/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi
new file mode 100644
index 0000000..9cf9a6e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi
@@ -0,0 +1,14 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales.texi b/Manuals/Repository/Filesystem/trunk/Locales.texi
new file mode 100644
index 0000000..98a4746
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales.texi
@@ -0,0 +1,56 @@
+The @file{trunk/Locales} directory exists to store the translation
+messages used to produce content in different languages.
+
+Translation messages are organized using the directory structure of
+the component being translated. For example, if we want to provide
+translation messages for @file{trunk/Manuals/Filesystem}, then the
+@file{trunk/Locales/Manuals/Filesystem} directory needs to be created.
+
+Once the locale directory exists for the component we want to provide
+translation messages for, it is necessary to create the translation
+files where translation messages are. The translation files follows
+the concepts of @command{xml2po} and GNU @command{gettext} tools.
+
+The basic translation process is as follow: first, translatable
+strings are extracted from files and a portable object template (.pot)
+is created or updated with the information. Using the portable object
+template, a portable object (.po) is created or updated for translator
+to locale the messages retrived. Finally, a machine object (.mo) is
+created from portable object to sotore the translated messages.
+
+Inside the repository there are two ways to retrive translatable
+strings from files. The first one is through @command{xml2po} command
+and the second through @command{xgettext} command. The @command{xml2po}
+is used to retrive translatable strings from XML files (e.g., Scalable
+Vector Graphics, DocBook, etc.) and the @command{xgettext} command is
+used to retrive translatable strings from shell scripts files (e.g.,
+the files that make the @command{centos-art.sh} command-line
+interface).
+
+When translatable strings are retrived from XML files, using the
+@command{xml2po} command, there is no need to create the machine
+object as we do when translatable strings ar retrived from shell
+files, using the @command{xgettext} command. The @command{xml2po}
+produces a temporal machine object in order to create a translated XML
+file. Once the translated XML file has been created the machine object
+is no longer needed. On the other hand, the machine object produced by
+the @command{xgettext} command is required by the system in order for
+the show shell script localized messages.
+
+Another difference between @command{xml2po} and @command{xgettext} we
+need to be aware of is the directory structure used to store machine
+objects. In @command{xml2po}, the machine object is created in the
+current working directory as @file{.xml2po.mo} and can be safetly
+removed once the translated XML file has been created. In the case of
+@command{xgettext}, the machine object needs to be stored in the
+@file{$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo} file in order
+for the system to interpret it and should not be removed since it is
+the file that contain the translation messages themselves.
+
+Automation of localization tasks is achived through the @code{locale}
+functionality of command-line interface.
+
+@menu
+* trunk Scripts Bash Cli Functions Locale::
+@end menu
+
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi
new file mode 100644
index 0000000..5bf1b70
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi
@@ -0,0 +1,29 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@comment --- Removed(* trunk Translations Identity Brands::) ---
+@comment --- Removed(* trunk Translations Identity Fonts::) ---
+@comment --- Removed(* trunk Translations Identity Models::) ---
+@comment --- Removed(* trunk Translations Identity Release::) ---
+@comment --- Removed(* trunk Translations Identity Themes::) ---
+@comment --- Removed(* trunk Translations Identity Widgets::) ---
+* trunk Identity::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi
new file mode 100644
index 0000000..6f771ef
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi
@@ -0,0 +1,105 @@
+@subsection Goals
+
+@itemize
+@item Organize brands' translation files.
+@end itemize
+
+@subsection Description
+
+Translation files, inside @file{trunk/Translations/Identity/Brands}
+translation entry, don't use default rendering translation
+functionality, they use the following translation pre-rendering
+configuration file instead:
+
+@verbatim
+/home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh
+@end verbatim
+
+Inside @file{trunk/Translations/Identity/Brands} translation entry,
+translation files are symbolic links pointing to the common template
+translation structure, inside the translation template (@samp{Tpl/})
+directory.
+
+Inside @file{trunk/Translations/Identity/Brands} translation entry,
+translation files are created using identity design templates as
+reference. The translation pre-rendering script creates a translation
+structure where the translation template (@samp{Tpl/}) directory
+structure applies to each single design template available.
+
+For example, if the brands' translation template (@samp{Tpl/})
+directory has 30 translation files, and there are 20 design templates;
+the brands' translation pre-rendering script creates a translation
+structure of symbolic links where the 30 translation files apply the
+20 design templates one by one, producing 600 translation symbolic
+links as result. At this point, when rendering identity, the
+@command{centos-art} script considers translation symbolic links as
+translation files.
+
+Translation file names, inside brands' translation template
+(@samp{Tpl}) directory have special meaning:
+
+@subsubsection Conventional file names
+@cindex Translation brands file names
+
+Convenctional file names look like @file{blue.sed}, @file{2c-a.sed},
+etc. Replacement commands inside translation file are applied to
+design templates and translation file names are used as final image
+name. The image dimensions use the same dimensions that design
+template has.
+
+@subsubsection Numeric file names
+@cindex Translation brands file names
+
+Numeric file names look like @file{300.sed}, @file{200.sed}, etc.
+Replacements commands inside translation files are applied to design
+templates, and translation file names are used as final image name.
+The final image is saved using an specific @samp{width} defined by the
+number part of the translation file name. The image @samp{height} is
+automatically scaled based on the previous @samp{width} definition to
+maintain the designing ratio.
+
+For example, if your design template has 400x200 pixels of dimension,
+and you apply a translation file named `300.sed' to it, the final
+image you get as result will have 300x100 pixels of dimension. The
+same is true if you use higher numbers like `1024.sed', `2048.sed',
+etc. In these cases you have bigger images proportionally.
+
+As we are using scalable vector graphics to design identity templates,
+the image size you produce is not limitted in size. You can use one
+design template produced in 400x200 pixels to produce larger or
+shorter PNG images using numeric translation files as described
+above.
+
+@subsubsection Translation markers
+
+Inside @file{trunk/Translations/Identity/Brands/}, translation files
+combine the following translation markers:
+
+@table @samp
+@item #000000
+
+Specify which color to use when rendering brand images.
+
+@quotation
+@strong{Note} As translation files inside
+@file{trunk/Translations/Identity/Brands} are symbolic links that
+point to template translation files, translation markers are defined
+inside template translation files.
+@end quotation
+@end table
+
+@subsection Usage
+@cindex How to render brands' translation files
+
+To render brands' translation files, use the following command:
+
+@verbatim
+centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
+@end verbatim
+
+@subsection See also
+
+@menu
+@comment --- Removed(* trunk Translations Identity Brands Tpl::) ---
+* trunk Identity Brands::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi
new file mode 100644
index 0000000..b53171e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi
@@ -0,0 +1,10 @@
+@subsection Goals
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi
new file mode 100644
index 0000000..2699334
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi
@@ -0,0 +1,62 @@
+@subsection Goals
+
+This section exists to organize fonts translation files.
+@subsection Description
+
+Translation files, inside @file{trunk/Translations/Fonts}, have the
+following structure:
+
+@verbatim
+s!font-family:Denmark!font-family:DejaVu LGC Sans!
+s!font-weight:normal!font-weight:bold!
+s!font-style:normal!font-style:italic!
+@end verbatim
+
+Inside @file{trunk/Translations/Fonts}, there is one translation file
+for each font preview image you want to produce. This way, we create
+one translation file for each font-family we use somewhere inside
+CentOS visual identity.
+
+@quotation
+@strong{Important} Do not create translation files for
+font-families not used somewhere inside CentOS visual identity. The
+identity of font entry (@pxref{trunk Identity Fonts}) is used as
+reference when someone needs to know which font-families are allowed
+to use inside CentOS visual identity.
+@end quotation
+
+@subsubsection Translation Markers
+
+Inside @file{trunk/Translations/Identity/Fonts}, translation files
+combine the following translation markers:
+
+@table @samp
+@item font-family:Denmark
+Specify which font family to use when rendering font preview images.
+@item font-weight:normal
+Specify which font weight to use when rendering font preview images.
+@item font-style:normal
+Specify which font style to use when rendering font preview images.
+@end table
+
+@subsection Usage
+@cindex How to render fonts' translation files
+
+Inside @file{trunk/Translations/Fonts} you use your favorite text
+editor to create translation files. Inside
+@file{trunk/Translations/Fonts} there is not translation template
+directory (@file{Tpl/}), nor translation rendering using
+@command{centos-art} script. For example, to create the
+@file{dejavu_lgc_sans-boldoblique.sed} translation file using
+@command{vim} editor, type the following command:
+
+@verbatim
+vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
+@end verbatim
+
+@subsection See also
+
+@menu
+* trunk Identity Fonts::
+@end menu
+
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi
new file mode 100644
index 0000000..b53171e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi
@@ -0,0 +1,10 @@
+@subsection Goals
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi
new file mode 100644
index 0000000..b53171e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi
@@ -0,0 +1,10 @@
+@subsection Goals
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi
new file mode 100644
index 0000000..b53171e
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi
@@ -0,0 +1,10 @@
+@subsection Goals
+
+@subsection Description
+
+@subsection Usage
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
new file mode 100644
index 0000000..f2d99e2
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
@@ -0,0 +1,94 @@
+@subsection Goals
+
+@itemize
+@item Organize Anaconda progress translation templates.
+@item Organize Anaconda progress translation files in several
+languages and major releases of CentOS distribution.
+@end itemize
+
+@subsection Description
+
+Use the following command to produce translation files based:
+
+@example
+trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+`-- Tpl
+ |-- en
+ | |-- 01-welcome.sed
+ | |-- 02-donate.sed
+ | `-- 03-yum.sed
+ `-- es
+ |-- 01-welcome.sed
+ |-- 02-donate.sed
+ `-- 03-yum.sed
+@end example
+
+In order to produce the slide images in PNG format we need to have the
+translation files first. So we use the following commands to create
+translation files for CentOS 3, 4, and 5 major releases:
+
+@example
+centos-art render --translation --filter='3,4,5'
+@end example
+
+The above commands will produce the following translation structure:
+
+@example
+trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+|-- 3
+| |-- en
+| | |-- 01-welcome.sed
+| | |-- 02-donate.sed
+| | `-- 03-yum.sed
+| `-- es
+| |-- 01-welcome.sed
+| |-- 02-donate.sed
+| `-- 03-yum.sed
+|-- 4
+| |-- en
+| | |-- 01-welcome.sed
+| | |-- 02-donate.sed
+| | `-- 03-yum.sed
+| `-- es
+| |-- 01-welcome.sed
+| |-- 02-donate.sed
+| `-- 03-yum.sed
+|-- 5
+| |-- en
+| | |-- 01-welcome.sed
+| | |-- 02-donate.sed
+| | `-- 03-yum.sed
+| `-- es
+| |-- 01-welcome.sed
+| |-- 02-donate.sed
+| `-- 03-yum.sed
+`-- Tpl
+ |-- en
+ | |-- 01-welcome.sed
+ | |-- 02-donate.sed
+ | `-- 03-yum.sed
+ `-- es
+ |-- 01-welcome.sed
+ |-- 02-donate.sed
+ `-- 03-yum.sed
+@end example
+
+At this point we have all the translation files we need to produce
+Anaconda progress welcome, donate and yum slides images; in English
+and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is,
+a sum of 18 images around.
+
+Now, with translation files in place, let's move to
+@file{trunk/Identity} structure and render them.
+
+@itemize
+@item @xref{trunk Identity Themes Motifs Modern Distro Anaconda Progress}.
+@end itemize
+
+@subsection Usage
+
+Translation rendering is described in @samp{trunk/Translations}
+documentation entry (--- @strong{Removed}(pxref:trunk Translations) ---).
+
+
+@subsection See also
diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi
new file mode 100644
index 0000000..fda4863
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi
@@ -0,0 +1,23 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@comment --- Removed(* trunk Translations Identity Widgets::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Manuals.texi b/Manuals/Repository/Filesystem/trunk/Manuals.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Manuals.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts.texi b/Manuals/Repository/Filesystem/trunk/Scripts.texi
new file mode 100644
index 0000000..c9b371f
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts.texi
@@ -0,0 +1,25 @@
+@subsection Goals
+
+The @file{trunk/Scripts} directory exists to:
+
+@itemize
+@item Organize the ``trunk'' development line of automation scripts by
+programming language.
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi
new file mode 100644
index 0000000..0b387e6
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi
@@ -0,0 +1,156 @@
+@subsection Goals
+
+The @file{trunk/Scripts/Bash} directory exists to organize the trunk
+development line of @file{centos-art.sh} automation script. The
+@file{centos-art.sh} script standardizes frequent tasks inside your
+working copy of CentOS Artwork Repository.
+
+@subsection Description
+
+The best way to understand @file{centos-art.sh} automation script is
+studying its source code. However, as start point, you may prefer to
+read an introductory resume before diving into the source code
+details.
+
+The @file{centos-art.sh} script is written in Bash. Most tasks, inside
+@file{centos-art.sh} script, have been organized in many specific
+functionalities that you can invoke from the @command{centos-art}
+command-line interface.
+
+When you type the @command{centos-art} command in your terminal, the
+operating system trys to execute that command. In order to execute the
+command, the operating system needs to know where it is, so the
+operating system uses the @var{PATH} environment variable to look for
+that command location. If your system was prepared to use CentOS
+Artwork Repository correctly (--- @strong{Removed}(pxref:trunk Scripts Bash Functions
+Verify) ---), you should have a symbolic link inside @file{~/bin/}
+directory that points to the @file{centos-art.sh} script file. As
+@file{~/bin/} directory is, by default, inside @var{PATH} environment
+variable, the execution of @command{centos-art} command runs the
+@file{centos-art.sh} script.
+
+When @file{centos-art.sh} script is executed, the first it does is
+executing the @file{trunk/Scripts/Bash/initEnvironment.sh} script to
+initialize global variables (e.g., @command{gettext} variables) and
+global function scripts. Global function scripts are located inside
+@file{trunk/Scripts/Bash/Functions} directory and their file names
+begin with @samp{cli}. Global function scripts provide common
+functionalities that can be used anywhere inside @file{centos-art.sh}
+script execution environment.
+
+Once global variables and function scripts have been loaded,
+@file{centos-art.sh} script executes the @command{cli} global function
+from @file{cli.sh} function script to retrive command-line arguments
+and define some default values that may be used later by specific
+function scripts (--- @strong{Removed}(pxref:trunk Scripts Bash Functions) ---).
+
+As convenction, the @file{centos-art.sh} command-line arguments have
+the following format:
+
+@verbatim
+centos-art arg1 --arg2=val2 --arg3=val3
+@end verbatim
+
+In the above example, @samp{centos-art} is the command you use to
+invoke @file{centos-art.sh} script. The @samp{arg1} is required and
+represents the functionality you want to perform (e.g.,
+@option{verify}, @option{render}, @option{locale}, @option{manual},
+etc.). The remaining arguments are modifiers to @option{arg1}. The
+@option{--arg2} definition is required and represets, specifically,
+the action inside the functionality you want to perform. The
+@option{--arg3} and on, are optional.
+
+Once command-line arguments have been retrived, the
+@file{centos-art.sh} script loads specific functionalities using the
+@file{cli_getFunctions.sh} function script. Only one specific
+functionality can be loaded at one script execution I.e., you run
+@command{centos-art.sh} script to run just one functionality.
+
+@float Figure,fig:trunk/Scripts/Bash:Initialization
+@verbatim
++----------------------------------------------------------------------+
+| [centos@host]$ centos-art function --action='value' --option='value' |
++----------------------------------------------------------------------+
+| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh |
++---v-----------------------------------------v------------------------+
+ | centos-art.sh |
+ +---v---------------------------------v---+
+ . | initEnvironment.sh | .
+ . +---------------------------------+ .
+ . | cli $@ | .
+ . +---v-------------------------v---+ .
+ . . | cli_getFunctions | . .
+ . . +---v-----------------v---+ . .
+ . . . | function1 | . . .
+ . . . | function2 | . . .
+ . . . | function3 | . . .
+ . . . +-----------------+ . . .
+ . . ........................... . .
+ . ................................... .
+ ...........................................
+@end verbatim
+@caption{The functionalities initialization environment.}
+@end float
+
+Functionalities are implemented by means of actions. Once the
+functionality has been initiazalized, actions initialization take
+place for that functionality. Actions initialization model is very
+similar to functions initialization model. But with the difference,
+that actions are loaded inside function environment, and so, share
+variables and functions defined inside function environment.
+
+@float Figure,fig:trunk/Scripts/Bash/Functions:Initialization
+@verbatim
++--------------------------------------+
+| cli_getFunctions |
++---v------------------------------v---+
+. | function1 | .
+. +---v----------------------v---+ .
+. . | function1_getActions | . .
+. . +---v--------------v---+ . .
+. . . | action 1 | . . .
+. . . | action 2 | . . .
+. . . | action n | . . .
+. . . +--------------+ . . .
+. . ........................ . .
+. ................................ .
+. +------------------------------+ .
+. | function2 | .
+. +---v----------------------v---+ .
+. . | function2_getActions | . .
+. . +---v--------------v---+ . .
+. . . | action 1 | . . .
+. . . | action 2 | . . .
+. . . | action n | . . .
+. . . +--------------+ . . .
+. . ........................ . .
+. ................................ .
+. +------------------------------+ .
+. | function3 | .
+. +---v----------------------v---+ .
+. . | function3_getActions | . .
+. . +---v--------------v---+ . .
+. . . | action 1 | . . .
+. . . | action 2 | . . .
+. . . | action n | . . .
+. . . +--------------+ . . .
+. . ........................ . .
+. ................................ .
+........................................
+@end verbatim
+@caption{The actions initialization environment.}
+@end float
+
+@subsection Usage
+
+The @file{centos-art.sh} script usage information is described inside
+each specific function documentation (--- @strong{Removed}(pxref:trunk Scripts Bash
+Functions) ---).
+
+@subsection See also
+
+@menu
+* trunk Scripts::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@comment --- Removed(* trunk Scripts Bash Locale::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi
new file mode 100755
index 0000000..e69de29
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi
new file mode 100755
index 0000000..2a421ab
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi
@@ -0,0 +1,1222 @@
+@subsection Goals
+
+The @file{trunk/Scripts/Bash/Functions} directory exists to organize
+@file{centos-art.sh} specific functionalities.
+
+@subsection Description
+
+The specific functions of @file{centos-art.sh} script are designed
+with ``Software Toolbox'' philosophy (@pxref{Toolbox
+introduction,,,coreutils.info}) in mind: each program ``should do one
+thing well''. Inside @file{centos-art.sh} script, each specific
+functionality is considered a program that should do one thing well.
+Of course, if you find that they still don't do it, feel free to
+improve them in order for them to do so.
+
+The specific functions of @file{centos-art.sh} script are organized
+inside specific directories under @file{trunk/Scripts/Bash/Functions}
+location. Each specific function directory should be named as the
+function it represents, with the first letter in uppercase. For
+example, if the function name is @code{render}, the specific function
+directory for it would be @samp{trunk/Scripts/Bash/Functions/Render}.
+
+To better understand how specific functions of @file{centos-art.sh}
+script are designed, lets create one function which only goal is to
+output different kind of greetings to your screen.
+
+When we create specific functions for @file{centos-art.sh} script it
+is crucial to know what these functions will do exactly and if there
+is any function that already does what we intend to do. If there is no
+one, it is good time to create them then. Otherwise, if
+functionalities already available don't do what you exactly expect,
+contact their authors and work together to improve them.
+
+@quotation
+@strong{Tip} Join CentOS developers mailing list
+@email{centos-art@@centos.org} to share your ideas.
+@end quotation
+
+It is also worth to know what global functions and variables do we
+have available inside @file{centos-art.sh} script, so advantage can be
+taken from them. Global variables are defined inside global function
+scripts. Global functions scripts are stored immediatly under
+@file{trunk/Scripts/Bash/Functions} directory, in files begining with
+@samp{cli} prefix.
+
+OK, let's begin with our functionality example.
+
+What function name do we use? Well, lets use @code{greet}. Note that
+@samp{hello} word is not a verb; but an expression, a kind of
+greeting, an interjection specifically. In contrast, @samp{greet} is a
+verb and describes what we do when we say @samp{Hello!}, @samp{Hi!},
+and similar expressions.
+
+So far, we've gathered the following function information:
+
+@verbatim
+Name: greet
+Path: trunk/Scripts/Bash/Functions/Greet
+File: trunk/Scripts/Bash/Functions/Greet/greet.sh
+@end verbatim
+
+The @file{greet.sh} function script is the first file
+@file{centos-art.sh} script loads when the @samp{greet} functionality
+is called using commands like @samp{centos-art greet --hello='World'}.
+The @file{greet.sh} function script contains the @code{greet} function
+definition.
+
+Inside @file{centos-art.sh} script, as convenction, each function
+script has one top commentary, followed by one blank line, and then
+one function defintion below it only.
+
+Inside @file{centos-art.sh} script functions, top commentaries have
+the following components: the functionality description, one-line for
+copyright note with your personal information, the license under
+which the function source code is released ---the @file{centos-art.sh}
+script is released as GPL, so do all its functions---, the @code{$Id$}
+keyword of Subversion is later expanded by @command{svn propset}
+command.
+
+In our @code{greet} function example, top commentary for
+@file{greet.sh} function script would look like the following:
+
+@verbatim
+#!/bin/bash
+#
+# greet.sh -- This function outputs different kind of greetings to
+# your screen. Use this function to understand how centos-art.sh
+# script specific functionalities work.
+#
+# Copyright (C) YEAR YOURFULLNAME
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+# USA.
+#
+# ----------------------------------------------------------------------
+# $Id$
+# ----------------------------------------------------------------------
+@end verbatim
+
+After top commentary, separated by one blank line, the @code{greet}
+function definition would look like the following:
+
+@verbatim
+function greet {
+
+ # Define global variables.
+
+ # Define command-line interface.
+ greet_getActions
+
+}
+@end verbatim
+
+The first definition inside @code{greet} function, are global
+variables that will be available along @code{greet} function execution
+environment. This time we didn't use global variable definitions for
+@code{greet} function execution environment, so we left that section
+empty.
+
+Later, we call @code{greet_getActions} function to define the
+command-line interface of @code{greet} functionality. The command-line
+interface of @code{greet} functionality defines what and how actions
+are performed, based on arguments combination passed to
+@file{centos-art.sh} script.
+
+@verbatim
+function greet_getActions {
+
+ case "$ACTIONNAM" in
+
+ --hello )
+ greet_doHello
+ ;;
+
+ --bye )
+ greet_doBye
+ ;;
+
+ * )
+ cli_printMessage "`gettext "The option provided is not valid."`"
+ cli_printMessage "$(caller)" 'AsToKnowMoreLine'
+
+ esac
+
+}
+@end verbatim
+
+The @var{ACTIONNAM} global variable is defined in @file{cli.sh}
+function script and contains the value passed before the equal sign
+(i.e., @samp{=}) in the second command-line argument of
+@file{centos-art.sh} script. For example, if the second command-line
+argument is @option{--hello='World'}, the value of @var{ACTIONNAM}
+variable would be @samp{--hello}. Using this configuration let us
+deside which action to perform based on the action name passed to
+@file{centos-art.sh} script as second argument.
+
+The @code{greet} function definition makes available two valid
+greetings through @option{--hello} and @option{--bye} options. If no
+one of them is provided as second command-line argument, the @samp{*}
+case is evaluated instead.
+
+The @samp{*} case and its two lines further on should always be
+present in @file{_getActions.sh} function scripts, no matter what
+specific functionality you are creating. This convenction helps the
+user to find out documentation about current functionality in use,
+when no valid action is provided.
+
+The @code{greet_doHello} and @code{greet_doBye} function definitions
+are the core of @code{greet} specific functionality. In such function
+definitions we set what our @code{greet} function really does: to
+output different kinds of greetings.
+
+@verbatim
+function greet_doHello {
+
+ cli_printMessage "`gettext "Hello"` $ACTIONVAL"
+
+}
+@end verbatim
+
+The @code{greet_doHello} function definition is stored in
+@file{greet_doHello.sh} function script.
+
+@verbatim
+function greet_doBye {
+
+ cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
+
+}
+@end verbatim
+
+The @code{greet_doBye} function definition is stored in the
+@file{greet_doBye.sh} function script.
+
+Both @file{greet_doHello.sh} and @file{greet_doBye.sh} function
+scripts are stored inside @code{greet} function directory path (i.e.
+@file{trunk/Scripts/Bash/Functions/Greet}).
+
+The @var{ACTIONVAL} global variable is defined in @file{cli.sh}
+function script and contains the value passed after the equal sign
+(i.e., @samp{=}) in the second command-line argument of
+@file{centos-art.sh} script. For example, if the second command-line
+argument is @option{--hello='World'}, the value of @var{ACTIONVAL}
+variable would be @samp{World} without quotes.
+
+Let's see how @code{greet} specific functionality files are organzied
+under @code{greet} function directory. To see file organization we use
+the @command{tree} command:
+
+@verbatim
+trunk/Scripts/Bash/Functions/Greet
+|-- greet_doBye.sh
+|-- greet_doHello.sh
+|-- greet_getActions.sh
+`-- greet.sh
+@end verbatim
+
+To try the @code{greet} specific functionality we've just created,
+pass the function name (i.e., @samp{greet}) as first argument to
+@file{centos-art.sh} script, and any of the valid options as second
+argument. Some examples are illustrated below:
+
+@verbatim
+[centos@projects ~]$ centos-art greet --hello='World'
+Hello World
+[centos@projects ~]$ centos-art greet --bye='World'
+Goodbye World
+[centos@projects ~]$
+@end verbatim
+
+The word @samp{World} in the examples above can be anything. In fact,
+change it to have a little fun.
+
+Now that we have a specific function that works as we expect, it is
+time to document it. To document @code{greet} specific functionality,
+we use its directory path and the @code{manual} functionality
+(--- @strong{Removed}(pxref:trunk Scripts Bash Functions Manual) ---) of @file{centos-art.sh}
+script, just as the following command illustrates:
+
+@verbatim
+centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
+@end verbatim
+
+To have a well documented function helps user to understand how your
+function really works, and how it should be used. When no valid
+action is passed to a function, the @file{centos-art.sh} script uses
+the function documentation entry as vehicle to communicate which the
+valid functions are. When no documentation entry exists for a
+function, the @file{centos-art.sh} script informs that no
+documentation entry exists for such function and requests user to
+create it right at that time.
+
+Now that we have documented our function, it is time to translate its
+output messages to different languages. To translate specific
+functionality output messages to different languages we use the
+@code{locale} functionality (--- @strong{Removed}(pxref:trunk Scripts Bash Functions
+Locale) ---) of @file{centos-art.sh} script, just as the following command
+illustrates:
+
+@verbatim
+centos-art locale --edit
+@end verbatim
+
+@quotation
+@strong{Warning} To translate output messages in different languages,
+your system locale information ---as in @env{LANG} environment
+variable--- must be set to that locale you want to produce translated
+messages for. For example, if you want to produce translated messages
+for Spanish language, your system locale information must be set to
+@samp{es_ES.UTF-8}, or similar, first.
+@end quotation
+
+Well, it seems that our example is rather complete by now.
+
+In @code{greet} function example we've described so far, we only use
+@command{cli_printMessage} global function in action specific function
+definitions in order to print messages, but more interesting things
+can be achieved inside action specific function definitions. For
+example, if you pass a directory path as action value in second
+argument, you could retrive a list of files from therein, and process
+them. If the list of files turns too long or you just want to control
+which files to process, you could add the third argument in the form
+@option{--filter='regex'} and reduce the amount of files to process
+using a regular expression pattern.
+
+The @code{greet} function described in this section may serve you as
+an introduction to understand how specific functionalities work inside
+@file{centos-art.sh} script. With some of luck this introduction will
+also serve you as motivation to create your own @file{centos-art.sh}
+script specific functionalities.
+
+By the way, the @code{greet} functionality doesn't exist inside
+@file{centos-art.sh} script yet. Would you like to create it?
+
+@subsection Usage
+
+@subsubsection Global variables
+
+The following global variables of @file{centos-art.sh} script, are
+available for you to use inside specific functions:
+
+@defvar TEXTDOMAIN
+Default domain used to retrieve translated messages. This value is set
+in @file{initFunctions.sh} and shouldn't be changed.
+@end defvar
+
+@defvar TEXTDOMAINDIR
+Default directory used to retrieve translated messages. This value is
+set in @file{initFunctions.sh} and shouldn't be changed.
+@end defvar
+
+@defvar FUNCNAM
+Define function name.
+
+Function names associate sets of actions. There is one set of actions
+for each unique function name inside @file{centos-art.sh} script.
+
+Dunction names are passed as first argument in @file{centos-art.sh}
+command-line interface. For example, in the command @samp{centos-art
+render --entry=path/to/dir --filter=regex}, the @var{ACTION} passed to
+@file{centos-art.sh} script is @option{render}.
+
+When first argument is not provided, the @file{centos-art.sh} script
+immediatly ends its execution.
+@end defvar
+
+@defvar FUNCDIR
+@end defvar
+
+@defvar FUNCDIRNAME
+@end defvar
+
+@defvar FUNCSCRIPT
+@end defvar
+
+@defvar FUNCCONFIG
+@end defvar
+
+@defvar ACTIONNAM
+Define action name.
+
+Each action name identifies an specific action to perform, inside an
+specific function.
+
+Action name names aare passed as second argument in
+@file{centos-art.sh} command-line interface. For example, in the
+command @samp{centos-art render --entry=path/to/dir --filter=regex},
+the @var{ACTIONNAM} passed to @file{centos-art.sh} script is
+@option{--entry}.
+
+When second argument is not provided, the @file{centos-art.sh} script
+immediatly ends its execution.
+@end defvar
+
+@defvar ACTIONVAL
+Define action value.
+
+Action values are associated to just one action name. Action values
+contain the working copy entry over which its associated action will be
+performed in. Working copy entries can be files or directories inside
+the working copy.
+@end defvar
+
+@defvar REGEX
+Define regular expression used as pattern to build the list of files
+to process.
+
+By default, @var{REGEX} variable is set to @code{.+} to match all
+files.
+
+Functions that need to build a list of files to process use the option
+@option{--filter} to redefine @var{REGEX} variable default value, and
+so, control the amount of files to process.
+@end defvar
+
+@defvar ARGUMENTS
+Define optional arguments.
+
+Optional arguments, inside @file{centos-art.sh} script, are considered
+as all command-line arguments passed to @file{centos-art.sh} script,
+from third argument position on. For example, in the command
+@samp{centos-art render --entry=path/to/dir --filter=regex} , the
+optional arguments are from @samp{--filter=regex} argument on.
+
+Optional arguments are parsed using @command{getopt} command through
+the following base construction:
+
+@verbatim
+# Define short options we want to support.
+local ARGSS=""
+
+# Define long options we want to support.
+local ARGSL="filter:,to:"
+
+# Parse arguments using getopt(1) command parser.
+cli_doParseArguments
+
+# Reset positional parameters using output from (getopt) argument
+# parser.
+eval set -- "$ARGUMENTS"
+
+# Define action to take for each option passed.
+while true; do
+ case "$1" in
+ --filter )
+ REGEX="$2"
+ shift 2
+ ;;
+ --to )
+ TARGET="$2"
+ shift 2
+ ;;
+ * )
+ break
+ esac
+done
+@end verbatim
+
+Optional arguments provide support to command options inside
+@file{centos-art.sh} script. For instance, consider the Subversion
+(@command{svn}) command, where there are many options (e.g.,
+@option{copy}, @option{delete}, @option{move}, etc), and inside each
+option there are several modifiers (e.g., @samp{--revision},
+@samp{--message}, @samp{--username}, etc.) that can be combined one
+another in their short or long variants.
+
+The @var{ARGUMENTS} variable is used to store arguments passed from
+command-line for later use inside @file{centos-art.sh} script. Storing
+arguments is specially useful when we want to run a command with some
+specific options from them. Consider the following command:
+
+@verbatim
+centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
+@end verbatim
+
+In the above command, the @option{--message}, and @option{--username}
+options are specific to @command{svn copy} command. In such cases,
+options are not interpreted by @file{centos-art.sh} script itself.
+Instead, the @file{centos-art.sh} script uses @command{getopt} to
+retrive them and store them in the @var{ARGUMENTS} variable for later
+use, as described in the following command:
+
+@verbatim
+# Build subversion command to duplicate locations inside the
+# workstation.
+eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
+@end verbatim
+
+When @command{getopt} parses @var{ARGUMENTS}, we may use short options
+(e.g., @option{-m}) or long options (e.g., @option{--message}). When
+we use short options, arguments are separated by one space from the
+option (e.g., @option{-m 'This is a commit message.'}). When we use
+long options arguments are separated by an equal sign (@samp{=})
+(e.g., @option{--message='This is a commit message'}).
+
+In order for @command{getopt} to parse @var{ARGUMENTS} correctly, it
+is required to provide the short and long definition of options that
+will be passed or at least supported by the command performing the
+final action the function script exists for.
+
+As convenction, inside @file{centos-art.sh} script, short option
+definitions are set in the @var{ARGSS} variable; and long option
+definitions are set in the @var{ARGSL} variable.
+
+When you define short and long options, it may be needed to define
+which of these option arguments are required and which not. To define
+an option argument as required, you need to set one colon @samp{:}
+after the option definition (e.g., @option{-o m: -l message:}). On
+the other hand, to define an option argument as not required, you need
+to set two colons @samp{::} after the option definition (e.g.,
+@option{-o m:: -l message::}).
+@end defvar
+
+@defvar EDITOR
+Default text editor.
+
+The @file{centos-art.sh} script uses default text @env{EDITOR} to edit
+pre-commit subversion messages, translation files, configuration
+files, script files, and similar text-based files.
+
+If @env{EDITOR} environment variable is not set, @file{centos-art.sh}
+script uses @file{/usr/bin/vim} as default text editor. Otherwise, the
+following values are recognized by @file{centos-art.sh} script:
+
+@itemize
+@item @file{/usr/bin/vim}
+@item @file{/usr/bin/emacs}
+@item @file{/usr/bin/nano}
+@end itemize
+
+If no one of these values is set in @env{EDITOR} environment variable,
+@file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default.
+@end defvar
+
+@subsubsection Global functions
+
+Function scripts stored directly under
+@file{trunk/Scripts/Bash/Functions/} directory are used to define
+global functions. Global functions can be used inside action specific
+functionalities and or even be reused inside themselves. This section
+provides introductory information to global functions you can use
+inside @file{centos-art.sh} script.
+
+@defun cli_checkActionArguments
+Validate action value (@var{ACTIONVAL}) variable.
+
+The action value variable can take one of the following values:
+
+@enumerate
+@item Path to one directory inside the local working copy,
+@item Path to one file inside the local working copy,
+@end enumerate
+
+If another value different from that specified above is passed to
+action value variable, the @file{centos-art.sh} script prints an error
+message and ends script execution.
+@end defun
+
+@defun cli_checkFiles FILE [TYPE]
+Verify file existence.
+
+@code{cli_checkFiles} receives a @var{FILE} absolute path and performs
+file verification as specified in @var{TYPE}. When @var{TYPE} is not
+specified, @code{cli_checkFiles} verifies @var{FILE} existence, no
+matter what kind of file it be. If @var{TYPE} is specified, use one
+of the following values:
+
+@table @option
+@item d
+@itemx directory
+Ends script execution if @var{FILE} is not a directory.
+
+When you verify directories with cli_checkFiles, if directory doesn't
+exist, @file{centos-art.sh} script asks you for confirmation in order
+to create that directory. If you answer positively,
+@file{centos-art.sh} script creates that directory and continues
+script flows normally. Otherwise, if you answer negatively,
+@file{centos-art.sh} ends script execution with an error and
+documentation message.
+
+@item f
+@item regular-file
+Ends script execution if @var{FILE} is not a regular file.
+@item h
+@itemx symbolic-link
+Ends script execution if @var{FILE} is not a symbolic link.
+@item x
+@itemx execution
+Ends script execution if @var{FILE} is not executable.
+@item fh
+Ends script execution if @var{FILE} is neither a regular file nor a
+symbolic link.
+@item fd
+Ends script execution if @var{FILE} is neither a regular file nor a
+directory.
+@item isInWorkingCopy
+Ends script execution if @var{FILE} is not inside the working copy.
+@end table
+
+As default behaviour, if @var{FILE} passes all verifications,
+@file{centos-art.sh} script continues with its normal flow.
+@end defun
+
+@defun cli_commitRepoChanges [LOCATION]
+
+Syncronize changes between repository and working copy.
+
+The @code{cli_commitRepoChanges} function brings changes from the
+central repository down to the working copy---using @command{svn
+update}---, checks the working copy changes---using @command{svn
+status} command---, prints status report---using both @command{svn
+update} and @command{svn status} commands output, and finally, commits
+recent changes from the working copy up to the repository---using
+@command{svn commit} command---.
+
+Previous to commit the working copy changes up to the central
+repository, the @code{cli_commitRepoChanges} function asks you to
+verify changes---using @command{svn diff} command---, and later,
+another confirmation question is shown to be sure you really want to
+commit changes up to central repository.
+
+If @var{LOCATION} argument is not specified, the value of
+@var{ACTIONVAL} variable is used as reference instead.
+
+@float Figure, trunk/Scripts/Bash/Functions/cli_commitRepoChanges
+@verbatim
+----------------------------------------------------------------------
+--> Bringing changes from the repository into the working copy
+--> Checking changes in the working copy
+----------------------------------------------------------------------
+Added 0 file from the repository.
+Deleted 0 file from the repository.
+Updated 0 file from the repository.
+Conflicted 0 file from the repository.
+Merged 0 file from the repository.
+Modified 4 files from the working copy.
+Unversioned 0 file from the working copy.
+Deleted 0 file from the working copy.
+Added 0 file from the working copy.
+----------------------------------------------------------------------
+@end verbatim
+@caption{The @code{cli_commitRepoChanges} function output.}
+@end float
+
+Call the @code{cli_commitRepoChanges} function before or/and after
+calling functions that modify files or directories inside the working
+copy as you may need to.
+@end defun
+
+@defun cli_doParseArguments
+Redefine arguments (@var{ARGUMENTS}) global variable using
+@command{getopt} command output. For more information about how to use
+@code{cli_doParseArguments} function, see @var{ARGUMENTS} variable
+description above.
+@end defun
+
+@defun cli_doParseArgumentsReDef $@@
+Initialize/reset arguments (@var{ARGUMENTS}) global variable using
+positional parameters variable (@var{$@@}) as reference.
+
+When we work inside function definitions, positional parameters are
+reset to the last function definition positional parameters. If you
+need to redefine positional parameters from one specific function, you
+need to call @code{cli_doParseArgumentsReDef} with the positional
+parameters variable (@var{$@@}), set as first argument, to that
+specific function you want to redefine positional parameters at.
+@end defun
+
+@defun cli_getArguments
+
+Initialize function name (@var{FUNCNAM}), action name
+(@var{ACTIONNAM}), and action value (@var{ACTIONVAL}) global
+variables, using positional parameters passed in @var{$@@} variable.
+
+The @code{cli_getArguments} function is called from @code{cli.sh}
+function script, using @code{cli} function positional parameters
+(i.e., the positional parameters passed as arguments in the
+command-line) as first function argument.
+
+Once command-line positional parameters are accesible to
+@file{centos-art.sh} script execution evironment,
+@code{cli_getArguments} uses regular expression to retrive
+action variables from first and second argument. The first argument
+defines the value used as function name (@var{FUNCNAM}), and the
+second argument defines both values used as action name
+(@var{ACTIONNAM}) and action value (@var{ACTIONVAL}), respectively.
+
+The first argument is a word in lower case. This word specifies the
+name of the functionality you want to use (e.g., @samp{render} to
+render images, @samp{manual} to work on documentation, and so on.)
+
+The second argument has a long option style (e.g.,
+@samp{--option=value}). The @samp{--option} represents the action name
+(@var{ACTIONNAM}), and the characters inbetween the equal sign
+(@samp{=}) and the first space character, are considered as the action
+value (@var{ACTIONVAL}). In order to provide action values with space
+characters inbetween you need to enclose action value with quotes like
+in @samp{--option='This is long value with spaces inbetween'}.
+Generally, action values are used to specify paths over which the
+action name acts on.
+
+Once action related variables (i.e., @var{FUNCNAM}, @var{ACTIONNAM},
+and @var{ACTIONVAL}) are defined and validated,
+@code{cli_getArguments} shifts the positional arguments to remove the
+first two arguments passed (i.e., those used to retrive action related
+variables) and redefine the arguments (@var{ARGUMENTS}) global
+variable with the new positional parameters information.
+@end defun
+
+@defun cli_getFunctions
+Initialize funtionalities supported by @file{centos-art.sh} script.
+
+Functionalities supported by @file{centos-art.sh} script are organized
+in functionality directories under
+@file{trunk/Scripts/Bash/Functions/} directory. Each functionality
+directory stores function scripts to the functionality such directory
+was created for. Function scripts contain function definitions.
+Function definitions contain several commands focused on achieving one
+specific task only (i.e., the one such functionality was created for).
+
+In order for @file{centos-art.sh} script to recognize a functionality,
+such functionality needs to be stored under
+@file{trunk/Scripts/Bash/Functions/} in a directory written
+capitalized (i.e., the whole name is written in lowercase except the
+first character which is in uppercase). The directory where one
+specific functionality is stored is known as the @samp{functionality
+directory}.
+
+Inside each functionality directory, the functionalty itself is
+implemented through function scripts. Function scripts are organized
+in files independently one another and written in @samp{camelCase}
+format with the function name as prefix. Separation between prefix
+and description is done using underscore (@samp{_}) character.
+
+In order for @file{centos-art.sh} script to load functionalities
+correctly, function definition inside function scripts should be set
+using the @samp{function} reserved word, just as in the following
+example:
+
+@verbatim
+function prefix_doSomething {
+
+ # Do something here...
+
+}
+@end verbatim
+
+The above function definition is just a convenction we use, in order
+to make identification of function names easier read and automate by
+@file{centos-art.sh} script initialization commands, once
+@file{centos-art.sh} script determines which functionality directory
+to use. Specifically, in order to initialize and export functions,
+@file{centos-art.sh} script executes all function scripts inside the
+functionality directory, and later @command{grep} on them using a
+regular expression pattern, where the @samp{function} reserved word is
+used as reference to retrive the function names and export them to
+@file{centos-art.sh} script execution environment, and so, make
+function definitions ---from function scripts inside the functionality
+directory--- available for further calls.
+
+If the functionality specified in the command-line first argument
+doesn't have a functionality directory, @file{centos-art.sh} script
+considers the functionality provided in the command-line as invalid
+functionality and immediatly stops script execution with an error
+message.
+
+In order to keep visual consistency among function scripts, please
+consider using the following function script design model as template
+for your own function scripts:
+
+@verbatim
+#!/bin/bash
+#
+# prefix_doSomething.sh -- This function illustrates function scripts
+# design model you can use to create your own function scripts inside
+# centos-art.sh script.
+#
+# Copyright (C) YEAR YOURFULLNAME
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+# USA.
+#
+# ----------------------------------------------------------------------
+# $Id$
+# ----------------------------------------------------------------------
+
+function prefix_doSomething {
+
+ # Do something here...
+
+}
+@end verbatim
+@end defun
+
+@defun cli_getCountryCodes [FILTER]
+Output country codes supported by @file{centos-art.sh} script.
+
+The @code{cli_getCountryCodes} function outputs a list with country
+codes as defined in ISO3166 standard. When @var{FILTER} is provided,
+@code{cli_getCountryCodes} outputs country codes that match
+@var{FILTER} regular expression pattern.
+@end defun
+
+@defun cli_getCountryName [FILTER]
+Outputs country name supported by @file{centos-art.sh} script.
+
+The @code{cli_getCountryName} function reads one language locale code
+in the format LL_CC and outputs the name of its related country as in
+ISO3166. If filter is specified, @code{cli_getCountryName} returns the
+country name that matches the locale code specified in @var{FILTER},
+exactly.
+@end defun
+
+@defun cli_getCurrentLocale
+Output current locale used by @file{centos-art.sh} script.
+
+The @code{cli_getCurrentLocale} function uses @env{LANG} environment
+variable to build a locale pattern that is later applied to
+@code{cli_getLocales} function output in order to return the current
+locale that @file{centos-art.sh} script works with.
+
+The current locale information, returned by
+@code{cli_getCurrentLocale}, is output from more specific to less
+specific. For example, if @samp{en_GB} locale exists in
+@code{cli_getLocales} function output, the @samp{en_GB} locale would
+take precedence before @samp{en} locale.
+
+Locale precedence selection is quite important in order to define the
+locale type we use for message translations. For example, if
+@samp{en_GB} is used, we are also saying that the common language
+specification for English language (i.e., @samp{en}) is no longer
+used. Instead, we are using English non-common country-specific
+language specifications like @samp{en_AU}, @samp{en_BW}, @samp{en_GB},
+@samp{en_US}, etc., for message translations.
+
+Use @code{cli_getCurrentLocale} function to know what current locale
+information to use inside @file{centos-art.sh} script.
+@end defun
+
+@defun cli_getFilesList [LOCATION]
+Output list of files to process.
+
+The @code{cli_getFilesList} function uses @var{LOCATION} variable as
+source location to build a list of files just as specified by regular
+expression (@var{REGEX}) global variable. Essentially, what the
+@code{cli_getFilesList} function does is using @command{find} command
+to look for files in the location (@var{LOCATION}) just as posix-egrep
+regular expression (@var{REGEX}) specifies.
+
+If @var{LOCATION} is not specified when @code{cli_getFilesList}
+function is called, the action value (@var{ACTIONVAL}) global variable
+is used as location value instead.
+
+By default, if the regular expression (@var{REGEX}) global variable is
+not redefined after its first definition in the @code{cli} function,
+all files that match default regular expression value (i.e.,
+@samp{.+}) will be added to the list of files to process. Otherwise,
+if you redefine the regular expression global variable after its first
+definition in the @code{cli} function and before calling
+@code{cli_getFilesList} function, the last value you specifed is used
+instead.
+
+When you need to customize the regular expression (@var{REGEX}) global
+variable value inside a function, do not redefine the global variable
+(at least you be absolutly convinced you need to). Instead, set the
+regular expression global variable as @samp{local} to the function you
+need a customized regular expression value for. If we don't redefine
+the regular expression global variable as local to the function, or
+use another name for the regular expression variable (which is not
+very convenient in order to keep the amount of names to remember low),
+you may experiment undesired concantenation issues that make your
+regular expression to be something different from that you expect them
+to be, specially if the function where you are doing the variable
+redefinition is called several times during the same script execution.
+
+As result, the @code{cli_getFilesList} re-defines the value of
+@var{FILES} variable with the list of files the @command{find} command
+returned. As example, consider the following construction:
+
+@verbatim
+function prefix_doSomething {
+
+ # Initialize the list of files to process.
+ local FILES=''
+
+ # Initialize location.
+ local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default
+
+ # Re-define regular expression to match scalable vector graphic
+ # files only. Note how we use the global value of REGEX to build a
+ # new local REGEX value here.
+ local REGEX="${REGEX}.*\.(svgz|svg)"
+
+ # Redefine list of files to process.
+ cli_getFilesList $LOCATION
+
+ # Process list of files.
+ for FILE in $FILES;do
+ cli_printMessages "$FILE" 'AsResponseLine'
+ # Do something else here on...
+ done
+
+}
+@end verbatim
+
+@end defun
+
+@defun cli_getLangCodes [FILTER]
+Outputs language codes supported by @file{centos-art.sh} script.
+
+@code{cli_getLangCodes} function outputs a list of language codes as
+defined in ISO639 standard. When @var{FILTER} is provided,
+@code{cli_getLangCodes} outputs language codes that match @var{FILTER}
+regular expression pattern.
+@end defun
+
+@defun cli_getLangName [FILTER]
+Outputs language names supported by @file{centos-art.sh} script.
+
+@code{cli_getLangName} function reads one language locale code in the
+format LL_CC and outputs the language related name as in ISO639. If
+filter is specified, @code{cli_getLangName} returns the language name
+that matches the locale code specified in @var{FILTER}, exactly.
+@end defun
+
+@defun cli_getLocales
+Output locale codes supported by @file{centos-art.sh} script.
+
+Occasionally, you use @code{cli_getLocales} function to add locale
+information in non-common country-specific language (@samp{LL_CC})
+format for those languages (e.g., @samp{bn_IN}, @samp{pt_BR}, etc.)
+which locale differences cannot be solved using common language
+specifications (@samp{LL}) into one unique common locale specification
+(e.g., @samp{bn}, @samp{pt}, etc.).
+@end defun
+
+@defun cli_getRepoName NAME TYPE
+Sanitate file names.
+
+Inside @file{centos-art.sh} script, specific functionalities rely both
+in @code{cli_getRepoName} and repository file system organization to
+achieve their goals. Consider @code{cli_getRepoName} function as
+central place to manage file name convenctions for other functions
+inside @file{centos-art.sh} script.
+
+@quotation
+@strong{Important} @code{cli_getRepoName} function doesn't verify file
+or directory existence, for that purpose use @code{cli_checkFiles}
+function instead.
+@end quotation
+
+The @var{NAME} variable contains the file name or directory name you
+want to sanitate.
+
+The @var{TYPE} variable specifies what type of sanitation you want to
+perform on @var{NAME}. The @var{TYPE} can be one of the following
+values:
+
+@table @option
+@item d
+@itemx directory
+Sanitate directory @var{NAME}s.
+@item f
+@item regular-file
+Sanitate regular file @var{NAME}s.
+@end table
+
+Use @code{cli_getRepoName} function to sanitate file names and
+directory names before their utilization.
+
+Use @code{cli_getRepoName} when you need to change file name
+convenctions inside @file{centos-art.sh} script.
+
+When we change file name convenctions inside @code{cli_getRepoName}
+what we are really changing is the way functions interpret repository
+file system organization. Notice that when we change a file name
+(e.g., a function name), it is necessary to update all files where
+such file name is placed on. This may require a massive substitution
+inside the repository, each time we change name convenctions in the
+repository (--- @strong{Removed}(pxref:trunk Scripts Bash Functions Path) ---, for more
+information).
+@end defun
+
+@defun cli_getRepoStatus [LOCATION]
+Request repository status.
+
+This function requests the status of a @var{LOCATION} inside the
+working copy using the @command{svn status} command and returns the
+first character in the output line, just as described in @command{svn
+help status}. If @var{LOCATION} is not a regular file or a directory,
+inside the working copy, the @file{centos-art.sh} script prints a
+message and ends its execution.
+
+Use this function to perform verifications based a repository
+@var{LOCATION} status.
+@end defun
+
+@defun cli_getTemporalFile @var{NAME}
+Output absolute path to temporal file @var{NAME}.
+
+The @code{cli_getTemporalFile} function uses @file{/tmp} directory as
+source location to store temporal files, the @file{centos-art.sh}
+script name, and a random identification string to let you run more
+than one @file{centos-art.sh} script simultaneously on the same user
+session. For example, due the following temporal file defintion:
+
+@verbatim
+cli_getTemporalFile $FILE
+@end verbatim
+
+If @var{FILE} name is @file{instance.svg} and the unique random string
+is @samp{f16f7b51-ac12-4b7f-9e66-72df847f12de}, the final temporal
+file, built from previous temporal file definition, would be:
+
+@verbatim
+/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
+@end verbatim
+
+When you use the @code{cli_getTemporalFile} function to create
+temporal files, be sure to remove temporal files created once you've
+ended up with them. For example, consider the following construction:
+
+@verbatim
+for FILE in $FILES;do
+
+ # Initialize temporal instance of file.
+ INSTANCE=$(cli_getTemporalFile $FILE)
+
+ # Do something ...
+
+ # Remove temporal instance of file.
+ if [[ -f $INSTANCE ]];then
+ rm $INSTANCE
+ fi
+
+done
+@end verbatim
+
+Use the @code{cli_getTemporalFile} function whenever you need to
+create temporal files inside @file{centos-art.sh} script.
+@end defun
+
+@defun cli_getThemeName
+Output theme name.
+
+In order for @code{cli_getThemeName} function to extract theme name
+correctly, the @var{ACTIONVAL} variable must contain a directory path
+under @file{trunk/Identity/Themes/Motifs/} directory structure.
+Otherwise, @code{cli_getThemeName} returns an empty string.
+@end defun
+
+@defun cli_printMessage MESSAGE [FORMAT]
+Define standard output message definition supported by
+@file{centos-art.sh} script.
+
+When @var{FORMAT} is not specified, @code{cli_printMessage} outputs
+information just as it was passed in @var{MESSAGE} variable.
+Otherwise, @var{FORMAT} can take one of the following values:
+
+@table @option
+@item AsHeadingLine
+To print heading messages.
+@verbatim
+----------------------------------------------------------------------
+$MESSAGE
+----------------------------------------------------------------------
+@end verbatim
+
+@item AsWarningLine
+To print warning messages.
+@verbatim
+----------------------------------------------------------------------
+WARNING: $MESSAGE
+----------------------------------------------------------------------
+@end verbatim
+
+@item AsNoteLine
+To print note messages.
+@verbatim
+----------------------------------------------------------------------
+NOTE: $MESSAGE
+----------------------------------------------------------------------
+@end verbatim
+
+@item AsUpdatingLine
+To print @samp{Updating} messages on two-columns format.
+@verbatim
+Updating $MESSAGE
+@end verbatim
+
+@item AsRemovingLine
+To print @samp{Removing} messages on two-columns format.
+@verbatim
+Removing $MESSAGE
+@end verbatim
+
+@item AsCheckingLine
+To print @samp{Checking} messages on two-columns format.
+@verbatim
+Checking $MESSAGE
+@end verbatim
+
+@item AsCreatingLine
+To print @samp{Creating} messages on two-columns format.
+@verbatim
+Creating $MESSAGE
+@end verbatim
+
+@item AsSavedAsLine
+To print @samp{Saved as} messages on two-columns format.
+@verbatim
+Saved as $MESSAGE
+@end verbatim
+
+@item AsLinkToLine
+To print @samp{Linked to} messages on two-columns format.
+@verbatim
+Linked to $MESSAGE
+@end verbatim
+
+@item AsMovedToLine
+To print @samp{Moved to} messages on two-columns format.
+@verbatim
+Moved to $MESSAGE
+@end verbatim
+
+@item AsTranslationLine
+To print @samp{Translation} messages on two-columns format.
+@verbatim
+Translation $MESSAGE
+@end verbatim
+
+@item AsConfigurationLine
+To print @samp{Configuration} messages on two-columns format.
+@verbatim
+Configuration $MESSAGE
+@end verbatim
+
+@item AsResponseLine
+To print response messages on one-column format.
+@verbatim
+--> $MESSAGE
+@end verbatim
+
+@item AsRequestLine
+To print request messages on one-column format. Request messages
+output messages with one colon (@samp{:}) and without trailing newline
+(@samp{\n}) at message end.
+@verbatim
+$MESSAGE:
+@end verbatim
+
+@item AsYesOrNoRequestLine
+To print @samp{yes or no} request messages on one-column format. If
+something different from @samp{y} is answered (when using
+@code{en_US.UTF-8} locale), script execution ends immediatly.
+
+@verbatim
+$MESSAGE [y/N]:
+@end verbatim
+
+When we use @file{centos-art.sh} script in a locale different from
+@code{en_US.UTF-8}, confirmation answer may be different from
+@samp{y}. For example, if you use @code{es_ES.UTF-8} locale, the
+confirmation question would look like:
+
+@verbatim
+$MESSAGE [s/N]:
+@end verbatim
+
+and the confirmation answer would be @samp{s}, as it is on Spanish
+@samp{sí} word.
+
+Definition of which confirmation word to use is set on translation
+messages for your specific locale information. --- @strong{Removed}(xref:trunk Scripts
+Bash Functions Locale) ---, for more information about locale-specific
+translation messages.
+
+@item AsToKnowMoreLine
+To standardize @samp{to know more, run the following command:}
+messages. When the @option{AsToKnowMoreLine} option is used, the
+@var{MESSAGE} value should be set to @code{"$(caller)"}. @code{caller}
+is a Bash builtin that returns the context of the current subroutine
+call. @option{AsToKnowMoreLine} option uses @code{caller} builtin
+output to build documentation entries dynamically.
+
+@verbatim
+----------------------------------------------------------------------
+To know more, run the following command:
+centos-art manual --read='path/to/dir'
+----------------------------------------------------------------------
+@end verbatim
+
+Use @option{AsToKnowMoreLine} option after errors and for intentional
+script termination.
+
+@item AsRegularLine
+To standardize regular messages on one-column format.
+
+When @var{MESSAGE} contains a colon inside (e.g., @samp{description:
+message}), the @code{cli_printMessage} function outputs @var{MESSAGE}
+on two-columns format.
+@end table
+
+Use @code{cli_printMessage} function whenever you need to output
+information from @file{centos-art.sh} script.
+
+@quotation
+@strong{Tip} To improve two-columns format, change the following file:
+@verbatim
+trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
+@end verbatim
+@end quotation
+@end defun
+
+@subsubsection Specific functions
+
+The following specific functions of @file{centos-art.sh} script, are
+available for you to use:
+
+@menu
+@comment --- Removed(* trunk Scripts Bash Functions Html::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Locale::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Manual::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Path::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Render::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Render Config::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Shell::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Svg::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Verify::) ---
+@end menu
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Locale::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi
new file mode 100644
index 0000000..bf264c9
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi
@@ -0,0 +1,85 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+This command looks for @samp{.sh} files inside Bash directory and
+extracts translatable strings from files, using @command{xgettext}
+command, in order to create a portable object template
+(@file{centos-art.sh.pot}) file for them.
+
+With the @file{centos-art.sh.pot} file up to date, the
+@command{centos-art} command removes the temporal list of files sotred
+inside @file{/tmp} directory and checks the current language of your
+user's session to create a portable object file for it, in the
+location @file{$CLI_LANG/$CLI_LANG.po}.
+
+The @var{CLI_LANG} variable discribes the locale language used to
+output messages inside @command{centos-art} command. The locale
+language used inside @command{centos-art} command is taken from the
+@env{LANG} environment variable. The @var{CLI_LANG} variable has the
+@samp{LL_CC} format, where @samp{LL} is a language code from the
+ISO-639 standard, and @samp{CC} a country code from the ISO-3166
+standard.
+
+The @env{LANG} environment variable is set when you do log in to your
+system. If you are using a graphical session, change language to your
+native language and do login. That would set and exoprt the @env{LANG}
+environment variable to the correct value. On the other side, if you
+are using a text session edit your @file{~/.bash_profile} file to set
+and export the @env{LANG} environment variable to your native locale
+as defines the @command{locale -a} command output; do logout, and do
+login again.
+
+At this point, the @env{LANG} environment variable has the appropriate
+value you need, in order to translate @command{centos-art.sh} messages
+to your native language (the one set in @env{LANG} environment
+variable).
+
+With the @file{$CLI_LANG/$CLI_LANG.po} file up to date, the
+@command{centos-art} opens it for you to update translation strings.
+The @command{centos-art} command uses the value of @var{EDITOR}
+environment variable to determine your favorite text editor. If no
+value is defined on @var{EDITOR}, the @file{/usr/bin/vim} text editor
+is used as default.
+
+When you finishd PO file edition and quit text editor, the
+@command{centos-art} command creates the related machine object in the
+location @file{$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo}.
+
+At this point, all translations you made in the PO file should be
+available to your language when runing @command{centos-art.sh} script.
+
+In order to make the @command{centos-art.sh} internationalization, the
+@command{centos-art.sh} script was modified as described in the
+@command{gettext} info documentation (@command{info gettext}). You
+can find such modifications in the following files:
+
+@itemize
+@item @file{trunk/Scripts/Bash/initFunctions.sh}
+@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh}
+@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh}
+@end itemize
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@table @samp
+@item centos-art locale --edit
+Use this command to translate command-line interface output messages
+in the current system locale you are using (as specified in @env{LANG}
+environment variable).
+@item centos-art locale --list
+Use this command to see the command-line interface locale report.
+@end table
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi
new file mode 100644
index 0000000..a7c6c55
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi
@@ -0,0 +1,327 @@
+@subsection Goals
+
+This section exists to organize files related to @code{path}
+functiontionality. The @code{path} functionality standardizes
+movement, syncronization, branching, tagging, and general file
+maintainance inside the repository.
+
+@subsection Description
+
+@emph{''CentOS like trees, has roots, trunk, branches, leaves and
+flowers. Day by day they work together in freedom, ruled by the laws
+of nature and open standards, to show the beauty of its existence.''}
+
+@subsubsection Repository layout
+
+The repository layout describes organization of files and directories
+inside the repository. The repository layout provides the standard
+backend required for automation scripts to work correctly. If such
+layout changes unexpectedly, automation scripts may confuse themselves
+and stop doing what we expect from them to do.
+
+As convenction, inside CentOS Artwork Repository, we organize files
+and directories related to CentOS corporate visual identity under
+three top level directories named: @file{trunk/}, @file{branches/},
+and @file{tags/}.
+
+The @file{trunk/} directory (@pxref{trunk}) organizes the main
+development line of CentOS corporate visual identity. Inside
+@file{trunk/} directory structure, the CentOS corporate visual
+identity concepts are implemented using directories. There is one
+directory level for each relevant concept inside the repository. The
+@file{trunk/} directory structure is mainly used to perform
+development tasks related to CentOS corporate visual identity.
+
+The @file{branches/} directory (@pxref{branches}) oranizes parallel
+development lines to @file{trunk/} directory. The @file{branches/}
+directory is used to set points in time where develpment lines are
+devided one from another taking separte and idependent lives that
+share a common past from the point they were devided on. The
+@file{branches/} directory is mainly used to perform quality assurance
+tasks related to CentOS corporate visual identity.
+
+The @file{tags/} directory (@pxref{tags}) organizes parallel frozen
+lines to @file{branches/} directory. The parallel frozen lines are
+immutable, nothing change inside them once they has been created. The
+@file{tags/} directory is mainly used to publish final releases of
+CentOS corporate visual identity.
+
+The CentOS Artwork Repository layout is firmly grounded on a
+Subversion base. Subversion (@url{http://subversion.tigris.org}) is a
+version control system, which allows you to keep old versions of files
+and directories (usually source code), keep a log of who, when, and
+why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a
+single copy of the master sources. This copy is called the source
+``repository''; it contains all the information to permit extracting
+previous versions of those files at any time.
+
+@subsubsection Repository name convenctions
+
+Repository name convenctions help us to maintain consistency of names
+inside the repository.
+
+Repository name convenctions are applied to files and directories
+inside the repository layout. As convenction, inside the repository
+layout, file names are all written in lowercase
+(@samp{01-welcome.png}, @samp{splash.png}, @samp{anaconda_header.png},
+etc.) and directory names are all written capitalized (e.g.,
+@samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower},
+etc.).
+
+Repository name convenctions are implemented inside the
+@code{cli_getRepoName} function of @file{centos-art.sh} script. With
+@code{cli_getRepoName} function we reduce the amount of commands and
+convenctions to remember, concentrating them in just one single place
+to look for fixes and improvements.
+
+@subsubsection Repository work flow
+
+Repository work flow describes the steps and time intervals used to
+produce CentOS corporate visual identity inside CentOS Artwork
+Repository.
+
+To illustrate repository work flow let's consider themes' development
+cycle.
+
+Initially, we start working themes on their trunk development line
+(e.g., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we
+organize information that cannot be produced automatically (i.e.,
+background images, concepts, color information, screenshots, etc.).
+
+Later, when theme trunk development line is considered ``ready'' for
+implementation (e.g., all required backgrounds have been designed),
+we create a branch for it (e.g.,
+@file{branches/Identity/Themes/Motifs/TreeFlower/1/}). Once the
+branch has been created, we forget that branch and continue working
+the trunk development line while others (e.g., an artwork quality
+assurance team) test the new branch for tunning it up.
+
+Once the branch has been tunned up, and considered ``ready'' for
+release, it is freezed under @file{tags/} directory (e.g.,
+@file{tags/Identity/Themes/Motifs/TreeFower/1.0/}) for packagers,
+webmasters, promoters, and anyone who needs images from that CentOS
+theme the tag was created for.
+
+Both branches and tags, inside CentOS Artwork Repository, use
+numerical values to identify themselves under the same location.
+Branches start at one (i.e., @samp{1}) and increment one unit for each
+branch created from the same trunk development line. Tags start at
+zero (i.e., @samp{0}) and increment one unit for each tag created from
+the same branch development line.
+
+@quotation
+@strong{Convenction} Do not freeze trunk development lines using tags
+directly. If you think you need to freeze a trunk development line,
+create a branch for it and then freeze that branch instead.
+@end quotation
+
+The trunk development line may introduce problems we cannot see
+immediatly. Certainly, the high changable nature of trunk development
+line complicates finding and fixing such problems. On the other hand,
+the branched development lines provide a more predictable area where
+only fixes/corrections to current content are commited up to
+repository.
+
+If others find and fix bugs inside the branched development line, we
+could merge such changes/experiences back to trunk development line
+(not visversa) in order for future branches, created from trunk, to
+benefit.
+
+Time intervals used to create branches and tags may vary, just as
+different needs may arrive. For example, consider the release schema
+of CentOS distribution: one major release every 2 years, security
+updates every 6 months, support for 7 years long. Each time a CentOS
+distribution is released, specially if it is a major release, there is
+a theme need in order to cover CentOS distribution artwork
+requirements. At this point, is where CentOS Artwork Repository comes
+up to scene.
+
+Before releasing a new major release of CentOS distribution we create
+a branch for one of several theme development lines available inside
+the CentOS Artwork Repository, perform quality assurance on it, and
+later, freeze that branch using tags. Once a the theme branch has been
+frozen (under @file{tags/} directory), CentOS Packagers (the persons
+whom build CentOS distribution) can use that frozen branch as source
+location to fulfill CentOS distribution artwork needs. The same
+applies to CentOS Webmasters (the persons whom build CentOS websites),
+and any other visual manifestation required by the project.
+
+@subsubsection Parallel directories
+
+Inside CentOS Artwork Repository, parallel directories are simple
+directory entries built from a common parent directory and placed in a
+location different to that, the common parent directory is placed on.
+Parallel directories are useful to create branches, tags,
+translations, documentation, pre-rendering configuration script, and
+similar directory structures.
+
+Parallel directories take their structure from one unique parent
+directory. Inside CentOS Artwork Repository, this unique parent
+directory is under @file{trunk/Identity} location. The
+@file{trunk/Identity} location must be considered the reference for
+whatever information you plan to create inside the repository.
+
+In some circumstances, parallel directories may be created removing
+uncommon information from their paths. Uncommon path information
+refers to those directory levels in the path which are not common for
+other parallel directories. For example, when rendering
+@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory
+structure, the @file{centos-art.sh} script removes the
+@file{Motifs/TreeFlower/} directory levels from path, in order to
+build the parallel directory used to retrived translations, and
+pre-rendering configuration scripts required by @code{render}
+functionality.
+
+Another example of parallel directory is the documentation structure
+created by @code{manual} functionality. This time,
+@file{centos-art.sh} script uses parallel directory information with
+uncommon directory levels to build the documentation entry required by
+Texinfo documentation system, inside the repository.
+
+Othertimes, parallel directories may add uncommon information to their
+paths. This is the case we use to create branches and tags. When we
+create branches and tags, a numerical identifier is added to parallel
+directory structure path. The place where the numerical identifier is
+set on is relevant to corporate visual identity structure and should
+be carefully considered where it will be.
+
+When one parent directory changes, all their related parallel
+directories need to be changed too. This is required in order for
+parallel directories to retain their relation with the parent
+directory structure. In the other hand, parallel directories should
+never be modified under no reason but to satisfy the relation to their
+parent directory structure. Liberal change of parallel directories
+may suppresses the conceptual idea they were initially created for;
+and certainly, things may stop working the way they should do.
+
+@subsubsection Syncronizing path information
+
+Parallel directories are very useful to keep repository organized but
+introduce some complications. For instance, consider what would
+happen to functionalities like @code{manual} (@samp{trunk Scripts Bash
+Functions Manual}) that rely on parent directory structures to create
+documentation entries (using parallel directory structures) if one of
+those parent directory structures suddenly changes after the
+documentation entry has been already created for it?
+
+In such cases, functionalities like @code{manual} may confuse
+themselves if path information is not updated to reflect the relation
+with its parent directory. Such functionalities work with parent
+directory structure as reference; if a parent directory changes, the
+functionalities dont't even note it because they work with the last
+parent directory structure available in the repository, no matter what
+it is.
+
+In the specific case of documentation (the @code{manual}
+functionality), the problem mentioned above provokes that older parent
+directories, already documented, remain inside documentation directory
+structures as long as you get your hands into the documentation
+directory structure (@file{trunk/Manuals}) and change what must be
+changed to match the new parent directory structure.
+
+There is no immediate way for @code{manual}, and similar
+functionalities that use parent directories as reference, to know when
+and how directory movements take place inside the repository. Such
+information is available only when the file movement itself takes
+place inside the repository. So, is there, at the moment of moving
+files, when we need to syncronize parallel directories with their
+unique parent directory structure.
+
+@quotation
+@strong{Warning} There is not support for URL reference inside
+@file{centos-art.sh} script. The @file{centos-art.sh} script is
+designed to work with local files inside the working copy only.
+@end quotation
+
+As CentOS Artwork Repository is built over a version control system,
+file movements inside the repository are considered repository
+changes. In order for these repository changes to be versioned, we
+need to, firstly, add changes into the version control system, commit
+them, and later, perform movement actions using version control system
+commands. This configuration makes possible for everyone to know about
+changes details inside the repository; and if needed, revert or update
+them back to a previous revision.
+
+Finally, once all path information has been corrected, it is time to
+take care of information inside the files. For instance, considere
+what would happen if you make a reference to a documentation node, and
+later the documentation node you refere to is deleted. That would make
+Texinfo to produce error messages at export time. So, the
+@file{centos-art.sh} script needs to know when such changes happen, in
+a way they could be noted and handled without producing errors.
+
+@subsubsection What is the right place to store it?
+
+Occasionly, you may find that new corporate visual identity components
+need to be added to the repository. If that is your case, the first
+question you need to ask yourself, before start to create directories
+blindly all over, is: What is the right place to store it?
+
+The CentOS Community different free support vains (see:
+@url{http://wiki.centos.org/GettingHelp}) are the best place to find
+answers to your question, but going there with hands empty is not good
+idea. It may give the impression you don't really care about. Instead,
+consider the following suggestions to find your own comprehension and
+so, make your propositions based on it.
+
+When we are looking for the correct place to store new files, to bear
+in mind the corporate visual identity structure used inside the CentOS
+Artwork Repository (@pxref{trunk Identity}) would be probaly the best
+advice we could offer, the rest is just matter of choosing appropriate
+names. To illustrate this desition process let's consider the
+@file{trunk/Identity/Themes/Motifs/TreeFlower} directory as example.
+It is the trunk development line of @emph{TreeFlower} artistic motif.
+Artistic motifs are considered part of themes, which in turn are
+considered part of CentOS corporate visual identity.
+
+When building parent directory structures, you may find that reaching
+an acceptable location may take some time, and as it uses to happen
+most of time; once you've find it, that may be not a definite
+solution. There are many concepts that you need to play with, in
+order to find a result that match the conceptual idea you try to
+implement in the new directory location. To know which these concepts
+are, split the location in words and read its documentation entry from
+less specific to more specific.
+
+For example, the @file{trunk/Identity/Themes/Motifs/TreeFlower}
+location evolved through several months of contant work and there is
+no certain it won't change in the future, even it fixes quite well the
+concept we are trying to implement. The concepts used in
+@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} location are
+described in the following commands, respectively:
+
+@verbatim
+centos-art manual --read=turnk/
+centos-art manual --read=turnk/Identity/
+centos-art manual --read=turnk/Identity/Themes/
+centos-art manual --read=turnk/Identity/Themes/Motifs/
+centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
+@end verbatim
+
+Other location concepts can be found similary as we did above, just
+change the location we used above by the one you are trying to know
+concepts for.
+
+@subsection Usage
+
+@table @command
+@item centos-art path --copy='SRC' --to='DST'
+
+Copy @option{SRC} to @option{DST} and schedule @option{DST} for
+addition (with history). In this command, @file{SRC} and @file{DST}
+are both working copy (WC) entries.
+
+@item centos-art path --delete='SRC'
+
+Delete @option{DST}. In order for this command to work the file or
+directory you intend to delete should be under version control first.
+In this command, @file{SRC} is a working copy (WC) entry.
+
+@end table
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi
new file mode 100644
index 0000000..7dfe2c5
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi
@@ -0,0 +1,736 @@
+The @code{render} functionality exists to produce both identity and
+translation files on different levels of information (i.e., different
+languages, release numbers, architectures, etc.).
+
+The @code{render} functionality relies on ``renderable directory
+structures'' to produce files. Renderable directory structures can be
+either ``identity directory structures'' or ``translation directory
+structures'' with special directories inside.
+
+@subsection Renderable identity directory structures
+
+Renderable identity directory structures are the starting point of
+identity rendition. Whenever we want to render a component of CentOS
+corporate visual identity, we need to point @file{centos-art.sh} to a
+renderable identity directory structure. If such renderable identity
+directory structure doesn't exist, then it is good time to create it.
+
+Inside the working copy, one renderable identity directory structures
+represents one visual manifestation of CentOS corporate visual
+identity, or said differently, each visual manifestation of CentOS
+corporate visual identity should have one renderable identity
+directory structure.
+
+Inside renderable identity directory structures, @file{centos-art.sh}
+can render both image-based and text-based files. Specification of
+whether a renderable identity directory structure produces image-based
+or text-based content is a configuration action that takes place in
+the pre-rendition configuration script of that renderable identity
+directory structure.
+
+Inside renderable identity directory structures, content production is
+organized in different configurations. A content production
+configuration is a unique combination of the components that make an
+identity directory structure renderable. One content production
+configuration does one thing only (e.g., to produce untranslated
+images), but it can be extended (e.g., adding translation files) to
+achieve different needs (e.g., to produce translated images).
+
+@subsubsection Design template without translation
+
+The design template without translation configuration is based on a
+renderable identity directory structure with an empty translation
+directory structure. In this configuration, one design template
+produces one untranslated file. Both design templates and final
+untranslated files share the same file name, but they differ one
+another in file-type and file-extension.
+
+For example, to produce images without translations (there is no much
+use in producing text-based files without translations), consider the
+following configuration:
+
+@table @strong
+@item One renderable identity directory structure:
+
+In this example we used @file{Identity/Path/To/Dir} as the identity
+component we want to produce untranslated images for. Identity
+components can be either under @file{trunk/} or @file{branches/}
+directory structure.
+
+The identity component (i.e., @file{Identity/Path/To/Dir}, in this
+case) is also the bond component we use to connect the identity
+directory structures with their respective auxiliar directories (i.e.,
+translation directory structres and pre-rendition configuration
+structures). The bond component is the path convenction that
+@file{centos-art.sh} uses to know where to look for related
+translations, configuration scripts and whatever auxiliar thing a
+renderable directory structure may need to have.
+
+@verbatim
+ | The bond component
+ |----------------->|
+trunk/Identity/Path/To/Dir <-- Renderable identity directory structure.
+|-- Tpl <-- Design template directory.
+| `-- file.svg <-- Design template file.
+`-- Img <-- Directory used to store final files.
+ `-- file.png <-- Final image-based file produced from
+ design template file.
+@end verbatim
+
+Inside design template directory, design template files are based on
+@acronym{SVG,Scalable Vector Graphics} and use the extension
+@code{.svg}. Design template files can be organized using several
+directory levels to create a simple but extensible configuration,
+specially if translated images are not required.
+
+In order for @acronym{SVG,Scalable Vector Graphics} files to be
+considered ``design template'' files, they should be placed under the
+design template directory and to have set a @code{CENTOSARTWORK}
+object id inside.
+
+The @code{CENTOSARTWORK} word itself is a convenction name we use to
+define which object/design area, inside a design template, the
+@file{centos-art.sh} script will use to export as
+@acronym{PNG,Portable Network Graphic} image at rendition time.
+Whithout such object id specification, the @file{centos-art.sh} script
+cannot know what object/design area you (as designer) want to export
+as @acronym{PNG,Portable Network Graphic} image file.
+
+@quotation
+@strong{Note} At rendition time, the content of @file{Img/} directory
+structure is produced by @file{centos-art.sh} automatically.
+@end quotation
+
+When a renderable identity directory structure is configured to
+produce image-based content, @file{centos-art.sh} produces
+@acronym{PNG,Portable Network Graphics} files with the @code{.png}
+extension. Once the base image format has been produced, it is
+possible for @file{centos-art.sh} to use it in order to automatically
+create other image formats that may be needed (--- @strong{Removed}(pxref:trunk Scripts
+Bash Functions Render Config) ---).
+
+Inside the working copy, you can find an example of ``design template
+without translation'' configuration at @file{trunk/Identity/Models/}.
+
+@xref{trunk Identity}, for more information.
+
+@item One translation directory structure:
+
+In order for an identity entry to be considered an identity renderable
+directory structure, it should have a translation entry. The content
+of the translation entry is relevant to determine how to process the
+identity renderable directory entry.
+
+If the translation entry is empty (i.e., there is no file inside it),
+@file{centos-art.sh} interprets the identity renderable directory
+structure as a ``design templates without translation'' configuration.
+
+@verbatim
+ | The bond component
+ |----------------->|
+trunk/Translations/Identity/Path/To/Dir
+`-- (empty)
+@end verbatim
+
+If the translation entry is not empty, @file{centos-art.sh} can
+interpret the identity renderable directory structure as one of the
+following configurations: ``design template with translation
+(one-to-one)'' or ``design template with translation (optimized)''.
+Which one of these configurations is used depends on the value
+assigned to the matching list (@var{MATCHINGLIST}) variable in the
+pre-rendition configuration script of the renderable identity
+directory structure we are producing images for.
+
+If the matching list variable is empty (as it is by default), then
+``design template with translation (one-to-one)'' configuration is
+used. In this configuration it is required that both design templates
+and translation files have the same file names. This way, @emph{one}
+translation files is applied to @emph{one} design template, to produce
+@emph{one} translated image.
+
+If the matching list variable is not empty (because you redefine it in
+the pre-rendition configuration script), then ``design template with
+translation (optimized)'' configuration is used instead. In this
+configuration, design templates and translation files don't need to
+have the same names since such name relationship between them is
+specified in the matching list properly.
+
+--- @strong{Removed}(xref:trunk Translations) ---, for more information.
+
+@item One pre-rendition configuration script:
+
+In order to make an identity directory structure renderable, a
+pre-rendition configuration script should exist for it. The
+pre-rendition configuration script specifies what type of rendition
+does @file{centos-art.sh} will perform over the identity directory
+structure and how does it do that.
+
+@verbatim
+ | The bond component
+ |----------------->|
+trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
+@end verbatim
+
+In this configuration the pre-rendition configuration script
+(@file{render.conf.sh}) would look like the following:
+
+@verbatim
+function render_loadConfig {
+
+ # Define rendition actions.
+ ACTIONS[0]='BASE:renderImage'
+
+}
+@end verbatim
+
+Since translation directory structure is empty, @file{centos-art.sh}
+assumes a ``design template without translation'' configuration to
+produce untranslated images.
+
+To produce untranslated images, @file{centos-art.sh} takes one design
+template and creates one temporal instance from it. Later,
+@file{centos-art.sh} uses the temporal design template instance as
+source file to export the final untranslated image. The action of
+exporting images from @acronym{SVG,Scalable Vector Graphics} to
+@acronym{PNG,Portable Network Graphics} is possible thanks to
+Inkscape's command-line interface and the @code{CENTOSARTWORK} object
+id we previously set inside design templates.
+
+@verbatim
+centos-art.sh render --identity=trunk/Identity/Path/To/Dir
+-------------------------------------------------
+0 | Execute centos-art.sh on renderable identity directory structure.
+--v----------------------------------------------
+trunk/Identity/Path/To/Dir/Tpl/file.svg
+-------------------------------------------------
+1 | Create instance from design template.
+--v----------------------------------------------
+/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
+-------------------------------------------------
+2 | Render untranslated image from design template instance.
+--v----------------------------------------------
+trunk/Identity/NewDir/Img/file.png
+-------------------------------------------------
+3 | Remove design template instance.
+@end verbatim
+
+Finally, when the untranslated image has been created, the temporal
+design template instance is removed. At this point,
+@file{centos-art.sh} takes the next design template and repeats the
+whole production flow once again (design template by design template),
+until all design templates be processed.
+
+--- @strong{Removed}(xref:trunk Scripts Bash Functions Render Config) ---, for more
+information.
+@end table
+
+@subsubsection Design template with translation (one-to-one)
+
+Producing untranslated images is fine in many cases, but not always.
+Sometimes it is required to produce images in different languages and
+that is something that untrasnlated image production cannot achieve.
+However, if we fill its empty translation entry with translation files
+(one for each design template) we extend the production flow from
+untranslated image production to translated image production.
+
+In order for @file{centos-art.sh} to produce images correctly, each
+design template should have one translation file and each translation
+file should have one design template. Otherwise, if there is a
+missing design template or a missing translation file,
+@file{centos-art.sh} will not produce the final image related to the
+missing component.
+
+In order for @file{centos-art.sh} to know which is the relation
+between translation files and design templates the translation
+directory structure is taken as reference. For example, the
+@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation
+file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design
+template, but it doesn't match
+@file{trunk/Identity/Path/To/Dir/File.svg} or
+@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or
+@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design
+templates.
+
+The pre-rendition configuration script used to produce untranslated
+images is the same we use to produce translated images. There is no
+need to modify it. So, as we are using the same pre-rendition
+configuration script, we can say that translated image production is
+somehow an extended/improved version of untranslated image production.
+
+@quotation
+@strong{Note} If we use no translation file in the translation entry
+(i.e., an empty directory), @file{centos-art.sh} assumes the
+untranslated image production. If we fill the translation entry with
+translation files, @file{centos-art.sh} assumes the translated image
+production.
+@end quotation
+
+To produce final images, @file{centos-art.sh} applies one translation
+file to one design template and produce a translated design template
+instance. Later, @file{centos-art.sh} uses the translated template
+instance to produce the translated image. Finally, when the translated
+image has been produced, @file{centos-art.sh} removes the translated
+design template instance. This production flow is repeated for each
+translation file available in the translatio entry.
+
+@verbatim
+centos-art.sh render --identity=trunk/Identity/Path/To/Dir
+-------------------------------------------------
+0 | Execute centos-art.sh on directory structure.
+--v----------------------------------------------
+trunk/Translations/Identity/Path/To/Dir/file.sed
+-------------------------------------------------
+1 | Apply translation to design template.
+--v----------------------------------------------
+trunk/Identity/Path/To/Dir/Tpl/file.svg
+-------------------------------------------------
+2 | Create design template instance.
+--v----------------------------------------------
+/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
+-------------------------------------------------
+3 | Render PNG image from template instance.
+--v----------------------------------------------
+trunk/Identity/NewDir/Img/file.png
+-------------------------------------------------
+4 | Remove design template instance.
+@end verbatim
+
+@subsubsection Design template with translation (optimized)
+
+Producing translated images satisfies almost all our production images
+needs, but there is still a pitfall in them. In order to produce
+translated images as in the ``one-to-one'' configuration describes
+previously, it is required that one translation file has one design
+template. That's useful in many cases, but what would happen if we
+need to apply many different translation files to the same design
+template? Should we have to duplicate the same design template file
+for each translation file, in order to satisfy the ``one-to-one''
+relation? What if we need to assign translation files to design
+templates arbitrarily?
+
+Certenly, that's something the ``one-to-one'' configuration cannot
+handle. So, that's why we had to ``optimize'' it. The optimized
+configuration consists on using a matching list (@var{MATCHINGLIST})
+variable that specifies the relationship between translation files and
+design templates in an arbitrary way. Using such matching list between
+translation files and design templates let us use as many assignment
+combinations as translation files and design templates we are working
+with.
+
+The @var{MATCHINGLIST} variable is set in the pre-rendition
+configuration script of the component we want to produce images for.
+By default, the @var{MATCHINGLIST} variable is empty which means no
+matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a
+value different to empty value then, @file{centos-art.sh} interprets
+the matching list in order to know how translation files are applied
+to design templates.
+
+For example, consider the following configuration:
+
+@table @strong
+@item One entry under @file{trunk/Identity/}:
+
+In this configuration we want to produce three images using a
+paragraph-based style, controlled by @file{paragraph.svg} design
+template; and one image using a list-based style, controlled by
+@file{list.svg} design template.
+
+@verbatim
+trunk/Identity/Path/To/Dir
+|-- Tpl
+| |-- paragraph.svg
+| `-- list.svg
+`-- Img
+ |-- 01-welcome.png
+ |-- 02-donate.png
+ |-- 03-docs.png
+ `-- 04-support.png
+@end verbatim
+
+@item One entry under @file{trunk/Translations/}:
+
+In order to produce translated images we need to have one translation
+file for each translated image we want to produce. Notice how
+translation names do match final image file names, but how translation
+names do not match design template names. When we use matching list
+there is no need for translation files to match the names of design
+templates, such name relation is set inside the matching list itself.
+
+@verbatim
+trunk/Translations/Identity/Path/To/Dir
+|-- 01-welcome.sed
+|-- 02-donate.sed
+|-- 03-docs.sed
+`-- 04-support.sed
+@end verbatim
+
+@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}:
+
+In order to produce different translated images using specific design
+templates, we need to specify the relation between translation files
+and design templates in a way that @file{centos-art.sh} could know
+exactly what translation file to apply to what design template. This
+relation between translation files and design templates is set using
+the matching list @var{MATCHINGLIST} variable inside the pre-rendition
+configuration script of the component we want to produce images for.
+
+@verbatim
+trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
+@end verbatim
+
+In this configuration the pre-rendition configuration script
+(@file{render.conf.sh}) would look like the following:
+
+@verbatim
+function render_loadConfig {
+
+ # Define rendition actions.
+ ACTIONS[0]='BASE:renderImage'
+
+ # Define matching list.
+ MATCHINGLIST="\
+ paragraph.svg:\
+ 01-welcome.sed\
+ 02-donate.sed\
+ 04-support.sed
+ list.svg:\
+ 03-docs.sed
+ "
+
+}
+@end verbatim
+
+As result, @file{centos-art.sh} will produce @file{01-welcome.png},
+@file{02-donate.png} and @file{04-support.png} using the
+paragraph-based design template, but @file{03-docs.png} using the
+list-based design template.
+@end table
+
+@subsubsection Design template with translation (optimized+flexibility)
+
+In the production models we've seen so far, there are design templates
+to produce untranslated images and translation files which combiend
+with design templates produce translated images. That may seems like
+all our needs are covered, doesn't it? Well, it @emph{almost} does.
+
+Generally, we use design templates to define how final images will
+look like. Generally, each renderable directory structure has one
+@file{Tpl/} directory where we organize design templates for that
+identity component. So, we can say that there is only one unique
+design template definition for each identity component; or what is the
+same, said differently, identity components can be produced in one way
+only, the way its own design template directory specifies. This is
+not enough for theme production. It is a limitation, indeed.
+
+Initially, to create one theme, we created one renderable directory
+structure for each theme component. When we found ourselves with many
+themes, and components inside them, it was obvious that the same
+design model was duplicated inside each theme. As design models were
+independently one another, if we changed one theme's design model,
+that change was useless to other themes. So, in order to reuse design
+model changes, we unified design models into one common directory
+structure.
+
+With design models unified in a common structure, another problem rose
+up. As design models also had the visual style of theme components,
+there was no difference between themes, so there was no apparent need
+to have an independent theme directory structure for each different
+theme. So, it was also needed to separate visual styles from design
+models.
+
+At this point there are two independent worklines: one directory
+structure to store design models (the final image characteristics
+[i.e., dimensions, translation markers, etc.]) and one directory
+structure to store visual styles (the final image visual style [i.e.,
+the image look and feel]). So, it is possible to handle both
+different design models and different visual styles independtly one
+another and later create combinations among them using
+@file{centos-art.sh}.
+
+For example, consider the following configuration:
+
+@table @strong
+@item One entry under @file{trunk/Identity/Themes/Models/}:
+
+The design model entry exists to organize design model files (similar
+to design templates). Both design models and design templates are very
+similar; they both should have the @code{CENTOSARTWORK} export id
+present to identify the exportation area, translation marks, etc.
+However, design models do use dynamic backgrounds inclusion while
+design templates don't.
+
+@verbatim
+ THEMEMODEL | | The bond component
+ |<----| |--------------------->|
+trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
+|-- paragraph.svg
+`-- list.svg
+@end verbatim
+
+Inisde design models, dynamic backgrounds are required in order for
+different artistic motifs to reuse common design models. Firstly, in
+order to create dynamic backgrounds inside design models, we import a
+bitmap to cover design model's background and later, update design
+model's path information to replace fixed values to dynamic values.
+
+@item One entry under @file{trunk/Identity/Themes/Motifs/}:
+
+The artistic motif entry defines the visual style we want to produce
+images for, only. Final images (i.e., those built from combining both
+design models and artistic motif backrounds) are not stored here, but
+under branches directory structure. In the artistic motif entry, we
+only define those images that cannot be produced automatically by
+@file{centos-art.sh} (e.g., Backgrounds, Color information,
+Screenshots, etc.).
+
+@verbatim
+ Artistic motif name | | Artistic motif backgrounds
+ |<-------| |-------->|
+trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
+|-- Img
+| |-- Png
+| | |-- 510x300.png
+| | `-- 510x300-final.png
+| `-- Jpg
+| |-- 510x300.jpg
+| `-- 510x300-final.jpg
+|-- Tpl
+| `-- 510x300.svg
+`-- Xcf
+ `-- 510x300.xcf
+@end verbatim
+
+@item One entry under @file{trunk/Translations/}:
+
+The translation entry specifies, by means of translation files, the
+language-specific information we want to produce image for. When we
+create the translation entry we don't use the name of neither design
+model nor artistic motif, just the design model component we want to
+produce images for.
+
+@verbatim
+ | The bond component
+ |--------------------->|
+trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+`-- 5
+ |-- en
+ | |-- 01-welcome.sed
+ | |-- 02-donate.sed
+ | `-- 03-docs.sed
+ `-- es
+ |-- 01-welcome.sed
+ |-- 02-donate.sed
+ `-- 03-docs.sed
+@end verbatim
+
+@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}:
+
+There is one pre-rendition configuration script for each theme
+component. So, each time a theme component is rendered, its
+pre-rendition configuration script is evaluated to teach
+@file{centos-art.sh} how to render the component.
+
+@verbatim
+trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
+`-- render.conf.sh
+@end verbatim
+
+In this configuration the pre-rendition configuration script
+(@file{render.conf.sh}) would look like the following:
+
+@verbatim
+function render_loadConfig {
+
+ # Define rendition actions.
+ ACTIONS[0]='BASE:renderImage'
+
+ # Define matching list.
+ MATCHINGLIST="\
+ paragraph.svg:\
+ 01-welcome.sed\
+ 02-donate.sed
+ list.svg:\
+ 03-docs.sed
+ "
+
+ # Deifne theme model.
+ THEMEMODEL='Default'
+
+}
+@end verbatim
+@end table
+
+The production flow of ``optimize+flexibility'' configuration@dots{}
+@subsection Renderable translation directory structures
+
+Translation directory structures are auxiliar structures of renderable
+identity directory structures. There is one translation directory
+structure for each renderable identity directory structure. Inside
+translation directory structures we organize translation files used by
+renderable identity directory structures that produce translated
+images. Renderable identity directory structures that produce
+untranslated images don't use translation files, but they do use a
+translation directory structure, an empty translation directory
+structure, to be precise.
+
+In order to aliviate production of translation file, we made
+translation directory structures renderable adding a template
+(@file{Tpl/}) directory structure to handle common content inside
+translation files. This way, we work on translation templates and
+later use @file{centos-art.sh} to produce specific translation files
+(based on translation templates) for different information (e.g.,
+languages, release numbers, architectures, etc.).
+
+If for some reason, translation files get far from translation
+templates and translation templates become incovenient to produce such
+translation files then, care should be taken to avoid replacing the
+content of translation files with the content of translation templates
+when @file{centos-art.sh} is executed to produce translation files
+from translation templates.
+
+Inside renderable translation directory structures,
+@file{centos-art.sh} can produce text-based files only.
+
+@subsection Copying renderable directory structures
+
+A renderable layout is formed by design models, design images,
+pre-rendition configuration scripts and translations files. This way,
+when we say to duplicate rendition stuff we are saying to duplicate
+these four directory structures (i.e., design models, design images,
+pre-rendition configuration scripts, and related translations files).
+
+When we duplicate directories, inside `trunk/Identity' directory
+structure, we need to be aware of renderable layout described above
+and the source location used to perform the duplication action. The
+source location is relevant to centos-art.sh script in order to
+determine the required auxiliar information inside directory
+structures that need to be copied too (otherwise we may end up with
+orphan directory structures unable to be rendered, due the absence of
+required information).
+
+In order for a renderable directory structure to be valid, the new
+directory structure copied should match the following conditions:
+
+@enumerate
+@item To have a unique directory structure under
+@file{trunk/Identity}, organized by any one of the above
+organizational designs above.
+
+@item To have a unique directory structure under
+@file{trunk/Translations} to store translation files.
+
+@item To have a unique directory structure under
+@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition
+configuration script.
+@end enumerate
+
+As convenction, the @code{render_doCopy} function uses
+@file{trunk/Identity} directory structure as source location. Once
+the @file{trunk/Identity} directory structure has been specified and
+verified, the related path information is built from it and copied
+automatically to the new location specified by @var{FLAG_TO} variable.
+
+Design templates + No translation:
+
+Command:
+- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir
+
+Sources:
+- trunk/Identity/Path/To/Dir
+- trunk/Translations/Identity/Path/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+
+Targets:
+- trunk/Identity/NewPath/To/Dir
+- trunk/Translations/Identity/NewPath/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir
+
+Renderable layout 2:
+
+Command:
+- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \
+ --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir
+
+Sources:
+- trunk/Identity/Themes/Motifs/TreeFlower
+- trunk/Translations/Identity/Themes
+- trunk/Translations/Identity/Themes/Motifs/TreeFlower
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower
+
+Targets:
+- trunk/Identity/Themes/Motifs/NewPath/To/Dir
+- trunk/Translations/Identity/Themes
+- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir
+
+Notice that design models are not included in source or target
+locations. This is intentional. In ``Renderable layout 2'', design
+models live by their own, they just exist, they are there, available
+for any artistic motif to use. By default `Themes/Models/Default'
+design model directory structure is used, but other design models
+directory structures (under Themes/Models/) can be created and used
+changing the value of THEMEMODEL variable inside the pre-rendition
+configuration script of the artistic motif source location you want to
+produce.
+
+Notice how translations and pre-rendition configuration scripts may
+both be equal in source and target. This is because such structures
+are common to all artistic motifs (the default values to use when no
+specific values are provided).
+
+- The common directory structures are not copied or deleted. We cannot
+ copy a directory structure to itself.
+
+- The common directory structures represent the default value to use
+ when no specific translations and/or pre-rendition configuration
+ script are provided inside source location.
+
+- The specific directory structures, if present, are both copiable and
+ removable. This is, when you perform a copy or delete action from
+ source, that source specific auxiliar directories are transfered in
+ the copy action to a new location (that specified by FLAG_TO
+ variable).
+
+- When translations and/or pre-rendition configuration scripts are
+ found inside the source directory structure, the centos-art.sh
+ script loads common auxiliar directories first and later specific
+ auxiliar directories. This way, identity rendition of source
+ locations can be customized idividually over the base of common
+ default values.
+
+- The specific auxiliar directories are optional.
+
+- The common auxiliar directories should be present always. This is,
+ in order to provide the information required by render functionality
+ (i.e., to make it functional in the more basic level of its
+ existence).
+
+Notice how the duplication process is done from `trunk/Identity' on,
+not the oposite. If you try to duplicate a translation structure (or
+similar auxiliar directory structures like pre-rendition configuration
+scripts), the `trunk/Identity' for that translation is not created.
+This limitation is impossed by the fact that many `trunk/Identity'
+directory structures may reuse/share the same translation directory
+structure. We cannot delete one translation (or similar) directory
+structures while a related `trunk/Identity/' directory structure is
+still in need of it.
+
+The `render_doCopy' functionality does duplicate directory structures
+directly involved in rendition process only. Once such directories
+have been duplicated, the functionality stops thereat.
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@comment --- Removed(* trunk Scripts Bash Functions Render Config::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
new file mode 100644
index 0000000..3b3322b
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
@@ -0,0 +1,192 @@
+@subsection Goals
+
+The @file{trunk/Scripts/Bash/Config} directory exists to oraganize
+pre-rendering configuration scripts.
+
+@subsection Description
+
+Pre-rendering configuration scripts let you customize the way
+@command{centos-art.sh} script renders identity and translation
+repository entries. Pre-rendering configuration scripts are
+@file{render.conf.sh} files with @command{render_loadConfig} function
+definition inside.
+
+There is one @file{render.conf.sh} file for each pre-rendering
+configuration entry. Pre-rendering configuration entries can be based
+both on identity and translation repository entires. Pre-rendering
+configuration entries are required for each identity entry, but not
+for translation entries.
+
+@subsubsection The @file{render.conf.sh} identity model
+
+Inside CentOS Artwork Repository, we consider identity entries to all
+directories under @file{trunk/Identity} directory. Identity entries can be
+image-based or text-based. When you render image-based identity
+entries you need to use image-based pre-rendering configuration
+scripts. Likewise, when you render text-based identity entries you
+need to use text-based pre-rendering configuration scripts.
+
+Inside identity pre-rendering configuration scripts, image-based
+pre-rendering configuration scripts look like the following:
+
+@verbatim
+#!/bin/bash
+
+function render_loadConfig {
+
+ # Define rendering actions.
+ ACTIONS[0]='BASE:renderImage'
+ ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
+
+}
+@end verbatim
+
+Inside identity pre-rendering configuration scripts, text-based
+pre-rendering configuration scripts look like the following:
+
+@verbatim
+#!/bin/bash
+
+function render_loadConfig {
+
+ # Define rendering actions.
+ ACTIONS[0]='BASE:renderText'
+ ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
+
+}
+@end verbatim
+
+When using identity pre-rendering configuration scripts, you can
+extend both image-based and text-based pre-rendering configuration
+scripts using image-based and text-based post-rendering actions,
+respectively.
+
+@subsubsection The @file{render.conf.sh} translation model
+
+Translation pre-rendering configuration scripts take precedence before
+default translation rendering action. Translation pre-rendering
+actions are useful when default translation rendering action do not
+fit itself to translation entry rendering requirements.
+
+@subsubsection The @file{render.conf.sh} rendering actions
+
+Inside both image-based and text-based identity pre-rendering
+configuration scripts, we use the @samp{ACTIONS} array variable to
+define the way @command{centos-art.sh} script performs identity
+rendering. Identity rendering is organized by one @samp{BASE} action,
+and optional @samp{POST} and @samp{LAST} rendering actions.
+
+The @samp{BASE} action specifies what kind of rendering does the
+@command{centos-art.sh} script will perform with the files related to
+the pre-rendering configuration script. The @samp{BASE} action is
+required. Possible values to @samp{BASE} action are either
+@samp{renderImage} or @samp{renderText} only.
+
+To specify the @samp{BASE} action you need to set the @samp{BASE:}
+string followed by one of the possible values. For example, if you
+want to render images, consider the following definition of
+@samp{BASE} action:
+
+@verbatim
+ACTIONS[0]='BASE:renderImage'
+@end verbatim
+
+Only one @samp{BASE} action must be specified. If more than one
+@samp{BASE} action is specified, the last one is used. If no
+@samp{BASE} action is specified at all, an error is triggered and the
+@command{centos-art.sh} script ends its execution.
+
+The @samp{POST} action specifies which action to apply for
+each file rendered (at the rendering time). This action is optional.
+You can set many different @samp{POST} actions to apply many different
+actions over the same already rendered file. Possible values to
+@samp{POST} action are @samp{renderFormats}, @samp{renderSyslinux},
+@samp{renderGrub}, etc.
+
+To specify the @samp{POST} action, you need to use set the
+@samp{POST:} followed by the function name of the action you want to
+perform. The exact form depends on your needs. For example, consider
+the following example to produce @samp{xpm}, @samp{jpg}, and
+@samp{tif} images, based on already rendered @samp{png} image, and
+also organize the produced files in directories named as their own
+extensions:
+
+@verbatim
+ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
+@end verbatim
+
+In the previous example, file organization takes place at the moment
+of rendering, just after producing the @samp{png} base file and before
+going to the next file in the list of files to render. If you don't
+want to organized the produced files in directories named as their own
+extensions, just remove the @samp{POST:groupByFormat} action line:
+
+@verbatim
+ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+@end verbatim
+
+The @samp{LAST} action specifies which actions to apply once the last
+file in the list of files to process has been rendered. The
+@samp{LAST} action is optional. Possible values for @samp{LAST}
+actions may be @samp{groupByFormat}, @samp{renderGdmTgz}, etc.
+
+@quotation
+@strong{Note} --- @strong{Removed}(xref:trunk Scripts Bash Functions Render) ---, to know more
+about possible values for @samp{BASE}, @samp{POST} and @samp{LAST}
+action definitions.
+@end quotation
+
+To specify the @samp{LAST} action, you need to set the @samp{LAST:}
+string followed by the function name of the action you want to
+perform. For example, consider the following example if you want to
+render all files first and organize them later:
+
+@verbatim
+ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
+@end verbatim
+
+@subsection Usage
+
+Use the following commands to administer both identity and translation
+pre-rendering configuration scripts:
+
+@table @samp
+
+@item centos-art config --create='path/to/dir/'
+
+Use this command to create @samp{path/to/dir} related pre-rendering
+configuration script.
+
+@item centos-art config --edit='path/to/dir/'
+
+Use this command to edit @samp{path/to/dir} related pre-rendering
+configuration script.
+
+@item centos-art config --read='path/to/dir/'
+
+Use this command to read @samp{path/to/dir} related pre-rendering
+configuration script.
+
+@item centos-art config --remove='path/to/dir/'
+
+Use this command to remove @samp{path/to/dir} related pre-rendering
+configuration script.
+
+@end table
+
+In the commands above, @samp{path/to/dir} refers to one renderable
+directory path under @file{trunk/Identity} or
+@file{trunk/Translations} structures only.
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@comment --- Removed(* trunk Scripts Bash Functions Render::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi
new file mode 100644
index 0000000..a5016fe
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi
@@ -0,0 +1,184 @@
+@subsection Goals
+
+This section exists to organize files related to @code{shell}
+functionality of @file{centos-art.sh} script.
+
+@subsection Description
+
+The @code{shell} functionality of @file{centos-art.sh} script helps
+you to maintain bash scripts inside repository. For example, suppose
+you've created many functionalities for @file{centos-art.sh} script,
+and you want to use a common copyright and license note for
+consistency in all your script files. If you have a bunch of files,
+doing this one by one wouldn't be a big deal. In contrast, if the
+amount of files grows, updating the copyright and license note for all
+of them would be a task rather tedious. The @code{shell} functionality
+exists to solve maintainance tasks just as the one previously
+mentioned.
+
+When you use @code{shell} functionality to update copyright inside
+script files, it is required that your script files contain (at least)
+the following top commentary structure:
+
+@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:1
+@verbatim
+ 1| #!/bin/bash
+ 2| #
+ 3| # doSomething.sh -- The function description goes here.
+ 4| #
+ 5| # Copyright
+ 6| #
+ 7| # ...
+ 8| #
+ 9| # ----------------------------------------------------------------------
+10| # $Id$
+11| # ----------------------------------------------------------------------
+12|
+13| function doSomething {
+14|
+15| }
+@end verbatim
+@caption{The functions script base comment structure}
+@end float
+
+Relevant lines in the above structure are lines from 5 to 9.
+Everything else in the file is left immutable.
+
+When you are updating copyright through @code{shell}
+functionality, the @file{centos-art.sh} script replaces everything
+in-between line 5 ---the first one matching @samp{^# Copyright .+$}
+string--- and line 9---the first long dash separator matching @samp{^#
+-+$}--- with the content of copyright template instance.
+
+@quotation
+@strong{Caution} Be sure to add the long dash separator that matches
+@samp{^# -+$} regular expression @emph{before} the function
+definition. Otherwise, if the @samp{Copyright} line is present but no
+long dash separator exists, @file{centos-art.sh} will remove anything
+in-between the @samp{Copyright} line and the end of file. This way you
+may lost your function definitions entirely.
+@end quotation
+
+The copyright template instance is created from one copyright template
+stored in the @file{Config/tpl_forCopyright.sed} file. The template
+instance is created once, and later removed when no longer needed. At
+this moment, when template instance is created, the
+@file{centos-art.sh} script takes advantage of automation in order to
+set copyright full name and date dynamically.
+
+When you use @code{shell} functionality to update copyright, the first
+thing @file{shell} functionality does is requesting copyright
+information to user, and later, if values were left empty (i.e., no
+value was typed before pressing @key{RET} key), the @file{shell}
+functionality uses its own default values.
+
+When @code{shell} functionality uses its own default values, the final
+copyright note looks like the following:
+
+@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:2
+@verbatim
+ 1| #!/bin/bash
+ 2| #
+ 3| # doSomthing.sh -- The function description goes here.
+ 4| #
+ 5| # Copyright (C) 2003, 2010 The CentOS Project
+ 6| #
+ 7| # This program is free software; you can redistribute it and/or modify
+ 8| # it under the terms of the GNU General Public License as published by
+ 9| # the Free Software Foundation; either version 2 of the License, or
+10| # (at your option) any later version.
+11| #
+12| # This program is distributed in the hope that it will be useful, but
+13| # WITHOUT ANY WARRANTY; without even the implied warranty of
+14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+15| # General Public License for more details.
+16| #
+17| # You should have received a copy of the GNU General Public License
+18| # along with this program; if not, write to the Free Software
+19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+20| # USA.
+21| #
+22| # ----------------------------------------------------------------------
+23| # $Id$
+24| # ----------------------------------------------------------------------
+25|
+26| function doSomething {
+27|
+28| }
+@end verbatim
+@caption{The function script comment example}
+@end float
+
+Relevant lines in the above structure are lines from 5 to 22. Pay
+attention how the copyright line was built, and how the license was
+added into the top comment where previously was just three dots.
+Everything else in the file was left immutable.
+
+To change copyright information (i.e., full name or year information),
+run the @code{shell} functionality over the root directory containing
+the script files you want to update copyright in and enter the
+appropriate information when it be requested. You can run the
+@code{shell} functionality as many times as you need to.
+
+To change copyright license (i.e., the text in-between lines 7 and
+20), you need to edit the @file{Config/tpl_forCopyright.sed} file, set
+the appropriate information, and run the @code{shell} functionality
+once again for changes to take effect over the files you specify.
+
+@quotation
+@strong{Important} The @file{centos-art.sh} script is released as:
+
+@verbatim
+GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991
+
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+@end verbatim
+
+Do not change the license information under which @file{centos-art.sh}
+script is released. Instead, if you think a different license must be
+used, please share your reasons at @email{centos-devel@@centos-art.sh,
+CentOS Developers mailing list}.
+@end quotation
+
+@subsection Usage
+
+@table @command
+@item centos-art sh --update-copyright='path/to/dir'
+@itemx centos-art sh --update-copyright='path/to/dir' --filter='regex'
+Use these commands to update copyright information in @samp{.sh} files
+under @samp{path/to/dir} directory.
+@end table
+
+When you provide @option{--filter='regex'} argument, the list of files
+to process is reduced as specified in @samp{regex} regular expression.
+Inside @file{centos-art.sh} script, the @samp{regex} regular
+expression is used in combination with @command{find} command to look
+for files matching the regular expression path pattern.
+
+@quotation
+@strong{Warning} In order for @samp{regex} regular expression to match
+a file, the @samp{regex} regular expresion must match the whole file
+path not just the file name.
+@end quotation
+
+For example, if you want to match all @file{render.conf.sh} files
+inside @file{path/to/dir}, use the @code{.+/render.conf} regular
+expression. Later, @file{centos-art.sh} script uses this value inside
+@code{^$REGEX\.sh$} expression in order to build the final regular
+expression (i.e., @code{^.+/render.conf\.sh$}) that is evaluated
+against available file paths inside the list of files to process.
+
+Exceptionally, when you provide @option{--filter='regex'} in the way
+that @samp{regex}, appended to @samp{path/to/dir/} (i.e.
+@samp{path/to/dir/regex}), matches a regular file; the
+@file{centos-art.sh} script uses the file matching as only file in the
+list of files to process.
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi
new file mode 100644
index 0000000..341745d
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi
@@ -0,0 +1,192 @@
+@subsection Goals
+
+This section exists to organize files related to @code{svg}
+functionality of @file{centos-art.sh} script.
+
+@subsection Description
+
+The @code{svg} functionality of @file{centos-art.sh} script helps you
+to maintain scalable vector graphics (SVG) inside repository. For
+example, suppose you've been working in CentOS default design models
+under @file{trunk/Identity/Themes/Models/}, and you want to set common
+metadata to all of them, and later remove all unused SVG defintions
+from @samp{*.svg} files. Doing so file by file may be a tedious task,
+so the @file{centos-art.sh} script provides the @code{svg}
+functionality to aid you maintain such actions.
+
+@cindex Metadata maintainance
+@subsubsection Metadata maintainance
+
+The metadata used is defined by Inkscape 0.46 using the SVG standard
+markup. The @file{centos-art.sh} script replaces everything
+in-between @code{<metadata} and @code{</metadata>} tags with a
+predefined metadata template we've set for this purpose.
+
+The metadata template was created using the metadata information of a
+file which, using Inkscape 0.46, all metadata fields were set. This
+created a complete markup representation of how SVG metadata would
+look like. Later, we replaced every single static value with a
+translation marker in the form @samp{=SOMETEXT=}, where
+@code{SOMETEXT} is the name of its main opening tag. Later, we
+transform the metadata template into a sed replacement set of commads
+escaping new lines at the end of each line.
+
+With metadata template in place, the @file{centos-art.sh} script uses
+it to create a metadata template instance for the file being processed
+currently. The metadata template instance contains the metadata
+portion of sed replacement commands with translation markers already
+traduced. In this action, instance creation, is where we take
+advantage of automation and generate metadata values like title, date,
+keywords, source, identifier, and relation dynamically, based on the
+file path @file{centos-art.sh} script is currently creating metadata
+information for.
+
+With metadata template instance in place, the @file{centos-art.sh}
+script uses it to replace real values inside all @samp{.svg} files
+under the current location you're running the @file{centos-art.sh}
+script on. Default behaviour is to ask user to enter each metadatum
+required, one by one. If user leaves metadatum empty, by pressing
+@key{RET} key, @file{centos-art.sh} uses its default value.
+
+The @file{centos-art.sh} script modifies the following metadata:
+
+@table @samp
+@item Title
+Name by which this document is formally known. If no value is set
+here, @file{centos-art.sh} script uses the file name as title.
+
+@item Date
+Date associated with the creation of this document (YYYY-MM-DD). If no
+value is set here, @file{centos-art.sh} script uses the current date
+information as in @command{date +%Y-%m-%d}.
+
+@item Creator
+Name of entity primarily responsible for making the content of this
+document. If no value is set here, @file{centos-art.sh} script uses
+the string @samp{The CentOS Project}.
+
+@item Rights
+Name of entity with rights to the intellectual Property of this
+document. If no value is set here, @file{centos-art.sh} script uses
+the string @samp{The CentOS Project}.
+
+@item Publisher
+Name of entity responsible for making this document available. If no
+value is set here, @file{centos-art.sh} script uses the string
+@samp{The CentOS Project}.
+
+@item Identifier
+Unique URI to reference this document. If no value is set here,
+@file{centos-art.sh} script uses the current file path to build the
+related url that points to current file location inside repository
+central server.
+
+@item Source
+Unique URI to reference the source of this document. If no value is
+set here, @file{centos-art.sh} script uses current file path to build
+the related url that points to current file location inside repository
+central server.
+
+@item Relation
+Unique URI to a related document. If no value is set here,
+@file{centos-art.sh} script uses current file path to build the
+related url that points to current file location inside repository
+central server.
+
+@item Language
+Two-letter language tag with optional subtags for the language of this
+document. (e.g. @samp{en-GB}). If no value is set here,
+@file{centos-art.sh} script uses the current locale information as in
+@code{cli_getCurrentLocale} function.
+
+@item Keywords
+The topic of this document as comma-separated key words, prhases, or
+classifications. If no value is set here, @file{centos-art.sh} script
+uses file path to build
+
+@item Coverage
+Extent or scope of this document. If no value is set here,
+@file{centos-art.sh} script uses the string @samp{The CentOS Project}.
+
+@item Description
+Description about the document. If no value is set here,
+@file{centos-art.sh} script uses uses empty value as default.
+
+@item Contributors
+People that contributes in the creation/maintainance of the document.
+If no value is set here, @file{centos-art.sh} script uses uses empty
+value as default.
+@end table
+
+The @samp{License} metadatum is not set as a choise, by now. It is
+fixed @url{http://creativecommons.org/licenses/by-sa/3.0/, Creative
+Common Attribution Share-Alike 3.0 License}. This is done in order to
+grant license consistency among all SVG files we manage inside CentOS
+Artwork Repository.
+
+@cindex Unused definitions
+@subsubsection Unused definitions
+
+Many of the no-longer-used gradients, patterns, and markers (more
+precisely, those which you edited manually) remain in the
+corresponding palettes and can be reused for new objects. However if
+you want to optimize your document, use the @samp{Vacuum Defs} command
+in @samp{File} menu. It will remove any gradients, patterns, or
+markers which are not used by anything in the document, making the
+file smaller.
+
+If you have one or two couple of files, removing unused definitions
+using the graphical interface may be enough to you. In contrast, if
+you have dozens or even houndreds of scalable vector graphics files to
+maintain it is not a fun task to use the graphical interface to remove
+unused definitions editing those files one by one.
+
+To remove unused definitions from several scalable vector graphics
+files, the @file{centos-art.sh} script uses Inkscape command-line
+interface, specifically with the @option{--vaccum-defs} option.
+
+@subsection Usage
+
+@table @command
+@item centos-art svg --update-metadata='path/to/dir'
+@item centos-art svg --update-metadata='path/to/dir' --filter='regex'
+Use these commands to update metadata information to @samp{.svg} files
+under @samp{path/to/dir} directory.
+
+@item centos-art svg --vacuum-defs='path/to/dir'
+@item centos-art svg --vacuum-defs='path/to/dir' --filter='regex'
+Use these commands to remove unused definitions inside @samp{.svg}
+files under @samp{path/to/dir} directory.
+@end table
+
+When you provide @option{--filter='regex'} argument, the list of files
+to process is reduced as specified in @samp{regex} regular expression.
+Inside @file{centos-art.sh} script, the @samp{regex} regular
+expression is used in combination with @command{find} command to look
+for files matching the regular expression path pattern.
+
+@quotation
+@strong{Warning} In order for @samp{regex} regular expression to match
+a file, the @samp{regex} regular expresion must match the whole file
+path not just the file name.
+@end quotation
+
+For example, if you want to match all @file{summary.svg} files inside
+@file{path/to/dir}, use the @code{.+/summary} regular expression.
+Later, @file{centos-art.sh} script uses this value inside
+@code{^$REGEX\.svg$} expression in order to build the final regular
+expression (i.e., @code{^.+/summary\.svg$}) that is evaluated against
+available file paths inside the list of files to process.
+
+Exceptionally, when you provide @option{--filter='regex'} in the way
+that @samp{regex}, appended to @samp{path/to/dir/} (i.e.
+@samp{path/to/dir/regex}), matches a regular file; the
+@file{centos-art.sh} script uses the file matching as only file in the
+list of files to process.
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi
new file mode 100644
index 0000000..ff98b51
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi
@@ -0,0 +1,245 @@
+@subsection Goals
+
+This section exists to organize files related to @file{centos-art.sh}
+script @samp{verify} functionality. The @samp{verify}
+functionality of @file{centos-art.sh} script helps you to verify the
+workstation configuration you are planning to use as host for your
+working copy of CentOS Artwork Repository.
+
+@subsection Description
+
+The first time you download CentOS Artwork Repository you need to
+configure your workstation in order to use @file{centos-art.sh}
+script. These preliminar configurations are based mainly on auxiliar
+RPM packages installation, symbolic links creations, and environment
+variables definitions. The @samp{verify} functionality of
+@file{centos-art.sh} script guides you through this preliminar
+configuration process.
+
+If this is the first time you run @file{centos-art.sh} script, the
+appropriate way to use its @samp{verify} functionality is not using
+the @file{centos-art.sh} script directly, but the absolute path to
+@command{centos-art.sh} script instead (i.e.,
+@file{~/artwork/trunk/Scripts/Bash/centos-art.sh}). This is necessary
+because @file{centos-art} symbolic link, under @file{~/bin/}
+directory, has not been created yet.
+
+@subsubsection Packages
+
+Installation of auxiliar RPM packages provides the software required
+to manipulate files inside the repository (e.g., image files,
+documentation files, translation files, script files, etc.). Most of
+RPM packages @command{centos-art.sh} script uses are shipped with
+CentOS distribution, and can be installed from CentOS base repository.
+The only exception is @samp{inkscape}, the package we use to
+manipulate SVG files. The @samp{inkscape} package is not inside
+CentOS distribution so it needs to be installed from third party
+repositories.
+
+@quotation
+@strong{Note} Configuration of third party repositories inside CentOS
+distribution is described in CentOS wiki, specifically in the
+following URL:
+@url{http://wiki.centos.org/AdditionalResources/Repositories}
+@end quotation
+
+Before installing packages, the @file{centos-art.sh} script uses
+@command{sudo} to request root privileges to execute @command{yum}
+installation functionality. If your user isn't defined as a
+privileged user---at least to run @command{yum} commands--- inside
+@file{/etc/sudoers} configuration file, you will not be able to
+perform package installation tasks as set in @file{centos-art.sh}
+script @samp{verify} functionality.
+
+Setting sudo privileges to users is an administrative task you have to
+do by yourself. If you don't have experience with @command{sudo}
+command, please read its man page running the command: @command{man
+sudo}. This reading will be very useful, and with some practice, you
+will be able to configure your users to have @command{sudo}
+privileges.
+
+@subsubsection Links
+
+Creation of symbolic links helps us to alternate between different
+implementations of @file{centos-art.sh} script-line (e.g.,
+@file{centos-art.sh}, for Bash implementation; @file{centos-art.py},
+for Python implementation; @file{centos-art.pl}, for Perl
+implementation; and so on for other implementations). The
+@file{centos-art.sh} script-line definition takes place inside your
+personal binary (@file{~/bin/}) directory in order to make the script
+implementation ---the one that @file{centos-art} links to--- available
+to @var{PATH} environment variable.
+
+Creation of symbolic links helps us to reuse components from repository
+working copy. For example, color information files maintained inside
+your working copy must never be duplicated inside program-specific
+configuration directories that uses them in your workstation (e.g.,
+Gimp, Inkscape, etc.). Instead, a symbolic link must be created for
+each one of them, from program-specific configuration directories to
+files in the working copy. In this configuration, when someone
+commits changes to color information files up to central repository,
+they---the changes committed--- will be immediatly available to your
+programs the next time you update your working copy ---the place
+inside your workstation those color information files are stored---.
+
+Creation of symbolic links helps us to make @file{centos-art.sh}
+script functionalities available outside @file{trunk/} repository
+directory structure, but at its same level in repository tree. This is
+useful if you need to use the ``render'' functionality of
+@command{centos-art.sh} under @file{branches/} repository directory
+structure as you usually do inside @file{trunk/} repository directory
+structure. As consequence of this configuration, automation scripts
+cannot be branched under @file{branches/Scripts} directory structure.
+
+@subsubsection Environment variables
+
+Definition of environemnt variables helps us to set default values to
+our user session life. The user session environment variable defintion
+takes place in the user's @file{~/.bash_profile} file. The
+@samp{verify} functionality of @file{centos-art.sh} script doesn't
+modify your @file{~/.bash_profile} file.
+
+The @samp{verify} functionality of @file{centos-art.sh} script
+evaluates the following environment variables:
+
+@table @env
+@item EDITOR
+Default text editor.
+
+The @file{centos-art.sh} script uses default text @env{EDITOR} to edit
+pre-commit subversion messages, translation files, configuration
+files, script files, and similar text-based files.
+
+If @env{EDITOR} environment variable is not set, @file{centos-art.sh}
+script uses @file{/usr/bin/vim} as default text editor. Otherwise, the
+following values are recognized by @file{centos-art.sh} script:
+
+@itemize
+@item @file{/usr/bin/vim}
+@item @file{/usr/bin/emacs}
+@item @file{/usr/bin/nano}
+@end itemize
+
+If no one of these values is set in @env{EDITOR} environment variable,
+@file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default.
+
+@item TEXTDOMAIN
+
+Default domain used to retrieve translated messages. This variable is
+set in @file{initFunctions.sh} and shouldn't be changed.
+
+@item TEXTDOMAINDIR
+
+Default directory used to retrieve translated messages. This variable
+is set in @file{initFunctions.sh} and shouldn't be changed.
+
+@item LANG
+
+Default locale information.
+
+This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+@samp{Language} step; or once installed using the
+@command{system-config-language} tool.
+
+The @file{centos-art.sh} script uses the @var{LANG} environment
+variable to know in which language the script messages are printed
+out.
+
+@item TZ
+
+Default time zone representation.
+
+This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+@samp{Date and time} step; or once installed using the
+@command{system-config-date} tool.
+
+The @file{centos-art.sh} script doesn't use the @var{TZ} environment
+variable information at all. Instead, this variable is used by the
+system shell to show the time information according to your phisical
+location on planet Earth.
+
+Inside your computer, the time information is firstly set in the BIOS
+clock (which may need correction), and later in the configuration
+process of CentOS distribution installer (or later, by any of the
+related configuration tools inside CentOS distribution). Generally,
+setting time information is a straight-forward task and configuration
+tools available do cover most relevant location. However, if you need
+a time precision not provided by the configuration tools available
+inside CentOS distribution then, using @var{TZ} variable may be
+necessary.
+
+@quotation
+@strong{Convenction} In order to keep changes syncronized between
+central repository and its working copies: configure both repository
+server and workstations (i.e., the place where each working copy is
+set on) to use Coordinated Universal Time (UTC) as base time
+representation. Later, correct the time information for your specific
+location using time zone correction.
+@end quotation
+
+The format of @var{TZ} environment variable is described in
+@file{tzset(3)} manual page.
+
+@end table
+
+@subsection Usage
+
+@table @command
+
+@item centos-art verify --packages
+
+Verify required packages your workstation needs in order to run the
+@file{centos-art.sh} script correctly. If there are missing packages,
+the @file{centos-art.sh} script asks you to confirm their
+installation. When installing packages, the @file{centos-art.sh}
+script uses the @command{yum} application in order to achieve the
+task.
+
+In case all packages required by @file{centos-art.sh} script are
+already installed in your workstation, the message @samp{The required
+packages are already installed.} is output for you to know.
+
+@item centos-art verify --links
+
+Verify required links your workstation needs in order to run the
+centos-art command correctly. If any required link is missing, the
+@command{centos-art.sh} script asks you to confirm their installation.
+To install required links, the @command{centos-art.sh} script uses the
+@command{ln} command.
+
+In case all links required by @file{centos-art.sh} script are already
+created in your workstation, the message @samp{The required links are
+already installed.} is output for you to know.
+
+In case a regular file exists with the same name of a required link,
+the @file{centos-art.sh} script outputs the @samp{Already exists as
+regular file.} message when listing required links that will be
+installed. Of course, as there is already a regular file where must be
+a link, no link is created. In such cases the @file{centos-art.sh}
+script will fall into a continue installation request for that missing
+link. To end this continue request you can answer @samp{No}, or
+remove the existent regular file to let @file{centos-art.sh} script
+install the link on its place.
+
+@item centos-art verify --environment
+@itemx centos-art verify --environment --filter='regex'
+
+Output a brief description of environment variables used by
+@file{centos-art.sh} script.
+
+If @samp{--filter} option is provided, output is reduced as defined in
+the @samp{regex} regular expression value. If @samp{--filter} option
+is specified but @samp{regex} value is not, the @file{centos-art.sh}
+script outputs information as if @samp{--filter} option had not been
+provided at all.
+
+@end table
+
+@subsection See also
+
+@menu
+* trunk Scripts Bash::
+@comment --- Removed(* trunk Scripts Bash Functions::) ---
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi
@@ -0,0 +1,22 @@
+@subsection Goals
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Description
+
+@itemize
+@item ...
+@end itemize
+
+@subsection Usage
+
+@itemize
+@item ...
+@end itemize
+
+@subsection See also
+
+@menu
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/chapter-intro.texi b/Manuals/Repository/Filesystem/trunk/chapter-intro.texi
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/chapter-intro.texi
diff --git a/Manuals/Repository/Filesystem/trunk/chapter-menu.texi b/Manuals/Repository/Filesystem/trunk/chapter-menu.texi
new file mode 100644
index 0000000..1dace8c
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/chapter-menu.texi
@@ -0,0 +1,62 @@
+@menu
+* trunk Identity::
+* trunk Identity Brands::
+* trunk Identity Fonts::
+* trunk Identity Icons::
+* trunk Identity Isolinux::
+* trunk Identity Models::
+* trunk Identity Models Css::
+* trunk Identity Models Html::
+* trunk Identity Models Img Promo Web::
+* trunk Identity Models Tpl::
+* trunk Identity Models Tpl Promo Web::
+* trunk Identity Models Xcf::
+* trunk Identity Release::
+* trunk Identity Themes::
+* trunk Identity Themes Models::
+* trunk Identity Themes Models Alternative::
+* trunk Identity Themes Models Default::
+* trunk Identity Themes Models Default Distro::
+* trunk Identity Themes Models Default Distro Anaconda::
+* trunk Identity Themes Models Default Promo::
+* trunk Identity Themes Models Default Web::
+* trunk Identity Themes Motifs::
+* trunk Identity Themes Motifs Flame::
+* trunk Identity Themes Motifs Modern::
+* trunk Identity Themes Motifs Modern Backgrounds::
+* trunk Identity Themes Motifs Modern Backgrounds Img::
+* trunk Identity Themes Motifs Modern Backgrounds Tpl::
+* trunk Identity Themes Motifs Modern Backgrounds Xcf::
+* trunk Identity Themes Motifs Modern Distro Anaconda Progress::
+* trunk Identity Themes Motifs Modern Palettes::
+* trunk Identity Themes Motifs TreeFlower::
+* trunk Identity Themes Motifs TreeFlower Backgrounds::
+* trunk Identity Widgets::
+* trunk Locales::
+* trunk Locales Identity::
+* trunk Locales Identity Brands::
+* trunk Locales Identity Brands Tpl::
+* trunk Locales Identity Fonts::
+* trunk Locales Identity Models::
+* trunk Locales Identity Release::
+* trunk Locales Identity Themes::
+* trunk Locales Identity Themes Backgrounds::
+* trunk Locales Identity Themes Distro Anaconda Progress::
+* trunk Locales Identity Widgets::
+* trunk Manuals::
+* trunk Scripts::
+* trunk Scripts Bash::
+* trunk Scripts Bash Cli::
+* trunk Scripts Bash Cli Functions::
+* trunk Scripts Bash Cli Functions Help::
+* trunk Scripts Bash Cli Functions Html::
+* trunk Scripts Bash Cli Functions Locale::
+* trunk Scripts Bash Cli Functions Manual::
+* trunk Scripts Bash Cli Functions Path::
+* trunk Scripts Bash Cli Functions Render::
+* trunk Scripts Bash Cli Functions Render Config::
+* trunk Scripts Bash Cli Functions Shell::
+* trunk Scripts Bash Cli Functions Svg::
+* trunk Scripts Bash Cli Functions Verify::
+* trunk Scripts Python::
+@end menu
diff --git a/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi b/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi
new file mode 100644
index 0000000..2ab21f1
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi
@@ -0,0 +1,300 @@
+@node trunk Identity
+@section trunk/Identity
+@cindex trunk Identity
+@include trunk/Identity.texi
+
+@node trunk Identity Brands
+@section trunk/Identity/Brands
+@cindex trunk Identity Brands
+@include trunk/Identity/Brands.texi
+
+@node trunk Identity Fonts
+@section trunk/Identity/Fonts
+@cindex trunk Identity Fonts
+@include trunk/Identity/Fonts.texi
+
+@node trunk Identity Icons
+@section trunk/Identity/Icons
+@cindex trunk Identity Icons
+@include trunk/Identity/Icons.texi
+
+@node trunk Identity Isolinux
+@section trunk/Identity/Isolinux
+@cindex trunk Identity Isolinux
+@include trunk/Identity/Isolinux.texi
+
+@node trunk Identity Models
+@section trunk/Identity/Models
+@cindex trunk Identity Models
+@include trunk/Identity/Models.texi
+
+@node trunk Identity Models Css
+@section trunk/Identity/Models/Css
+@cindex trunk Identity Models Css
+@include trunk/Identity/Models/Css.texi
+
+@node trunk Identity Models Html
+@section trunk/Identity/Models/Html
+@cindex trunk Identity Models Html
+@include trunk/Identity/Models/Html.texi
+
+@node trunk Identity Models Img Promo Web
+@section trunk/Identity/Models/Img/Promo/Web
+@cindex trunk Identity Models Img Promo Web
+@include trunk/Identity/Models/Img/Promo/Web.texi
+
+@node trunk Identity Models Tpl
+@section trunk/Identity/Models/Tpl
+@cindex trunk Identity Models Tpl
+@include trunk/Identity/Models/Tpl.texi
+
+@node trunk Identity Models Tpl Promo Web
+@section trunk/Identity/Models/Tpl/Promo/Web
+@cindex trunk Identity Models Tpl Promo Web
+@include trunk/Identity/Models/Tpl/Promo/Web.texi
+
+@node trunk Identity Models Xcf
+@section trunk/Identity/Models/Xcf
+@cindex trunk Identity Models Xcf
+@include trunk/Identity/Models/Xcf.texi
+
+@node trunk Identity Release
+@section trunk/Identity/Release
+@cindex trunk Identity Release
+@include trunk/Identity/Release.texi
+
+@node trunk Identity Themes
+@section trunk/Identity/Themes
+@cindex trunk Identity Themes
+@include trunk/Identity/Themes.texi
+
+@node trunk Identity Themes Models
+@section trunk/Identity/Themes/Models
+@cindex trunk Identity Themes Models
+@include trunk/Identity/Themes/Models.texi
+
+@node trunk Identity Themes Models Alternative
+@section trunk/Identity/Themes/Models/Alternative
+@cindex trunk Identity Themes Models Alternative
+@include trunk/Identity/Themes/Models/Alternative.texi
+
+@node trunk Identity Themes Models Default
+@section trunk/Identity/Themes/Models/Default
+@cindex trunk Identity Themes Models Default
+@include trunk/Identity/Themes/Models/Default.texi
+
+@node trunk Identity Themes Models Default Distro
+@section trunk/Identity/Themes/Models/Default/Distro
+@cindex trunk Identity Themes Models Default Distro
+@include trunk/Identity/Themes/Models/Default/Distro.texi
+
+@node trunk Identity Themes Models Default Distro Anaconda
+@section trunk/Identity/Themes/Models/Default/Distro/Anaconda
+@cindex trunk Identity Themes Models Default Distro Anaconda
+@include trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
+
+@node trunk Identity Themes Models Default Promo
+@section trunk/Identity/Themes/Models/Default/Promo
+@cindex trunk Identity Themes Models Default Promo
+@include trunk/Identity/Themes/Models/Default/Promo.texi
+
+@node trunk Identity Themes Models Default Web
+@section trunk/Identity/Themes/Models/Default/Web
+@cindex trunk Identity Themes Models Default Web
+@include trunk/Identity/Themes/Models/Default/Web.texi
+
+@node trunk Identity Themes Motifs
+@section trunk/Identity/Themes/Motifs
+@cindex trunk Identity Themes Motifs
+@include trunk/Identity/Themes/Motifs.texi
+
+@node trunk Identity Themes Motifs Flame
+@section trunk/Identity/Themes/Motifs/Flame
+@cindex trunk Identity Themes Motifs Flame
+@include trunk/Identity/Themes/Motifs/Flame.texi
+
+@node trunk Identity Themes Motifs Modern
+@section trunk/Identity/Themes/Motifs/Modern
+@cindex trunk Identity Themes Motifs Modern
+@include trunk/Identity/Themes/Motifs/Modern.texi
+
+@node trunk Identity Themes Motifs Modern Backgrounds
+@section trunk/Identity/Themes/Motifs/Modern/Backgrounds
+@cindex trunk Identity Themes Motifs Modern Backgrounds
+@include trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
+
+@node trunk Identity Themes Motifs Modern Backgrounds Img
+@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
+@cindex trunk Identity Themes Motifs Modern Backgrounds Img
+@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
+
+@node trunk Identity Themes Motifs Modern Backgrounds Tpl
+@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
+@cindex trunk Identity Themes Motifs Modern Backgrounds Tpl
+@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
+
+@node trunk Identity Themes Motifs Modern Backgrounds Xcf
+@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf
+@cindex trunk Identity Themes Motifs Modern Backgrounds Xcf
+@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
+
+@node trunk Identity Themes Motifs Modern Distro Anaconda Progress
+@section trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
+@cindex trunk Identity Themes Motifs Modern Distro Anaconda Progress
+@include trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
+
+@node trunk Identity Themes Motifs Modern Palettes
+@section trunk/Identity/Themes/Motifs/Modern/Palettes
+@cindex trunk Identity Themes Motifs Modern Palettes
+@include trunk/Identity/Themes/Motifs/Modern/Palettes.texi
+
+@node trunk Identity Themes Motifs TreeFlower
+@section trunk/Identity/Themes/Motifs/TreeFlower
+@cindex trunk Identity Themes Motifs TreeFlower
+@include trunk/Identity/Themes/Motifs/TreeFlower.texi
+
+@node trunk Identity Themes Motifs TreeFlower Backgrounds
+@section trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
+@cindex trunk Identity Themes Motifs TreeFlower Backgrounds
+@include trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
+
+@node trunk Identity Widgets
+@section trunk/Identity/Widgets
+@cindex trunk Identity Widgets
+@include trunk/Identity/Widgets.texi
+
+@node trunk Locales
+@section trunk/Locales
+@cindex trunk Locales
+@include trunk/Locales.texi
+
+@node trunk Locales Identity
+@section trunk/Locales/Identity
+@cindex trunk Locales Identity
+@include trunk/Locales/Identity.texi
+
+@node trunk Locales Identity Brands
+@section trunk/Locales/Identity/Brands
+@cindex trunk Locales Identity Brands
+@include trunk/Locales/Identity/Brands.texi
+
+@node trunk Locales Identity Brands Tpl
+@section trunk/Locales/Identity/Brands/Tpl
+@cindex trunk Locales Identity Brands Tpl
+@include trunk/Locales/Identity/Brands/Tpl.texi
+
+@node trunk Locales Identity Fonts
+@section trunk/Locales/Identity/Fonts
+@cindex trunk Locales Identity Fonts
+@include trunk/Locales/Identity/Fonts.texi
+
+@node trunk Locales Identity Models
+@section trunk/Locales/Identity/Models
+@cindex trunk Locales Identity Models
+@include trunk/Locales/Identity/Models.texi
+
+@node trunk Locales Identity Release
+@section trunk/Locales/Identity/Release
+@cindex trunk Locales Identity Release
+@include trunk/Locales/Identity/Release.texi
+
+@node trunk Locales Identity Themes
+@section trunk/Locales/Identity/Themes
+@cindex trunk Locales Identity Themes
+@include trunk/Locales/Identity/Themes.texi
+
+@node trunk Locales Identity Themes Backgrounds
+@section trunk/Locales/Identity/Themes/Backgrounds
+@cindex trunk Locales Identity Themes Backgrounds
+@include trunk/Locales/Identity/Themes/Backgrounds.texi
+
+@node trunk Locales Identity Themes Distro Anaconda Progress
+@section trunk/Locales/Identity/Themes/Distro/Anaconda/Progress
+@cindex trunk Locales Identity Themes Distro Anaconda Progress
+@include trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
+
+@node trunk Locales Identity Widgets
+@section trunk/Locales/Identity/Widgets
+@cindex trunk Locales Identity Widgets
+@include trunk/Locales/Identity/Widgets.texi
+
+@node trunk Manuals
+@section trunk/Manuals
+@cindex trunk Manuals
+@include trunk/Manuals.texi
+
+@node trunk Scripts
+@section trunk/Scripts
+@cindex trunk Scripts
+@include trunk/Scripts.texi
+
+@node trunk Scripts Bash
+@section trunk/Scripts/Bash
+@cindex trunk Scripts Bash
+@include trunk/Scripts/Bash.texi
+
+@node trunk Scripts Bash Cli
+@section trunk/Scripts/Bash/Cli
+@cindex trunk Scripts Bash Cli
+@include trunk/Scripts/Bash/Cli.texi
+
+@node trunk Scripts Bash Cli Functions
+@section trunk/Scripts/Bash/Cli/Functions
+@cindex trunk Scripts Bash Cli Functions
+@include trunk/Scripts/Bash/Cli/Functions.texi
+
+@node trunk Scripts Bash Cli Functions Help
+@section trunk/Scripts/Bash/Cli/Functions/Help
+@cindex trunk Scripts Bash Cli Functions Help
+@include trunk/Scripts/Bash/Cli/Functions/Help.texi
+
+@node trunk Scripts Bash Cli Functions Html
+@section trunk/Scripts/Bash/Cli/Functions/Html
+@cindex trunk Scripts Bash Cli Functions Html
+@include trunk/Scripts/Bash/Cli/Functions/Html.texi
+
+@node trunk Scripts Bash Cli Functions Locale
+@section trunk/Scripts/Bash/Cli/Functions/Locale
+@cindex trunk Scripts Bash Cli Functions Locale
+@include trunk/Scripts/Bash/Cli/Functions/Locale.texi
+
+@node trunk Scripts Bash Cli Functions Manual
+@section trunk/Scripts/Bash/Cli/Functions/Manual
+@cindex trunk Scripts Bash Cli Functions Manual
+@include trunk/Scripts/Bash/Cli/Functions/Manual.texi
+
+@node trunk Scripts Bash Cli Functions Path
+@section trunk/Scripts/Bash/Cli/Functions/Path
+@cindex trunk Scripts Bash Cli Functions Path
+@include trunk/Scripts/Bash/Cli/Functions/Path.texi
+
+@node trunk Scripts Bash Cli Functions Render
+@section trunk/Scripts/Bash/Cli/Functions/Render
+@cindex trunk Scripts Bash Cli Functions Render
+@include trunk/Scripts/Bash/Cli/Functions/Render.texi
+
+@node trunk Scripts Bash Cli Functions Render Config
+@section trunk/Scripts/Bash/Cli/Functions/Render/Config
+@cindex trunk Scripts Bash Cli Functions Render Config
+@include trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
+
+@node trunk Scripts Bash Cli Functions Shell
+@section trunk/Scripts/Bash/Cli/Functions/Shell
+@cindex trunk Scripts Bash Cli Functions Shell
+@include trunk/Scripts/Bash/Cli/Functions/Shell.texi
+
+@node trunk Scripts Bash Cli Functions Svg
+@section trunk/Scripts/Bash/Cli/Functions/Svg
+@cindex trunk Scripts Bash Cli Functions Svg
+@include trunk/Scripts/Bash/Cli/Functions/Svg.texi
+
+@node trunk Scripts Bash Cli Functions Verify
+@section trunk/Scripts/Bash/Cli/Functions/Verify
+@cindex trunk Scripts Bash Cli Functions Verify
+@include trunk/Scripts/Bash/Cli/Functions/Verify.texi
+
+@node trunk Scripts Python
+@section trunk/Scripts/Python
+@cindex trunk Scripts Python
+@include trunk/Scripts/Python.texi
+
diff --git a/Manuals/Repository/Filesystem/trunk/chapter.texi b/Manuals/Repository/Filesystem/trunk/chapter.texi
new file mode 100644
index 0000000..73ba088
--- /dev/null
+++ b/Manuals/Repository/Filesystem/trunk/chapter.texi
@@ -0,0 +1,6 @@
+@node trunk
+@chapter trunk
+@cindex trunk
+@include trunk/chapter-intro.texi
+@include trunk/chapter-menu.texi
+@include trunk/chapter-nodes.texi
diff --git a/Manuals/Repository/branches/chapter-intro.texi b/Manuals/Repository/branches/chapter-intro.texi
deleted file mode 100644
index e69de29..0000000
--- a/Manuals/Repository/branches/chapter-intro.texi
+++ /dev/null
diff --git a/Manuals/Repository/branches/chapter-menu.texi b/Manuals/Repository/branches/chapter-menu.texi
deleted file mode 100644
index 8b13789..0000000
--- a/Manuals/Repository/branches/chapter-menu.texi
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/Manuals/Repository/branches/chapter-nodes.texi b/Manuals/Repository/branches/chapter-nodes.texi
deleted file mode 100644
index 8b13789..0000000
--- a/Manuals/Repository/branches/chapter-nodes.texi
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/Manuals/Repository/branches/chapter.texi b/Manuals/Repository/branches/chapter.texi
deleted file mode 100644
index e053279..0000000
--- a/Manuals/Repository/branches/chapter.texi
+++ /dev/null
@@ -1,6 +0,0 @@
-@node branches
-@chapter branches
-@cindex branches
-@include branches/chapter-intro.texi
-@include branches/chapter-menu.texi
-@include branches/chapter-nodes.texi
diff --git a/Manuals/Repository/tags/chapter-intro.texi b/Manuals/Repository/tags/chapter-intro.texi
deleted file mode 100644
index e69de29..0000000
--- a/Manuals/Repository/tags/chapter-intro.texi
+++ /dev/null
diff --git a/Manuals/Repository/tags/chapter-menu.texi b/Manuals/Repository/tags/chapter-menu.texi
deleted file mode 100644
index 8b13789..0000000
--- a/Manuals/Repository/tags/chapter-menu.texi
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/Manuals/Repository/tags/chapter-nodes.texi b/Manuals/Repository/tags/chapter-nodes.texi
deleted file mode 100644
index 8b13789..0000000
--- a/Manuals/Repository/tags/chapter-nodes.texi
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/Manuals/Repository/tags/chapter.texi b/Manuals/Repository/tags/chapter.texi
deleted file mode 100644
index 2b05ba0..0000000
--- a/Manuals/Repository/tags/chapter.texi
+++ /dev/null
@@ -1,6 +0,0 @@
-@node tags
-@chapter tags
-@cindex tags
-@include tags/chapter-intro.texi
-@include tags/chapter-menu.texi
-@include tags/chapter-nodes.texi
diff --git a/Manuals/Repository/trunk/Identity.texi b/Manuals/Repository/trunk/Identity.texi
deleted file mode 100644
index 65f22ca..0000000
--- a/Manuals/Repository/trunk/Identity.texi
+++ /dev/null
@@ -1,126 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Identity} directory exists to organize CentOS
-corporate identity artworks.
-
-@subsection Description
-
-The CentOS Project corporate identity is the ``persona'' of the
-organization known as The CentOS Project. The CentOS Project
-corporate identity plays a significant role in the way the CentOS
-Project, as organization, presents itself to both internal and
-external stakeholders. In general terms, the CentOS Project corporate
-visual identity expresses the values and ambitions of the CentOS
-Project organization, its business, and its characteristics.
-
-The CentOS Project corporate identity provides visibility,
-recognizability, reputation, structure and identification to the
-CentOS Project organization by means of corporate design, corporate
-communication, and corporate behaviour.
-
-The CentOS Project settles down its corporate visual identity on a
-``monolithic corporate visual identity structure''. In this structure
-The CentOS Project uses one unique name (The CentOS Brand) and one
-unique visual style (The CentOS Default Theme) in all its
-manifestations.
-
-@table @strong
-
-@item The CentOS Brands
-The CentOS brand is the name or trademark that conncects the producer
-with their products. In this case, the producer is The CentOS Project
-and the products are the CentOS distributions, the CentOS web sites,
-the CentOS promotion stuff, etc.
-
-@xref{trunk Identity Brands}, for more information.
-
-@item The CentOS Themes
-
-The CentOS themes are a set of image files connected all together by
-one unique visual style. Each theme is organized in different visual
-manifestations, in order to cover each visual manifestation of The
-CentOS Project (i.e., distributions, websites, promotion stuff, etc.).
-@xref{trunk Identity Themes}, for more information.
-@end table
-
-Inside a monolithic corporate visual identity structure, internal and
-external stakeholders use to feel a strong sensation of uniformity,
-orientation, and identification with the organization. No matter if
-you are visiting websites, using the distribution, or acting on social
-events, the one unique name and one unique visual style conect them
-all to say: Hey! we are all parts of the CentOS project. And,
-probably, some vister will say: Can I join the party? Yes you can, it
-is free. :)
-
-@subsection Usage
-
-To produce identity artworks, use the following commands:
-
-@table @samp
-@item centos-art render 'path/to/dir'
-
-When @samp{path/to/dir} refers to one renderable directory under
-@file{trunk/Identity}, this command renders identity artworks using
-both related design models and related translation files.
-
-@item centos-art render 'path/to/dir' --filter='pattern'
-
-When @samp{path/to/dir} refers to one renderable directory under
-@file{trunk/Identity}, this command renders identity artworks using
-both related design models and related translation files that match
-the regular expression passed in @samp{--filter='pattern'} argument.
-
-To control the number of files produced by @command{centos-art}
-command, you need to look into the translation path and provide a
-regular expression pattern that matches the translation path, or
-paths, related to the file, or files, you want to produce.
-
-The regular expression pattern you provide to @command{centos-art}
-command is applied to the translation path from its very beginning.
-It is not the same to say @samp{5/en/01-welcome} that
-@samp{01-welcome}, the frist expression matches but the last one does
-not.
-
-When using @samp{--filter='pattern'} you don't need to specify the
-file extension. It is removed from translation path before applying
-the pattern, so it doesn't count here.
-@end table
-
-@subsection File name convenctions
-
-As file name convenction, inside CentOS Artwork Repository, both
-text-based and image-based file name produced by @command{centos-art.sh}
-script has the same name of their translation files without
-the @samp{.sed} extension. The file extension is set as follow:
-
-@subsubsection When text-based files are rendered
-
-Text-based files end up having the same extension of their design
-template file.
-
-@subsubsection When image-based files are rendered
-
-Image-based files always end up having the @file{.png} extension.
-
-@quotation
-@strong{Tip} Once @file{.png} images are created, other image formats
-may be created using the @command{renderFormats} post-rendering
-action, inside the image-based related pre-rendering configuration
-script.
-
-@xref{trunk Scripts Bash}, for more information.
-@end quotation
-
-@subsection See also
-
-@menu
-@comment --- Removed(* trunk Translations::) ---
-@end menu
-
-@subsection References
-
-@itemize
-@item @url{http://en.wikipedia.org/Corporate_identity} (and related
-links).
-@end itemize
-
diff --git a/Manuals/Repository/trunk/Identity/Brands.texi b/Manuals/Repository/trunk/Identity/Brands.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Brands.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Fonts.texi b/Manuals/Repository/trunk/Identity/Fonts.texi
deleted file mode 100644
index ef6730a..0000000
--- a/Manuals/Repository/trunk/Identity/Fonts.texi
+++ /dev/null
@@ -1,79 +0,0 @@
-@subsection Goals
-
-This section exists to organize digital typographies used by the
-CentOS project.
-
-@subsection Description
-
-@subsection Usage
-
-The CentOS corporate identity is attached to @samp{DejaVu LGC}
-font-family. Whatever artwork you design for CentOS project, that
-requires typography usage, must be done using @samp{DejaVu LGC}
-font-family.
-
-@table @strong
-@item Recommendation-1:
-
-For screen desings (e.g., anything that final destination will never
-be printed on paper or any medium outside computer screens) use
-@samp{DejaVu LGC Sans} font-family.
-
-@item Recommendation-2:
-
-For non-screen designs (e.g., anything that final desition will be
-printed on paper or any other medium outside computer screens) use
-@samp{DejaVu LGC Serif} font-family. As convenction files described in
-this rule are stored under @samp{Stationery} directories.
-@end table
-
-The only execption for the two recommendations above is the typography
-used inside CentOS logo. The CentOS logo is the main visual
-representation of the CentOS project so the typography used in it must
-be the same always, no matter where it be shown. It also has to be
-clear enough to dismiss any confussion between similar typefaces
-(e.g., the number one (1) sometimes is confuesed with the letter
-@samp{el} (l) or letter @samp{ai} (i)).
-
-As CentOS logo typography convenction, the word @samp{CentOS} uses
-@samp{Denmark} typography as base, both for the word @samp{CentOS} and
-the phrase @samp{Community Enterprise Operating System}. The phrase
-size of CentOS logo is half the size in poits the word @samp{CentOS}
-has and it below @samp{CentOS} word and aligned with it on the left.
-The distance between @samp{CentOS} word and phrase @samp{Community
-Enterprise Operating System} have the size in points the phrase has.
-
-When the CentOS release brand is built, use @samp{Denmark} typography
-for the release number. The release number size is two times larger
-(in height) than default @samp{CentOS} word. The separation between
-release number and @samp{CentOS} word is twice the size in points of
-separation between @samp{CentOS} word and phrase @samp{Community
-Enterprise Operating System}.
-
-Another component inside CentOS logo is the trademark symbol (TM).
-This symbol specifies that the CentOS logo must be consider a product
-brand, even it is not a registered one. The trademark symbol uses
-DejaVu LGC Sans Regular typography. The trademark symbol is aligned
-right-top on the outter side of @samp{CentOS} word. The trademark
-symbol must not exceed haf the distance, in points, between
-@samp{CentOS} word and the release number on its right.
-
-It would be very convenient for the CentOS Project and its community
-to to make a registered trademark (®) of CentOS logo. To make a
-register trademark of CentOS Logo prevents legal complications in the
-market place of brands. It grants the consistency, through time, of
-CentOS project corporate visual identity.
-
-@quotation
-@strong{Note} The information about trademarks and corporate identity
-is my personal interpretation of
-@url{http://en.wikipedia.org/Corporate_identity} and
-@url{http://en.wikipedia.org/Trademark} description. If you have
-practical experiences with these affairs, please serve yourself to
-improve this section with your reasons.
-@end quotation
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Icons.texi b/Manuals/Repository/trunk/Identity/Icons.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Icons.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Isolinux.texi b/Manuals/Repository/trunk/Identity/Isolinux.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Isolinux.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models.texi b/Manuals/Repository/trunk/Identity/Models.texi
deleted file mode 100644
index 3973252..0000000
--- a/Manuals/Repository/trunk/Identity/Models.texi
+++ /dev/null
@@ -1,19 +0,0 @@
-@subsection Goals
-
-This section exists to organize design models.
-
-@subsection Description
-
-Design models are representative designs useful to understand how
-to build artworks.
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-* trunk Identity Models Html::
-* trunk Identity Models Css::
-* trunk Identity Models Tpl::
-* trunk Identity Models Xcf::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Css.texi b/Manuals/Repository/trunk/Identity/Models/Css.texi
deleted file mode 100644
index 5639459..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Css.texi
+++ /dev/null
@@ -1,21 +0,0 @@
-@subsection Goals
-
-This directory exists to provide common style sheets (CSS) definitions
-to HTML design models.
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Html.texi b/Manuals/Repository/trunk/Identity/Models/Html.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Html.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Img/Promo/Web.texi b/Manuals/Repository/trunk/Identity/Models/Img/Promo/Web.texi
deleted file mode 100644
index ec9b88b..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Img/Promo/Web.texi
+++ /dev/null
@@ -1,23 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Provide images related to CentOS web interface.
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-* trunk Identity Models Tpl Promo Web::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Tpl.texi b/Manuals/Repository/trunk/Identity/Models/Tpl.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Tpl.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Tpl/Promo/Web.texi b/Manuals/Repository/trunk/Identity/Models/Tpl/Promo/Web.texi
deleted file mode 100644
index 56b7f37..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Tpl/Promo/Web.texi
+++ /dev/null
@@ -1,329 +0,0 @@
-@subsection Goals
-
-Organize scalable vector graphics (svg) to help describe the CentOS
-web environment.
-
-@subsection The CentOS web environment
-
-Inside CentOS corporate identity, the CentOS web environment is
-considered a promotion component. The CentOS web environment is formed
-by a central web application ---to cover base needs (e.g., per-major
-release information like release notes, lifetime, downloads,
-documentation, support, security advisories, bugs, etc.)--- and many
-different free web applications ---to cover specific needs (e.g.,
-wiki, mailing lists, etc.)---.
-
-The CentOS web environment is addressed to solve the following issues:
-
-@itemize
-@item One unique name and one unique visual style to all web
-applications used inside the web environment.
-
-@item One-step navigation to web applications inside the environment.
-
-@item High degree of customization to change the visual style of all
-web applications with few changes (e.g, updating just two or three
-images plus common style sheet [CSS] definitions).
-@end itemize
-
-The CentOS project is attached to a monolithic corporate visual
-identity (@pxref{trunk Identity}), where all visual manifestations
-have one unique name and one unique visual style. This way, the CentOS
-web environment has one unique name (the CentOS brand) and one unique
-visual style (the CentOS default theme) for all its visual
-manifestations, the web applications in this case.
-
-Since a maintainance point of view, achiving the one unique visual
-style inside CentOS web environment is not a simple task. The CentOS
-web environment is built upon many different web applications which
-have different visual styles and different internal ways to customize
-their own visual styles. For example: MoinMoin, the web application
-used to support the CentOS wiki (@url{http://wiki.centos.org/}) is
-highly customizable but Mailman (in its 2.x.x serie), the web
-application used to support the CentOS mailing list, doesn't
-support@footnote{The theme support of Mailman may be introduced in
-mailman-3.x.x release.} a customization system that separates
-presentation from logic, similar to that used by MoinMoin.
-
-This visual style diversity complicates our goal of one unique visual
-style for all web applications. So, if we want one unique visual style
-for all web applications used, it is innevitable to modify the web
-applications in order to implement the CentOS one unique visual style
-customization in them. Direct modification of upstream applications is
-not convenient because upstream applications come with their one
-visual style and administrators take the risk of loosing all
-customization changes the next time the application be updated (since
-not all upstream web applications, used in CentOS web environment,
-separate presentation from logic).
-
-To solve the ``one unique visual style'' issue, installation and
-actualization of web applications ---used inside CentOS web
-environment--- need to be independent from upstream web applications
-development line; in a way that CentOS web environment administrators
-can install and update web applications freely without risk of loosing
-the one unique visual style customization changes.
-
-At the surface of this issue we can see the need of one specific yum
-repository to store CentOS web environment customized web applications.
-
-@subsubsection Design model (without ads)
-
-@subsubsection Design model (with ads)
-
-@subsubsection HTML definitions
-
-@subsubsection Controlling visual style
-
-Inside CentOS web environment, the visual style is controlled by the
-following compenents:
-
-@table @strong
-@item Webenv header background
-@verbatim
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
-@end verbatim
-
-@item CSS definitions
-@verbatim
-trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css
-@end verbatim
-@end table
-
-@subsubsection Producing visual style
-
-The visual style of CentOS web environment is defined in the following
-files:
-
-@verbatim
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg
-@end verbatim
-
-As graphic designer you use @file{1024x250.xcf} file to produce
-@file{1024x250-bg.png} file. Later, inside @file{1024x250.svg} file,
-you use the @file{1024x250-bg.png} file as background layer to draw
-your vectorial design. When you consider you artwork ready, use the
-@command{centos-art.sh} script, as described below, to produce the
-visual style controller images of CentOS web environment.
-
-@verbatim
-centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250'
-@end verbatim
-
-Once you have rendered required image files, changing the visual style
-of CentOS web environment is a matter of replacing old image files
-with new ones, inside webenv repository file system structure. The
-visual style changes will take effect the next time customization line
-of CentOS web applications be packaged, uploded, and installed from
-[webenv] or [webenv-test] repositories.
-
-@subsubsection Navigation
-
-Inside CentOS web environment, the one-step navegation between web
-applications is addressed using the web environment navigation bar.
-The web environment navigation bar contains links to main applications
-and is always visible no matter where you are inside the web
-environment.
-
-@subsubsection Development and release cycle
-
-The CentOS web environment development and relase cycle is described
-below:
-
-@table @strong
-
-@item Download
-
-The first action is download the source code of web applications we
-want to use inside CentOS web environment.
-
-@quotation
-@strong{Important} The source location from which web application are
-downloaded is very important. Use SRPMs from CentOS @strong{[base]}
-and @strong{[updates]} repositories as first choise, and third party
-repositories (e.g. RPMForge, EPEL, etc.) as last resource.
-@end quotation
-
-@item Prepare
-
-Once web application source code has been downloaded, our duty is
-organize its files inside @samp{webenv} version controlled repository.
-
-When preparing the structure keep in mind that different web
-applications have different visual styles, and also different ways to
-implement it. A convenient way to organize the file system structure
-would be create one development line for each web application we use
-inside CentOS web environment. For example, consider the following
-file system structure:
-
-@verbatim
-https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-| |-- Sources/
-| | `-- webapp1-0.0.1/
-| |-- Rpms/
-| | `-- webapp1-0.0.1.rpm
-| |-- Srpms/
-| | `-- webapp1-0.0.1.srpm
-| `-- Specs/
-| `-- webapp1-0.0.1.spec
-|-- WebApp2/
-`-- WebAppN/
-@end verbatim
-
-@item Customize
-
-Once web applications have been organized inside the version
-controlled repository file system, use subversion to create the CentOS
-customization development line of web applications source code. For
-example, using the above file system structure, you can create the
-customization development line of @file{webapp1-0.0.1/} with the
-following command:
-
-@verbatim
-svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv
-@end verbatim
-
-The command above creates the following structure:
-
-@verbatim
-https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-| |-- Sources/
-| | |-- webapp1-0.0.1/
-| | `-- webapp1-0.0.1-webenv/
-| |-- Rpms/
-| | `-- webapp1-0.0.1.rpm
-| |-- Srpms/
-| | `-- webapp1-0.0.1.srpm
-| `-- Specs/
-| `-- webapp1-0.0.1.spec
-|-- WebApp2/
-`-- WebAppN/
-@end verbatim
-
-In the above structure, the @file{webapp1-0.0.1-webenv/} directory is
-the place where you customize the visual style of
-@file{webapp1-0.0.1/} web application.
-
-@quotation
-@strong{Tip} Use the @command{diff} command of Subversion between
-CentOS customization and upstream development lines to know what you
-are changing exactly.
-@end quotation
-
-@item Build packages
-
-When web application has been customized, build the web application
-RPM and SRPM using the source location with @samp{-webenv} prefix.
-
-@verbatim
-https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-| |-- Sources/
-| | |-- webapp1-0.0.1/
-| | `-- webapp1-0.0.1-webenv/
-| |-- Rpms/
-| | |-- webapp1-0.0.1.rpm
-| | `-- webapp1-0.0.1-webenv.rpm
-| |-- Srpms/
-| | |-- webapp1-0.0.1.srpm
-| | `-- webapp1-0.0.1-webenv.srpm
-| `-- Specs/
-| |-- webapp1-0.0.1.spec
-| `-- webapp1-0.0.1-webenv.spec
-|-- WebApp2/
-`-- WebAppN/
-@end verbatim
-
-@item Release for testing
-
-When the customized web application has been packaged, make packages
-available for testing and quality assurance. This can be achives using
-a [webenv-test] yum repository.
-
-@quotation
-@strong{Note} The [webenv-test] repository is not shipped inside
-CentOS distribution default yum configuraiton. In order to use
-[webenv-test] repository you need to configure it first.
-@end quotation
-
-If some problem is found to install/update/use the customized version
-of web application, the problem is notified somewhere (a bugtracker
-maybe) and the customization face is repated in order to fix the
-problem. To release the new package add a number after @samp{-webenv}
-prefix. For example, if some problem is found in
-@file{webapp1-0.0.1-webenv.rpm}, when it be fixed the new package will
-be named @file{webapp1-0.0.1-webenv-1.rpm}. If a problem is found in
-@file{webapp1-0.0.1-webenv-1.rpm}, when it be fixed the new package
-will be named @file{webapp1-0.0.1-webenv-2.rpm}, and so on.
-
-The ``customization --- release for testing'' process is repeated
-until CentOS quality assurance team considers the package is ready for
-production.
-
-@item Release for production
-
-When customized web application packages are considered ready for
-production they are moved from [webenv-test] to [webenv] repository.
-This action is commited by CentOS quality assurance team.
-
-@quotation
-@strong{Note} The [webenv] repository is not shipped inside CentOS
-distribution default yum configuraiton. In order to use [webenv]
-repository you need to configure it first.
-@end quotation
-@end table
-
-@subsubsection The [webenv-test] repository
-
-@verbatim
-/etc/yum.repos.d/CentOS-Webenv-test.repo
-@end verbatim
-
-@verbatim
-[webenv-test]
-name=CentOS-$releasever - Webenv-test
-mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test
-#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/
-gpgcheck=1
-gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
-enabled=1
-priority=10
-@end verbatim
-
-@subsubsection The [webenv] repository
-
-@verbatim
-/etc/yum.repos.d/CentOS-Webenv.repo
-@end verbatim
-
-@verbatim
-[webenv]
-name=CentOS-$releasever - Webenv
-mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv
-#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/
-gpgcheck=1
-gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
-enabled=1
-priority=10
-@end verbatim
-
-@subsubsection Priority configuration
-
-Both [webenv] and [webenv-test] repositories update packages inside
-CentOS [base] and CentOS [updates] repositories.
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-* trunk Identity Models Img Promo Web::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Models/Xcf.texi b/Manuals/Repository/trunk/Identity/Models/Xcf.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Identity/Models/Xcf.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Release.texi b/Manuals/Repository/trunk/Identity/Release.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Release.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes.texi b/Manuals/Repository/trunk/Identity/Themes.texi
deleted file mode 100644
index 01a20c1..0000000
--- a/Manuals/Repository/trunk/Identity/Themes.texi
+++ /dev/null
@@ -1,26 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Identity/Themes/} directory exists to organize
-production of CentOS themes.
-
-@subsection Description
-
-@subsection Usage
-
-In this location themes are organized in ``Models'' ---to store common
-information--- and ``Motifs''---to store unique information. At
-rendering time, both motifs and models are combined to produce the
-final CentOS themes. CentOS themes can be tagged as ``Default'' or
-``Alternative''. CentOS themes are maintained by CentOS community.
-
-@menu
-* trunk Identity Themes Models::
-* trunk Identity Themes Motifs::
-@end menu
-
-@subsection See also
-
-@menu
-* trunk Identity::
-* trunk::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models.texi b/Manuals/Repository/trunk/Identity/Themes/Models.texi
deleted file mode 100644
index b91973a..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models.texi
+++ /dev/null
@@ -1,30 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Organize theme models.
-@end itemize
-
-@subsection Description
-
-Theme models let you modeling characteristics (e.g., dimensions,
-translation markers, position of each element on the display area,
-etc.) common to all themes. Theme models let you reduce the time
-needed when propagating artistic motifs to different visual
-manifestations.
-
-Theme models serves as a central pool of design templates for themes
-to use. This way you can produce themes with different artistic motifs
-but same characteristics.
-
-@subsection Usage
-
-Inside the framework location above, you find theme models organized
-by name. You can add your own theme models to the structure by adding
-a directory to the list. By default you have the `@xref{trunk Identity
-Themes Models Default, Default},' and `@xref{trunk Identity Themes
-Models Alternative, Alternative},' ready-to-use theme models.
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Alternative.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Alternative.texi
deleted file mode 100644
index 483226a..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Alternative.texi
+++ /dev/null
@@ -1,26 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-CentOS alternative theme models exist for people how want to use a
-different visual style on their installations of CentOS distribution.
-As the visual style is needed for a system already installed
-components like Anaconda are not required inside alternative themes.
-Inside alternative themes you find post-installation visual style only
-(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative
-themes are maintained by CentOS Community.
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Default.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Default.texi
deleted file mode 100644
index 6ce9103..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Default.texi
+++ /dev/null
@@ -1,27 +0,0 @@
-@subsection Goals
-
-This location stores CentOS default theme model. The default theme
-model of CentOS is used in all visual manifestations of CentOS Project
-corporate visual identity (e.g., distributions, web sites, promotion,
-etc.).
-
-@subsection Description
-
-@subsection Usage
-
-Changing CentOS default theme is not very convenient because that
-affects the ``recognition'' of CentOS Project. Nevertheless, we are
-interested on seeing your art work propositions. Specially if your
-art work is an improvement to the base idea behind CentOS default
-theme (@strong{Modern}, squares and circles flowing up.).
-
-If you are not happy with CentOS default theme, you can look inside
-CentOS alternative themes and download the one you are interested in.
-If you are not happy with any of the CentOS alternative themes
-available, then go and design your own CentOS alternative theme as
-described in @xref{trunk Identity Themes Motifs, Theme Motifs}.
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro.texi
deleted file mode 100644
index d10a829..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro.texi
+++ /dev/null
@@ -1,83 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-It applies to all major releases of CentOS distribution.
-
-@subsubsection One theme for all major releases
-
-Sometimes, specific visual manifestations are formed by common
-components which have internal differences. That is the case of CentOS
-distribution visual manifestation.
-
-Since a visual style point of view, the CentOS distributions share
-common artwork components like Anaconda ---to cover the CentOS
-distribution installation---, BootUp ---to cover the CentOS
-distribution start up---, and Backgrounds ---to cover the CentOS
-distribution desktop---. Now, since a technical point of view, those
-common artwork components are made of software improved constantly.
-So, we need to find a way to keep one unique name and one unique
-visual style in artwork components that have internal difference and
-also remark internal difference as well.
-
-@quotation
-@strong{Important} Remarking the CentOS release schema inside each
-major release of CentOS distribution ---or similar visual
-manifestation--- takes @emph{high attention} inside The CentOS Project
-corporate visual identity. It should be very clear for people which
-major release of CentOS distribution they are using.
-@end quotation
-
-In order to remark the CentOS release schema, the CentOS Artwork SIG
-uses a release-specific brand design named ``The CentOS Release
-Brand''. The CentOS release brand is compossed by the CentOS logotype
-@emph{and} the CentOS major release number (as specified in CentOS
-release schema definition). In this solution, the CentOS release brand
-is set inside all release-specific artworks (e.g., distribution,
-installation media, etc.) in remarkable way. The CentOS release
-brand is the design component that lets us remark the CentOS release
-schema inside the monolithic corporate visual identity structure we
-propose to use.
-
-@subsubsection One theme for each major release
-
-Other way we've been using to remark CentOS release schema is
-applying one unique theme for @emph{each} major release of CentOS
-distribution. That is, if we have 4 major releases of CentOS
-distribution, we need to provide 4 different themes to cover each
-CentOS distribution available.
-
-Inside CentOS Artwork Repository, you can create many themes and that
-is very convenient. But using one unique theme for @emph{each} major
-release of CentOS distribution would bring visual isolation among
-distributions, websites and promotion visual manifestations. If the
-CentOS project would maintain just one CentOS distribution (and many
-experienced graphic designers ready to create beautiful artworks) this
-model would be nice. Indeed, this model looks quite similar to that
-one used by Fedora project, doesn't it. But no, the CentOS project
-maintains near to 4 major releases of CentOS distribution in parallel,
-and that fact makes a huge difference since the corporate visual
-identity point of view.
-
-If we use one unique theme for @emph{each} major release of CentOS
-distribution, which one of those themes, does we use to cover other
-CentOS visual manifestations, like websites and promotion stuff?
-
-In whatever case you choose some release-specific distribution user
-will be visually isolated from other CentOS visual manifestations like
-websites and promotion stuff, even if the CentOS brand is present in
-all visual manifestations. In such a case, probably, users will end up
-asking themselves, why my CentOS distribution has this design and the
-CentOS website another one? Isn't them on the same project? With luck
-the CentOS brand will exonerate user form visual isolation.
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Promo.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Default/Promo.texi
deleted file mode 100644
index 7bfbe48..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Promo.texi
+++ /dev/null
@@ -1,27 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-It applies to all tangible and non tangible items CentOS uses to
-promote its existence. Clothes, posters, installation media,
-stationery, release countdown images, banners, stickers, are all
-examples of promotion designs.
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Web.texi b/Manuals/Repository/trunk/Identity/Themes/Models/Default/Web.texi
deleted file mode 100644
index 427850f..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Models/Default/Web.texi
+++ /dev/null
@@ -1,26 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-It applies to all web applications CentOS uses to handle its needs
-(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving
-HTML standards should be consider here.
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs.texi
deleted file mode 100644
index 7b8c0e0..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs.texi
+++ /dev/null
@@ -1,114 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Identity/Themes/Motifs} directory exists to:
-
-@itemize
-@item Organize CentOS themes' artistic motifs.
-@end itemize
-
-@subsection Description
-
-The artistic motif of theme is a graphic design component that
-provides the visual style of themes, it is used as pattern to connect
-all visual manifestations inside one unique theme.
-
-Artistic motifs are based on conceptual ideas. Conceptual ideas bring
-the motivation, they are fuel for the engines of human imagination.
-Good conceptual ideas may produce good motivation to produce almost
-anything, and art works don't escape from it.
-
-@table @samp
-@item TreeFlower
-CentOS like trees, has roots, trunk, branches, leaves and flowers. Day
-by day they work together in freedom, ruled by the laws of nature and
-open standards, to show the beauty of its existence.
-@item Modern
-Modern, squares and circles flowing up.
-@end table
-
-If you have new conceptual ideas for CentOS, then you can say that you
-want to create a new artistic motif for CentOS. To create a new
-artistic motif you need to create a directory under
-@file{Identity/Themes/Motifs/} using a name coherent with your
-conceptual idea. That name will be the name of your artistic motif. If
-possible, when creating new conceptual ideas for CentOS, think about
-what CentOS means for you, what does it makes you feel, take your
-time, think deep, and share; you can improve the idea as time goes on.
-
-Once you have defined a name for your theme, you need to create the
-motif structure of your theme. The motif structure is the basic
-direcotry structure you'll use to work your ideas. Here is where you
-organize your graphic design projects.
-
-To add a new motif structure to CentOS Artwork Repository, you need to
-use the @command{centos-art} command line in the
-@file{Identity/Themes/Motifs/} directory as described below:
-
-@example
-centos-art add --motif=ThemeName
-@end example
-
-The previous command will create the basic structure of themes for
-you. The basic structure produced by @command{centos-art} command is
-illustrated in the following figure:
-
-@example
-trunk/Identity/Themes/Motifs/$ThemeName/
-|-- Backgrounds
-| |-- Img
-| `-- Tpl
-|-- Info
-| |-- Img
-| `-- Tpl
-|-- Palettes
-`-- Screenshots
-@end example
-
-@subsection Usage
-
-When designing artistic motifs for CentOS, consider the following
-recommendations:
-
-@itemize
-@item Give a unique (case-sensitive) name to your Motif. This name is
-used as value wherever theme variable (@b{$THEME}) or translation marker
-(@b{=THEME=}) is. Optionally, you can add a description about
-inspiration and concepts behind your work.
-
-@item Use the location @file{trunk/Identity/Themes/Motifs/$THEME/} to
-store your work. If it doesn't exist create it. Note that this require
-you to have previous commit access in CentOS Artwork Repository.
-
-@item The CentOS Project is using the blue color (@b{#204c8d}) as base
-color for its corporate visual identity. Use such base corporate color
-information as much as possible in your artistic motif designs.
-
-@item Try to make your design fit one of the theme models.
-
-@item Feel free to make your art enterprise-level and beautiful.
-
-@item Add the following information on your artwork (both in a visible
-design area and document metadata):
-
-@itemize
-
-@item The name (or logo) of your artistic motif.
-
-@item The copyright sentence: @b{Copyright (C) YEAR YOURNAME}
-
-@item The license under which the work is released. All CentOS Art
-works are released under
-@url{http://creativecommons.org/licenses/by-sa/3.0/,Creative Common
-Share-Alike License 3.0}
-(@url{http://creativecommons.org/licenses/by-sa/3.0/}).
-
-@end itemize
-@end itemize
-
-@subsection See also
-
-@menu
-* trunk Identity Themes::
-* trunk Identity::
-* trunk::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Flame.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Flame.texi
deleted file mode 100644
index b9e787a..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Flame.texi
+++ /dev/null
@@ -1,206 +0,0 @@
-@subsection Goals
-
-This section describes the steps we followed to construct the
-@emph{Flame} artistic motif. This section may be useful for anyone
-interested in reproducing the @emph{Flame} artistic motif, or in
-creating new artistic motifs for The CentOS Project corporate visual
-identity (@pxref{trunk Identity}).
-
-@subsection Description
-
-The @emph{Flame} artistic motif was built using the flame filter of
-Gimp 2.2 in CentOS 5.5.
-
-The flame filter of Gimp can produce stunning, randomly generated
-fractal patterns. The flame filter of Gimp gives us a great oportunity
-to reduce the time used to produce new artistic motifs, because of its
-``randomly generated'' nature. Once the artistic motif be created, it
-is propagated through all visual manifestations of CentOS Project
-corporate visual identity using the @file{centos-art.sh} script
-(@pxref{trunk Scripts Bash}) inside the CentOS Artwork Repository.
-
-To set the time intervals between each new visual style production, we
-could reuse the CentOS distribution major release schema. I.e., we
-could produce a new visual style, every two years, based on a new
-``randomly generated'' flame pattern, and publish the whole corporate
-visual identity (i.e., distribution stuff, promotion stuff, websites
-stuff, etc.) with the new major release of CentOS distribution all
-together at once.
-
-Producing a new visual style is not one day's task. Once we have
-defined the artistic motif, we need to propagate it through all visual
-manifestations of The CentOS Project corporate visual identity. When
-we say that we could produce one new visual style every two years we
-really mean: to work two years long in order to propagate a new visual
-style to all visual manifestations of The CentOS Project corporate
-visual identity.
-
-Obviously, in order to propagate one visual style to all different
-visual manifestations of The CentOS Project corporate visual identity,
-we need first to know which the visual manifestations are. To define
-which visual manifestations are inside The CentOS Project corporate
-visual identity is one of the goals the CentOS Artwork Repository and
-this documentation manual are both aimed to satisfy.
-
-Once we define which the visual manifestation are, it is possible to
-define how to produce them, and this way, organize the automation
-process. Such automation process is one of the goals of
-@file{centos-art.sh} script.
-
-With the combination of both CentOS Artwork Repository and
-@file{centos-art.sh} scripts we define work lines where translators,
-programmers, and graphic designers work together to distribute and
-reduce the amount of time employed to produce The CentOS Project
-monolithic corporate identity.
-
-From a monolithic corporate visual identity point of view, notice that
-we are producing a new visual style for the same theme (i.e.,
-@emph{Flame}). It would be another flame design but still a flame
-design. This idea is very important to be aware of, because we are
-somehow ``refreshing'' the theme, not changing it at all.
-
-This way, as we are ``refreshing'' the theme, we still keep oursleves
-inside the monolithic conception we are trying to be attached to
-(i.e., one unique name, and one unique visual style for all visual
-manifestations).
-
-Producing artistic motifs is a creative process that may consume long
-time, specially for people without experienced knowledge on graphic
-design land. Using ``randomly generated'' conception to produce
-artistic motifs could be, practically, a way for anyone to follow in
-order to produce maintainable artistic motifs in few steps.
-
-Due to the ``randomly generated'' nature of Flame filter, we find that
-@emph{Flame} pattern is not always the same when we use @emph{Flame}
-filter interface.
-
-Using the same pattern design for each visual manifestation is
-essential in order to maintain the visual connection among all visual
-manifestations inside the same theme. Occasionally, we may introduce
-pattern variations in opacity, size, or even position but never change
-the pattern design itself, nor the color information used by images
-considered part of the same theme.
-
-@quotation
-@strong{Important}
-When we design background images, which are considered part of the
-same theme, it is essential to use the same design pattern always.
-This is what makes theme images to be visually connected among
-themeselves, and so, the reason we use to define the word ``theme''
-as: a set of images visually connected among themeselves.
-@end quotation
-
-In order for us to reproduce the same flame pattern always,
-@emph{Flame} filter interface provides the @samp{Save} and @samp{Open}
-options. The @samp{Save} option brings up a file save dialog that
-allows you to save the current Flame settings for the plug-in, so that
-you can recreate them later. The @samp{Open} option brings up a file
-selector that allows you to open a previously saved Flame settings
-file.
-
-The Flame settings we used in our example are saved in the file:
-
-@verbatim
-trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
-@end verbatim
-
-@subsection Construction
-
-@subsubsection Step 1: Set image size
-
-Create an empty image and fill the @samp{Background} layer with black
-(@code{000000}) color. Image dimensions depend on the final
-destination you plan to use the image for. For the sake of our
-construction example we used an image of 640x480 pixels and 300 pixels
-per inch (ppi).
-
-@subsubsection Step 2: Add base color and pattern information
-
-Create a new layer named @samp{Base}, place it over @samp{Background}
-layer and fill it with the base color (@code{7800ff}) you want to have
-your background image set in. Add a mask to @samp{Base} layer using
-radial gradient and blur it. You may need to repeat this step more
-than once in order to achieve a confortable black radial degradation
-on the right side of your design.
-
-Duplicate @samp{Base} layer and name it @samp{Paper}. Place
-@samp{Paper} layer over @samp{Base} layer. Remove content of
-@samp{Paper} layer and fill it with @samp{Paper (100x100)} pattern.
-Once you've done with black radial degradation, reduce the
-@samp{Paper} layer opacity to 20%.
-
-Notice that when we duplicate one layer, the mask information related
-to layer is preserved from previous to next layer. This saves us some
-of the time required to produce different layers with the same mask
-information on them.
-
-Duplicate @samp{Paper} layer and rename it @samp{Stripes}. Remove
-paper pattern from @samp{Stripes} layer. Fill @samp{Stripes} layer
-with @samp{Stripes (48x48)} pattern and reduce the @samp{Stripes}
-layer opacity to 15%.
-
-@subsubsection Step 3: Add flame motif
-
-Create a new layer named @samp{Flame}. Set the foreground
-(@code{003cff}) and background (@code{0084ff}) colors to the gradient
-you want to build the flame motif.
-
-To build flame motif, use the flame filter (@samp{Filters > Render >
-Nature > Flame...}) on @samp{Flame} layer. We used a layer mask, with
-a radial gradient on it to control the boundaries of flame motif on
-@samp{Flame} layer.
-
-Duplicate @samp{Flame} layer and rename it `Flame Blur'. Place `Flame
-Blur' below @samp{Flame} layer. Apply Gussian blur filter
-(@samp{Filters > Blur > Gussian Blur...}) until reaching the desiered
-effect.
-
-The opacity value, in @samp{Flame} layers, may vary from one image to
-another based on the place the image will be finally placed on. For
-example, images used as desktop background have the @samp{Flame} layer
-opacity set at 100% but @samp{Flame Blur} is set to 70%. However, you
-may find that background images used in anaconda progress slides have
-opacity reduced differently, in order to reduce brightness in a way
-that texts could look clean and readable over it.
-
-@subsubsection Step 4: Add foreground color
-
-Create a new layer named @samp{Color}, place it on top of all visible
-layers and fill it with plain color (@code{4c005a}). Reduce
-@samp{Color} layer opacity to 20%. You can use the @samp{Color} layer
-to control the right side color information you want to produce the
-image for.
-
-Duplicate @samp{Flame} layer and create a new layer named
-@samp{Color#1}. Place @samp{Color#1} layer on top of layer named
-@samp{Color}. Remove the mask information from @samp{Color#1} layer
-and recreate a new one using an inverted alpha channel as reference.
-Remove @samp{Color#1} layer content and fill it back with plain black
-(@code{000000}) color. Reduce @samp{Color#1} opacity to 20%. In this
-step we created a mask to protect the flame artistic motif from black
-color, so when we decrement or increment the opacity of layer, the
-flame artistic motif wouldn't be affected, just the environment
-suround it.
-
-When you set color information, remember that the same artistic motif
-needs to be indexed to 14 and 16 colors, in order to produce Grub and
-Syslinux visual manifestations respectively. Using many different
-colors in the artistic motif may reduce the possibility of your design
-to fix all different situations in. Likewise, using more colors in
-one design, and less colors in another design will reduce the
-connectivity among your designs, since color information is relevant
-to visual identity.
-
-When you propagate your artistic motif visual style to different
-visual manifestations of CentOS Project corporate visual identity, it
-is up to you to find out justice and compromise among all possible
-variables you may face.
-
-@subsection See also
-
-@menu
-* trunk Identity Themes Motifs::
-* trunk Identity Themes::
-* trunk Identity::
-* trunk::
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern.texi
deleted file mode 100644
index 306ab79..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Presentation
-
-@subsection Construction
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
deleted file mode 100644
index adda528..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
+++ /dev/null
@@ -1,143 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Organize background images for Modern theme.
-@end itemize
-
-@subsection Description
-
-Inside @file{Motifs} directory, the @file{Backgrounds/} directory is
-used to create vectorial designs using Inkscape and background images
-using Gimp. Later, you can export background images as @file{.png} and
-load them in your vectorial design project using the import feautre of
-Inkscape.
-
-You may need to repeat this technic for different screen resoluions.
-In that case you need to create one file for each screen resolution
-and do the appropriate linking inside .svg to .png files. For example
-if you need to produce background images in 800x600 you need to create
-the following file:
-
-@example
-xcf/800x600.xcf
-@end example
-
-to produce the background image:
-
-@example
-img/800x600-bg.png
-@end example
-
-which is loaded in:
-
-@example
-svg/800x600.svg
-@end example
-
-to produce the final background image:
-
-@example
-img/800x600.png
-@end example
-
-The @file{img/800x600.png} background image is produced automatically
-by means of rendering scripts.
-
-In other cases (e.g. Anaconda), it is possible that you need to make
-some variations to one background image that don't want to appear on
-regular background images of the same resolution. In this case you
-need to create a new and specific background image for that art
-component. For example, if you need to produce the background image
-used by Anconda (800x600) art works you create the file:
-
-@example
-xcf/800x600-anaconda.xcf
-@end example
-
-to produce the background image:
-
-@example
-img/800x600-anaconda-bg.png
-@end example
-
-which is loaded in:
-
-@example
-svg/800x600-anaconda.svg
-@end example
-
-to produce the file:
-
-@example
-img/800x600-anaconda.png
-@end example
-
-The 800x600-anaconda.png file is used by all Anaconda art works
-sharing a common 800x600 screen resolution (e.g., Header, Progress,
-Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors
-and 640x480 pixels so you need to create a 640x480 background image
-for it, and take the color limitation into account when designing it.
-
-Background images without artistic motif are generally used as based
-to build the Background images that do contain the theme artistic
-motif.
-
-Background images are linked (using the @b{import} feature of
-Inkscape) inside almost all theme art works. This structure let you
-make centralized changes on the visual identity and propagate them
-quickly to other areas.
-
-In this structure you design background images for different screen
-resolutions based on the theme artistic motif.
-
-You may create different artistic motifs propositions based
-on the same conceptual idea. The conceptual idea is what defines a
-theme. Artistic motifs are interpretations of that idea.
-
-Inside this directory artistic motifs are organized by name (e.g.,
-TreeFlower, Modern, etc.).
-
-Each artistic motif directory represents just one unique artistic
-motif.
-
-The artistic motif is graphic design used as common pattern to connect
-all visual manifestations inside one unique theme. The artistic motif
-is based on a conceptual idea. Artistic motifs provide visual style
-to themes.
-
-Designing artistic motifs is for anyone interested in creating
-beautiful themes for CentOS. When building a theme for CentOS, the
-first design you need to define is the artistic motif.
-
-
-Inside CentOS Artwork Repository, theme visual styles (Motifs) and
-theme visual structures (Models) are two different working lines.
-When you design an artistic motif for CentOS you concentrate on its
-visual style, and eventualy, use the @command{centos-art} command line
-interface to render the visual style, you are currently producing,
-against an already-made theme model in order to produce the final
-result. Final images are stored under @file{Motifs/} directory using
-the model name, and the model directory structure as reference.
-
-The artistic motif base structure is used by @command{centos-art} to
-produce images automatically. This section describes each directory of
-CentOS artistic motif base structure.
-
-@subsection Usage
-
-The @file{Backgrounds/} directory is probably the core component,
-inside @file{Motifs/} directory structure. Inside @file{Backgrounds/}
-directory you produce background images used by almost all theme
-models (e.g., Distribution, Websites, Promotion, etc.). The
-@file{Backgrounds/} directory can contain subdirectories to help you
-organize the design process.
-
-@subsection See also
-
-@menu
-* trunk Identity Themes Motifs Modern Backgrounds Img::
-* trunk Identity Themes Motifs Modern Backgrounds Tpl::
-* trunk Identity Themes Motifs Modern Backgrounds Xcf::
-@comment --- Removed(* trunk Translations Identity Themes Backgrounds::) ---
-@end menu
-
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
deleted file mode 100644
index fc1ecfb..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
+++ /dev/null
@@ -1,19 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-In this directory is where you store all background images (e.g.,
-.png, .jpg, .xpm, etc.). This directory is required by
-@file{centos-art} command line interface.
-
-@subsection See also
-
-@menu
-@end menu
-
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
deleted file mode 100644
index 4b3308a..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
+++ /dev/null
@@ -1,18 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-In this directory is where you store all the scalable vector graphics
-(e.g., .svg) files. This directory is required by @file{centos-art}
-command line interface.
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
deleted file mode 100644
index b572a3d..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
+++ /dev/null
@@ -1,27 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-
-@subsection Usage
-
-In this directory is where you store the project files (e.g, .xcf) of
-Gimp. This directory is not required by @file{centos-art} command
-line interface. If you can create a beautiful background images using
-scalable vector graphics only, then there is no need to use the
-@file{Xcf/} directory to store background projects. Of course, you can
-merge both Gimp and Inkscape power to produce images based on them.
-In this last case you need the @file{Xcf/} directory.
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
deleted file mode 100644
index 8735b28..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
+++ /dev/null
@@ -1,59 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-To render Anaconda progress slide images using the @emph{Modern}
-artistic motif design, the Default theme model, and available
-translation files (--- @strong{Removed}(pxref:trunk Translations Identity Themes Distro
-Anaconda Progress) ---); use the following commands:
-
-@example
-cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
-centos-art render --identity
-@end example
-
-The above command will create the following structure:
-
-@example
-trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
-|-- 3
-| |-- en
-| | |-- 01-welcome.png
-| | |-- 02-donate.png
-| | `-- 03-yum.png
-| `-- es
-| |-- 01-welcome.png
-| |-- 02-donate.png
-| `-- 03-yum.png
-|-- 4
-| |-- en
-| | |-- 01-welcome.png
-| | |-- 02-donate.png
-| | `-- 03-yum.png
-| `-- es
-| |-- 01-welcome.png
-| |-- 02-donate.png
-| `-- 03-yum.png
-`-- 5
- |-- en
- | |-- 01-welcome.png
- | |-- 02-donate.png
- | `-- 03-yum.png
- `-- es
- |-- 01-welcome.png
- |-- 02-donate.png
- `-- 03-yum.png
-@end example
-
-
-@subsection See also
-
-@menu
-@end menu
-
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Palettes.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Palettes.texi
deleted file mode 100644
index 79765d1..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/Modern/Palettes.texi
+++ /dev/null
@@ -1,20 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Organize palette files for Modern theme.
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-Here is where graphic designers define theme palettes for
-color-limited art works. Theme palettes contain the color information
-that rendering functions need, in order to produce images with color
-limitations. Theme palettes contain the unique color information
-required by theme.
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi b/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
deleted file mode 100644
index 32e0626..0000000
--- a/Manuals/Repository/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
+++ /dev/null
@@ -1,323 +0,0 @@
-@subsection Goals
-
-This section exists to orgnize backgrounds of @emph{TreeFlower}
-artistic motif.
-
-@subsection Description
-
-@subsubsection Desktop background
-
-Once you have defined the vectorial artistic motif design, use the
-@command{centos-art.sh} script (as described in usage section below)
-to produce the png version of it. With the png version of your
-vectorial design do the following:
-
-Open the png version with GIMP.
-
-Save the png version as a project of GIMP inside
-@file{trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf}
-directory, using the same name of your vectorial design but with the
-@samp{.xcf} extension.
-
-Now use GIMP to improve your design. Here you may add one layer for
-pattern, another for colors, and so on until you find yourself
-confortable with your artwork. For example, the following layer
-distribution (from bottom to top) was used to build revision 285 of
-file @file{1360x768.xcf} using @emph{TreeFlower} artistic motif at
-revision 241.
-
-@table @strong
-@item Layer 1: Background
-
-The first thing we did with GIMP was to create a layer named
-@samp{Background} to store the artistic motif (File > Open as layer).
-This layer is the lowest layer in the image. Later, we started to
-create layers one upon another to change the artistic motif visual
-style.
-
-@item Layer 2: Shadow#1
-
-This layer is above @samp{Background} and contains a linear gradient
-from left (000000) to right (transparent) covering the whole image.
-This layer masks the artistic motif to avoid the effect of linear
-gradient. This layer is 100% of opacity.
-
-@item Layer 3: Shadow#2
-
-This layer is above @samp{Shadow#1} and contains a linear gradient
-from left (000000) to right (transparent) covering just the 70% of the
-whole image aproximatly. This layer doesn't mask the artistic motif
-which make the left part of it fall into the dark of linear gradient.
-This layer is 100% of opacity.
-
-@item Layer 4: Pattern (Paper)
-
-This layer is above @samp{Shadow#2} an contains the paper pattern
-shipped with GIMP 2.2. This layer doesn't mask the artistic motif so
-the pattern is applied over the whole image. This layer is set to 15%
-of opacity.
-
-@item Layer 5: Pattern (Stripes)
-
-This layer is above @samp{Pattern (Paper)} and contains the stripes
-used over the artistic motif. This layer do masks the artistic motif
-so the stripes are only applied to it. This layer is set to 10% of
-opacity.
-
-@item Layer 6: Shadow#3
-
-This layer is above @samp{Pattern (Stripes)} and contains a linear
-gradient from right (6600ff) to left (transparent). This layer masks
-the artistic motif so the linear gradient doesn't affect it. This
-layer is set to 15% of opacity.
-
-@item Layer 7: Shadow#4
-
-This layer is above @samp{Shadow#3} and contains a
-linear gradient from left (000000) to right (transparent). This layer
-do masks the artistic motif so the linear gradient doesn't affect it.
-This layer is set to 10% of opacity.
-
-@item Layer 8: Color#1
-
-This layer is above @samp{Shadow#4} and is filled with orange (ffae00)
-color over the whole image. This layer is set to 10% of opacity.
-
-@item Layer 9: Color#2
-
-This layer is above @samp{Color#1} and is filled with
-blue (010a88) color over the whole image. This layer is set to 10% of
-opacity.
-
-@end table
-
-@quotation
-@strong{Note} There is no definite combination. To get the appropriate
-visual design is a matter of constant testing and personal taste.
-@end quotation
-
-Finally, use @samp{Save as copy ...} option to export the final
-design. To export the final design use the same name of your vectorial
-design plus @samp{-final.png} extension.
-
-You can repeat these steps to create images for other screen
-resolutions.
-
-@subsubsection Anaconda Prompt (syslinux) background
-
-When building syslinux backgrounds it is needed to take into account
-that the final image is reduced to 16 colors. In desktop background
-there is no color limitation but syslinux does have. The goal of this
-section is achieving a final syslinux background as close as possible
-to desktop backgrounds using 16 colors only.
-
-Another point to consider is the forground and background definition
-used by syslinux. The syslinux documentation says that the color set
-in position 0 is the background and color set in position 7 is the
-forground. The final palette of color used by our background will
-match that specification. For great contrast we'll use black as
-background and white as forground. At this poing we have black
-(000000) and white (ffffff) colors in our syslinux palette, which left
-us with 14 colors to play with.
-
-Let's begin with @file{Xcf/640x300.xcf} layer distribution from bottom
-to top:
-
-@table @strong
-@item Layer 1: Background
-
-This layer is the lowest layer in the image composition and contains
-the artistic motif image rendered for the same resolution (i.e.,
-@file{Img/Png/640x300.png}). This layer is set to 100% of opacity.
-
-@item Layer 2: Pattern (Paper)
-
-This layer is placed above @samp{Background} layer and contains the
-paper pattern shipped with GIMP 2.2. This layer doesn't mask the
-artistic motif. This layer is set to 30% of opacity.
-
-@item Layer 3: Pattern (Stripes)
-
-This layer is placed above @samp{Pattern (Paper)} layer and contains
-the stripes pattern shipped with GIMP 2.2. This layer does mask the
-artistic motif in order to apply the stripes over it only. The
-background is not affected by the stripes pattern just the artistic
-motif. This layer is set to 20% of opacity.
-
-@item Layer 4: Shadow#1
-
-This layer is placed above @samp{Pattern (Stripes)} layer and fills
-the entire layer area with violet (6600ff) color. This layer do mask
-the artistic motif in order to applied the violet color to the
-background area outside the artistic motif only. This layer is set to
-15% of opacity.
-
-@item Layer 5: Color#1
-
-This layer is above @samp{Shadow#1} and is filled with orange (ffae00)
-color to cover the whole image. This layer is set to 10% of opacity.
-
-@item Layer 6: Color#2
-
-This layer is above @samp{Color#1} and is filled with blue (010a88)
-color to cover the whole image. This layer is set to 10% of opacity.
-
-@item Layer 7: Shadow#2
-
-This layer is above @samp{Color#1} and contains a linear gradient from
-left (000000) to right (transparent) covering 70% of the image
-approximately.
-
-@end table
-
-At this point we have the composition and should look like the desktop
-backgrounds. Compared with desktop backgrounds there are some
-differences in opacity. This is because in our testings the final
-color information found with this composition produces an acceptable
-16 color image. Of course this is something we haven't seen yet.
-
-To define the color information of our current coposition, save the
-syslinux background composition we've done using @samp{File > Save as
-Copy ...} option in the following location:
-
-@verbatim
-trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png
-@end verbatim
-
-Now, create the final png version of syslinux backgrounds using the
-following command:
-
-@verbatim
-centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt
-@end verbatim
-
-This command will create syslinux-splash final images for all major
-releases of CentOS distribution the repository has been configured to.
-The important files here are @file{syslinux-splash.png}, other
-files may contain the wrong information because we haven't defined yet
-the correct color information to use.
-
-Open one @file{syslinux-splash.png} file with GIMP and use the
-@samp{Image > Mode > Indexed} to reduce image colors up to 16 colors,
-using the @samp{Generate optimum palette} feature of GIMP. If the
-image looks aceptable after reducing colors, use the @samp{Palettes}
-menu (Ctrl+P) of GIMP to import a new palette from file and name it
-@samp{CentOS-TreeFlower-Syslinux}. Once you've saved the palette, the
-color information is stored at:
-
-@verbatim
-~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
-@end verbatim
-
-You need to edit @file{CentOS-TreeFlower-Syslinux.gpl} file in order
-to set the appropriate order of colors. Remember black (000000) in
-position 0, and white (ffffff) in position 7. Other positions are
-irrelevant. When editing this file you may find that color reduction
-did not set black and white colors to their respective values exactly.
-Change that manually. For example, consider the following palette:
-
-@verbatim
-GIMP Palette
-Name: CentOS-TreeFlower-Syslinux
-Columns: 16
-#
- 0 0 0 Background (black)
- 23 20 35 Untitled
- 34 25 48 Untitled
- 37 35 60 Untitled
- 47 36 68 Untitled
- 37 54 86 Untitled
- 60 48 90 Untitled
-255 255 255 Foreground (white)
- 66 54 99 Untitled
- 74 61 98 Untitled
- 49 78 126 Untitled
- 43 87 151 Untitled
- 92 89 95 Untitled
- 54 104 183 Untitled
-158 153 156 Untitled
-201 196 195 Untitled
-@end verbatim
-
-Update the @samp{Palettes} menu to get the new color positions from
-the file you just edited and open the palette with double click.
-
-Update the @file{syslinux.gpl} file copying the following file:
-
-@verbatim
-~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
-@end verbatim
-
-to
-
-@verbatim
-trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl
-@end verbatim
-
-With the @samp{CentOS-TreeFlower-Syslinux} palette opened in the
-@samp{Palette Editor}, open (Ctrl+O) the following file:
-
-@verbatim
-trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm
-@end verbatim
-
-and replace its color information with that one in
-@samp{CentOS-TreeFlower-Syslinux} palette. When you are replacing
-color information inside @file{syslilnux.ppm}, remember to keep the
-order of colors just as they are in the
-@samp{CentOS-TreeFlower-Palette} palette.
-
-The @file{syslinux.ppm} file is 16 pixels width and 1 pixel height, so
-you probably need to zoom it a bit to set the color information in
-their place when using the pen tool with the brush @samp{Circle (01)
-(1 x 1)}.
-
-Once you've updated the @samp{syslinux.ppm} file, it is time to update
-the following file:
-
-@verbatim
-trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex
-@end verbatim
-
-The @file{syslinux.hex} file contains the color information in
-hexadecimal notation. The color information in hexadecimal notation
-is required by @command{ppmtolss16} command. The @command{ppmtolss16}
-command produces the final LSS16 image format that is used by syslinux
-program inside CentOS distribution.
-
-The color information inside @file{syslinux.hex} must match the one in
-@file{syslinux.ppm} and @file{syslinux.gpl}. For example, based on
-@file{CentOS-TreeFlower-Syslinux} palette of colors above, consider
-the following @file{syslinux.hex} file:
-
-@verbatim
-#000000=0
-#171423=1
-#221930=2
-#25233c=3
-#2f2444=4
-#253656=5
-#3c305a=6
-#ffffff=7
-#423663=8
-#4a3d62=9
-#314e7e=10
-#2b5797=11
-#5c595f=12
-#3668b7=13
-#9e999c=14
-#c9c4c3=15
-@end verbatim
-
-@subsubsection Grub background
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Identity/Widgets.texi b/Manuals/Repository/trunk/Identity/Widgets.texi
deleted file mode 100644
index 9cf9a6e..0000000
--- a/Manuals/Repository/trunk/Identity/Widgets.texi
+++ /dev/null
@@ -1,14 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales.texi b/Manuals/Repository/trunk/Locales.texi
deleted file mode 100644
index 98a4746..0000000
--- a/Manuals/Repository/trunk/Locales.texi
+++ /dev/null
@@ -1,56 +0,0 @@
-The @file{trunk/Locales} directory exists to store the translation
-messages used to produce content in different languages.
-
-Translation messages are organized using the directory structure of
-the component being translated. For example, if we want to provide
-translation messages for @file{trunk/Manuals/Filesystem}, then the
-@file{trunk/Locales/Manuals/Filesystem} directory needs to be created.
-
-Once the locale directory exists for the component we want to provide
-translation messages for, it is necessary to create the translation
-files where translation messages are. The translation files follows
-the concepts of @command{xml2po} and GNU @command{gettext} tools.
-
-The basic translation process is as follow: first, translatable
-strings are extracted from files and a portable object template (.pot)
-is created or updated with the information. Using the portable object
-template, a portable object (.po) is created or updated for translator
-to locale the messages retrived. Finally, a machine object (.mo) is
-created from portable object to sotore the translated messages.
-
-Inside the repository there are two ways to retrive translatable
-strings from files. The first one is through @command{xml2po} command
-and the second through @command{xgettext} command. The @command{xml2po}
-is used to retrive translatable strings from XML files (e.g., Scalable
-Vector Graphics, DocBook, etc.) and the @command{xgettext} command is
-used to retrive translatable strings from shell scripts files (e.g.,
-the files that make the @command{centos-art.sh} command-line
-interface).
-
-When translatable strings are retrived from XML files, using the
-@command{xml2po} command, there is no need to create the machine
-object as we do when translatable strings ar retrived from shell
-files, using the @command{xgettext} command. The @command{xml2po}
-produces a temporal machine object in order to create a translated XML
-file. Once the translated XML file has been created the machine object
-is no longer needed. On the other hand, the machine object produced by
-the @command{xgettext} command is required by the system in order for
-the show shell script localized messages.
-
-Another difference between @command{xml2po} and @command{xgettext} we
-need to be aware of is the directory structure used to store machine
-objects. In @command{xml2po}, the machine object is created in the
-current working directory as @file{.xml2po.mo} and can be safetly
-removed once the translated XML file has been created. In the case of
-@command{xgettext}, the machine object needs to be stored in the
-@file{$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo} file in order
-for the system to interpret it and should not be removed since it is
-the file that contain the translation messages themselves.
-
-Automation of localization tasks is achived through the @code{locale}
-functionality of command-line interface.
-
-@menu
-* trunk Scripts Bash Cli Functions Locale::
-@end menu
-
diff --git a/Manuals/Repository/trunk/Locales/Identity.texi b/Manuals/Repository/trunk/Locales/Identity.texi
deleted file mode 100644
index 5bf1b70..0000000
--- a/Manuals/Repository/trunk/Locales/Identity.texi
+++ /dev/null
@@ -1,29 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@comment --- Removed(* trunk Translations Identity Brands::) ---
-@comment --- Removed(* trunk Translations Identity Fonts::) ---
-@comment --- Removed(* trunk Translations Identity Models::) ---
-@comment --- Removed(* trunk Translations Identity Release::) ---
-@comment --- Removed(* trunk Translations Identity Themes::) ---
-@comment --- Removed(* trunk Translations Identity Widgets::) ---
-* trunk Identity::
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Brands.texi b/Manuals/Repository/trunk/Locales/Identity/Brands.texi
deleted file mode 100644
index 6f771ef..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Brands.texi
+++ /dev/null
@@ -1,105 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Organize brands' translation files.
-@end itemize
-
-@subsection Description
-
-Translation files, inside @file{trunk/Translations/Identity/Brands}
-translation entry, don't use default rendering translation
-functionality, they use the following translation pre-rendering
-configuration file instead:
-
-@verbatim
-/home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh
-@end verbatim
-
-Inside @file{trunk/Translations/Identity/Brands} translation entry,
-translation files are symbolic links pointing to the common template
-translation structure, inside the translation template (@samp{Tpl/})
-directory.
-
-Inside @file{trunk/Translations/Identity/Brands} translation entry,
-translation files are created using identity design templates as
-reference. The translation pre-rendering script creates a translation
-structure where the translation template (@samp{Tpl/}) directory
-structure applies to each single design template available.
-
-For example, if the brands' translation template (@samp{Tpl/})
-directory has 30 translation files, and there are 20 design templates;
-the brands' translation pre-rendering script creates a translation
-structure of symbolic links where the 30 translation files apply the
-20 design templates one by one, producing 600 translation symbolic
-links as result. At this point, when rendering identity, the
-@command{centos-art} script considers translation symbolic links as
-translation files.
-
-Translation file names, inside brands' translation template
-(@samp{Tpl}) directory have special meaning:
-
-@subsubsection Conventional file names
-@cindex Translation brands file names
-
-Convenctional file names look like @file{blue.sed}, @file{2c-a.sed},
-etc. Replacement commands inside translation file are applied to
-design templates and translation file names are used as final image
-name. The image dimensions use the same dimensions that design
-template has.
-
-@subsubsection Numeric file names
-@cindex Translation brands file names
-
-Numeric file names look like @file{300.sed}, @file{200.sed}, etc.
-Replacements commands inside translation files are applied to design
-templates, and translation file names are used as final image name.
-The final image is saved using an specific @samp{width} defined by the
-number part of the translation file name. The image @samp{height} is
-automatically scaled based on the previous @samp{width} definition to
-maintain the designing ratio.
-
-For example, if your design template has 400x200 pixels of dimension,
-and you apply a translation file named `300.sed' to it, the final
-image you get as result will have 300x100 pixels of dimension. The
-same is true if you use higher numbers like `1024.sed', `2048.sed',
-etc. In these cases you have bigger images proportionally.
-
-As we are using scalable vector graphics to design identity templates,
-the image size you produce is not limitted in size. You can use one
-design template produced in 400x200 pixels to produce larger or
-shorter PNG images using numeric translation files as described
-above.
-
-@subsubsection Translation markers
-
-Inside @file{trunk/Translations/Identity/Brands/}, translation files
-combine the following translation markers:
-
-@table @samp
-@item #000000
-
-Specify which color to use when rendering brand images.
-
-@quotation
-@strong{Note} As translation files inside
-@file{trunk/Translations/Identity/Brands} are symbolic links that
-point to template translation files, translation markers are defined
-inside template translation files.
-@end quotation
-@end table
-
-@subsection Usage
-@cindex How to render brands' translation files
-
-To render brands' translation files, use the following command:
-
-@verbatim
-centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
-@end verbatim
-
-@subsection See also
-
-@menu
-@comment --- Removed(* trunk Translations Identity Brands Tpl::) ---
-* trunk Identity Brands::
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Brands/Tpl.texi b/Manuals/Repository/trunk/Locales/Identity/Brands/Tpl.texi
deleted file mode 100644
index b53171e..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Brands/Tpl.texi
+++ /dev/null
@@ -1,10 +0,0 @@
-@subsection Goals
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Fonts.texi b/Manuals/Repository/trunk/Locales/Identity/Fonts.texi
deleted file mode 100644
index 2699334..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Fonts.texi
+++ /dev/null
@@ -1,62 +0,0 @@
-@subsection Goals
-
-This section exists to organize fonts translation files.
-@subsection Description
-
-Translation files, inside @file{trunk/Translations/Fonts}, have the
-following structure:
-
-@verbatim
-s!font-family:Denmark!font-family:DejaVu LGC Sans!
-s!font-weight:normal!font-weight:bold!
-s!font-style:normal!font-style:italic!
-@end verbatim
-
-Inside @file{trunk/Translations/Fonts}, there is one translation file
-for each font preview image you want to produce. This way, we create
-one translation file for each font-family we use somewhere inside
-CentOS visual identity.
-
-@quotation
-@strong{Important} Do not create translation files for
-font-families not used somewhere inside CentOS visual identity. The
-identity of font entry (@pxref{trunk Identity Fonts}) is used as
-reference when someone needs to know which font-families are allowed
-to use inside CentOS visual identity.
-@end quotation
-
-@subsubsection Translation Markers
-
-Inside @file{trunk/Translations/Identity/Fonts}, translation files
-combine the following translation markers:
-
-@table @samp
-@item font-family:Denmark
-Specify which font family to use when rendering font preview images.
-@item font-weight:normal
-Specify which font weight to use when rendering font preview images.
-@item font-style:normal
-Specify which font style to use when rendering font preview images.
-@end table
-
-@subsection Usage
-@cindex How to render fonts' translation files
-
-Inside @file{trunk/Translations/Fonts} you use your favorite text
-editor to create translation files. Inside
-@file{trunk/Translations/Fonts} there is not translation template
-directory (@file{Tpl/}), nor translation rendering using
-@command{centos-art} script. For example, to create the
-@file{dejavu_lgc_sans-boldoblique.sed} translation file using
-@command{vim} editor, type the following command:
-
-@verbatim
-vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
-@end verbatim
-
-@subsection See also
-
-@menu
-* trunk Identity Fonts::
-@end menu
-
diff --git a/Manuals/Repository/trunk/Locales/Identity/Models.texi b/Manuals/Repository/trunk/Locales/Identity/Models.texi
deleted file mode 100644
index b53171e..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Models.texi
+++ /dev/null
@@ -1,10 +0,0 @@
-@subsection Goals
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Release.texi b/Manuals/Repository/trunk/Locales/Identity/Release.texi
deleted file mode 100644
index b53171e..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Release.texi
+++ /dev/null
@@ -1,10 +0,0 @@
-@subsection Goals
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Themes.texi b/Manuals/Repository/trunk/Locales/Identity/Themes.texi
deleted file mode 100644
index b53171e..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Themes.texi
+++ /dev/null
@@ -1,10 +0,0 @@
-@subsection Goals
-
-@subsection Description
-
-@subsection Usage
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Themes/Backgrounds.texi b/Manuals/Repository/trunk/Locales/Identity/Themes/Backgrounds.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Themes/Backgrounds.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi b/Manuals/Repository/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
deleted file mode 100644
index f2d99e2..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
+++ /dev/null
@@ -1,94 +0,0 @@
-@subsection Goals
-
-@itemize
-@item Organize Anaconda progress translation templates.
-@item Organize Anaconda progress translation files in several
-languages and major releases of CentOS distribution.
-@end itemize
-
-@subsection Description
-
-Use the following command to produce translation files based:
-
-@example
-trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
-`-- Tpl
- |-- en
- | |-- 01-welcome.sed
- | |-- 02-donate.sed
- | `-- 03-yum.sed
- `-- es
- |-- 01-welcome.sed
- |-- 02-donate.sed
- `-- 03-yum.sed
-@end example
-
-In order to produce the slide images in PNG format we need to have the
-translation files first. So we use the following commands to create
-translation files for CentOS 3, 4, and 5 major releases:
-
-@example
-centos-art render --translation --filter='3,4,5'
-@end example
-
-The above commands will produce the following translation structure:
-
-@example
-trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
-|-- 3
-| |-- en
-| | |-- 01-welcome.sed
-| | |-- 02-donate.sed
-| | `-- 03-yum.sed
-| `-- es
-| |-- 01-welcome.sed
-| |-- 02-donate.sed
-| `-- 03-yum.sed
-|-- 4
-| |-- en
-| | |-- 01-welcome.sed
-| | |-- 02-donate.sed
-| | `-- 03-yum.sed
-| `-- es
-| |-- 01-welcome.sed
-| |-- 02-donate.sed
-| `-- 03-yum.sed
-|-- 5
-| |-- en
-| | |-- 01-welcome.sed
-| | |-- 02-donate.sed
-| | `-- 03-yum.sed
-| `-- es
-| |-- 01-welcome.sed
-| |-- 02-donate.sed
-| `-- 03-yum.sed
-`-- Tpl
- |-- en
- | |-- 01-welcome.sed
- | |-- 02-donate.sed
- | `-- 03-yum.sed
- `-- es
- |-- 01-welcome.sed
- |-- 02-donate.sed
- `-- 03-yum.sed
-@end example
-
-At this point we have all the translation files we need to produce
-Anaconda progress welcome, donate and yum slides images; in English
-and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is,
-a sum of 18 images around.
-
-Now, with translation files in place, let's move to
-@file{trunk/Identity} structure and render them.
-
-@itemize
-@item @xref{trunk Identity Themes Motifs Modern Distro Anaconda Progress}.
-@end itemize
-
-@subsection Usage
-
-Translation rendering is described in @samp{trunk/Translations}
-documentation entry (--- @strong{Removed}(pxref:trunk Translations) ---).
-
-
-@subsection See also
diff --git a/Manuals/Repository/trunk/Locales/Identity/Widgets.texi b/Manuals/Repository/trunk/Locales/Identity/Widgets.texi
deleted file mode 100644
index fda4863..0000000
--- a/Manuals/Repository/trunk/Locales/Identity/Widgets.texi
+++ /dev/null
@@ -1,23 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@comment --- Removed(* trunk Translations Identity Widgets::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Manuals.texi b/Manuals/Repository/trunk/Manuals.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Manuals.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts.texi b/Manuals/Repository/trunk/Scripts.texi
deleted file mode 100644
index c9b371f..0000000
--- a/Manuals/Repository/trunk/Scripts.texi
+++ /dev/null
@@ -1,25 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Scripts} directory exists to:
-
-@itemize
-@item Organize the ``trunk'' development line of automation scripts by
-programming language.
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash.texi b/Manuals/Repository/trunk/Scripts/Bash.texi
deleted file mode 100644
index 0b387e6..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash.texi
+++ /dev/null
@@ -1,156 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Scripts/Bash} directory exists to organize the trunk
-development line of @file{centos-art.sh} automation script. The
-@file{centos-art.sh} script standardizes frequent tasks inside your
-working copy of CentOS Artwork Repository.
-
-@subsection Description
-
-The best way to understand @file{centos-art.sh} automation script is
-studying its source code. However, as start point, you may prefer to
-read an introductory resume before diving into the source code
-details.
-
-The @file{centos-art.sh} script is written in Bash. Most tasks, inside
-@file{centos-art.sh} script, have been organized in many specific
-functionalities that you can invoke from the @command{centos-art}
-command-line interface.
-
-When you type the @command{centos-art} command in your terminal, the
-operating system trys to execute that command. In order to execute the
-command, the operating system needs to know where it is, so the
-operating system uses the @var{PATH} environment variable to look for
-that command location. If your system was prepared to use CentOS
-Artwork Repository correctly (--- @strong{Removed}(pxref:trunk Scripts Bash Functions
-Verify) ---), you should have a symbolic link inside @file{~/bin/}
-directory that points to the @file{centos-art.sh} script file. As
-@file{~/bin/} directory is, by default, inside @var{PATH} environment
-variable, the execution of @command{centos-art} command runs the
-@file{centos-art.sh} script.
-
-When @file{centos-art.sh} script is executed, the first it does is
-executing the @file{trunk/Scripts/Bash/initEnvironment.sh} script to
-initialize global variables (e.g., @command{gettext} variables) and
-global function scripts. Global function scripts are located inside
-@file{trunk/Scripts/Bash/Functions} directory and their file names
-begin with @samp{cli}. Global function scripts provide common
-functionalities that can be used anywhere inside @file{centos-art.sh}
-script execution environment.
-
-Once global variables and function scripts have been loaded,
-@file{centos-art.sh} script executes the @command{cli} global function
-from @file{cli.sh} function script to retrive command-line arguments
-and define some default values that may be used later by specific
-function scripts (--- @strong{Removed}(pxref:trunk Scripts Bash Functions) ---).
-
-As convenction, the @file{centos-art.sh} command-line arguments have
-the following format:
-
-@verbatim
-centos-art arg1 --arg2=val2 --arg3=val3
-@end verbatim
-
-In the above example, @samp{centos-art} is the command you use to
-invoke @file{centos-art.sh} script. The @samp{arg1} is required and
-represents the functionality you want to perform (e.g.,
-@option{verify}, @option{render}, @option{locale}, @option{manual},
-etc.). The remaining arguments are modifiers to @option{arg1}. The
-@option{--arg2} definition is required and represets, specifically,
-the action inside the functionality you want to perform. The
-@option{--arg3} and on, are optional.
-
-Once command-line arguments have been retrived, the
-@file{centos-art.sh} script loads specific functionalities using the
-@file{cli_getFunctions.sh} function script. Only one specific
-functionality can be loaded at one script execution I.e., you run
-@command{centos-art.sh} script to run just one functionality.
-
-@float Figure,fig:trunk/Scripts/Bash:Initialization
-@verbatim
-+----------------------------------------------------------------------+
-| [centos@host]$ centos-art function --action='value' --option='value' |
-+----------------------------------------------------------------------+
-| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh |
-+---v-----------------------------------------v------------------------+
- | centos-art.sh |
- +---v---------------------------------v---+
- . | initEnvironment.sh | .
- . +---------------------------------+ .
- . | cli $@ | .
- . +---v-------------------------v---+ .
- . . | cli_getFunctions | . .
- . . +---v-----------------v---+ . .
- . . . | function1 | . . .
- . . . | function2 | . . .
- . . . | function3 | . . .
- . . . +-----------------+ . . .
- . . ........................... . .
- . ................................... .
- ...........................................
-@end verbatim
-@caption{The functionalities initialization environment.}
-@end float
-
-Functionalities are implemented by means of actions. Once the
-functionality has been initiazalized, actions initialization take
-place for that functionality. Actions initialization model is very
-similar to functions initialization model. But with the difference,
-that actions are loaded inside function environment, and so, share
-variables and functions defined inside function environment.
-
-@float Figure,fig:trunk/Scripts/Bash/Functions:Initialization
-@verbatim
-+--------------------------------------+
-| cli_getFunctions |
-+---v------------------------------v---+
-. | function1 | .
-. +---v----------------------v---+ .
-. . | function1_getActions | . .
-. . +---v--------------v---+ . .
-. . . | action 1 | . . .
-. . . | action 2 | . . .
-. . . | action n | . . .
-. . . +--------------+ . . .
-. . ........................ . .
-. ................................ .
-. +------------------------------+ .
-. | function2 | .
-. +---v----------------------v---+ .
-. . | function2_getActions | . .
-. . +---v--------------v---+ . .
-. . . | action 1 | . . .
-. . . | action 2 | . . .
-. . . | action n | . . .
-. . . +--------------+ . . .
-. . ........................ . .
-. ................................ .
-. +------------------------------+ .
-. | function3 | .
-. +---v----------------------v---+ .
-. . | function3_getActions | . .
-. . +---v--------------v---+ . .
-. . . | action 1 | . . .
-. . . | action 2 | . . .
-. . . | action n | . . .
-. . . +--------------+ . . .
-. . ........................ . .
-. ................................ .
-........................................
-@end verbatim
-@caption{The actions initialization environment.}
-@end float
-
-@subsection Usage
-
-The @file{centos-art.sh} script usage information is described inside
-each specific function documentation (--- @strong{Removed}(pxref:trunk Scripts Bash
-Functions) ---).
-
-@subsection See also
-
-@menu
-* trunk Scripts::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@comment --- Removed(* trunk Scripts Bash Locale::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli.texi
deleted file mode 100755
index e69de29..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli.texi
+++ /dev/null
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions.texi
deleted file mode 100755
index 2a421ab..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions.texi
+++ /dev/null
@@ -1,1222 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Scripts/Bash/Functions} directory exists to organize
-@file{centos-art.sh} specific functionalities.
-
-@subsection Description
-
-The specific functions of @file{centos-art.sh} script are designed
-with ``Software Toolbox'' philosophy (@pxref{Toolbox
-introduction,,,coreutils.info}) in mind: each program ``should do one
-thing well''. Inside @file{centos-art.sh} script, each specific
-functionality is considered a program that should do one thing well.
-Of course, if you find that they still don't do it, feel free to
-improve them in order for them to do so.
-
-The specific functions of @file{centos-art.sh} script are organized
-inside specific directories under @file{trunk/Scripts/Bash/Functions}
-location. Each specific function directory should be named as the
-function it represents, with the first letter in uppercase. For
-example, if the function name is @code{render}, the specific function
-directory for it would be @samp{trunk/Scripts/Bash/Functions/Render}.
-
-To better understand how specific functions of @file{centos-art.sh}
-script are designed, lets create one function which only goal is to
-output different kind of greetings to your screen.
-
-When we create specific functions for @file{centos-art.sh} script it
-is crucial to know what these functions will do exactly and if there
-is any function that already does what we intend to do. If there is no
-one, it is good time to create them then. Otherwise, if
-functionalities already available don't do what you exactly expect,
-contact their authors and work together to improve them.
-
-@quotation
-@strong{Tip} Join CentOS developers mailing list
-@email{centos-art@@centos.org} to share your ideas.
-@end quotation
-
-It is also worth to know what global functions and variables do we
-have available inside @file{centos-art.sh} script, so advantage can be
-taken from them. Global variables are defined inside global function
-scripts. Global functions scripts are stored immediatly under
-@file{trunk/Scripts/Bash/Functions} directory, in files begining with
-@samp{cli} prefix.
-
-OK, let's begin with our functionality example.
-
-What function name do we use? Well, lets use @code{greet}. Note that
-@samp{hello} word is not a verb; but an expression, a kind of
-greeting, an interjection specifically. In contrast, @samp{greet} is a
-verb and describes what we do when we say @samp{Hello!}, @samp{Hi!},
-and similar expressions.
-
-So far, we've gathered the following function information:
-
-@verbatim
-Name: greet
-Path: trunk/Scripts/Bash/Functions/Greet
-File: trunk/Scripts/Bash/Functions/Greet/greet.sh
-@end verbatim
-
-The @file{greet.sh} function script is the first file
-@file{centos-art.sh} script loads when the @samp{greet} functionality
-is called using commands like @samp{centos-art greet --hello='World'}.
-The @file{greet.sh} function script contains the @code{greet} function
-definition.
-
-Inside @file{centos-art.sh} script, as convenction, each function
-script has one top commentary, followed by one blank line, and then
-one function defintion below it only.
-
-Inside @file{centos-art.sh} script functions, top commentaries have
-the following components: the functionality description, one-line for
-copyright note with your personal information, the license under
-which the function source code is released ---the @file{centos-art.sh}
-script is released as GPL, so do all its functions---, the @code{$Id$}
-keyword of Subversion is later expanded by @command{svn propset}
-command.
-
-In our @code{greet} function example, top commentary for
-@file{greet.sh} function script would look like the following:
-
-@verbatim
-#!/bin/bash
-#
-# greet.sh -- This function outputs different kind of greetings to
-# your screen. Use this function to understand how centos-art.sh
-# script specific functionalities work.
-#
-# Copyright (C) YEAR YOURFULLNAME
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-# USA.
-#
-# ----------------------------------------------------------------------
-# $Id$
-# ----------------------------------------------------------------------
-@end verbatim
-
-After top commentary, separated by one blank line, the @code{greet}
-function definition would look like the following:
-
-@verbatim
-function greet {
-
- # Define global variables.
-
- # Define command-line interface.
- greet_getActions
-
-}
-@end verbatim
-
-The first definition inside @code{greet} function, are global
-variables that will be available along @code{greet} function execution
-environment. This time we didn't use global variable definitions for
-@code{greet} function execution environment, so we left that section
-empty.
-
-Later, we call @code{greet_getActions} function to define the
-command-line interface of @code{greet} functionality. The command-line
-interface of @code{greet} functionality defines what and how actions
-are performed, based on arguments combination passed to
-@file{centos-art.sh} script.
-
-@verbatim
-function greet_getActions {
-
- case "$ACTIONNAM" in
-
- --hello )
- greet_doHello
- ;;
-
- --bye )
- greet_doBye
- ;;
-
- * )
- cli_printMessage "`gettext "The option provided is not valid."`"
- cli_printMessage "$(caller)" 'AsToKnowMoreLine'
-
- esac
-
-}
-@end verbatim
-
-The @var{ACTIONNAM} global variable is defined in @file{cli.sh}
-function script and contains the value passed before the equal sign
-(i.e., @samp{=}) in the second command-line argument of
-@file{centos-art.sh} script. For example, if the second command-line
-argument is @option{--hello='World'}, the value of @var{ACTIONNAM}
-variable would be @samp{--hello}. Using this configuration let us
-deside which action to perform based on the action name passed to
-@file{centos-art.sh} script as second argument.
-
-The @code{greet} function definition makes available two valid
-greetings through @option{--hello} and @option{--bye} options. If no
-one of them is provided as second command-line argument, the @samp{*}
-case is evaluated instead.
-
-The @samp{*} case and its two lines further on should always be
-present in @file{_getActions.sh} function scripts, no matter what
-specific functionality you are creating. This convenction helps the
-user to find out documentation about current functionality in use,
-when no valid action is provided.
-
-The @code{greet_doHello} and @code{greet_doBye} function definitions
-are the core of @code{greet} specific functionality. In such function
-definitions we set what our @code{greet} function really does: to
-output different kinds of greetings.
-
-@verbatim
-function greet_doHello {
-
- cli_printMessage "`gettext "Hello"` $ACTIONVAL"
-
-}
-@end verbatim
-
-The @code{greet_doHello} function definition is stored in
-@file{greet_doHello.sh} function script.
-
-@verbatim
-function greet_doBye {
-
- cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
-
-}
-@end verbatim
-
-The @code{greet_doBye} function definition is stored in the
-@file{greet_doBye.sh} function script.
-
-Both @file{greet_doHello.sh} and @file{greet_doBye.sh} function
-scripts are stored inside @code{greet} function directory path (i.e.
-@file{trunk/Scripts/Bash/Functions/Greet}).
-
-The @var{ACTIONVAL} global variable is defined in @file{cli.sh}
-function script and contains the value passed after the equal sign
-(i.e., @samp{=}) in the second command-line argument of
-@file{centos-art.sh} script. For example, if the second command-line
-argument is @option{--hello='World'}, the value of @var{ACTIONVAL}
-variable would be @samp{World} without quotes.
-
-Let's see how @code{greet} specific functionality files are organzied
-under @code{greet} function directory. To see file organization we use
-the @command{tree} command:
-
-@verbatim
-trunk/Scripts/Bash/Functions/Greet
-|-- greet_doBye.sh
-|-- greet_doHello.sh
-|-- greet_getActions.sh
-`-- greet.sh
-@end verbatim
-
-To try the @code{greet} specific functionality we've just created,
-pass the function name (i.e., @samp{greet}) as first argument to
-@file{centos-art.sh} script, and any of the valid options as second
-argument. Some examples are illustrated below:
-
-@verbatim
-[centos@projects ~]$ centos-art greet --hello='World'
-Hello World
-[centos@projects ~]$ centos-art greet --bye='World'
-Goodbye World
-[centos@projects ~]$
-@end verbatim
-
-The word @samp{World} in the examples above can be anything. In fact,
-change it to have a little fun.
-
-Now that we have a specific function that works as we expect, it is
-time to document it. To document @code{greet} specific functionality,
-we use its directory path and the @code{manual} functionality
-(--- @strong{Removed}(pxref:trunk Scripts Bash Functions Manual) ---) of @file{centos-art.sh}
-script, just as the following command illustrates:
-
-@verbatim
-centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
-@end verbatim
-
-To have a well documented function helps user to understand how your
-function really works, and how it should be used. When no valid
-action is passed to a function, the @file{centos-art.sh} script uses
-the function documentation entry as vehicle to communicate which the
-valid functions are. When no documentation entry exists for a
-function, the @file{centos-art.sh} script informs that no
-documentation entry exists for such function and requests user to
-create it right at that time.
-
-Now that we have documented our function, it is time to translate its
-output messages to different languages. To translate specific
-functionality output messages to different languages we use the
-@code{locale} functionality (--- @strong{Removed}(pxref:trunk Scripts Bash Functions
-Locale) ---) of @file{centos-art.sh} script, just as the following command
-illustrates:
-
-@verbatim
-centos-art locale --edit
-@end verbatim
-
-@quotation
-@strong{Warning} To translate output messages in different languages,
-your system locale information ---as in @env{LANG} environment
-variable--- must be set to that locale you want to produce translated
-messages for. For example, if you want to produce translated messages
-for Spanish language, your system locale information must be set to
-@samp{es_ES.UTF-8}, or similar, first.
-@end quotation
-
-Well, it seems that our example is rather complete by now.
-
-In @code{greet} function example we've described so far, we only use
-@command{cli_printMessage} global function in action specific function
-definitions in order to print messages, but more interesting things
-can be achieved inside action specific function definitions. For
-example, if you pass a directory path as action value in second
-argument, you could retrive a list of files from therein, and process
-them. If the list of files turns too long or you just want to control
-which files to process, you could add the third argument in the form
-@option{--filter='regex'} and reduce the amount of files to process
-using a regular expression pattern.
-
-The @code{greet} function described in this section may serve you as
-an introduction to understand how specific functionalities work inside
-@file{centos-art.sh} script. With some of luck this introduction will
-also serve you as motivation to create your own @file{centos-art.sh}
-script specific functionalities.
-
-By the way, the @code{greet} functionality doesn't exist inside
-@file{centos-art.sh} script yet. Would you like to create it?
-
-@subsection Usage
-
-@subsubsection Global variables
-
-The following global variables of @file{centos-art.sh} script, are
-available for you to use inside specific functions:
-
-@defvar TEXTDOMAIN
-Default domain used to retrieve translated messages. This value is set
-in @file{initFunctions.sh} and shouldn't be changed.
-@end defvar
-
-@defvar TEXTDOMAINDIR
-Default directory used to retrieve translated messages. This value is
-set in @file{initFunctions.sh} and shouldn't be changed.
-@end defvar
-
-@defvar FUNCNAM
-Define function name.
-
-Function names associate sets of actions. There is one set of actions
-for each unique function name inside @file{centos-art.sh} script.
-
-Dunction names are passed as first argument in @file{centos-art.sh}
-command-line interface. For example, in the command @samp{centos-art
-render --entry=path/to/dir --filter=regex}, the @var{ACTION} passed to
-@file{centos-art.sh} script is @option{render}.
-
-When first argument is not provided, the @file{centos-art.sh} script
-immediatly ends its execution.
-@end defvar
-
-@defvar FUNCDIR
-@end defvar
-
-@defvar FUNCDIRNAME
-@end defvar
-
-@defvar FUNCSCRIPT
-@end defvar
-
-@defvar FUNCCONFIG
-@end defvar
-
-@defvar ACTIONNAM
-Define action name.
-
-Each action name identifies an specific action to perform, inside an
-specific function.
-
-Action name names aare passed as second argument in
-@file{centos-art.sh} command-line interface. For example, in the
-command @samp{centos-art render --entry=path/to/dir --filter=regex},
-the @var{ACTIONNAM} passed to @file{centos-art.sh} script is
-@option{--entry}.
-
-When second argument is not provided, the @file{centos-art.sh} script
-immediatly ends its execution.
-@end defvar
-
-@defvar ACTIONVAL
-Define action value.
-
-Action values are associated to just one action name. Action values
-contain the working copy entry over which its associated action will be
-performed in. Working copy entries can be files or directories inside
-the working copy.
-@end defvar
-
-@defvar REGEX
-Define regular expression used as pattern to build the list of files
-to process.
-
-By default, @var{REGEX} variable is set to @code{.+} to match all
-files.
-
-Functions that need to build a list of files to process use the option
-@option{--filter} to redefine @var{REGEX} variable default value, and
-so, control the amount of files to process.
-@end defvar
-
-@defvar ARGUMENTS
-Define optional arguments.
-
-Optional arguments, inside @file{centos-art.sh} script, are considered
-as all command-line arguments passed to @file{centos-art.sh} script,
-from third argument position on. For example, in the command
-@samp{centos-art render --entry=path/to/dir --filter=regex} , the
-optional arguments are from @samp{--filter=regex} argument on.
-
-Optional arguments are parsed using @command{getopt} command through
-the following base construction:
-
-@verbatim
-# Define short options we want to support.
-local ARGSS=""
-
-# Define long options we want to support.
-local ARGSL="filter:,to:"
-
-# Parse arguments using getopt(1) command parser.
-cli_doParseArguments
-
-# Reset positional parameters using output from (getopt) argument
-# parser.
-eval set -- "$ARGUMENTS"
-
-# Define action to take for each option passed.
-while true; do
- case "$1" in
- --filter )
- REGEX="$2"
- shift 2
- ;;
- --to )
- TARGET="$2"
- shift 2
- ;;
- * )
- break
- esac
-done
-@end verbatim
-
-Optional arguments provide support to command options inside
-@file{centos-art.sh} script. For instance, consider the Subversion
-(@command{svn}) command, where there are many options (e.g.,
-@option{copy}, @option{delete}, @option{move}, etc), and inside each
-option there are several modifiers (e.g., @samp{--revision},
-@samp{--message}, @samp{--username}, etc.) that can be combined one
-another in their short or long variants.
-
-The @var{ARGUMENTS} variable is used to store arguments passed from
-command-line for later use inside @file{centos-art.sh} script. Storing
-arguments is specially useful when we want to run a command with some
-specific options from them. Consider the following command:
-
-@verbatim
-centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
-@end verbatim
-
-In the above command, the @option{--message}, and @option{--username}
-options are specific to @command{svn copy} command. In such cases,
-options are not interpreted by @file{centos-art.sh} script itself.
-Instead, the @file{centos-art.sh} script uses @command{getopt} to
-retrive them and store them in the @var{ARGUMENTS} variable for later
-use, as described in the following command:
-
-@verbatim
-# Build subversion command to duplicate locations inside the
-# workstation.
-eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
-@end verbatim
-
-When @command{getopt} parses @var{ARGUMENTS}, we may use short options
-(e.g., @option{-m}) or long options (e.g., @option{--message}). When
-we use short options, arguments are separated by one space from the
-option (e.g., @option{-m 'This is a commit message.'}). When we use
-long options arguments are separated by an equal sign (@samp{=})
-(e.g., @option{--message='This is a commit message'}).
-
-In order for @command{getopt} to parse @var{ARGUMENTS} correctly, it
-is required to provide the short and long definition of options that
-will be passed or at least supported by the command performing the
-final action the function script exists for.
-
-As convenction, inside @file{centos-art.sh} script, short option
-definitions are set in the @var{ARGSS} variable; and long option
-definitions are set in the @var{ARGSL} variable.
-
-When you define short and long options, it may be needed to define
-which of these option arguments are required and which not. To define
-an option argument as required, you need to set one colon @samp{:}
-after the option definition (e.g., @option{-o m: -l message:}). On
-the other hand, to define an option argument as not required, you need
-to set two colons @samp{::} after the option definition (e.g.,
-@option{-o m:: -l message::}).
-@end defvar
-
-@defvar EDITOR
-Default text editor.
-
-The @file{centos-art.sh} script uses default text @env{EDITOR} to edit
-pre-commit subversion messages, translation files, configuration
-files, script files, and similar text-based files.
-
-If @env{EDITOR} environment variable is not set, @file{centos-art.sh}
-script uses @file{/usr/bin/vim} as default text editor. Otherwise, the
-following values are recognized by @file{centos-art.sh} script:
-
-@itemize
-@item @file{/usr/bin/vim}
-@item @file{/usr/bin/emacs}
-@item @file{/usr/bin/nano}
-@end itemize
-
-If no one of these values is set in @env{EDITOR} environment variable,
-@file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default.
-@end defvar
-
-@subsubsection Global functions
-
-Function scripts stored directly under
-@file{trunk/Scripts/Bash/Functions/} directory are used to define
-global functions. Global functions can be used inside action specific
-functionalities and or even be reused inside themselves. This section
-provides introductory information to global functions you can use
-inside @file{centos-art.sh} script.
-
-@defun cli_checkActionArguments
-Validate action value (@var{ACTIONVAL}) variable.
-
-The action value variable can take one of the following values:
-
-@enumerate
-@item Path to one directory inside the local working copy,
-@item Path to one file inside the local working copy,
-@end enumerate
-
-If another value different from that specified above is passed to
-action value variable, the @file{centos-art.sh} script prints an error
-message and ends script execution.
-@end defun
-
-@defun cli_checkFiles FILE [TYPE]
-Verify file existence.
-
-@code{cli_checkFiles} receives a @var{FILE} absolute path and performs
-file verification as specified in @var{TYPE}. When @var{TYPE} is not
-specified, @code{cli_checkFiles} verifies @var{FILE} existence, no
-matter what kind of file it be. If @var{TYPE} is specified, use one
-of the following values:
-
-@table @option
-@item d
-@itemx directory
-Ends script execution if @var{FILE} is not a directory.
-
-When you verify directories with cli_checkFiles, if directory doesn't
-exist, @file{centos-art.sh} script asks you for confirmation in order
-to create that directory. If you answer positively,
-@file{centos-art.sh} script creates that directory and continues
-script flows normally. Otherwise, if you answer negatively,
-@file{centos-art.sh} ends script execution with an error and
-documentation message.
-
-@item f
-@item regular-file
-Ends script execution if @var{FILE} is not a regular file.
-@item h
-@itemx symbolic-link
-Ends script execution if @var{FILE} is not a symbolic link.
-@item x
-@itemx execution
-Ends script execution if @var{FILE} is not executable.
-@item fh
-Ends script execution if @var{FILE} is neither a regular file nor a
-symbolic link.
-@item fd
-Ends script execution if @var{FILE} is neither a regular file nor a
-directory.
-@item isInWorkingCopy
-Ends script execution if @var{FILE} is not inside the working copy.
-@end table
-
-As default behaviour, if @var{FILE} passes all verifications,
-@file{centos-art.sh} script continues with its normal flow.
-@end defun
-
-@defun cli_commitRepoChanges [LOCATION]
-
-Syncronize changes between repository and working copy.
-
-The @code{cli_commitRepoChanges} function brings changes from the
-central repository down to the working copy---using @command{svn
-update}---, checks the working copy changes---using @command{svn
-status} command---, prints status report---using both @command{svn
-update} and @command{svn status} commands output, and finally, commits
-recent changes from the working copy up to the repository---using
-@command{svn commit} command---.
-
-Previous to commit the working copy changes up to the central
-repository, the @code{cli_commitRepoChanges} function asks you to
-verify changes---using @command{svn diff} command---, and later,
-another confirmation question is shown to be sure you really want to
-commit changes up to central repository.
-
-If @var{LOCATION} argument is not specified, the value of
-@var{ACTIONVAL} variable is used as reference instead.
-
-@float Figure, trunk/Scripts/Bash/Functions/cli_commitRepoChanges
-@verbatim
-----------------------------------------------------------------------
---> Bringing changes from the repository into the working copy
---> Checking changes in the working copy
-----------------------------------------------------------------------
-Added 0 file from the repository.
-Deleted 0 file from the repository.
-Updated 0 file from the repository.
-Conflicted 0 file from the repository.
-Merged 0 file from the repository.
-Modified 4 files from the working copy.
-Unversioned 0 file from the working copy.
-Deleted 0 file from the working copy.
-Added 0 file from the working copy.
-----------------------------------------------------------------------
-@end verbatim
-@caption{The @code{cli_commitRepoChanges} function output.}
-@end float
-
-Call the @code{cli_commitRepoChanges} function before or/and after
-calling functions that modify files or directories inside the working
-copy as you may need to.
-@end defun
-
-@defun cli_doParseArguments
-Redefine arguments (@var{ARGUMENTS}) global variable using
-@command{getopt} command output. For more information about how to use
-@code{cli_doParseArguments} function, see @var{ARGUMENTS} variable
-description above.
-@end defun
-
-@defun cli_doParseArgumentsReDef $@@
-Initialize/reset arguments (@var{ARGUMENTS}) global variable using
-positional parameters variable (@var{$@@}) as reference.
-
-When we work inside function definitions, positional parameters are
-reset to the last function definition positional parameters. If you
-need to redefine positional parameters from one specific function, you
-need to call @code{cli_doParseArgumentsReDef} with the positional
-parameters variable (@var{$@@}), set as first argument, to that
-specific function you want to redefine positional parameters at.
-@end defun
-
-@defun cli_getArguments
-
-Initialize function name (@var{FUNCNAM}), action name
-(@var{ACTIONNAM}), and action value (@var{ACTIONVAL}) global
-variables, using positional parameters passed in @var{$@@} variable.
-
-The @code{cli_getArguments} function is called from @code{cli.sh}
-function script, using @code{cli} function positional parameters
-(i.e., the positional parameters passed as arguments in the
-command-line) as first function argument.
-
-Once command-line positional parameters are accesible to
-@file{centos-art.sh} script execution evironment,
-@code{cli_getArguments} uses regular expression to retrive
-action variables from first and second argument. The first argument
-defines the value used as function name (@var{FUNCNAM}), and the
-second argument defines both values used as action name
-(@var{ACTIONNAM}) and action value (@var{ACTIONVAL}), respectively.
-
-The first argument is a word in lower case. This word specifies the
-name of the functionality you want to use (e.g., @samp{render} to
-render images, @samp{manual} to work on documentation, and so on.)
-
-The second argument has a long option style (e.g.,
-@samp{--option=value}). The @samp{--option} represents the action name
-(@var{ACTIONNAM}), and the characters inbetween the equal sign
-(@samp{=}) and the first space character, are considered as the action
-value (@var{ACTIONVAL}). In order to provide action values with space
-characters inbetween you need to enclose action value with quotes like
-in @samp{--option='This is long value with spaces inbetween'}.
-Generally, action values are used to specify paths over which the
-action name acts on.
-
-Once action related variables (i.e., @var{FUNCNAM}, @var{ACTIONNAM},
-and @var{ACTIONVAL}) are defined and validated,
-@code{cli_getArguments} shifts the positional arguments to remove the
-first two arguments passed (i.e., those used to retrive action related
-variables) and redefine the arguments (@var{ARGUMENTS}) global
-variable with the new positional parameters information.
-@end defun
-
-@defun cli_getFunctions
-Initialize funtionalities supported by @file{centos-art.sh} script.
-
-Functionalities supported by @file{centos-art.sh} script are organized
-in functionality directories under
-@file{trunk/Scripts/Bash/Functions/} directory. Each functionality
-directory stores function scripts to the functionality such directory
-was created for. Function scripts contain function definitions.
-Function definitions contain several commands focused on achieving one
-specific task only (i.e., the one such functionality was created for).
-
-In order for @file{centos-art.sh} script to recognize a functionality,
-such functionality needs to be stored under
-@file{trunk/Scripts/Bash/Functions/} in a directory written
-capitalized (i.e., the whole name is written in lowercase except the
-first character which is in uppercase). The directory where one
-specific functionality is stored is known as the @samp{functionality
-directory}.
-
-Inside each functionality directory, the functionalty itself is
-implemented through function scripts. Function scripts are organized
-in files independently one another and written in @samp{camelCase}
-format with the function name as prefix. Separation between prefix
-and description is done using underscore (@samp{_}) character.
-
-In order for @file{centos-art.sh} script to load functionalities
-correctly, function definition inside function scripts should be set
-using the @samp{function} reserved word, just as in the following
-example:
-
-@verbatim
-function prefix_doSomething {
-
- # Do something here...
-
-}
-@end verbatim
-
-The above function definition is just a convenction we use, in order
-to make identification of function names easier read and automate by
-@file{centos-art.sh} script initialization commands, once
-@file{centos-art.sh} script determines which functionality directory
-to use. Specifically, in order to initialize and export functions,
-@file{centos-art.sh} script executes all function scripts inside the
-functionality directory, and later @command{grep} on them using a
-regular expression pattern, where the @samp{function} reserved word is
-used as reference to retrive the function names and export them to
-@file{centos-art.sh} script execution environment, and so, make
-function definitions ---from function scripts inside the functionality
-directory--- available for further calls.
-
-If the functionality specified in the command-line first argument
-doesn't have a functionality directory, @file{centos-art.sh} script
-considers the functionality provided in the command-line as invalid
-functionality and immediatly stops script execution with an error
-message.
-
-In order to keep visual consistency among function scripts, please
-consider using the following function script design model as template
-for your own function scripts:
-
-@verbatim
-#!/bin/bash
-#
-# prefix_doSomething.sh -- This function illustrates function scripts
-# design model you can use to create your own function scripts inside
-# centos-art.sh script.
-#
-# Copyright (C) YEAR YOURFULLNAME
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-# USA.
-#
-# ----------------------------------------------------------------------
-# $Id$
-# ----------------------------------------------------------------------
-
-function prefix_doSomething {
-
- # Do something here...
-
-}
-@end verbatim
-@end defun
-
-@defun cli_getCountryCodes [FILTER]
-Output country codes supported by @file{centos-art.sh} script.
-
-The @code{cli_getCountryCodes} function outputs a list with country
-codes as defined in ISO3166 standard. When @var{FILTER} is provided,
-@code{cli_getCountryCodes} outputs country codes that match
-@var{FILTER} regular expression pattern.
-@end defun
-
-@defun cli_getCountryName [FILTER]
-Outputs country name supported by @file{centos-art.sh} script.
-
-The @code{cli_getCountryName} function reads one language locale code
-in the format LL_CC and outputs the name of its related country as in
-ISO3166. If filter is specified, @code{cli_getCountryName} returns the
-country name that matches the locale code specified in @var{FILTER},
-exactly.
-@end defun
-
-@defun cli_getCurrentLocale
-Output current locale used by @file{centos-art.sh} script.
-
-The @code{cli_getCurrentLocale} function uses @env{LANG} environment
-variable to build a locale pattern that is later applied to
-@code{cli_getLocales} function output in order to return the current
-locale that @file{centos-art.sh} script works with.
-
-The current locale information, returned by
-@code{cli_getCurrentLocale}, is output from more specific to less
-specific. For example, if @samp{en_GB} locale exists in
-@code{cli_getLocales} function output, the @samp{en_GB} locale would
-take precedence before @samp{en} locale.
-
-Locale precedence selection is quite important in order to define the
-locale type we use for message translations. For example, if
-@samp{en_GB} is used, we are also saying that the common language
-specification for English language (i.e., @samp{en}) is no longer
-used. Instead, we are using English non-common country-specific
-language specifications like @samp{en_AU}, @samp{en_BW}, @samp{en_GB},
-@samp{en_US}, etc., for message translations.
-
-Use @code{cli_getCurrentLocale} function to know what current locale
-information to use inside @file{centos-art.sh} script.
-@end defun
-
-@defun cli_getFilesList [LOCATION]
-Output list of files to process.
-
-The @code{cli_getFilesList} function uses @var{LOCATION} variable as
-source location to build a list of files just as specified by regular
-expression (@var{REGEX}) global variable. Essentially, what the
-@code{cli_getFilesList} function does is using @command{find} command
-to look for files in the location (@var{LOCATION}) just as posix-egrep
-regular expression (@var{REGEX}) specifies.
-
-If @var{LOCATION} is not specified when @code{cli_getFilesList}
-function is called, the action value (@var{ACTIONVAL}) global variable
-is used as location value instead.
-
-By default, if the regular expression (@var{REGEX}) global variable is
-not redefined after its first definition in the @code{cli} function,
-all files that match default regular expression value (i.e.,
-@samp{.+}) will be added to the list of files to process. Otherwise,
-if you redefine the regular expression global variable after its first
-definition in the @code{cli} function and before calling
-@code{cli_getFilesList} function, the last value you specifed is used
-instead.
-
-When you need to customize the regular expression (@var{REGEX}) global
-variable value inside a function, do not redefine the global variable
-(at least you be absolutly convinced you need to). Instead, set the
-regular expression global variable as @samp{local} to the function you
-need a customized regular expression value for. If we don't redefine
-the regular expression global variable as local to the function, or
-use another name for the regular expression variable (which is not
-very convenient in order to keep the amount of names to remember low),
-you may experiment undesired concantenation issues that make your
-regular expression to be something different from that you expect them
-to be, specially if the function where you are doing the variable
-redefinition is called several times during the same script execution.
-
-As result, the @code{cli_getFilesList} re-defines the value of
-@var{FILES} variable with the list of files the @command{find} command
-returned. As example, consider the following construction:
-
-@verbatim
-function prefix_doSomething {
-
- # Initialize the list of files to process.
- local FILES=''
-
- # Initialize location.
- local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default
-
- # Re-define regular expression to match scalable vector graphic
- # files only. Note how we use the global value of REGEX to build a
- # new local REGEX value here.
- local REGEX="${REGEX}.*\.(svgz|svg)"
-
- # Redefine list of files to process.
- cli_getFilesList $LOCATION
-
- # Process list of files.
- for FILE in $FILES;do
- cli_printMessages "$FILE" 'AsResponseLine'
- # Do something else here on...
- done
-
-}
-@end verbatim
-
-@end defun
-
-@defun cli_getLangCodes [FILTER]
-Outputs language codes supported by @file{centos-art.sh} script.
-
-@code{cli_getLangCodes} function outputs a list of language codes as
-defined in ISO639 standard. When @var{FILTER} is provided,
-@code{cli_getLangCodes} outputs language codes that match @var{FILTER}
-regular expression pattern.
-@end defun
-
-@defun cli_getLangName [FILTER]
-Outputs language names supported by @file{centos-art.sh} script.
-
-@code{cli_getLangName} function reads one language locale code in the
-format LL_CC and outputs the language related name as in ISO639. If
-filter is specified, @code{cli_getLangName} returns the language name
-that matches the locale code specified in @var{FILTER}, exactly.
-@end defun
-
-@defun cli_getLocales
-Output locale codes supported by @file{centos-art.sh} script.
-
-Occasionally, you use @code{cli_getLocales} function to add locale
-information in non-common country-specific language (@samp{LL_CC})
-format for those languages (e.g., @samp{bn_IN}, @samp{pt_BR}, etc.)
-which locale differences cannot be solved using common language
-specifications (@samp{LL}) into one unique common locale specification
-(e.g., @samp{bn}, @samp{pt}, etc.).
-@end defun
-
-@defun cli_getRepoName NAME TYPE
-Sanitate file names.
-
-Inside @file{centos-art.sh} script, specific functionalities rely both
-in @code{cli_getRepoName} and repository file system organization to
-achieve their goals. Consider @code{cli_getRepoName} function as
-central place to manage file name convenctions for other functions
-inside @file{centos-art.sh} script.
-
-@quotation
-@strong{Important} @code{cli_getRepoName} function doesn't verify file
-or directory existence, for that purpose use @code{cli_checkFiles}
-function instead.
-@end quotation
-
-The @var{NAME} variable contains the file name or directory name you
-want to sanitate.
-
-The @var{TYPE} variable specifies what type of sanitation you want to
-perform on @var{NAME}. The @var{TYPE} can be one of the following
-values:
-
-@table @option
-@item d
-@itemx directory
-Sanitate directory @var{NAME}s.
-@item f
-@item regular-file
-Sanitate regular file @var{NAME}s.
-@end table
-
-Use @code{cli_getRepoName} function to sanitate file names and
-directory names before their utilization.
-
-Use @code{cli_getRepoName} when you need to change file name
-convenctions inside @file{centos-art.sh} script.
-
-When we change file name convenctions inside @code{cli_getRepoName}
-what we are really changing is the way functions interpret repository
-file system organization. Notice that when we change a file name
-(e.g., a function name), it is necessary to update all files where
-such file name is placed on. This may require a massive substitution
-inside the repository, each time we change name convenctions in the
-repository (--- @strong{Removed}(pxref:trunk Scripts Bash Functions Path) ---, for more
-information).
-@end defun
-
-@defun cli_getRepoStatus [LOCATION]
-Request repository status.
-
-This function requests the status of a @var{LOCATION} inside the
-working copy using the @command{svn status} command and returns the
-first character in the output line, just as described in @command{svn
-help status}. If @var{LOCATION} is not a regular file or a directory,
-inside the working copy, the @file{centos-art.sh} script prints a
-message and ends its execution.
-
-Use this function to perform verifications based a repository
-@var{LOCATION} status.
-@end defun
-
-@defun cli_getTemporalFile @var{NAME}
-Output absolute path to temporal file @var{NAME}.
-
-The @code{cli_getTemporalFile} function uses @file{/tmp} directory as
-source location to store temporal files, the @file{centos-art.sh}
-script name, and a random identification string to let you run more
-than one @file{centos-art.sh} script simultaneously on the same user
-session. For example, due the following temporal file defintion:
-
-@verbatim
-cli_getTemporalFile $FILE
-@end verbatim
-
-If @var{FILE} name is @file{instance.svg} and the unique random string
-is @samp{f16f7b51-ac12-4b7f-9e66-72df847f12de}, the final temporal
-file, built from previous temporal file definition, would be:
-
-@verbatim
-/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
-@end verbatim
-
-When you use the @code{cli_getTemporalFile} function to create
-temporal files, be sure to remove temporal files created once you've
-ended up with them. For example, consider the following construction:
-
-@verbatim
-for FILE in $FILES;do
-
- # Initialize temporal instance of file.
- INSTANCE=$(cli_getTemporalFile $FILE)
-
- # Do something ...
-
- # Remove temporal instance of file.
- if [[ -f $INSTANCE ]];then
- rm $INSTANCE
- fi
-
-done
-@end verbatim
-
-Use the @code{cli_getTemporalFile} function whenever you need to
-create temporal files inside @file{centos-art.sh} script.
-@end defun
-
-@defun cli_getThemeName
-Output theme name.
-
-In order for @code{cli_getThemeName} function to extract theme name
-correctly, the @var{ACTIONVAL} variable must contain a directory path
-under @file{trunk/Identity/Themes/Motifs/} directory structure.
-Otherwise, @code{cli_getThemeName} returns an empty string.
-@end defun
-
-@defun cli_printMessage MESSAGE [FORMAT]
-Define standard output message definition supported by
-@file{centos-art.sh} script.
-
-When @var{FORMAT} is not specified, @code{cli_printMessage} outputs
-information just as it was passed in @var{MESSAGE} variable.
-Otherwise, @var{FORMAT} can take one of the following values:
-
-@table @option
-@item AsHeadingLine
-To print heading messages.
-@verbatim
-----------------------------------------------------------------------
-$MESSAGE
-----------------------------------------------------------------------
-@end verbatim
-
-@item AsWarningLine
-To print warning messages.
-@verbatim
-----------------------------------------------------------------------
-WARNING: $MESSAGE
-----------------------------------------------------------------------
-@end verbatim
-
-@item AsNoteLine
-To print note messages.
-@verbatim
-----------------------------------------------------------------------
-NOTE: $MESSAGE
-----------------------------------------------------------------------
-@end verbatim
-
-@item AsUpdatingLine
-To print @samp{Updating} messages on two-columns format.
-@verbatim
-Updating $MESSAGE
-@end verbatim
-
-@item AsRemovingLine
-To print @samp{Removing} messages on two-columns format.
-@verbatim
-Removing $MESSAGE
-@end verbatim
-
-@item AsCheckingLine
-To print @samp{Checking} messages on two-columns format.
-@verbatim
-Checking $MESSAGE
-@end verbatim
-
-@item AsCreatingLine
-To print @samp{Creating} messages on two-columns format.
-@verbatim
-Creating $MESSAGE
-@end verbatim
-
-@item AsSavedAsLine
-To print @samp{Saved as} messages on two-columns format.
-@verbatim
-Saved as $MESSAGE
-@end verbatim
-
-@item AsLinkToLine
-To print @samp{Linked to} messages on two-columns format.
-@verbatim
-Linked to $MESSAGE
-@end verbatim
-
-@item AsMovedToLine
-To print @samp{Moved to} messages on two-columns format.
-@verbatim
-Moved to $MESSAGE
-@end verbatim
-
-@item AsTranslationLine
-To print @samp{Translation} messages on two-columns format.
-@verbatim
-Translation $MESSAGE
-@end verbatim
-
-@item AsConfigurationLine
-To print @samp{Configuration} messages on two-columns format.
-@verbatim
-Configuration $MESSAGE
-@end verbatim
-
-@item AsResponseLine
-To print response messages on one-column format.
-@verbatim
---> $MESSAGE
-@end verbatim
-
-@item AsRequestLine
-To print request messages on one-column format. Request messages
-output messages with one colon (@samp{:}) and without trailing newline
-(@samp{\n}) at message end.
-@verbatim
-$MESSAGE:
-@end verbatim
-
-@item AsYesOrNoRequestLine
-To print @samp{yes or no} request messages on one-column format. If
-something different from @samp{y} is answered (when using
-@code{en_US.UTF-8} locale), script execution ends immediatly.
-
-@verbatim
-$MESSAGE [y/N]:
-@end verbatim
-
-When we use @file{centos-art.sh} script in a locale different from
-@code{en_US.UTF-8}, confirmation answer may be different from
-@samp{y}. For example, if you use @code{es_ES.UTF-8} locale, the
-confirmation question would look like:
-
-@verbatim
-$MESSAGE [s/N]:
-@end verbatim
-
-and the confirmation answer would be @samp{s}, as it is on Spanish
-@samp{sí} word.
-
-Definition of which confirmation word to use is set on translation
-messages for your specific locale information. --- @strong{Removed}(xref:trunk Scripts
-Bash Functions Locale) ---, for more information about locale-specific
-translation messages.
-
-@item AsToKnowMoreLine
-To standardize @samp{to know more, run the following command:}
-messages. When the @option{AsToKnowMoreLine} option is used, the
-@var{MESSAGE} value should be set to @code{"$(caller)"}. @code{caller}
-is a Bash builtin that returns the context of the current subroutine
-call. @option{AsToKnowMoreLine} option uses @code{caller} builtin
-output to build documentation entries dynamically.
-
-@verbatim
-----------------------------------------------------------------------
-To know more, run the following command:
-centos-art manual --read='path/to/dir'
-----------------------------------------------------------------------
-@end verbatim
-
-Use @option{AsToKnowMoreLine} option after errors and for intentional
-script termination.
-
-@item AsRegularLine
-To standardize regular messages on one-column format.
-
-When @var{MESSAGE} contains a colon inside (e.g., @samp{description:
-message}), the @code{cli_printMessage} function outputs @var{MESSAGE}
-on two-columns format.
-@end table
-
-Use @code{cli_printMessage} function whenever you need to output
-information from @file{centos-art.sh} script.
-
-@quotation
-@strong{Tip} To improve two-columns format, change the following file:
-@verbatim
-trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
-@end verbatim
-@end quotation
-@end defun
-
-@subsubsection Specific functions
-
-The following specific functions of @file{centos-art.sh} script, are
-available for you to use:
-
-@menu
-@comment --- Removed(* trunk Scripts Bash Functions Html::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Locale::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Manual::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Path::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Render::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Render Config::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Shell::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Svg::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Verify::) ---
-@end menu
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Locale::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Help.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Help.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Help.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Html.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Html.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Html.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Locale.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Locale.texi
deleted file mode 100644
index bf264c9..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Locale.texi
+++ /dev/null
@@ -1,85 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-This command looks for @samp{.sh} files inside Bash directory and
-extracts translatable strings from files, using @command{xgettext}
-command, in order to create a portable object template
-(@file{centos-art.sh.pot}) file for them.
-
-With the @file{centos-art.sh.pot} file up to date, the
-@command{centos-art} command removes the temporal list of files sotred
-inside @file{/tmp} directory and checks the current language of your
-user's session to create a portable object file for it, in the
-location @file{$CLI_LANG/$CLI_LANG.po}.
-
-The @var{CLI_LANG} variable discribes the locale language used to
-output messages inside @command{centos-art} command. The locale
-language used inside @command{centos-art} command is taken from the
-@env{LANG} environment variable. The @var{CLI_LANG} variable has the
-@samp{LL_CC} format, where @samp{LL} is a language code from the
-ISO-639 standard, and @samp{CC} a country code from the ISO-3166
-standard.
-
-The @env{LANG} environment variable is set when you do log in to your
-system. If you are using a graphical session, change language to your
-native language and do login. That would set and exoprt the @env{LANG}
-environment variable to the correct value. On the other side, if you
-are using a text session edit your @file{~/.bash_profile} file to set
-and export the @env{LANG} environment variable to your native locale
-as defines the @command{locale -a} command output; do logout, and do
-login again.
-
-At this point, the @env{LANG} environment variable has the appropriate
-value you need, in order to translate @command{centos-art.sh} messages
-to your native language (the one set in @env{LANG} environment
-variable).
-
-With the @file{$CLI_LANG/$CLI_LANG.po} file up to date, the
-@command{centos-art} opens it for you to update translation strings.
-The @command{centos-art} command uses the value of @var{EDITOR}
-environment variable to determine your favorite text editor. If no
-value is defined on @var{EDITOR}, the @file{/usr/bin/vim} text editor
-is used as default.
-
-When you finishd PO file edition and quit text editor, the
-@command{centos-art} command creates the related machine object in the
-location @file{$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo}.
-
-At this point, all translations you made in the PO file should be
-available to your language when runing @command{centos-art.sh} script.
-
-In order to make the @command{centos-art.sh} internationalization, the
-@command{centos-art.sh} script was modified as described in the
-@command{gettext} info documentation (@command{info gettext}). You
-can find such modifications in the following files:
-
-@itemize
-@item @file{trunk/Scripts/Bash/initFunctions.sh}
-@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh}
-@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh}
-@end itemize
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@table @samp
-@item centos-art locale --edit
-Use this command to translate command-line interface output messages
-in the current system locale you are using (as specified in @env{LANG}
-environment variable).
-@item centos-art locale --list
-Use this command to see the command-line interface locale report.
-@end table
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Manual.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Manual.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Manual.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Path.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Path.texi
deleted file mode 100644
index a7c6c55..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Path.texi
+++ /dev/null
@@ -1,327 +0,0 @@
-@subsection Goals
-
-This section exists to organize files related to @code{path}
-functiontionality. The @code{path} functionality standardizes
-movement, syncronization, branching, tagging, and general file
-maintainance inside the repository.
-
-@subsection Description
-
-@emph{''CentOS like trees, has roots, trunk, branches, leaves and
-flowers. Day by day they work together in freedom, ruled by the laws
-of nature and open standards, to show the beauty of its existence.''}
-
-@subsubsection Repository layout
-
-The repository layout describes organization of files and directories
-inside the repository. The repository layout provides the standard
-backend required for automation scripts to work correctly. If such
-layout changes unexpectedly, automation scripts may confuse themselves
-and stop doing what we expect from them to do.
-
-As convenction, inside CentOS Artwork Repository, we organize files
-and directories related to CentOS corporate visual identity under
-three top level directories named: @file{trunk/}, @file{branches/},
-and @file{tags/}.
-
-The @file{trunk/} directory (@pxref{trunk}) organizes the main
-development line of CentOS corporate visual identity. Inside
-@file{trunk/} directory structure, the CentOS corporate visual
-identity concepts are implemented using directories. There is one
-directory level for each relevant concept inside the repository. The
-@file{trunk/} directory structure is mainly used to perform
-development tasks related to CentOS corporate visual identity.
-
-The @file{branches/} directory (@pxref{branches}) oranizes parallel
-development lines to @file{trunk/} directory. The @file{branches/}
-directory is used to set points in time where develpment lines are
-devided one from another taking separte and idependent lives that
-share a common past from the point they were devided on. The
-@file{branches/} directory is mainly used to perform quality assurance
-tasks related to CentOS corporate visual identity.
-
-The @file{tags/} directory (@pxref{tags}) organizes parallel frozen
-lines to @file{branches/} directory. The parallel frozen lines are
-immutable, nothing change inside them once they has been created. The
-@file{tags/} directory is mainly used to publish final releases of
-CentOS corporate visual identity.
-
-The CentOS Artwork Repository layout is firmly grounded on a
-Subversion base. Subversion (@url{http://subversion.tigris.org}) is a
-version control system, which allows you to keep old versions of files
-and directories (usually source code), keep a log of who, when, and
-why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a
-single copy of the master sources. This copy is called the source
-``repository''; it contains all the information to permit extracting
-previous versions of those files at any time.
-
-@subsubsection Repository name convenctions
-
-Repository name convenctions help us to maintain consistency of names
-inside the repository.
-
-Repository name convenctions are applied to files and directories
-inside the repository layout. As convenction, inside the repository
-layout, file names are all written in lowercase
-(@samp{01-welcome.png}, @samp{splash.png}, @samp{anaconda_header.png},
-etc.) and directory names are all written capitalized (e.g.,
-@samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower},
-etc.).
-
-Repository name convenctions are implemented inside the
-@code{cli_getRepoName} function of @file{centos-art.sh} script. With
-@code{cli_getRepoName} function we reduce the amount of commands and
-convenctions to remember, concentrating them in just one single place
-to look for fixes and improvements.
-
-@subsubsection Repository work flow
-
-Repository work flow describes the steps and time intervals used to
-produce CentOS corporate visual identity inside CentOS Artwork
-Repository.
-
-To illustrate repository work flow let's consider themes' development
-cycle.
-
-Initially, we start working themes on their trunk development line
-(e.g., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we
-organize information that cannot be produced automatically (i.e.,
-background images, concepts, color information, screenshots, etc.).
-
-Later, when theme trunk development line is considered ``ready'' for
-implementation (e.g., all required backgrounds have been designed),
-we create a branch for it (e.g.,
-@file{branches/Identity/Themes/Motifs/TreeFlower/1/}). Once the
-branch has been created, we forget that branch and continue working
-the trunk development line while others (e.g., an artwork quality
-assurance team) test the new branch for tunning it up.
-
-Once the branch has been tunned up, and considered ``ready'' for
-release, it is freezed under @file{tags/} directory (e.g.,
-@file{tags/Identity/Themes/Motifs/TreeFower/1.0/}) for packagers,
-webmasters, promoters, and anyone who needs images from that CentOS
-theme the tag was created for.
-
-Both branches and tags, inside CentOS Artwork Repository, use
-numerical values to identify themselves under the same location.
-Branches start at one (i.e., @samp{1}) and increment one unit for each
-branch created from the same trunk development line. Tags start at
-zero (i.e., @samp{0}) and increment one unit for each tag created from
-the same branch development line.
-
-@quotation
-@strong{Convenction} Do not freeze trunk development lines using tags
-directly. If you think you need to freeze a trunk development line,
-create a branch for it and then freeze that branch instead.
-@end quotation
-
-The trunk development line may introduce problems we cannot see
-immediatly. Certainly, the high changable nature of trunk development
-line complicates finding and fixing such problems. On the other hand,
-the branched development lines provide a more predictable area where
-only fixes/corrections to current content are commited up to
-repository.
-
-If others find and fix bugs inside the branched development line, we
-could merge such changes/experiences back to trunk development line
-(not visversa) in order for future branches, created from trunk, to
-benefit.
-
-Time intervals used to create branches and tags may vary, just as
-different needs may arrive. For example, consider the release schema
-of CentOS distribution: one major release every 2 years, security
-updates every 6 months, support for 7 years long. Each time a CentOS
-distribution is released, specially if it is a major release, there is
-a theme need in order to cover CentOS distribution artwork
-requirements. At this point, is where CentOS Artwork Repository comes
-up to scene.
-
-Before releasing a new major release of CentOS distribution we create
-a branch for one of several theme development lines available inside
-the CentOS Artwork Repository, perform quality assurance on it, and
-later, freeze that branch using tags. Once a the theme branch has been
-frozen (under @file{tags/} directory), CentOS Packagers (the persons
-whom build CentOS distribution) can use that frozen branch as source
-location to fulfill CentOS distribution artwork needs. The same
-applies to CentOS Webmasters (the persons whom build CentOS websites),
-and any other visual manifestation required by the project.
-
-@subsubsection Parallel directories
-
-Inside CentOS Artwork Repository, parallel directories are simple
-directory entries built from a common parent directory and placed in a
-location different to that, the common parent directory is placed on.
-Parallel directories are useful to create branches, tags,
-translations, documentation, pre-rendering configuration script, and
-similar directory structures.
-
-Parallel directories take their structure from one unique parent
-directory. Inside CentOS Artwork Repository, this unique parent
-directory is under @file{trunk/Identity} location. The
-@file{trunk/Identity} location must be considered the reference for
-whatever information you plan to create inside the repository.
-
-In some circumstances, parallel directories may be created removing
-uncommon information from their paths. Uncommon path information
-refers to those directory levels in the path which are not common for
-other parallel directories. For example, when rendering
-@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory
-structure, the @file{centos-art.sh} script removes the
-@file{Motifs/TreeFlower/} directory levels from path, in order to
-build the parallel directory used to retrived translations, and
-pre-rendering configuration scripts required by @code{render}
-functionality.
-
-Another example of parallel directory is the documentation structure
-created by @code{manual} functionality. This time,
-@file{centos-art.sh} script uses parallel directory information with
-uncommon directory levels to build the documentation entry required by
-Texinfo documentation system, inside the repository.
-
-Othertimes, parallel directories may add uncommon information to their
-paths. This is the case we use to create branches and tags. When we
-create branches and tags, a numerical identifier is added to parallel
-directory structure path. The place where the numerical identifier is
-set on is relevant to corporate visual identity structure and should
-be carefully considered where it will be.
-
-When one parent directory changes, all their related parallel
-directories need to be changed too. This is required in order for
-parallel directories to retain their relation with the parent
-directory structure. In the other hand, parallel directories should
-never be modified under no reason but to satisfy the relation to their
-parent directory structure. Liberal change of parallel directories
-may suppresses the conceptual idea they were initially created for;
-and certainly, things may stop working the way they should do.
-
-@subsubsection Syncronizing path information
-
-Parallel directories are very useful to keep repository organized but
-introduce some complications. For instance, consider what would
-happen to functionalities like @code{manual} (@samp{trunk Scripts Bash
-Functions Manual}) that rely on parent directory structures to create
-documentation entries (using parallel directory structures) if one of
-those parent directory structures suddenly changes after the
-documentation entry has been already created for it?
-
-In such cases, functionalities like @code{manual} may confuse
-themselves if path information is not updated to reflect the relation
-with its parent directory. Such functionalities work with parent
-directory structure as reference; if a parent directory changes, the
-functionalities dont't even note it because they work with the last
-parent directory structure available in the repository, no matter what
-it is.
-
-In the specific case of documentation (the @code{manual}
-functionality), the problem mentioned above provokes that older parent
-directories, already documented, remain inside documentation directory
-structures as long as you get your hands into the documentation
-directory structure (@file{trunk/Manuals}) and change what must be
-changed to match the new parent directory structure.
-
-There is no immediate way for @code{manual}, and similar
-functionalities that use parent directories as reference, to know when
-and how directory movements take place inside the repository. Such
-information is available only when the file movement itself takes
-place inside the repository. So, is there, at the moment of moving
-files, when we need to syncronize parallel directories with their
-unique parent directory structure.
-
-@quotation
-@strong{Warning} There is not support for URL reference inside
-@file{centos-art.sh} script. The @file{centos-art.sh} script is
-designed to work with local files inside the working copy only.
-@end quotation
-
-As CentOS Artwork Repository is built over a version control system,
-file movements inside the repository are considered repository
-changes. In order for these repository changes to be versioned, we
-need to, firstly, add changes into the version control system, commit
-them, and later, perform movement actions using version control system
-commands. This configuration makes possible for everyone to know about
-changes details inside the repository; and if needed, revert or update
-them back to a previous revision.
-
-Finally, once all path information has been corrected, it is time to
-take care of information inside the files. For instance, considere
-what would happen if you make a reference to a documentation node, and
-later the documentation node you refere to is deleted. That would make
-Texinfo to produce error messages at export time. So, the
-@file{centos-art.sh} script needs to know when such changes happen, in
-a way they could be noted and handled without producing errors.
-
-@subsubsection What is the right place to store it?
-
-Occasionly, you may find that new corporate visual identity components
-need to be added to the repository. If that is your case, the first
-question you need to ask yourself, before start to create directories
-blindly all over, is: What is the right place to store it?
-
-The CentOS Community different free support vains (see:
-@url{http://wiki.centos.org/GettingHelp}) are the best place to find
-answers to your question, but going there with hands empty is not good
-idea. It may give the impression you don't really care about. Instead,
-consider the following suggestions to find your own comprehension and
-so, make your propositions based on it.
-
-When we are looking for the correct place to store new files, to bear
-in mind the corporate visual identity structure used inside the CentOS
-Artwork Repository (@pxref{trunk Identity}) would be probaly the best
-advice we could offer, the rest is just matter of choosing appropriate
-names. To illustrate this desition process let's consider the
-@file{trunk/Identity/Themes/Motifs/TreeFlower} directory as example.
-It is the trunk development line of @emph{TreeFlower} artistic motif.
-Artistic motifs are considered part of themes, which in turn are
-considered part of CentOS corporate visual identity.
-
-When building parent directory structures, you may find that reaching
-an acceptable location may take some time, and as it uses to happen
-most of time; once you've find it, that may be not a definite
-solution. There are many concepts that you need to play with, in
-order to find a result that match the conceptual idea you try to
-implement in the new directory location. To know which these concepts
-are, split the location in words and read its documentation entry from
-less specific to more specific.
-
-For example, the @file{trunk/Identity/Themes/Motifs/TreeFlower}
-location evolved through several months of contant work and there is
-no certain it won't change in the future, even it fixes quite well the
-concept we are trying to implement. The concepts used in
-@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} location are
-described in the following commands, respectively:
-
-@verbatim
-centos-art manual --read=turnk/
-centos-art manual --read=turnk/Identity/
-centos-art manual --read=turnk/Identity/Themes/
-centos-art manual --read=turnk/Identity/Themes/Motifs/
-centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
-@end verbatim
-
-Other location concepts can be found similary as we did above, just
-change the location we used above by the one you are trying to know
-concepts for.
-
-@subsection Usage
-
-@table @command
-@item centos-art path --copy='SRC' --to='DST'
-
-Copy @option{SRC} to @option{DST} and schedule @option{DST} for
-addition (with history). In this command, @file{SRC} and @file{DST}
-are both working copy (WC) entries.
-
-@item centos-art path --delete='SRC'
-
-Delete @option{DST}. In order for this command to work the file or
-directory you intend to delete should be under version control first.
-In this command, @file{SRC} is a working copy (WC) entry.
-
-@end table
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render.texi
deleted file mode 100644
index 7dfe2c5..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render.texi
+++ /dev/null
@@ -1,736 +0,0 @@
-The @code{render} functionality exists to produce both identity and
-translation files on different levels of information (i.e., different
-languages, release numbers, architectures, etc.).
-
-The @code{render} functionality relies on ``renderable directory
-structures'' to produce files. Renderable directory structures can be
-either ``identity directory structures'' or ``translation directory
-structures'' with special directories inside.
-
-@subsection Renderable identity directory structures
-
-Renderable identity directory structures are the starting point of
-identity rendition. Whenever we want to render a component of CentOS
-corporate visual identity, we need to point @file{centos-art.sh} to a
-renderable identity directory structure. If such renderable identity
-directory structure doesn't exist, then it is good time to create it.
-
-Inside the working copy, one renderable identity directory structures
-represents one visual manifestation of CentOS corporate visual
-identity, or said differently, each visual manifestation of CentOS
-corporate visual identity should have one renderable identity
-directory structure.
-
-Inside renderable identity directory structures, @file{centos-art.sh}
-can render both image-based and text-based files. Specification of
-whether a renderable identity directory structure produces image-based
-or text-based content is a configuration action that takes place in
-the pre-rendition configuration script of that renderable identity
-directory structure.
-
-Inside renderable identity directory structures, content production is
-organized in different configurations. A content production
-configuration is a unique combination of the components that make an
-identity directory structure renderable. One content production
-configuration does one thing only (e.g., to produce untranslated
-images), but it can be extended (e.g., adding translation files) to
-achieve different needs (e.g., to produce translated images).
-
-@subsubsection Design template without translation
-
-The design template without translation configuration is based on a
-renderable identity directory structure with an empty translation
-directory structure. In this configuration, one design template
-produces one untranslated file. Both design templates and final
-untranslated files share the same file name, but they differ one
-another in file-type and file-extension.
-
-For example, to produce images without translations (there is no much
-use in producing text-based files without translations), consider the
-following configuration:
-
-@table @strong
-@item One renderable identity directory structure:
-
-In this example we used @file{Identity/Path/To/Dir} as the identity
-component we want to produce untranslated images for. Identity
-components can be either under @file{trunk/} or @file{branches/}
-directory structure.
-
-The identity component (i.e., @file{Identity/Path/To/Dir}, in this
-case) is also the bond component we use to connect the identity
-directory structures with their respective auxiliar directories (i.e.,
-translation directory structres and pre-rendition configuration
-structures). The bond component is the path convenction that
-@file{centos-art.sh} uses to know where to look for related
-translations, configuration scripts and whatever auxiliar thing a
-renderable directory structure may need to have.
-
-@verbatim
- | The bond component
- |----------------->|
-trunk/Identity/Path/To/Dir <-- Renderable identity directory structure.
-|-- Tpl <-- Design template directory.
-| `-- file.svg <-- Design template file.
-`-- Img <-- Directory used to store final files.
- `-- file.png <-- Final image-based file produced from
- design template file.
-@end verbatim
-
-Inside design template directory, design template files are based on
-@acronym{SVG,Scalable Vector Graphics} and use the extension
-@code{.svg}. Design template files can be organized using several
-directory levels to create a simple but extensible configuration,
-specially if translated images are not required.
-
-In order for @acronym{SVG,Scalable Vector Graphics} files to be
-considered ``design template'' files, they should be placed under the
-design template directory and to have set a @code{CENTOSARTWORK}
-object id inside.
-
-The @code{CENTOSARTWORK} word itself is a convenction name we use to
-define which object/design area, inside a design template, the
-@file{centos-art.sh} script will use to export as
-@acronym{PNG,Portable Network Graphic} image at rendition time.
-Whithout such object id specification, the @file{centos-art.sh} script
-cannot know what object/design area you (as designer) want to export
-as @acronym{PNG,Portable Network Graphic} image file.
-
-@quotation
-@strong{Note} At rendition time, the content of @file{Img/} directory
-structure is produced by @file{centos-art.sh} automatically.
-@end quotation
-
-When a renderable identity directory structure is configured to
-produce image-based content, @file{centos-art.sh} produces
-@acronym{PNG,Portable Network Graphics} files with the @code{.png}
-extension. Once the base image format has been produced, it is
-possible for @file{centos-art.sh} to use it in order to automatically
-create other image formats that may be needed (--- @strong{Removed}(pxref:trunk Scripts
-Bash Functions Render Config) ---).
-
-Inside the working copy, you can find an example of ``design template
-without translation'' configuration at @file{trunk/Identity/Models/}.
-
-@xref{trunk Identity}, for more information.
-
-@item One translation directory structure:
-
-In order for an identity entry to be considered an identity renderable
-directory structure, it should have a translation entry. The content
-of the translation entry is relevant to determine how to process the
-identity renderable directory entry.
-
-If the translation entry is empty (i.e., there is no file inside it),
-@file{centos-art.sh} interprets the identity renderable directory
-structure as a ``design templates without translation'' configuration.
-
-@verbatim
- | The bond component
- |----------------->|
-trunk/Translations/Identity/Path/To/Dir
-`-- (empty)
-@end verbatim
-
-If the translation entry is not empty, @file{centos-art.sh} can
-interpret the identity renderable directory structure as one of the
-following configurations: ``design template with translation
-(one-to-one)'' or ``design template with translation (optimized)''.
-Which one of these configurations is used depends on the value
-assigned to the matching list (@var{MATCHINGLIST}) variable in the
-pre-rendition configuration script of the renderable identity
-directory structure we are producing images for.
-
-If the matching list variable is empty (as it is by default), then
-``design template with translation (one-to-one)'' configuration is
-used. In this configuration it is required that both design templates
-and translation files have the same file names. This way, @emph{one}
-translation files is applied to @emph{one} design template, to produce
-@emph{one} translated image.
-
-If the matching list variable is not empty (because you redefine it in
-the pre-rendition configuration script), then ``design template with
-translation (optimized)'' configuration is used instead. In this
-configuration, design templates and translation files don't need to
-have the same names since such name relationship between them is
-specified in the matching list properly.
-
---- @strong{Removed}(xref:trunk Translations) ---, for more information.
-
-@item One pre-rendition configuration script:
-
-In order to make an identity directory structure renderable, a
-pre-rendition configuration script should exist for it. The
-pre-rendition configuration script specifies what type of rendition
-does @file{centos-art.sh} will perform over the identity directory
-structure and how does it do that.
-
-@verbatim
- | The bond component
- |----------------->|
-trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-@end verbatim
-
-In this configuration the pre-rendition configuration script
-(@file{render.conf.sh}) would look like the following:
-
-@verbatim
-function render_loadConfig {
-
- # Define rendition actions.
- ACTIONS[0]='BASE:renderImage'
-
-}
-@end verbatim
-
-Since translation directory structure is empty, @file{centos-art.sh}
-assumes a ``design template without translation'' configuration to
-produce untranslated images.
-
-To produce untranslated images, @file{centos-art.sh} takes one design
-template and creates one temporal instance from it. Later,
-@file{centos-art.sh} uses the temporal design template instance as
-source file to export the final untranslated image. The action of
-exporting images from @acronym{SVG,Scalable Vector Graphics} to
-@acronym{PNG,Portable Network Graphics} is possible thanks to
-Inkscape's command-line interface and the @code{CENTOSARTWORK} object
-id we previously set inside design templates.
-
-@verbatim
-centos-art.sh render --identity=trunk/Identity/Path/To/Dir
--------------------------------------------------
-0 | Execute centos-art.sh on renderable identity directory structure.
---v----------------------------------------------
-trunk/Identity/Path/To/Dir/Tpl/file.svg
--------------------------------------------------
-1 | Create instance from design template.
---v----------------------------------------------
-/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
--------------------------------------------------
-2 | Render untranslated image from design template instance.
---v----------------------------------------------
-trunk/Identity/NewDir/Img/file.png
--------------------------------------------------
-3 | Remove design template instance.
-@end verbatim
-
-Finally, when the untranslated image has been created, the temporal
-design template instance is removed. At this point,
-@file{centos-art.sh} takes the next design template and repeats the
-whole production flow once again (design template by design template),
-until all design templates be processed.
-
---- @strong{Removed}(xref:trunk Scripts Bash Functions Render Config) ---, for more
-information.
-@end table
-
-@subsubsection Design template with translation (one-to-one)
-
-Producing untranslated images is fine in many cases, but not always.
-Sometimes it is required to produce images in different languages and
-that is something that untrasnlated image production cannot achieve.
-However, if we fill its empty translation entry with translation files
-(one for each design template) we extend the production flow from
-untranslated image production to translated image production.
-
-In order for @file{centos-art.sh} to produce images correctly, each
-design template should have one translation file and each translation
-file should have one design template. Otherwise, if there is a
-missing design template or a missing translation file,
-@file{centos-art.sh} will not produce the final image related to the
-missing component.
-
-In order for @file{centos-art.sh} to know which is the relation
-between translation files and design templates the translation
-directory structure is taken as reference. For example, the
-@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation
-file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design
-template, but it doesn't match
-@file{trunk/Identity/Path/To/Dir/File.svg} or
-@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or
-@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design
-templates.
-
-The pre-rendition configuration script used to produce untranslated
-images is the same we use to produce translated images. There is no
-need to modify it. So, as we are using the same pre-rendition
-configuration script, we can say that translated image production is
-somehow an extended/improved version of untranslated image production.
-
-@quotation
-@strong{Note} If we use no translation file in the translation entry
-(i.e., an empty directory), @file{centos-art.sh} assumes the
-untranslated image production. If we fill the translation entry with
-translation files, @file{centos-art.sh} assumes the translated image
-production.
-@end quotation
-
-To produce final images, @file{centos-art.sh} applies one translation
-file to one design template and produce a translated design template
-instance. Later, @file{centos-art.sh} uses the translated template
-instance to produce the translated image. Finally, when the translated
-image has been produced, @file{centos-art.sh} removes the translated
-design template instance. This production flow is repeated for each
-translation file available in the translatio entry.
-
-@verbatim
-centos-art.sh render --identity=trunk/Identity/Path/To/Dir
--------------------------------------------------
-0 | Execute centos-art.sh on directory structure.
---v----------------------------------------------
-trunk/Translations/Identity/Path/To/Dir/file.sed
--------------------------------------------------
-1 | Apply translation to design template.
---v----------------------------------------------
-trunk/Identity/Path/To/Dir/Tpl/file.svg
--------------------------------------------------
-2 | Create design template instance.
---v----------------------------------------------
-/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
--------------------------------------------------
-3 | Render PNG image from template instance.
---v----------------------------------------------
-trunk/Identity/NewDir/Img/file.png
--------------------------------------------------
-4 | Remove design template instance.
-@end verbatim
-
-@subsubsection Design template with translation (optimized)
-
-Producing translated images satisfies almost all our production images
-needs, but there is still a pitfall in them. In order to produce
-translated images as in the ``one-to-one'' configuration describes
-previously, it is required that one translation file has one design
-template. That's useful in many cases, but what would happen if we
-need to apply many different translation files to the same design
-template? Should we have to duplicate the same design template file
-for each translation file, in order to satisfy the ``one-to-one''
-relation? What if we need to assign translation files to design
-templates arbitrarily?
-
-Certenly, that's something the ``one-to-one'' configuration cannot
-handle. So, that's why we had to ``optimize'' it. The optimized
-configuration consists on using a matching list (@var{MATCHINGLIST})
-variable that specifies the relationship between translation files and
-design templates in an arbitrary way. Using such matching list between
-translation files and design templates let us use as many assignment
-combinations as translation files and design templates we are working
-with.
-
-The @var{MATCHINGLIST} variable is set in the pre-rendition
-configuration script of the component we want to produce images for.
-By default, the @var{MATCHINGLIST} variable is empty which means no
-matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a
-value different to empty value then, @file{centos-art.sh} interprets
-the matching list in order to know how translation files are applied
-to design templates.
-
-For example, consider the following configuration:
-
-@table @strong
-@item One entry under @file{trunk/Identity/}:
-
-In this configuration we want to produce three images using a
-paragraph-based style, controlled by @file{paragraph.svg} design
-template; and one image using a list-based style, controlled by
-@file{list.svg} design template.
-
-@verbatim
-trunk/Identity/Path/To/Dir
-|-- Tpl
-| |-- paragraph.svg
-| `-- list.svg
-`-- Img
- |-- 01-welcome.png
- |-- 02-donate.png
- |-- 03-docs.png
- `-- 04-support.png
-@end verbatim
-
-@item One entry under @file{trunk/Translations/}:
-
-In order to produce translated images we need to have one translation
-file for each translated image we want to produce. Notice how
-translation names do match final image file names, but how translation
-names do not match design template names. When we use matching list
-there is no need for translation files to match the names of design
-templates, such name relation is set inside the matching list itself.
-
-@verbatim
-trunk/Translations/Identity/Path/To/Dir
-|-- 01-welcome.sed
-|-- 02-donate.sed
-|-- 03-docs.sed
-`-- 04-support.sed
-@end verbatim
-
-@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}:
-
-In order to produce different translated images using specific design
-templates, we need to specify the relation between translation files
-and design templates in a way that @file{centos-art.sh} could know
-exactly what translation file to apply to what design template. This
-relation between translation files and design templates is set using
-the matching list @var{MATCHINGLIST} variable inside the pre-rendition
-configuration script of the component we want to produce images for.
-
-@verbatim
-trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-@end verbatim
-
-In this configuration the pre-rendition configuration script
-(@file{render.conf.sh}) would look like the following:
-
-@verbatim
-function render_loadConfig {
-
- # Define rendition actions.
- ACTIONS[0]='BASE:renderImage'
-
- # Define matching list.
- MATCHINGLIST="\
- paragraph.svg:\
- 01-welcome.sed\
- 02-donate.sed\
- 04-support.sed
- list.svg:\
- 03-docs.sed
- "
-
-}
-@end verbatim
-
-As result, @file{centos-art.sh} will produce @file{01-welcome.png},
-@file{02-donate.png} and @file{04-support.png} using the
-paragraph-based design template, but @file{03-docs.png} using the
-list-based design template.
-@end table
-
-@subsubsection Design template with translation (optimized+flexibility)
-
-In the production models we've seen so far, there are design templates
-to produce untranslated images and translation files which combiend
-with design templates produce translated images. That may seems like
-all our needs are covered, doesn't it? Well, it @emph{almost} does.
-
-Generally, we use design templates to define how final images will
-look like. Generally, each renderable directory structure has one
-@file{Tpl/} directory where we organize design templates for that
-identity component. So, we can say that there is only one unique
-design template definition for each identity component; or what is the
-same, said differently, identity components can be produced in one way
-only, the way its own design template directory specifies. This is
-not enough for theme production. It is a limitation, indeed.
-
-Initially, to create one theme, we created one renderable directory
-structure for each theme component. When we found ourselves with many
-themes, and components inside them, it was obvious that the same
-design model was duplicated inside each theme. As design models were
-independently one another, if we changed one theme's design model,
-that change was useless to other themes. So, in order to reuse design
-model changes, we unified design models into one common directory
-structure.
-
-With design models unified in a common structure, another problem rose
-up. As design models also had the visual style of theme components,
-there was no difference between themes, so there was no apparent need
-to have an independent theme directory structure for each different
-theme. So, it was also needed to separate visual styles from design
-models.
-
-At this point there are two independent worklines: one directory
-structure to store design models (the final image characteristics
-[i.e., dimensions, translation markers, etc.]) and one directory
-structure to store visual styles (the final image visual style [i.e.,
-the image look and feel]). So, it is possible to handle both
-different design models and different visual styles independtly one
-another and later create combinations among them using
-@file{centos-art.sh}.
-
-For example, consider the following configuration:
-
-@table @strong
-@item One entry under @file{trunk/Identity/Themes/Models/}:
-
-The design model entry exists to organize design model files (similar
-to design templates). Both design models and design templates are very
-similar; they both should have the @code{CENTOSARTWORK} export id
-present to identify the exportation area, translation marks, etc.
-However, design models do use dynamic backgrounds inclusion while
-design templates don't.
-
-@verbatim
- THEMEMODEL | | The bond component
- |<----| |--------------------->|
-trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
-|-- paragraph.svg
-`-- list.svg
-@end verbatim
-
-Inisde design models, dynamic backgrounds are required in order for
-different artistic motifs to reuse common design models. Firstly, in
-order to create dynamic backgrounds inside design models, we import a
-bitmap to cover design model's background and later, update design
-model's path information to replace fixed values to dynamic values.
-
-@item One entry under @file{trunk/Identity/Themes/Motifs/}:
-
-The artistic motif entry defines the visual style we want to produce
-images for, only. Final images (i.e., those built from combining both
-design models and artistic motif backrounds) are not stored here, but
-under branches directory structure. In the artistic motif entry, we
-only define those images that cannot be produced automatically by
-@file{centos-art.sh} (e.g., Backgrounds, Color information,
-Screenshots, etc.).
-
-@verbatim
- Artistic motif name | | Artistic motif backgrounds
- |<-------| |-------->|
-trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
-|-- Img
-| |-- Png
-| | |-- 510x300.png
-| | `-- 510x300-final.png
-| `-- Jpg
-| |-- 510x300.jpg
-| `-- 510x300-final.jpg
-|-- Tpl
-| `-- 510x300.svg
-`-- Xcf
- `-- 510x300.xcf
-@end verbatim
-
-@item One entry under @file{trunk/Translations/}:
-
-The translation entry specifies, by means of translation files, the
-language-specific information we want to produce image for. When we
-create the translation entry we don't use the name of neither design
-model nor artistic motif, just the design model component we want to
-produce images for.
-
-@verbatim
- | The bond component
- |--------------------->|
-trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
-`-- 5
- |-- en
- | |-- 01-welcome.sed
- | |-- 02-donate.sed
- | `-- 03-docs.sed
- `-- es
- |-- 01-welcome.sed
- |-- 02-donate.sed
- `-- 03-docs.sed
-@end verbatim
-
-@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}:
-
-There is one pre-rendition configuration script for each theme
-component. So, each time a theme component is rendered, its
-pre-rendition configuration script is evaluated to teach
-@file{centos-art.sh} how to render the component.
-
-@verbatim
-trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
-`-- render.conf.sh
-@end verbatim
-
-In this configuration the pre-rendition configuration script
-(@file{render.conf.sh}) would look like the following:
-
-@verbatim
-function render_loadConfig {
-
- # Define rendition actions.
- ACTIONS[0]='BASE:renderImage'
-
- # Define matching list.
- MATCHINGLIST="\
- paragraph.svg:\
- 01-welcome.sed\
- 02-donate.sed
- list.svg:\
- 03-docs.sed
- "
-
- # Deifne theme model.
- THEMEMODEL='Default'
-
-}
-@end verbatim
-@end table
-
-The production flow of ``optimize+flexibility'' configuration@dots{}
-@subsection Renderable translation directory structures
-
-Translation directory structures are auxiliar structures of renderable
-identity directory structures. There is one translation directory
-structure for each renderable identity directory structure. Inside
-translation directory structures we organize translation files used by
-renderable identity directory structures that produce translated
-images. Renderable identity directory structures that produce
-untranslated images don't use translation files, but they do use a
-translation directory structure, an empty translation directory
-structure, to be precise.
-
-In order to aliviate production of translation file, we made
-translation directory structures renderable adding a template
-(@file{Tpl/}) directory structure to handle common content inside
-translation files. This way, we work on translation templates and
-later use @file{centos-art.sh} to produce specific translation files
-(based on translation templates) for different information (e.g.,
-languages, release numbers, architectures, etc.).
-
-If for some reason, translation files get far from translation
-templates and translation templates become incovenient to produce such
-translation files then, care should be taken to avoid replacing the
-content of translation files with the content of translation templates
-when @file{centos-art.sh} is executed to produce translation files
-from translation templates.
-
-Inside renderable translation directory structures,
-@file{centos-art.sh} can produce text-based files only.
-
-@subsection Copying renderable directory structures
-
-A renderable layout is formed by design models, design images,
-pre-rendition configuration scripts and translations files. This way,
-when we say to duplicate rendition stuff we are saying to duplicate
-these four directory structures (i.e., design models, design images,
-pre-rendition configuration scripts, and related translations files).
-
-When we duplicate directories, inside `trunk/Identity' directory
-structure, we need to be aware of renderable layout described above
-and the source location used to perform the duplication action. The
-source location is relevant to centos-art.sh script in order to
-determine the required auxiliar information inside directory
-structures that need to be copied too (otherwise we may end up with
-orphan directory structures unable to be rendered, due the absence of
-required information).
-
-In order for a renderable directory structure to be valid, the new
-directory structure copied should match the following conditions:
-
-@enumerate
-@item To have a unique directory structure under
-@file{trunk/Identity}, organized by any one of the above
-organizational designs above.
-
-@item To have a unique directory structure under
-@file{trunk/Translations} to store translation files.
-
-@item To have a unique directory structure under
-@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition
-configuration script.
-@end enumerate
-
-As convenction, the @code{render_doCopy} function uses
-@file{trunk/Identity} directory structure as source location. Once
-the @file{trunk/Identity} directory structure has been specified and
-verified, the related path information is built from it and copied
-automatically to the new location specified by @var{FLAG_TO} variable.
-
-Design templates + No translation:
-
-Command:
-- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir
-
-Sources:
-- trunk/Identity/Path/To/Dir
-- trunk/Translations/Identity/Path/To/Dir
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-
-Targets:
-- trunk/Identity/NewPath/To/Dir
-- trunk/Translations/Identity/NewPath/To/Dir
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir
-
-Renderable layout 2:
-
-Command:
-- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \
- --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir
-
-Sources:
-- trunk/Identity/Themes/Motifs/TreeFlower
-- trunk/Translations/Identity/Themes
-- trunk/Translations/Identity/Themes/Motifs/TreeFlower
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower
-
-Targets:
-- trunk/Identity/Themes/Motifs/NewPath/To/Dir
-- trunk/Translations/Identity/Themes
-- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
-- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir
-
-Notice that design models are not included in source or target
-locations. This is intentional. In ``Renderable layout 2'', design
-models live by their own, they just exist, they are there, available
-for any artistic motif to use. By default `Themes/Models/Default'
-design model directory structure is used, but other design models
-directory structures (under Themes/Models/) can be created and used
-changing the value of THEMEMODEL variable inside the pre-rendition
-configuration script of the artistic motif source location you want to
-produce.
-
-Notice how translations and pre-rendition configuration scripts may
-both be equal in source and target. This is because such structures
-are common to all artistic motifs (the default values to use when no
-specific values are provided).
-
-- The common directory structures are not copied or deleted. We cannot
- copy a directory structure to itself.
-
-- The common directory structures represent the default value to use
- when no specific translations and/or pre-rendition configuration
- script are provided inside source location.
-
-- The specific directory structures, if present, are both copiable and
- removable. This is, when you perform a copy or delete action from
- source, that source specific auxiliar directories are transfered in
- the copy action to a new location (that specified by FLAG_TO
- variable).
-
-- When translations and/or pre-rendition configuration scripts are
- found inside the source directory structure, the centos-art.sh
- script loads common auxiliar directories first and later specific
- auxiliar directories. This way, identity rendition of source
- locations can be customized idividually over the base of common
- default values.
-
-- The specific auxiliar directories are optional.
-
-- The common auxiliar directories should be present always. This is,
- in order to provide the information required by render functionality
- (i.e., to make it functional in the more basic level of its
- existence).
-
-Notice how the duplication process is done from `trunk/Identity' on,
-not the oposite. If you try to duplicate a translation structure (or
-similar auxiliar directory structures like pre-rendition configuration
-scripts), the `trunk/Identity' for that translation is not created.
-This limitation is impossed by the fact that many `trunk/Identity'
-directory structures may reuse/share the same translation directory
-structure. We cannot delete one translation (or similar) directory
-structures while a related `trunk/Identity/' directory structure is
-still in need of it.
-
-The `render_doCopy' functionality does duplicate directory structures
-directly involved in rendition process only. Once such directories
-have been duplicated, the functionality stops thereat.
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@comment --- Removed(* trunk Scripts Bash Functions Render Config::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
deleted file mode 100644
index 3b3322b..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
+++ /dev/null
@@ -1,192 +0,0 @@
-@subsection Goals
-
-The @file{trunk/Scripts/Bash/Config} directory exists to oraganize
-pre-rendering configuration scripts.
-
-@subsection Description
-
-Pre-rendering configuration scripts let you customize the way
-@command{centos-art.sh} script renders identity and translation
-repository entries. Pre-rendering configuration scripts are
-@file{render.conf.sh} files with @command{render_loadConfig} function
-definition inside.
-
-There is one @file{render.conf.sh} file for each pre-rendering
-configuration entry. Pre-rendering configuration entries can be based
-both on identity and translation repository entires. Pre-rendering
-configuration entries are required for each identity entry, but not
-for translation entries.
-
-@subsubsection The @file{render.conf.sh} identity model
-
-Inside CentOS Artwork Repository, we consider identity entries to all
-directories under @file{trunk/Identity} directory. Identity entries can be
-image-based or text-based. When you render image-based identity
-entries you need to use image-based pre-rendering configuration
-scripts. Likewise, when you render text-based identity entries you
-need to use text-based pre-rendering configuration scripts.
-
-Inside identity pre-rendering configuration scripts, image-based
-pre-rendering configuration scripts look like the following:
-
-@verbatim
-#!/bin/bash
-
-function render_loadConfig {
-
- # Define rendering actions.
- ACTIONS[0]='BASE:renderImage'
- ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
-
-}
-@end verbatim
-
-Inside identity pre-rendering configuration scripts, text-based
-pre-rendering configuration scripts look like the following:
-
-@verbatim
-#!/bin/bash
-
-function render_loadConfig {
-
- # Define rendering actions.
- ACTIONS[0]='BASE:renderText'
- ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
-
-}
-@end verbatim
-
-When using identity pre-rendering configuration scripts, you can
-extend both image-based and text-based pre-rendering configuration
-scripts using image-based and text-based post-rendering actions,
-respectively.
-
-@subsubsection The @file{render.conf.sh} translation model
-
-Translation pre-rendering configuration scripts take precedence before
-default translation rendering action. Translation pre-rendering
-actions are useful when default translation rendering action do not
-fit itself to translation entry rendering requirements.
-
-@subsubsection The @file{render.conf.sh} rendering actions
-
-Inside both image-based and text-based identity pre-rendering
-configuration scripts, we use the @samp{ACTIONS} array variable to
-define the way @command{centos-art.sh} script performs identity
-rendering. Identity rendering is organized by one @samp{BASE} action,
-and optional @samp{POST} and @samp{LAST} rendering actions.
-
-The @samp{BASE} action specifies what kind of rendering does the
-@command{centos-art.sh} script will perform with the files related to
-the pre-rendering configuration script. The @samp{BASE} action is
-required. Possible values to @samp{BASE} action are either
-@samp{renderImage} or @samp{renderText} only.
-
-To specify the @samp{BASE} action you need to set the @samp{BASE:}
-string followed by one of the possible values. For example, if you
-want to render images, consider the following definition of
-@samp{BASE} action:
-
-@verbatim
-ACTIONS[0]='BASE:renderImage'
-@end verbatim
-
-Only one @samp{BASE} action must be specified. If more than one
-@samp{BASE} action is specified, the last one is used. If no
-@samp{BASE} action is specified at all, an error is triggered and the
-@command{centos-art.sh} script ends its execution.
-
-The @samp{POST} action specifies which action to apply for
-each file rendered (at the rendering time). This action is optional.
-You can set many different @samp{POST} actions to apply many different
-actions over the same already rendered file. Possible values to
-@samp{POST} action are @samp{renderFormats}, @samp{renderSyslinux},
-@samp{renderGrub}, etc.
-
-To specify the @samp{POST} action, you need to use set the
-@samp{POST:} followed by the function name of the action you want to
-perform. The exact form depends on your needs. For example, consider
-the following example to produce @samp{xpm}, @samp{jpg}, and
-@samp{tif} images, based on already rendered @samp{png} image, and
-also organize the produced files in directories named as their own
-extensions:
-
-@verbatim
-ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
-@end verbatim
-
-In the previous example, file organization takes place at the moment
-of rendering, just after producing the @samp{png} base file and before
-going to the next file in the list of files to render. If you don't
-want to organized the produced files in directories named as their own
-extensions, just remove the @samp{POST:groupByFormat} action line:
-
-@verbatim
-ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-@end verbatim
-
-The @samp{LAST} action specifies which actions to apply once the last
-file in the list of files to process has been rendered. The
-@samp{LAST} action is optional. Possible values for @samp{LAST}
-actions may be @samp{groupByFormat}, @samp{renderGdmTgz}, etc.
-
-@quotation
-@strong{Note} --- @strong{Removed}(xref:trunk Scripts Bash Functions Render) ---, to know more
-about possible values for @samp{BASE}, @samp{POST} and @samp{LAST}
-action definitions.
-@end quotation
-
-To specify the @samp{LAST} action, you need to set the @samp{LAST:}
-string followed by the function name of the action you want to
-perform. For example, consider the following example if you want to
-render all files first and organize them later:
-
-@verbatim
-ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
-@end verbatim
-
-@subsection Usage
-
-Use the following commands to administer both identity and translation
-pre-rendering configuration scripts:
-
-@table @samp
-
-@item centos-art config --create='path/to/dir/'
-
-Use this command to create @samp{path/to/dir} related pre-rendering
-configuration script.
-
-@item centos-art config --edit='path/to/dir/'
-
-Use this command to edit @samp{path/to/dir} related pre-rendering
-configuration script.
-
-@item centos-art config --read='path/to/dir/'
-
-Use this command to read @samp{path/to/dir} related pre-rendering
-configuration script.
-
-@item centos-art config --remove='path/to/dir/'
-
-Use this command to remove @samp{path/to/dir} related pre-rendering
-configuration script.
-
-@end table
-
-In the commands above, @samp{path/to/dir} refers to one renderable
-directory path under @file{trunk/Identity} or
-@file{trunk/Translations} structures only.
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@comment --- Removed(* trunk Scripts Bash Functions Render::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Shell.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Shell.texi
deleted file mode 100644
index a5016fe..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Shell.texi
+++ /dev/null
@@ -1,184 +0,0 @@
-@subsection Goals
-
-This section exists to organize files related to @code{shell}
-functionality of @file{centos-art.sh} script.
-
-@subsection Description
-
-The @code{shell} functionality of @file{centos-art.sh} script helps
-you to maintain bash scripts inside repository. For example, suppose
-you've created many functionalities for @file{centos-art.sh} script,
-and you want to use a common copyright and license note for
-consistency in all your script files. If you have a bunch of files,
-doing this one by one wouldn't be a big deal. In contrast, if the
-amount of files grows, updating the copyright and license note for all
-of them would be a task rather tedious. The @code{shell} functionality
-exists to solve maintainance tasks just as the one previously
-mentioned.
-
-When you use @code{shell} functionality to update copyright inside
-script files, it is required that your script files contain (at least)
-the following top commentary structure:
-
-@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:1
-@verbatim
- 1| #!/bin/bash
- 2| #
- 3| # doSomething.sh -- The function description goes here.
- 4| #
- 5| # Copyright
- 6| #
- 7| # ...
- 8| #
- 9| # ----------------------------------------------------------------------
-10| # $Id$
-11| # ----------------------------------------------------------------------
-12|
-13| function doSomething {
-14|
-15| }
-@end verbatim
-@caption{The functions script base comment structure}
-@end float
-
-Relevant lines in the above structure are lines from 5 to 9.
-Everything else in the file is left immutable.
-
-When you are updating copyright through @code{shell}
-functionality, the @file{centos-art.sh} script replaces everything
-in-between line 5 ---the first one matching @samp{^# Copyright .+$}
-string--- and line 9---the first long dash separator matching @samp{^#
--+$}--- with the content of copyright template instance.
-
-@quotation
-@strong{Caution} Be sure to add the long dash separator that matches
-@samp{^# -+$} regular expression @emph{before} the function
-definition. Otherwise, if the @samp{Copyright} line is present but no
-long dash separator exists, @file{centos-art.sh} will remove anything
-in-between the @samp{Copyright} line and the end of file. This way you
-may lost your function definitions entirely.
-@end quotation
-
-The copyright template instance is created from one copyright template
-stored in the @file{Config/tpl_forCopyright.sed} file. The template
-instance is created once, and later removed when no longer needed. At
-this moment, when template instance is created, the
-@file{centos-art.sh} script takes advantage of automation in order to
-set copyright full name and date dynamically.
-
-When you use @code{shell} functionality to update copyright, the first
-thing @file{shell} functionality does is requesting copyright
-information to user, and later, if values were left empty (i.e., no
-value was typed before pressing @key{RET} key), the @file{shell}
-functionality uses its own default values.
-
-When @code{shell} functionality uses its own default values, the final
-copyright note looks like the following:
-
-@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:2
-@verbatim
- 1| #!/bin/bash
- 2| #
- 3| # doSomthing.sh -- The function description goes here.
- 4| #
- 5| # Copyright (C) 2003, 2010 The CentOS Project
- 6| #
- 7| # This program is free software; you can redistribute it and/or modify
- 8| # it under the terms of the GNU General Public License as published by
- 9| # the Free Software Foundation; either version 2 of the License, or
-10| # (at your option) any later version.
-11| #
-12| # This program is distributed in the hope that it will be useful, but
-13| # WITHOUT ANY WARRANTY; without even the implied warranty of
-14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-15| # General Public License for more details.
-16| #
-17| # You should have received a copy of the GNU General Public License
-18| # along with this program; if not, write to the Free Software
-19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-20| # USA.
-21| #
-22| # ----------------------------------------------------------------------
-23| # $Id$
-24| # ----------------------------------------------------------------------
-25|
-26| function doSomething {
-27|
-28| }
-@end verbatim
-@caption{The function script comment example}
-@end float
-
-Relevant lines in the above structure are lines from 5 to 22. Pay
-attention how the copyright line was built, and how the license was
-added into the top comment where previously was just three dots.
-Everything else in the file was left immutable.
-
-To change copyright information (i.e., full name or year information),
-run the @code{shell} functionality over the root directory containing
-the script files you want to update copyright in and enter the
-appropriate information when it be requested. You can run the
-@code{shell} functionality as many times as you need to.
-
-To change copyright license (i.e., the text in-between lines 7 and
-20), you need to edit the @file{Config/tpl_forCopyright.sed} file, set
-the appropriate information, and run the @code{shell} functionality
-once again for changes to take effect over the files you specify.
-
-@quotation
-@strong{Important} The @file{centos-art.sh} script is released as:
-
-@verbatim
-GNU GENERAL PUBLIC LICENSE
-Version 2, June 1991
-
-Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-@end verbatim
-
-Do not change the license information under which @file{centos-art.sh}
-script is released. Instead, if you think a different license must be
-used, please share your reasons at @email{centos-devel@@centos-art.sh,
-CentOS Developers mailing list}.
-@end quotation
-
-@subsection Usage
-
-@table @command
-@item centos-art sh --update-copyright='path/to/dir'
-@itemx centos-art sh --update-copyright='path/to/dir' --filter='regex'
-Use these commands to update copyright information in @samp{.sh} files
-under @samp{path/to/dir} directory.
-@end table
-
-When you provide @option{--filter='regex'} argument, the list of files
-to process is reduced as specified in @samp{regex} regular expression.
-Inside @file{centos-art.sh} script, the @samp{regex} regular
-expression is used in combination with @command{find} command to look
-for files matching the regular expression path pattern.
-
-@quotation
-@strong{Warning} In order for @samp{regex} regular expression to match
-a file, the @samp{regex} regular expresion must match the whole file
-path not just the file name.
-@end quotation
-
-For example, if you want to match all @file{render.conf.sh} files
-inside @file{path/to/dir}, use the @code{.+/render.conf} regular
-expression. Later, @file{centos-art.sh} script uses this value inside
-@code{^$REGEX\.sh$} expression in order to build the final regular
-expression (i.e., @code{^.+/render.conf\.sh$}) that is evaluated
-against available file paths inside the list of files to process.
-
-Exceptionally, when you provide @option{--filter='regex'} in the way
-that @samp{regex}, appended to @samp{path/to/dir/} (i.e.
-@samp{path/to/dir/regex}), matches a regular file; the
-@file{centos-art.sh} script uses the file matching as only file in the
-list of files to process.
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Svg.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Svg.texi
deleted file mode 100644
index 341745d..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Svg.texi
+++ /dev/null
@@ -1,192 +0,0 @@
-@subsection Goals
-
-This section exists to organize files related to @code{svg}
-functionality of @file{centos-art.sh} script.
-
-@subsection Description
-
-The @code{svg} functionality of @file{centos-art.sh} script helps you
-to maintain scalable vector graphics (SVG) inside repository. For
-example, suppose you've been working in CentOS default design models
-under @file{trunk/Identity/Themes/Models/}, and you want to set common
-metadata to all of them, and later remove all unused SVG defintions
-from @samp{*.svg} files. Doing so file by file may be a tedious task,
-so the @file{centos-art.sh} script provides the @code{svg}
-functionality to aid you maintain such actions.
-
-@cindex Metadata maintainance
-@subsubsection Metadata maintainance
-
-The metadata used is defined by Inkscape 0.46 using the SVG standard
-markup. The @file{centos-art.sh} script replaces everything
-in-between @code{<metadata} and @code{</metadata>} tags with a
-predefined metadata template we've set for this purpose.
-
-The metadata template was created using the metadata information of a
-file which, using Inkscape 0.46, all metadata fields were set. This
-created a complete markup representation of how SVG metadata would
-look like. Later, we replaced every single static value with a
-translation marker in the form @samp{=SOMETEXT=}, where
-@code{SOMETEXT} is the name of its main opening tag. Later, we
-transform the metadata template into a sed replacement set of commads
-escaping new lines at the end of each line.
-
-With metadata template in place, the @file{centos-art.sh} script uses
-it to create a metadata template instance for the file being processed
-currently. The metadata template instance contains the metadata
-portion of sed replacement commands with translation markers already
-traduced. In this action, instance creation, is where we take
-advantage of automation and generate metadata values like title, date,
-keywords, source, identifier, and relation dynamically, based on the
-file path @file{centos-art.sh} script is currently creating metadata
-information for.
-
-With metadata template instance in place, the @file{centos-art.sh}
-script uses it to replace real values inside all @samp{.svg} files
-under the current location you're running the @file{centos-art.sh}
-script on. Default behaviour is to ask user to enter each metadatum
-required, one by one. If user leaves metadatum empty, by pressing
-@key{RET} key, @file{centos-art.sh} uses its default value.
-
-The @file{centos-art.sh} script modifies the following metadata:
-
-@table @samp
-@item Title
-Name by which this document is formally known. If no value is set
-here, @file{centos-art.sh} script uses the file name as title.
-
-@item Date
-Date associated with the creation of this document (YYYY-MM-DD). If no
-value is set here, @file{centos-art.sh} script uses the current date
-information as in @command{date +%Y-%m-%d}.
-
-@item Creator
-Name of entity primarily responsible for making the content of this
-document. If no value is set here, @file{centos-art.sh} script uses
-the string @samp{The CentOS Project}.
-
-@item Rights
-Name of entity with rights to the intellectual Property of this
-document. If no value is set here, @file{centos-art.sh} script uses
-the string @samp{The CentOS Project}.
-
-@item Publisher
-Name of entity responsible for making this document available. If no
-value is set here, @file{centos-art.sh} script uses the string
-@samp{The CentOS Project}.
-
-@item Identifier
-Unique URI to reference this document. If no value is set here,
-@file{centos-art.sh} script uses the current file path to build the
-related url that points to current file location inside repository
-central server.
-
-@item Source
-Unique URI to reference the source of this document. If no value is
-set here, @file{centos-art.sh} script uses current file path to build
-the related url that points to current file location inside repository
-central server.
-
-@item Relation
-Unique URI to a related document. If no value is set here,
-@file{centos-art.sh} script uses current file path to build the
-related url that points to current file location inside repository
-central server.
-
-@item Language
-Two-letter language tag with optional subtags for the language of this
-document. (e.g. @samp{en-GB}). If no value is set here,
-@file{centos-art.sh} script uses the current locale information as in
-@code{cli_getCurrentLocale} function.
-
-@item Keywords
-The topic of this document as comma-separated key words, prhases, or
-classifications. If no value is set here, @file{centos-art.sh} script
-uses file path to build
-
-@item Coverage
-Extent or scope of this document. If no value is set here,
-@file{centos-art.sh} script uses the string @samp{The CentOS Project}.
-
-@item Description
-Description about the document. If no value is set here,
-@file{centos-art.sh} script uses uses empty value as default.
-
-@item Contributors
-People that contributes in the creation/maintainance of the document.
-If no value is set here, @file{centos-art.sh} script uses uses empty
-value as default.
-@end table
-
-The @samp{License} metadatum is not set as a choise, by now. It is
-fixed @url{http://creativecommons.org/licenses/by-sa/3.0/, Creative
-Common Attribution Share-Alike 3.0 License}. This is done in order to
-grant license consistency among all SVG files we manage inside CentOS
-Artwork Repository.
-
-@cindex Unused definitions
-@subsubsection Unused definitions
-
-Many of the no-longer-used gradients, patterns, and markers (more
-precisely, those which you edited manually) remain in the
-corresponding palettes and can be reused for new objects. However if
-you want to optimize your document, use the @samp{Vacuum Defs} command
-in @samp{File} menu. It will remove any gradients, patterns, or
-markers which are not used by anything in the document, making the
-file smaller.
-
-If you have one or two couple of files, removing unused definitions
-using the graphical interface may be enough to you. In contrast, if
-you have dozens or even houndreds of scalable vector graphics files to
-maintain it is not a fun task to use the graphical interface to remove
-unused definitions editing those files one by one.
-
-To remove unused definitions from several scalable vector graphics
-files, the @file{centos-art.sh} script uses Inkscape command-line
-interface, specifically with the @option{--vaccum-defs} option.
-
-@subsection Usage
-
-@table @command
-@item centos-art svg --update-metadata='path/to/dir'
-@item centos-art svg --update-metadata='path/to/dir' --filter='regex'
-Use these commands to update metadata information to @samp{.svg} files
-under @samp{path/to/dir} directory.
-
-@item centos-art svg --vacuum-defs='path/to/dir'
-@item centos-art svg --vacuum-defs='path/to/dir' --filter='regex'
-Use these commands to remove unused definitions inside @samp{.svg}
-files under @samp{path/to/dir} directory.
-@end table
-
-When you provide @option{--filter='regex'} argument, the list of files
-to process is reduced as specified in @samp{regex} regular expression.
-Inside @file{centos-art.sh} script, the @samp{regex} regular
-expression is used in combination with @command{find} command to look
-for files matching the regular expression path pattern.
-
-@quotation
-@strong{Warning} In order for @samp{regex} regular expression to match
-a file, the @samp{regex} regular expresion must match the whole file
-path not just the file name.
-@end quotation
-
-For example, if you want to match all @file{summary.svg} files inside
-@file{path/to/dir}, use the @code{.+/summary} regular expression.
-Later, @file{centos-art.sh} script uses this value inside
-@code{^$REGEX\.svg$} expression in order to build the final regular
-expression (i.e., @code{^.+/summary\.svg$}) that is evaluated against
-available file paths inside the list of files to process.
-
-Exceptionally, when you provide @option{--filter='regex'} in the way
-that @samp{regex}, appended to @samp{path/to/dir/} (i.e.
-@samp{path/to/dir/regex}), matches a regular file; the
-@file{centos-art.sh} script uses the file matching as only file in the
-list of files to process.
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Verify.texi b/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Verify.texi
deleted file mode 100644
index ff98b51..0000000
--- a/Manuals/Repository/trunk/Scripts/Bash/Cli/Functions/Verify.texi
+++ /dev/null
@@ -1,245 +0,0 @@
-@subsection Goals
-
-This section exists to organize files related to @file{centos-art.sh}
-script @samp{verify} functionality. The @samp{verify}
-functionality of @file{centos-art.sh} script helps you to verify the
-workstation configuration you are planning to use as host for your
-working copy of CentOS Artwork Repository.
-
-@subsection Description
-
-The first time you download CentOS Artwork Repository you need to
-configure your workstation in order to use @file{centos-art.sh}
-script. These preliminar configurations are based mainly on auxiliar
-RPM packages installation, symbolic links creations, and environment
-variables definitions. The @samp{verify} functionality of
-@file{centos-art.sh} script guides you through this preliminar
-configuration process.
-
-If this is the first time you run @file{centos-art.sh} script, the
-appropriate way to use its @samp{verify} functionality is not using
-the @file{centos-art.sh} script directly, but the absolute path to
-@command{centos-art.sh} script instead (i.e.,
-@file{~/artwork/trunk/Scripts/Bash/centos-art.sh}). This is necessary
-because @file{centos-art} symbolic link, under @file{~/bin/}
-directory, has not been created yet.
-
-@subsubsection Packages
-
-Installation of auxiliar RPM packages provides the software required
-to manipulate files inside the repository (e.g., image files,
-documentation files, translation files, script files, etc.). Most of
-RPM packages @command{centos-art.sh} script uses are shipped with
-CentOS distribution, and can be installed from CentOS base repository.
-The only exception is @samp{inkscape}, the package we use to
-manipulate SVG files. The @samp{inkscape} package is not inside
-CentOS distribution so it needs to be installed from third party
-repositories.
-
-@quotation
-@strong{Note} Configuration of third party repositories inside CentOS
-distribution is described in CentOS wiki, specifically in the
-following URL:
-@url{http://wiki.centos.org/AdditionalResources/Repositories}
-@end quotation
-
-Before installing packages, the @file{centos-art.sh} script uses
-@command{sudo} to request root privileges to execute @command{yum}
-installation functionality. If your user isn't defined as a
-privileged user---at least to run @command{yum} commands--- inside
-@file{/etc/sudoers} configuration file, you will not be able to
-perform package installation tasks as set in @file{centos-art.sh}
-script @samp{verify} functionality.
-
-Setting sudo privileges to users is an administrative task you have to
-do by yourself. If you don't have experience with @command{sudo}
-command, please read its man page running the command: @command{man
-sudo}. This reading will be very useful, and with some practice, you
-will be able to configure your users to have @command{sudo}
-privileges.
-
-@subsubsection Links
-
-Creation of symbolic links helps us to alternate between different
-implementations of @file{centos-art.sh} script-line (e.g.,
-@file{centos-art.sh}, for Bash implementation; @file{centos-art.py},
-for Python implementation; @file{centos-art.pl}, for Perl
-implementation; and so on for other implementations). The
-@file{centos-art.sh} script-line definition takes place inside your
-personal binary (@file{~/bin/}) directory in order to make the script
-implementation ---the one that @file{centos-art} links to--- available
-to @var{PATH} environment variable.
-
-Creation of symbolic links helps us to reuse components from repository
-working copy. For example, color information files maintained inside
-your working copy must never be duplicated inside program-specific
-configuration directories that uses them in your workstation (e.g.,
-Gimp, Inkscape, etc.). Instead, a symbolic link must be created for
-each one of them, from program-specific configuration directories to
-files in the working copy. In this configuration, when someone
-commits changes to color information files up to central repository,
-they---the changes committed--- will be immediatly available to your
-programs the next time you update your working copy ---the place
-inside your workstation those color information files are stored---.
-
-Creation of symbolic links helps us to make @file{centos-art.sh}
-script functionalities available outside @file{trunk/} repository
-directory structure, but at its same level in repository tree. This is
-useful if you need to use the ``render'' functionality of
-@command{centos-art.sh} under @file{branches/} repository directory
-structure as you usually do inside @file{trunk/} repository directory
-structure. As consequence of this configuration, automation scripts
-cannot be branched under @file{branches/Scripts} directory structure.
-
-@subsubsection Environment variables
-
-Definition of environemnt variables helps us to set default values to
-our user session life. The user session environment variable defintion
-takes place in the user's @file{~/.bash_profile} file. The
-@samp{verify} functionality of @file{centos-art.sh} script doesn't
-modify your @file{~/.bash_profile} file.
-
-The @samp{verify} functionality of @file{centos-art.sh} script
-evaluates the following environment variables:
-
-@table @env
-@item EDITOR
-Default text editor.
-
-The @file{centos-art.sh} script uses default text @env{EDITOR} to edit
-pre-commit subversion messages, translation files, configuration
-files, script files, and similar text-based files.
-
-If @env{EDITOR} environment variable is not set, @file{centos-art.sh}
-script uses @file{/usr/bin/vim} as default text editor. Otherwise, the
-following values are recognized by @file{centos-art.sh} script:
-
-@itemize
-@item @file{/usr/bin/vim}
-@item @file{/usr/bin/emacs}
-@item @file{/usr/bin/nano}
-@end itemize
-
-If no one of these values is set in @env{EDITOR} environment variable,
-@file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default.
-
-@item TEXTDOMAIN
-
-Default domain used to retrieve translated messages. This variable is
-set in @file{initFunctions.sh} and shouldn't be changed.
-
-@item TEXTDOMAINDIR
-
-Default directory used to retrieve translated messages. This variable
-is set in @file{initFunctions.sh} and shouldn't be changed.
-
-@item LANG
-
-Default locale information.
-
-This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-@samp{Language} step; or once installed using the
-@command{system-config-language} tool.
-
-The @file{centos-art.sh} script uses the @var{LANG} environment
-variable to know in which language the script messages are printed
-out.
-
-@item TZ
-
-Default time zone representation.
-
-This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-@samp{Date and time} step; or once installed using the
-@command{system-config-date} tool.
-
-The @file{centos-art.sh} script doesn't use the @var{TZ} environment
-variable information at all. Instead, this variable is used by the
-system shell to show the time information according to your phisical
-location on planet Earth.
-
-Inside your computer, the time information is firstly set in the BIOS
-clock (which may need correction), and later in the configuration
-process of CentOS distribution installer (or later, by any of the
-related configuration tools inside CentOS distribution). Generally,
-setting time information is a straight-forward task and configuration
-tools available do cover most relevant location. However, if you need
-a time precision not provided by the configuration tools available
-inside CentOS distribution then, using @var{TZ} variable may be
-necessary.
-
-@quotation
-@strong{Convenction} In order to keep changes syncronized between
-central repository and its working copies: configure both repository
-server and workstations (i.e., the place where each working copy is
-set on) to use Coordinated Universal Time (UTC) as base time
-representation. Later, correct the time information for your specific
-location using time zone correction.
-@end quotation
-
-The format of @var{TZ} environment variable is described in
-@file{tzset(3)} manual page.
-
-@end table
-
-@subsection Usage
-
-@table @command
-
-@item centos-art verify --packages
-
-Verify required packages your workstation needs in order to run the
-@file{centos-art.sh} script correctly. If there are missing packages,
-the @file{centos-art.sh} script asks you to confirm their
-installation. When installing packages, the @file{centos-art.sh}
-script uses the @command{yum} application in order to achieve the
-task.
-
-In case all packages required by @file{centos-art.sh} script are
-already installed in your workstation, the message @samp{The required
-packages are already installed.} is output for you to know.
-
-@item centos-art verify --links
-
-Verify required links your workstation needs in order to run the
-centos-art command correctly. If any required link is missing, the
-@command{centos-art.sh} script asks you to confirm their installation.
-To install required links, the @command{centos-art.sh} script uses the
-@command{ln} command.
-
-In case all links required by @file{centos-art.sh} script are already
-created in your workstation, the message @samp{The required links are
-already installed.} is output for you to know.
-
-In case a regular file exists with the same name of a required link,
-the @file{centos-art.sh} script outputs the @samp{Already exists as
-regular file.} message when listing required links that will be
-installed. Of course, as there is already a regular file where must be
-a link, no link is created. In such cases the @file{centos-art.sh}
-script will fall into a continue installation request for that missing
-link. To end this continue request you can answer @samp{No}, or
-remove the existent regular file to let @file{centos-art.sh} script
-install the link on its place.
-
-@item centos-art verify --environment
-@itemx centos-art verify --environment --filter='regex'
-
-Output a brief description of environment variables used by
-@file{centos-art.sh} script.
-
-If @samp{--filter} option is provided, output is reduced as defined in
-the @samp{regex} regular expression value. If @samp{--filter} option
-is specified but @samp{regex} value is not, the @file{centos-art.sh}
-script outputs information as if @samp{--filter} option had not been
-provided at all.
-
-@end table
-
-@subsection See also
-
-@menu
-* trunk Scripts Bash::
-@comment --- Removed(* trunk Scripts Bash Functions::) ---
-@end menu
diff --git a/Manuals/Repository/trunk/Scripts/Python.texi b/Manuals/Repository/trunk/Scripts/Python.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Repository/trunk/Scripts/Python.texi
+++ /dev/null
@@ -1,22 +0,0 @@
-@subsection Goals
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Description
-
-@itemize
-@item ...
-@end itemize
-
-@subsection Usage
-
-@itemize
-@item ...
-@end itemize
-
-@subsection See also
-
-@menu
-@end menu
diff --git a/Manuals/Repository/trunk/chapter-intro.texi b/Manuals/Repository/trunk/chapter-intro.texi
deleted file mode 100644
index e69de29..0000000
--- a/Manuals/Repository/trunk/chapter-intro.texi
+++ /dev/null
diff --git a/Manuals/Repository/trunk/chapter-menu.texi b/Manuals/Repository/trunk/chapter-menu.texi
deleted file mode 100644
index 1dace8c..0000000
--- a/Manuals/Repository/trunk/chapter-menu.texi
+++ /dev/null
@@ -1,62 +0,0 @@
-@menu
-* trunk Identity::
-* trunk Identity Brands::
-* trunk Identity Fonts::
-* trunk Identity Icons::
-* trunk Identity Isolinux::
-* trunk Identity Models::
-* trunk Identity Models Css::
-* trunk Identity Models Html::
-* trunk Identity Models Img Promo Web::
-* trunk Identity Models Tpl::
-* trunk Identity Models Tpl Promo Web::
-* trunk Identity Models Xcf::
-* trunk Identity Release::
-* trunk Identity Themes::
-* trunk Identity Themes Models::
-* trunk Identity Themes Models Alternative::
-* trunk Identity Themes Models Default::
-* trunk Identity Themes Models Default Distro::
-* trunk Identity Themes Models Default Distro Anaconda::
-* trunk Identity Themes Models Default Promo::
-* trunk Identity Themes Models Default Web::
-* trunk Identity Themes Motifs::
-* trunk Identity Themes Motifs Flame::
-* trunk Identity Themes Motifs Modern::
-* trunk Identity Themes Motifs Modern Backgrounds::
-* trunk Identity Themes Motifs Modern Backgrounds Img::
-* trunk Identity Themes Motifs Modern Backgrounds Tpl::
-* trunk Identity Themes Motifs Modern Backgrounds Xcf::
-* trunk Identity Themes Motifs Modern Distro Anaconda Progress::
-* trunk Identity Themes Motifs Modern Palettes::
-* trunk Identity Themes Motifs TreeFlower::
-* trunk Identity Themes Motifs TreeFlower Backgrounds::
-* trunk Identity Widgets::
-* trunk Locales::
-* trunk Locales Identity::
-* trunk Locales Identity Brands::
-* trunk Locales Identity Brands Tpl::
-* trunk Locales Identity Fonts::
-* trunk Locales Identity Models::
-* trunk Locales Identity Release::
-* trunk Locales Identity Themes::
-* trunk Locales Identity Themes Backgrounds::
-* trunk Locales Identity Themes Distro Anaconda Progress::
-* trunk Locales Identity Widgets::
-* trunk Manuals::
-* trunk Scripts::
-* trunk Scripts Bash::
-* trunk Scripts Bash Cli::
-* trunk Scripts Bash Cli Functions::
-* trunk Scripts Bash Cli Functions Help::
-* trunk Scripts Bash Cli Functions Html::
-* trunk Scripts Bash Cli Functions Locale::
-* trunk Scripts Bash Cli Functions Manual::
-* trunk Scripts Bash Cli Functions Path::
-* trunk Scripts Bash Cli Functions Render::
-* trunk Scripts Bash Cli Functions Render Config::
-* trunk Scripts Bash Cli Functions Shell::
-* trunk Scripts Bash Cli Functions Svg::
-* trunk Scripts Bash Cli Functions Verify::
-* trunk Scripts Python::
-@end menu
diff --git a/Manuals/Repository/trunk/chapter-nodes.texi b/Manuals/Repository/trunk/chapter-nodes.texi
deleted file mode 100644
index 2ab21f1..0000000
--- a/Manuals/Repository/trunk/chapter-nodes.texi
+++ /dev/null
@@ -1,300 +0,0 @@
-@node trunk Identity
-@section trunk/Identity
-@cindex trunk Identity
-@include trunk/Identity.texi
-
-@node trunk Identity Brands
-@section trunk/Identity/Brands
-@cindex trunk Identity Brands
-@include trunk/Identity/Brands.texi
-
-@node trunk Identity Fonts
-@section trunk/Identity/Fonts
-@cindex trunk Identity Fonts
-@include trunk/Identity/Fonts.texi
-
-@node trunk Identity Icons
-@section trunk/Identity/Icons
-@cindex trunk Identity Icons
-@include trunk/Identity/Icons.texi
-
-@node trunk Identity Isolinux
-@section trunk/Identity/Isolinux
-@cindex trunk Identity Isolinux
-@include trunk/Identity/Isolinux.texi
-
-@node trunk Identity Models
-@section trunk/Identity/Models
-@cindex trunk Identity Models
-@include trunk/Identity/Models.texi
-
-@node trunk Identity Models Css
-@section trunk/Identity/Models/Css
-@cindex trunk Identity Models Css
-@include trunk/Identity/Models/Css.texi
-
-@node trunk Identity Models Html
-@section trunk/Identity/Models/Html
-@cindex trunk Identity Models Html
-@include trunk/Identity/Models/Html.texi
-
-@node trunk Identity Models Img Promo Web
-@section trunk/Identity/Models/Img/Promo/Web
-@cindex trunk Identity Models Img Promo Web
-@include trunk/Identity/Models/Img/Promo/Web.texi
-
-@node trunk Identity Models Tpl
-@section trunk/Identity/Models/Tpl
-@cindex trunk Identity Models Tpl
-@include trunk/Identity/Models/Tpl.texi
-
-@node trunk Identity Models Tpl Promo Web
-@section trunk/Identity/Models/Tpl/Promo/Web
-@cindex trunk Identity Models Tpl Promo Web
-@include trunk/Identity/Models/Tpl/Promo/Web.texi
-
-@node trunk Identity Models Xcf
-@section trunk/Identity/Models/Xcf
-@cindex trunk Identity Models Xcf
-@include trunk/Identity/Models/Xcf.texi
-
-@node trunk Identity Release
-@section trunk/Identity/Release
-@cindex trunk Identity Release
-@include trunk/Identity/Release.texi
-
-@node trunk Identity Themes
-@section trunk/Identity/Themes
-@cindex trunk Identity Themes
-@include trunk/Identity/Themes.texi
-
-@node trunk Identity Themes Models
-@section trunk/Identity/Themes/Models
-@cindex trunk Identity Themes Models
-@include trunk/Identity/Themes/Models.texi
-
-@node trunk Identity Themes Models Alternative
-@section trunk/Identity/Themes/Models/Alternative
-@cindex trunk Identity Themes Models Alternative
-@include trunk/Identity/Themes/Models/Alternative.texi
-
-@node trunk Identity Themes Models Default
-@section trunk/Identity/Themes/Models/Default
-@cindex trunk Identity Themes Models Default
-@include trunk/Identity/Themes/Models/Default.texi
-
-@node trunk Identity Themes Models Default Distro
-@section trunk/Identity/Themes/Models/Default/Distro
-@cindex trunk Identity Themes Models Default Distro
-@include trunk/Identity/Themes/Models/Default/Distro.texi
-
-@node trunk Identity Themes Models Default Distro Anaconda
-@section trunk/Identity/Themes/Models/Default/Distro/Anaconda
-@cindex trunk Identity Themes Models Default Distro Anaconda
-@include trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi
-
-@node trunk Identity Themes Models Default Promo
-@section trunk/Identity/Themes/Models/Default/Promo
-@cindex trunk Identity Themes Models Default Promo
-@include trunk/Identity/Themes/Models/Default/Promo.texi
-
-@node trunk Identity Themes Models Default Web
-@section trunk/Identity/Themes/Models/Default/Web
-@cindex trunk Identity Themes Models Default Web
-@include trunk/Identity/Themes/Models/Default/Web.texi
-
-@node trunk Identity Themes Motifs
-@section trunk/Identity/Themes/Motifs
-@cindex trunk Identity Themes Motifs
-@include trunk/Identity/Themes/Motifs.texi
-
-@node trunk Identity Themes Motifs Flame
-@section trunk/Identity/Themes/Motifs/Flame
-@cindex trunk Identity Themes Motifs Flame
-@include trunk/Identity/Themes/Motifs/Flame.texi
-
-@node trunk Identity Themes Motifs Modern
-@section trunk/Identity/Themes/Motifs/Modern
-@cindex trunk Identity Themes Motifs Modern
-@include trunk/Identity/Themes/Motifs/Modern.texi
-
-@node trunk Identity Themes Motifs Modern Backgrounds
-@section trunk/Identity/Themes/Motifs/Modern/Backgrounds
-@cindex trunk Identity Themes Motifs Modern Backgrounds
-@include trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi
-
-@node trunk Identity Themes Motifs Modern Backgrounds Img
-@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
-@cindex trunk Identity Themes Motifs Modern Backgrounds Img
-@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi
-
-@node trunk Identity Themes Motifs Modern Backgrounds Tpl
-@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
-@cindex trunk Identity Themes Motifs Modern Backgrounds Tpl
-@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi
-
-@node trunk Identity Themes Motifs Modern Backgrounds Xcf
-@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf
-@cindex trunk Identity Themes Motifs Modern Backgrounds Xcf
-@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi
-
-@node trunk Identity Themes Motifs Modern Distro Anaconda Progress
-@section trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
-@cindex trunk Identity Themes Motifs Modern Distro Anaconda Progress
-@include trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi
-
-@node trunk Identity Themes Motifs Modern Palettes
-@section trunk/Identity/Themes/Motifs/Modern/Palettes
-@cindex trunk Identity Themes Motifs Modern Palettes
-@include trunk/Identity/Themes/Motifs/Modern/Palettes.texi
-
-@node trunk Identity Themes Motifs TreeFlower
-@section trunk/Identity/Themes/Motifs/TreeFlower
-@cindex trunk Identity Themes Motifs TreeFlower
-@include trunk/Identity/Themes/Motifs/TreeFlower.texi
-
-@node trunk Identity Themes Motifs TreeFlower Backgrounds
-@section trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
-@cindex trunk Identity Themes Motifs TreeFlower Backgrounds
-@include trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi
-
-@node trunk Identity Widgets
-@section trunk/Identity/Widgets
-@cindex trunk Identity Widgets
-@include trunk/Identity/Widgets.texi
-
-@node trunk Locales
-@section trunk/Locales
-@cindex trunk Locales
-@include trunk/Locales.texi
-
-@node trunk Locales Identity
-@section trunk/Locales/Identity
-@cindex trunk Locales Identity
-@include trunk/Locales/Identity.texi
-
-@node trunk Locales Identity Brands
-@section trunk/Locales/Identity/Brands
-@cindex trunk Locales Identity Brands
-@include trunk/Locales/Identity/Brands.texi
-
-@node trunk Locales Identity Brands Tpl
-@section trunk/Locales/Identity/Brands/Tpl
-@cindex trunk Locales Identity Brands Tpl
-@include trunk/Locales/Identity/Brands/Tpl.texi
-
-@node trunk Locales Identity Fonts
-@section trunk/Locales/Identity/Fonts
-@cindex trunk Locales Identity Fonts
-@include trunk/Locales/Identity/Fonts.texi
-
-@node trunk Locales Identity Models
-@section trunk/Locales/Identity/Models
-@cindex trunk Locales Identity Models
-@include trunk/Locales/Identity/Models.texi
-
-@node trunk Locales Identity Release
-@section trunk/Locales/Identity/Release
-@cindex trunk Locales Identity Release
-@include trunk/Locales/Identity/Release.texi
-
-@node trunk Locales Identity Themes
-@section trunk/Locales/Identity/Themes
-@cindex trunk Locales Identity Themes
-@include trunk/Locales/Identity/Themes.texi
-
-@node trunk Locales Identity Themes Backgrounds
-@section trunk/Locales/Identity/Themes/Backgrounds
-@cindex trunk Locales Identity Themes Backgrounds
-@include trunk/Locales/Identity/Themes/Backgrounds.texi
-
-@node trunk Locales Identity Themes Distro Anaconda Progress
-@section trunk/Locales/Identity/Themes/Distro/Anaconda/Progress
-@cindex trunk Locales Identity Themes Distro Anaconda Progress
-@include trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi
-
-@node trunk Locales Identity Widgets
-@section trunk/Locales/Identity/Widgets
-@cindex trunk Locales Identity Widgets
-@include trunk/Locales/Identity/Widgets.texi
-
-@node trunk Manuals
-@section trunk/Manuals
-@cindex trunk Manuals
-@include trunk/Manuals.texi
-
-@node trunk Scripts
-@section trunk/Scripts
-@cindex trunk Scripts
-@include trunk/Scripts.texi
-
-@node trunk Scripts Bash
-@section trunk/Scripts/Bash
-@cindex trunk Scripts Bash
-@include trunk/Scripts/Bash.texi
-
-@node trunk Scripts Bash Cli
-@section trunk/Scripts/Bash/Cli
-@cindex trunk Scripts Bash Cli
-@include trunk/Scripts/Bash/Cli.texi
-
-@node trunk Scripts Bash Cli Functions
-@section trunk/Scripts/Bash/Cli/Functions
-@cindex trunk Scripts Bash Cli Functions
-@include trunk/Scripts/Bash/Cli/Functions.texi
-
-@node trunk Scripts Bash Cli Functions Help
-@section trunk/Scripts/Bash/Cli/Functions/Help
-@cindex trunk Scripts Bash Cli Functions Help
-@include trunk/Scripts/Bash/Cli/Functions/Help.texi
-
-@node trunk Scripts Bash Cli Functions Html
-@section trunk/Scripts/Bash/Cli/Functions/Html
-@cindex trunk Scripts Bash Cli Functions Html
-@include trunk/Scripts/Bash/Cli/Functions/Html.texi
-
-@node trunk Scripts Bash Cli Functions Locale
-@section trunk/Scripts/Bash/Cli/Functions/Locale
-@cindex trunk Scripts Bash Cli Functions Locale
-@include trunk/Scripts/Bash/Cli/Functions/Locale.texi
-
-@node trunk Scripts Bash Cli Functions Manual
-@section trunk/Scripts/Bash/Cli/Functions/Manual
-@cindex trunk Scripts Bash Cli Functions Manual
-@include trunk/Scripts/Bash/Cli/Functions/Manual.texi
-
-@node trunk Scripts Bash Cli Functions Path
-@section trunk/Scripts/Bash/Cli/Functions/Path
-@cindex trunk Scripts Bash Cli Functions Path
-@include trunk/Scripts/Bash/Cli/Functions/Path.texi
-
-@node trunk Scripts Bash Cli Functions Render
-@section trunk/Scripts/Bash/Cli/Functions/Render
-@cindex trunk Scripts Bash Cli Functions Render
-@include trunk/Scripts/Bash/Cli/Functions/Render.texi
-
-@node trunk Scripts Bash Cli Functions Render Config
-@section trunk/Scripts/Bash/Cli/Functions/Render/Config
-@cindex trunk Scripts Bash Cli Functions Render Config
-@include trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
-
-@node trunk Scripts Bash Cli Functions Shell
-@section trunk/Scripts/Bash/Cli/Functions/Shell
-@cindex trunk Scripts Bash Cli Functions Shell
-@include trunk/Scripts/Bash/Cli/Functions/Shell.texi
-
-@node trunk Scripts Bash Cli Functions Svg
-@section trunk/Scripts/Bash/Cli/Functions/Svg
-@cindex trunk Scripts Bash Cli Functions Svg
-@include trunk/Scripts/Bash/Cli/Functions/Svg.texi
-
-@node trunk Scripts Bash Cli Functions Verify
-@section trunk/Scripts/Bash/Cli/Functions/Verify
-@cindex trunk Scripts Bash Cli Functions Verify
-@include trunk/Scripts/Bash/Cli/Functions/Verify.texi
-
-@node trunk Scripts Python
-@section trunk/Scripts/Python
-@cindex trunk Scripts Python
-@include trunk/Scripts/Python.texi
-
diff --git a/Manuals/Repository/trunk/chapter.texi b/Manuals/Repository/trunk/chapter.texi
deleted file mode 100644
index 73ba088..0000000
--- a/Manuals/Repository/trunk/chapter.texi
+++ /dev/null
@@ -1,6 +0,0 @@
-@node trunk
-@chapter trunk
-@cindex trunk
-@include trunk/chapter-intro.texi
-@include trunk/chapter-menu.texi
-@include trunk/chapter-nodes.texi