diff --git a/Manuals/Filesystem/trunk/Scripts/Bash/Cli.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli.texi
new file mode 100755
index 0000000..e69de29
--- /dev/null
+++ b/Manuals/Filesystem/trunk/Scripts/Bash/Cli.texi
diff --git a/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi
new file mode 100755
index 0000000..2a421ab
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi
new file mode 100644
index 0000000..bf264c9
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi
new file mode 100644
index 0000000..fb39647
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi
new file mode 100644
index 0000000..a7c6c55
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi
new file mode 100644
index 0000000..7dfe2c5
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi
new file mode 100644
index 0000000..3b3322b
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi
new file mode 100644
index 0000000..a5016fe
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi
new file mode 100644
index 0000000..341745d
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi b/Manuals/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi
new file mode 100644
index 0000000..ff98b51
--- /dev/null
+++ b/Manuals/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/Filesystem/trunk/Scripts/Bash/cli.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli.texi
deleted file mode 100755
index e69de29..0000000
--- a/Manuals/Filesystem/trunk/Scripts/Bash/cli.texi
+++ /dev/null
diff --git a/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions.texi
deleted file mode 100755
index 2a421ab..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Help.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Help.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Html.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Html.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Locale.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Locale.texi
deleted file mode 100644
index bf264c9..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Manual.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Manual.texi
deleted file mode 100644
index fb39647..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Path.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Path.texi
deleted file mode 100644
index a7c6c55..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Render.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Render.texi
deleted file mode 100644
index 7dfe2c5..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Render/Config.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Render/Config.texi
deleted file mode 100644
index 3b3322b..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Shell.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Shell.texi
deleted file mode 100644
index a5016fe..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Svg.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Svg.texi
deleted file mode 100644
index 341745d..0000000
--- a/Manuals/Filesystem/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/Filesystem/trunk/Scripts/Bash/cli/Functions/Verify.texi b/Manuals/Filesystem/trunk/Scripts/Bash/cli/Functions/Verify.texi
deleted file mode 100644
index ff98b51..0000000
--- a/Manuals/Filesystem/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