From 52772c766a6e4227801c42eec3b3a4ecd0c1c637 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Mar 22 2011 21:28:08 +0000 Subject: Update repository documentation manual. --- diff --git a/Manual/Filesystem/trunk/Identity.texi b/Manual/Filesystem/trunk/Identity.texi index 861f994..3a36cc1 100644 --- a/Manual/Filesystem/trunk/Identity.texi +++ b/Manual/Filesystem/trunk/Identity.texi @@ -152,7 +152,7 @@ In order to produce content inside rendereble directories, you can use the following command: @verbatim -centos-art identity --render='trunk/Identity/Path/To/Dir' +centos-art render trunk/Identity/Path/To/Dir @end verbatim @quotation diff --git a/Manual/repository-html/repository.html b/Manual/repository-html/repository.html index 1fe5e73..b08ff4c 100644 --- a/Manual/repository-html/repository.html +++ b/Manual/repository-html/repository.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + - + - + -CentOS Artwork Repository: 2.6 The trunk/Identity/Colors Directory +CentOS Artwork Repository: 2.3 The trunk Directory - - + + @@ -55,66 +55,112 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.6 The `trunk/Identity/Colors' Directory

+ + +

2.3 The `trunk' Directory

- -

2.6.1 Goals

+ +

2.3.1 Goals

- +

This directory implements the Subversion's trunk concept in a +trunk, branches, tags repository structure. +

+ +

2.3.2 Description

- -

2.6.2 Description

+

The `trunk/' directory structure is the main development line +inside the CentOS Artwork Repository and organizes the following +sections: +

+
+
Identity
+

This section organizes image production in different formats and some +non-image formats like XHTML and text files, as well. This is the +perfect place to consolidate The CentOS Artwork SIG. If you are +interested in producing art works for The CentOS Project, this place +is for you. +

+

See section The `trunk/Identity' Directory, for more information. +

+
+
Manual
+

This section organizes the CentOS Artwork Repository Manual +(i.e., the documentation manual you're reading right now). If you are +interested on improving The CentOS Artwork Repository Manual, in this +place you'll find the Texinfo documentation structure you need to work +with. +

+

See section The `trunk/Manual' Directory, for more information. +

+
+
Scripts
+

This section organizes production of automation scripts specially +designed to automate most frequent tasks in the repository (e.g., +image rendition, documenting directory structures, translating +content, etc.). If you can't resist the idea of automating repeatable +tasks, then take a look here. +

+

See section The `trunk/Scripts' Directory, for more information. +

+
+
Locales
+

This section organizes production of translation messages for +Identity, Documentation and Scripts. This place +is perfect to consolidate The CentOS Translation SIG. If you +love translating, you'll find lot of messages waiting for you to +translate here. +

+

See section The `trunk/Locales' Directory, for more information. +

+
- + +

2.3.3 Usage

- -

2.6.3 Usage

+

It seems to be no other use for this directory but to organize the +sections described above. +

+ + +

2.3.4 See also

- -

2.6.4 See also

- - - - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_11.html b/Manual/repository-html/repository_11.html index 282de6e..a358cfd 100644 --- a/Manual/repository-html/repository_11.html +++ b/Manual/repository-html/repository_11.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.7 The trunk/Identity/Fonts Directory +CentOS Artwork Repository: 2.4 The trunk/Identity Directory - - + + @@ -55,124 +55,276 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.7 The `trunk/Identity/Fonts' Directory

+ + +

2.4 The `trunk/Identity' Directory

- -

2.7.1 Goals

+ +

2.4.1 Goals

-

This section exists to organize digital typographies used by the -CentOS project. +

The `trunk/Identity' directory structure implements The +CentOS Project Corporate Identity.

- -

2.7.2 Description

+ +

2.4.2 Description

+

The CentOS Project corporate identity is the "persona" of the +organization known as The CentOS Project. The CentOS Project +corporate identity plays a significant role in the way the CentOS +Project, as organization, presents itself to both internal and +external stakeholders. In general terms, the CentOS Project corporate +visual identity expresses the values and ambitions of the CentOS +Project organization, its business, and its characteristics. +

+

The CentOS Project corporate identity provides visibility, +recognizability, reputation, structure and identification to The +CentOS Project organization by means of Corporate Design, +Corporate Communication, and Corporate Behaviour. +

- -

2.7.3 Usage

+ +

2.4.2.1 Corporate Design

-

The CentOS corporate identity is attached to `DejaVu LGC' -font-family. Whatever artwork you design for CentOS project, that -requires typography usage, must be done using `DejaVu LGC' -font-family. +

The CentOS Project corporate design is applied to every single visual +manifestations The CentOS Project as organization wants to express its +existence. Examples of the most relevant visual manifestations inside +The CentOS Project are The CentOS Distribution, The +CentOS Web and The CentOS Stationery. +

+

The CentOS Project corporate design is organized in the following +work-lines:

-
Recommendation-1:
-
-

For screen desings (e.g., anything that final destination will never -be printed on paper or any medium outside computer screens) use -`DejaVu LGC Sans' font-family. +

The CentOS Brand
+

The CentOS Brand is the name or trademark that connects the producer +with their products. In this case, the producer is The CentOS Project +and the products are The CentOS Project visual manifestations. +

+

See section The `trunk/Identity/Brands' Directory, for more information.

-
Recommendation-2:
+
The CentOS Colors
+
+

The CentOS Fonts provides the color information used along The CentOS +Project visual manifestations. +

+

See section The `trunk/Identity/Colors' Directory, for more information. +

+
The CentOS Fonts
+
+

The CentOS Fonts provides the typography information used along The +CentOS Project visual manifestations. +

+

See section The `trunk/Identity/Fonts' Directory, for more information. +

+
The CentOS Themes
-

For non-screen designs (e.g., anything that final desition will be -printed on paper or any other medium outside computer screens) use -`DejaVu LGC Serif' font-family. As convenction files described in -this rule are stored under `Stationery' directories. +

The CentOS Themes provides structural information and visual style +information, as well, used along The CentOS Project visual +manifestations. +

+

See section The `trunk/Identity/Themes' Directory, for more information.

-

The only execption for the two recommendations above is the typography -used inside CentOS logo. The CentOS logo is the main visual -representation of the CentOS project so the typography used in it must -be the same always, no matter where it be shown. It also has to be -clear enough to dismiss any confussion between similar typefaces -(e.g., the number one (1) sometimes is confuesed with the letter -`el' (l) or letter `ai' (i)). -

-

As CentOS logo typography convenction, the word `CentOS' uses -`Denmark' typography as base, both for the word `CentOS' and -the phrase `Community Enterprise Operating System'. The phrase -size of CentOS logo is half the size in poits the word `CentOS' -has and it below `CentOS' word and aligned with it on the left. -The distance between `CentOS' word and phrase `Community -Enterprise Operating System' have the size in points the phrase has. -

-

When the CentOS release brand is built, use `Denmark' typography -for the release number. The release number size is two times larger -(in height) than default `CentOS' word. The separation between -release number and `CentOS' word is twice the size in points of -separation between `CentOS' word and phrase `Community -Enterprise Operating System'. -

-

Another component inside CentOS logo is the trademark symbol (TM). -This symbol specifies that the CentOS logo must be consider a product -brand, even it is not a registered one. The trademark symbol uses -DejaVu LGC Sans Regular typography. The trademark symbol is aligned -right-top on the outter side of `CentOS' word. The trademark -symbol must not exceed haf the distance, in points, between -`CentOS' word and the release number on its right. -

-

It would be very convenient for the CentOS Project and its community -to to make a registered trademark (®) of CentOS logo. To make a -register trademark of CentOS Logo prevents legal complications in the -market place of brands. It grants the consistency, through time, of -CentOS project corporate visual identity. -

-
info

Note

The information about trademarks and corporate identity -is my personal interpretation of -http://en.wikipedia.org/Corporate_identity and -http://en.wikipedia.org/Trademark description. If you have -practical experiences with these affairs, please serve yourself to -improve this section with your reasons. -

+ +

2.4.2.2 Corporate Communication

+ +

The CentOS Project corporate communication is based on community +communication. In that sake, the following media are available for +corporate communication: +

+ + + + +

2.4.2.3 Corporate Behaviour

+ +

The CentOS Project corporate behaviour is based on community +behaviour. +

+ + +

2.4.2.4 Corporate Structure

- -

2.7.4 See also

+

The CentOS Project corporate structure is based on a monolithic +corporate visual identity structure. In this structure, we use one +unique name (The CentOS Brand) and one unique visual style (The CentOS +Theme) in all The CentOS Project visual manifestations. +

+

Inside a monolithic corporate visual identity structure, internal and +external stakeholders use to feel a strong sensation of uniformity, +orientation, and identification with the organization. No matter if +you are visiting web sites, using the distribution, or acting on +social events, the one unique name and one unique visual style +connects them all to say: Hey! we are all part of The CentOS +Project. +

+

Other corporate structures have been considered as well, but they +introduce visual contradictions we need to be aware of. In that sake, +lets describe the idea of: Producing one different visual style +for each major release of The CentOS Distribution. +

+

The CentOS Project maintains near to four different major releases of +The CentOS Distribution parallely in time and that fact makes one part +of The CentOS Project structural design, but just one part, not the +complete structural design. In order to produce the correct corporate +structure for The CentOS Project we need to concider all the visual +manifestations The CentOS Project is made of, not just one of them. +

+

If one different visual style is used for each major release of The +CentOS Distribution, which one of those different visual styles would +be used to cover the remaining visual manifestations The CentOS +Project is made of. Would we end up with four different visual styles, +one for each distribution? In that case, why The CentOS Distribution +we use shows one visual style, The CentOS Web sites another and The +CentOS Stationery even another completly different one? Isn't them +all part of the same project? +

+

Probably you be thinking, that's right, but The CentOS Brand connects +them all already, why would we need to join them up into the same +visual style too, isn't it more work to do, and harder to maintain? +

+

Harder to maintain, more work to do, it is probably. Specially when +you consider that The CentOS Project has proven stability and +consistency through time and that, certainly, didn't come through +swinging magical wangs or something but hardly working out to automate +tasks and so providing maintainance through time. Said that, we +consider that The CentOS Project visual structure should be consequent +with such stability and consistency tradition. It is true The CentOS +Brand does connect all the visual manifestations it is present on, but +that connection would be stronger if one unique visual style backups +it. In fact, whatever thing you do to strength the visual connection +among The CentOS Project visual manifestations would be very good in +favor of The CentOS Project recognition. +

+

Obviously, having just one visual style in all visual manifestations +for eternity would be a very boring thing and would give the idea of a +visually dead project. So, there is no problem on creating a brand new +visual style for each new major release of The CentOS Distribution, in +order to refresh The CentOS Distribution visual style; the problem +does is in not propagating the brand new visual style created for the +new release of CentOS Distribution to all other visual manifestations +The CentOS Project is made of, in a way The CentOS Project could be +recognized no matter what visual manifestation be in front of us. Such +lack of uniformity is what introduces the visual contradition we are +precisely trying to solve by mean of themes production in the CentOS +Artwork Repository. +

+ + +

2.4.3 Usage

+ +

The `trunk/' directory structure is organized in +renderable and non-renderable directories. Generally, +renderable directories contain two non-renderable directories inside, +one to store design templates (the `Tpl/' directory), and other +to store the content produced (the `Img/' directory). +

+

In order to produce content inside rendereble directories, you can use +the following command: +

+
centos-art render trunk/Identity/Path/To/Dir
+
+
Warning

Warning

If the centos-art command-line +is not found in your workstation, it is probably because you haven't +prepared it for using The CentOS Artwork Repository yet. +See section The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory, for more +information. +

+ +

This command takes one design template from the template directory and +creates an instance of it in order to apply translation messages on +it, if any. Later, using the design template instance, the command +renders the final content based on whether the design template +instance is a SVG file or a Docbook file. If the design template +instace is a SVG file, the final content produced is a PNG image. On +the other hand, if the design template instance is a Docbook file, the +final content produced is a XHTML file. Final content is stored in the +image directory using the design template directory paths as referece. +The rendition flow described so far is known as the +base-rendition flow. +

+

Besides the base-rendition flow, the centos-art provides the +post-rendition and last-rendition flows. The +post-rendition flow is applied to files produced as result of +base-rendition flow under the same directory structure. For example, +you can use post-rendition action to convert the PNG base output into +different outputs (e.g., JPG, PDF, etc.) before passing to process the +next file in the same directory structure. The last-rendition flow is +applied to all files produced as result of both base-rendition and +post-rendition flows in the same directory structure, just before +passing to process a different directory structure. For example, the +`Preview.png' image from Ksplash component is made of three +images. In order to build the `Preview.png' image through +centos-art we need to wait for all the three images the +`Preview.png' image is made of to be rendered, so we can combine +them all together into just one image (i.e., the `Preview.png' +image). This is something we can't do using post-rendition flow. +

+

Inside `trunk/Identity' directory structure, you can find that +base-rendition, post-rendition and last-rendition flows can be +combined to build directory-specific rendition. The +directory-specific rendition exists to automatically process specific +renderable directories in very specific ways. Using directory-specific +rendition speeds up production of different components like Syslinux, +Grub, Gdm, Kdm and Ksplash that require intermediate formats or even +several independent files, in order to reach its final construction. +Directory-specific rendition is a way to programmatically describe how +specific art works are built in and organized inside The CentOS +Artwork Repository. Such descriptions have been added to +centos-art command-line to let you produce them all with +just one single command, as fast as your machine can be able to handle +it. +

+

See section The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory, for more +information about the identity functionality of +centos-art command-line interface. +

+ +

2.4.4 See also

+

See http://en.wikipedia.org/Corporate_identity (and related +links), for general information on corporate identity. +

+

Specially useful has been, and still be, the book Corporate +Identity by Wally Olins (1989). This book provides many conceptual +ideas we've used as base to build The CentOS Artwork Repository. +

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_12.html b/Manual/repository-html/repository_12.html index 9832078..044298c 100644 --- a/Manual/repository-html/repository_12.html +++ b/Manual/repository-html/repository_12.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.8 The trunk/Identity/Icons Directory +CentOS Artwork Repository: 2.5 The trunk/Identity/Brands Directory - - + + @@ -55,58 +55,58 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.8 The `trunk/Identity/Icons' Directory

+ + +

2.5 The `trunk/Identity/Brands' Directory

- -

2.8.1 Goals

+ +

2.5.1 Goals

- -

2.8.2 Description

+ +

2.5.2 Description

- -

2.8.3 Usage

+ +

2.5.3 Usage

- -

2.8.4 See also

+ +

2.5.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_13.html b/Manual/repository-html/repository_13.html index 05a2f96..4c79cf6 100644 --- a/Manual/repository-html/repository_13.html +++ b/Manual/repository-html/repository_13.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.9 The trunk/Identity/Isolinux Directory +CentOS Artwork Repository: 2.6 The trunk/Identity/Colors Directory - - + + @@ -55,58 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.9 The `trunk/Identity/Isolinux' Directory

+ + +

2.6 The `trunk/Identity/Colors' Directory

- -

2.9.1 Goals

+ +

2.6.1 Goals

- -

2.9.2 Description

+ +

2.6.2 Description

+ + - -

2.9.3 Usage

+ +

2.6.3 Usage

+ + - -

2.9.4 See also

+ +

2.6.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_14.html b/Manual/repository-html/repository_14.html index 49e253a..ff472b8 100644 --- a/Manual/repository-html/repository_14.html +++ b/Manual/repository-html/repository_14.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.10 The trunk/Identity/Models Directory +CentOS Artwork Repository: 2.7 The trunk/Identity/Fonts Directory - - + + @@ -55,69 +55,124 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.10 The `trunk/Identity/Models' Directory

+ + +

2.7 The `trunk/Identity/Fonts' Directory

- -

2.10.1 Goals

+ +

2.7.1 Goals

-

This section exists to organize design models. +

This section exists to organize digital typographies used by the +CentOS project.

- -

2.10.2 Description

+ +

2.7.2 Description

-

Design models are representative designs useful to understand how -to build artworks. -

- -

2.10.3 Usage

+ +

2.7.3 Usage

+ +

The CentOS corporate identity is attached to `DejaVu LGC' +font-family. Whatever artwork you design for CentOS project, that +requires typography usage, must be done using `DejaVu LGC' +font-family. +

+
+
Recommendation-1:
+
+

For screen desings (e.g., anything that final destination will never +be printed on paper or any medium outside computer screens) use +`DejaVu LGC Sans' font-family. +

+
+
Recommendation-2:
+
+

For non-screen designs (e.g., anything that final desition will be +printed on paper or any other medium outside computer screens) use +`DejaVu LGC Serif' font-family. As convenction files described in +this rule are stored under `Stationery' directories. +

+
+ +

The only execption for the two recommendations above is the typography +used inside CentOS logo. The CentOS logo is the main visual +representation of the CentOS project so the typography used in it must +be the same always, no matter where it be shown. It also has to be +clear enough to dismiss any confussion between similar typefaces +(e.g., the number one (1) sometimes is confuesed with the letter +`el' (l) or letter `ai' (i)). +

+

As CentOS logo typography convenction, the word `CentOS' uses +`Denmark' typography as base, both for the word `CentOS' and +the phrase `Community Enterprise Operating System'. The phrase +size of CentOS logo is half the size in poits the word `CentOS' +has and it below `CentOS' word and aligned with it on the left. +The distance between `CentOS' word and phrase `Community +Enterprise Operating System' have the size in points the phrase has. +

+

When the CentOS release brand is built, use `Denmark' typography +for the release number. The release number size is two times larger +(in height) than default `CentOS' word. The separation between +release number and `CentOS' word is twice the size in points of +separation between `CentOS' word and phrase `Community +Enterprise Operating System'. +

+

Another component inside CentOS logo is the trademark symbol (TM). +This symbol specifies that the CentOS logo must be consider a product +brand, even it is not a registered one. The trademark symbol uses +DejaVu LGC Sans Regular typography. The trademark symbol is aligned +right-top on the outter side of `CentOS' word. The trademark +symbol must not exceed haf the distance, in points, between +`CentOS' word and the release number on its right. +

+

It would be very convenient for the CentOS Project and its community +to to make a registered trademark (®) of CentOS logo. To make a +register trademark of CentOS Logo prevents legal complications in the +market place of brands. It grants the consistency, through time, of +CentOS project corporate visual identity. +

+
info

Note

The information about trademarks and corporate identity +is my personal interpretation of +http://en.wikipedia.org/Corporate_identity and +http://en.wikipedia.org/Trademark description. If you have +practical experiences with these affairs, please serve yourself to +improve this section with your reasons. +

- -

2.10.4 See also

+ +

2.7.4 See also

- - - - - -
2.12 The `trunk/Identity/Models/Html' Directory   -
2.11 The `trunk/Identity/Models/Css' Directory   -
2.14 The `trunk/Identity/Models/Tpl' Directory   -
2.17 The `trunk/Identity/Models/Xcf' Directory   -
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_15.html b/Manual/repository-html/repository_15.html index 8bc8628..83560e0 100644 --- a/Manual/repository-html/repository_15.html +++ b/Manual/repository-html/repository_15.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.11 The trunk/Identity/Models/Css Directory +CentOS Artwork Repository: 2.8 The trunk/Identity/Icons Directory - - + + @@ -55,65 +55,58 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.11 The `trunk/Identity/Models/Css' Directory

+ + +

2.8 The `trunk/Identity/Icons' Directory

- -

2.11.1 Goals

- -

This directory exists to provide common style sheets (CSS) definitions -to HTML design models. -

- - -

2.11.2 Description

+ +

2.8.1 Goals

- -

2.11.3 Usage

+ +

2.8.2 Description

- + + +

2.8.3 Usage

- -

2.11.4 See also

+ +

2.8.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_16.html b/Manual/repository-html/repository_16.html index ab846c1..dfe3b03 100644 --- a/Manual/repository-html/repository_16.html +++ b/Manual/repository-html/repository_16.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.12 The trunk/Identity/Models/Html Directory +CentOS Artwork Repository: 2.9 The trunk/Identity/Isolinux Directory - - + + @@ -55,66 +55,58 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.12 The `trunk/Identity/Models/Html' Directory

+ + +

2.9 The `trunk/Identity/Isolinux' Directory

- -

2.12.1 Goals

+ +

2.9.1 Goals

- -

2.12.2 Description

- - + +

2.9.2 Description

- -

2.12.3 Usage

- - + +

2.9.3 Usage

- -

2.12.4 See also

+ +

2.9.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_17.html b/Manual/repository-html/repository_17.html index 9f667a5..4748527 100644 --- a/Manual/repository-html/repository_17.html +++ b/Manual/repository-html/repository_17.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.13 The trunk/Identity/Models/Img/Promo/Web Directory +CentOS Artwork Repository: 2.10 The trunk/Identity/Models Directory - - + + @@ -55,70 +55,69 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory

+ + +

2.10 The `trunk/Identity/Models' Directory

- -

2.13.1 Goals

+ +

2.10.1 Goals

- - - - -

2.13.2 Description

- - +

This section exists to organize design models. +

+ +

2.10.2 Description

- -

2.13.3 Usage

+

Design models are representative designs useful to understand how +to build artworks. +

- + +

2.10.3 Usage

- -

2.13.4 See also

+ +

2.10.4 See also

- + + +
2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory   +
2.12 The `trunk/Identity/Models/Html' Directory   +
2.11 The `trunk/Identity/Models/Css' Directory   +
2.14 The `trunk/Identity/Models/Tpl' Directory   +
2.17 The `trunk/Identity/Models/Xcf' Directory  
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_18.html b/Manual/repository-html/repository_18.html index 8cc46dd..8deaa64 100644 --- a/Manual/repository-html/repository_18.html +++ b/Manual/repository-html/repository_18.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.14 The trunk/Identity/Models/Tpl Directory +CentOS Artwork Repository: 2.11 The trunk/Identity/Models/Css Directory - - + + @@ -55,66 +55,65 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.14 The `trunk/Identity/Models/Tpl' Directory

+ + +

2.11 The `trunk/Identity/Models/Css' Directory

- -

2.14.1 Goals

- - + +

2.11.1 Goals

+

This directory exists to provide common style sheets (CSS) definitions +to HTML design models. +

- -

2.14.2 Description

+ +

2.11.2 Description

- -

2.14.3 Usage

+ +

2.11.3 Usage

- -

2.14.4 See also

+ +

2.11.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_19.html b/Manual/repository-html/repository_19.html index 96793fd..bdbd0b1 100644 --- a/Manual/repository-html/repository_19.html +++ b/Manual/repository-html/repository_19.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.15 The trunk/Identity/Models/Tpl/Brands Directory +CentOS Artwork Repository: 2.12 The trunk/Identity/Models/Html Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.15 The `trunk/Identity/Models/Tpl/Brands' Directory

+ + +

2.12 The `trunk/Identity/Models/Html' Directory

- -

2.15.1 Goals

+ +

2.12.1 Goals

- -

2.15.2 Description

+ +

2.12.2 Description

- -

2.15.3 Usage

+ +

2.12.3 Usage

- -

2.15.4 See also

+ +

2.12.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_2.html b/Manual/repository-html/repository_2.html index b35e90c..9b20412 100644 --- a/Manual/repository-html/repository_2.html +++ b/Manual/repository-html/repository_2.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 1.1 Document Convenctions +CentOS Artwork Repository: 1.1 History - - + + @@ -56,144 +56,166 @@ ul.toc {list-style: none} - + - + - +
[ < ][ > ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- + -

1.1 Document Convenctions

- -

In this manual the word we, as personal pronoun, is used to -repesent The CentOS Artwork SIG, the group of persons building -the CentOS Artwork Repository. -

-

In this manual, certain words are represented in different fonts, -typefaces, sizes, and weights. This highlighting is systematic; -different words are represented in the same style to indicate their -inclusion in a specific category. The types of words that are -represented this way include the following: -

-
-
command
-
-

Linux commands (and other operating system commands, when used) are -represented this way. This style should indicate to you that you can -type the word or phrase on the command line and press Enter to invoke -a command. Sometimes a command contains words that would be displayed -in a different style on their own (such as file names). In these -cases, they are considered to be part of the command, so the entire -phrase is displayed as a command. For example: -

-

Use the centos-art identity --render='path/to/dir' command -to produce contents inside the `trunk/Identity' directory -structure. -

-
- -
-
`file name'
-
-

File names, directory names, paths, and RPM package names are -represented this way. This style indicates that a particular file or -directory exists with that name on your system. Examples: -

-

The `init.sh' file in `trunk/Scripts/Bash/Cli/' directory is -the initialization script, written in Bash, used to automate most of -tasks in the repository. -

-

The centos-art command uses the `ImageMagick' RPM -package to convert images from PNG format to other formats. -

-
- -
-
key
-
-

A key on the keyboard is shown in this style. For example: -

-

To use TAB completion to list particular files in a directory, -type ls, then a character, and finally the Tab key. Your -terminal displays the list of files in the working directory that -begin with that character. -

-
- -
-
key-combination
-

A combination of keystrokes is represented in this way. For example: -

-

The Ctrl-Alt-Backspace key combination exits your graphical -session and returns you to the graphical login screen or the console. -

-
- -
-
computer output
-
-

Text in this style indicates text displayed to a shell prompt such as -error messages and responses to commands. For example: -

-

The ls command displays the contents of a directory. For example: -

-
Config                           manual_renameEntry.sh
-manual_copyEntry.sh              manual_restoreCrossReferences.sh
-manual_deleteCrossReferences.sh  manual_searchIndex.sh
-
-

The output returned in response to the command (in this case, the -contents of the directory) is shown in this style. -

-
+

1.1 History

-

Additionally, we use several different strategies to draw your -attention to certain pieces of information. In order of urgency, these -items are marked as a note, tip, important, caution, or warning. For -example: +

This section records noteworthy changes of CentOS Artwork Repository.

-
info

Note

Remember that Linux is case sensitive. In other words, a -rose is not a ROSE is not a rOsE. -

- -
Info

Tip

The directory `/usr/share/doc/' contains additional -documentation for packages installed on your system. -

- -
Important

Important

If you modify the DHCP configuration file, the -changes do not take effect until you restart the DHCP daemon. -

- -
Caution

Caution

Do not perform routine tasks as root -- use a -regular user account unless you need to use the root account for -system administration tasks. -

+ +

2008

-
Warning

Warning

Be careful to remove only the necessary partitions. -Removing other partitions could result in data loss or a corrupted -system environment. -

+

The CentOS Artwork Repository started at CentOS Developers mailing +list (centos-devel@centos.org) during a discussion about how +to automate the slide images of Anaconda. In such discussion, Ralph +Angenendt rose up his hand to ask: Do you have something to show? +

+

To answer the question, Alain Reguera Delgado posted a bash script to +produce slide images in different languages --together with the +proposition of creating a Subversion centralized repository where +translations and image production could be distributed inside The +CentOS Community--. +

+

Karanbirn Sighn considered the idea intresting and provides the +infrastructure to support the effort. This way both the CentOS Artwork +SIG and the CentOS Artwork Repository were created. +

+ + +

Once the CentOS Artwork Repository was available, Alain Reguera +Delagdo uploaded the bash script for rendering Anaconda slides and +Ralph Angenendt documented the script very well. +

+

Once the rendition script and its documentation were available online, +translators started to download working copies of CentOS Artwork +Repository to produce slide images in their own languages. +

+ +

2009

+ +

The rendition script is designed to take one SVG file, apply one SED +file with replacement command inside to produce one SVG translated +instance that is used to produce one translated PNG image by means of +Inkscape program. The rendition script was named render.sh +and it is copied to each directory structure that requires such +process to produce images. +

+

Furthermore, functionalies are centralized in a common placed and +linked from different directory structures. There is no need to have +the same code in different directory structures if can have it in just +one place and then create links to it. +

+

Start to implement concepts about corporate identity. As referece it +is used Wikipedia (http://en.wikipedia.org/Corporate_identity) +and the book Corporate Identity by Wally Olins (1989). The main +goal of render.sh becomes to: automate production of a +monolithic corporate visual identity structure based on The CentOS +Mission and The CentOS Release Schema. +

+

Around March, Alain Reguera Delgado is out of Internet for an +undefined amount of time, but continues developing the idea of CentOS +Artwork Repository and the rendition script off-line. +

+

Most of the work I propose from this time on is my own responsability. +I keep myself thinking to be part of the CentOS Artwork SIG and in +that sake, I use the personal pronoun we to refer what I do as +part of the group hoping someday to share this work with you again and +improve it together. +

+

The CentOS Artwork Repository documentation starts to take form in +LaTeX format. +

+ +

2010

+ +

The render.sh is removed from the repository directory +structures and the centos-art.sh script is used instead. The +centos-art.sh is created to be a command-line interface that +automate most frequent tasks inside the repository and can be called +anywhere inside the repository or outside it; whenever it points to a +directory structure inside the repository. At the very first moments +of using centos-art.sh command-line, it used to have the +following using form: +

+
centos-art function --action=path/to/dir
+
+

Inside the rendition script, functionalities started to get identified +and separated one another. For example, when images are rendered, +there is no need to load manual functionality. There are now common +functionalities and specific functionalities. Common functionalities +are loaded when the script is initiated and are available to specific +functionalities. +

+

Start using getopt to handle command-line options. +

+

The repository directory structure is optimized to continue +implementing corporate identity concepts and the centos-art +command-line. +

+ +

2011

+

The `trunk/Translation' directory structure is removed. The +`trunk/Locales' directory structure is used instead to store locale +information. +

+

The `.sed' translation files are no longer used, scalable vector +graphics are used instead. Translation messages take place by means +of xml2po and gettext. With xml2po translatable strings are retrived +from `.svg' files and stored inside gettext `.pot' and `.po' files for +translators to edit. Finally, xml2po is used again to build the +temporal design model translated instance which the final `.png' image +is built from. +

+

Inside centos-art.sh, update command-line arguments and +options parsing. Keep using getopt to parse options passed +in the command-line, but change the way centos-art.sh is +called from. The following form is used: +

+
centos-art function path/to/dir --options
+
+

Start using verbs to name the centos-art.sh functionalities. +

+

Organize centos-art.sh functionalities in "administrative" +functions and "productive" functions. Administrative functions +cover actions like: copying, deleting and renaming directory +structures. Also, preparing your workstation for using +centos-art command-line, make backups of the distribution +theme currently installed, installing themes created inside The +CentOS Artwork repository and restoring themes from backup. On the +other hand, productive functions cover actions like: content +rendition, content localization, content documentation and content +maintainance. +

- + - +
[ < ][ > ][ > ]   [ << ] [ Up ][ >> ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_20.html b/Manual/repository-html/repository_20.html index 3076322..649dee4 100644 --- a/Manual/repository-html/repository_20.html +++ b/Manual/repository-html/repository_20.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.16 The trunk/Identity/Models/Tpl/Promo/Web Directory +CentOS Artwork Repository: 2.13 The trunk/Identity/Models/Img/Promo/Web Directory - - + + @@ -55,374 +55,70 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory

+ + +

2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory

- -

2.16.1 Goals

+ +

2.13.1 Goals

-

Organize scalable vector graphics (svg) to help describe the CentOS -web environment. -

- - -

2.16.2 The CentOS web environment

- -

Inside CentOS corporate identity, the CentOS web environment is -considered a promotion component. The CentOS web environment is formed -by a central web application --to cover base needs (e.g., per-major -release information like release notes, lifetime, downloads, -documentation, support, security advisories, bugs, etc.)-- and many -different free web applications --to cover specific needs (e.g., -wiki, mailing lists, etc.)--. -

-

The CentOS web environment is addressed to solve the following issues: -

-

The CentOS project is attached to a monolithic corporate visual -identity (see section The `trunk/Identity' Directory), where all visual manifestations -have one unique name and one unique visual style. This way, the CentOS -web environment has one unique name (the CentOS brand) and one unique -visual style (the CentOS default theme) for all its visual -manifestations, the web applications in this case. -

-

Since a maintainance point of view, achiving the one unique visual -style inside CentOS web environment is not a simple task. The CentOS -web environment is built upon many different web applications which -have different visual styles and different internal ways to customize -their own visual styles. For example: MoinMoin, the web application -used to support the CentOS wiki (http://wiki.centos.org/) is -highly customizable but Mailman (in its 2.x.x serie), the web -application used to support the CentOS mailing list, doesn't -support(1) a customization system that separates -presentation from logic, similar to that used by MoinMoin. -

-

This visual style diversity complicates our goal of one unique visual -style for all web applications. So, if we want one unique visual style -for all web applications used, it is innevitable to modify the web -applications in order to implement the CentOS one unique visual style -customization in them. Direct modification of upstream applications is -not convenient because upstream applications come with their one -visual style and administrators take the risk of loosing all -customization changes the next time the application be updated (since -not all upstream web applications, used in CentOS web environment, -separate presentation from logic). -

-

To solve the "one unique visual style" issue, installation and -actualization of web applications --used inside CentOS web -environment-- need to be independent from upstream web applications -development line; in a way that CentOS web environment administrators -can install and update web applications freely without risk of loosing -the one unique visual style customization changes. -

-

At the surface of this issue we can see the need of one specific yum -repository to store CentOS web environment customized web applications. -

- - -

2.16.2.1 Design model (without ads)

- - -

2.16.2.2 Design model (with ads)

+ +

2.13.2 Description

+ - -

2.16.2.3 HTML definitions

- - - -

2.16.2.4 Controlling visual style

- -

Inside CentOS web environment, the visual style is controlled by the -following compenents: -

-
-
Webenv header background
-
trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
-
-
-
CSS definitions
-
trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css
-
-
- - - -

2.16.2.5 Producing visual style

- -

The visual style of CentOS web environment is defined in the following -files: -

-
trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png
-trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg
-
-

As graphic designer you use `1024x250.xcf' file to produce -`1024x250-bg.png' file. Later, inside `1024x250.svg' file, -you use the `1024x250-bg.png' file as background layer to draw -your vectorial design. When you consider you artwork ready, use the -centos-art.sh script, as described below, to produce the -visual style controller images of CentOS web environment. -

-
centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250'
-
-

Once you have rendered required image files, changing the visual style -of CentOS web environment is a matter of replacing old image files -with new ones, inside webenv repository file system structure. The -visual style changes will take effect the next time customization line -of CentOS web applications be packaged, uploded, and installed from -[webenv] or [webenv-test] repositories. -

- - -

2.16.2.6 Navigation

- -

Inside CentOS web environment, the one-step navegation between web -applications is addressed using the web environment navigation bar. -The web environment navigation bar contains links to main applications -and is always visible no matter where you are inside the web -environment. -

- - -

2.16.2.7 Development and release cycle

- -

The CentOS web environment development and relase cycle is described -below: -

-
-
Download
-
-

The first action is download the source code of web applications we -want to use inside CentOS web environment. -

-
Important

Important

The source location from which web application are -downloaded is very important. Use SRPMs from CentOS [base] -and [updates] repositories as first choise, and third party -repositories (e.g. RPMForge, EPEL, etc.) as last resource. -

- -
-
Prepare
-
-

Once web application source code has been downloaded, our duty is -organize its files inside `webenv' version controlled repository. -

-

When preparing the structure keep in mind that different web -applications have different visual styles, and also different ways to -implement it. A convenient way to organize the file system structure -would be create one development line for each web application we use -inside CentOS web environment. For example, consider the following -file system structure: -

-
https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-|   |-- Sources/
-|   |   `-- webapp1-0.0.1/
-|   |-- Rpms/
-|   |   `-- webapp1-0.0.1.rpm
-|   |-- Srpms/
-|   |   `-- webapp1-0.0.1.srpm
-|   `-- Specs/
-|       `-- webapp1-0.0.1.spec
-|-- WebApp2/
-`-- WebAppN/
-
-
-
Customize
-
-

Once web applications have been organized inside the version -controlled repository file system, use subversion to create the CentOS -customization development line of web applications source code. For -example, using the above file system structure, you can create the -customization development line of `webapp1-0.0.1/' with the -following command: -

-
svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv
-
-

The command above creates the following structure: -

-
https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-|   |-- Sources/
-|   |   |-- webapp1-0.0.1/
-|   |   `-- webapp1-0.0.1-webenv/
-|   |-- Rpms/
-|   |   `-- webapp1-0.0.1.rpm
-|   |-- Srpms/
-|   |   `-- webapp1-0.0.1.srpm
-|   `-- Specs/
-|       `-- webapp1-0.0.1.spec
-|-- WebApp2/
-`-- WebAppN/
-
-

In the above structure, the `webapp1-0.0.1-webenv/' directory is -the place where you customize the visual style of -`webapp1-0.0.1/' web application. -

-
Info

Tip

Use the diff command of Subversion between -CentOS customization and upstream development lines to know what you -are changing exactly. -

- -
-
Build packages
-
-

When web application has been customized, build the web application -RPM and SRPM using the source location with `-webenv' prefix. -

-
https://projects.centos.org/svn/webenv/trunk/
-|-- WebApp1/
-|   |-- Sources/
-|   |   |-- webapp1-0.0.1/
-|   |   `-- webapp1-0.0.1-webenv/
-|   |-- Rpms/
-|   |   |-- webapp1-0.0.1.rpm
-|   |   `-- webapp1-0.0.1-webenv.rpm
-|   |-- Srpms/
-|   |   |-- webapp1-0.0.1.srpm
-|   |   `-- webapp1-0.0.1-webenv.srpm
-|   `-- Specs/
-|       |-- webapp1-0.0.1.spec
-|       `-- webapp1-0.0.1-webenv.spec
-|-- WebApp2/
-`-- WebAppN/
-
-
-
Release for testing
-
-

When the customized web application has been packaged, make packages -available for testing and quality assurance. This can be achives using -a [webenv-test] yum repository. -

-
info

Note

The [webenv-test] repository is not shipped inside -CentOS distribution default yum configuraiton. In order to use -[webenv-test] repository you need to configure it first. -

- -

If some problem is found to install/update/use the customized version -of web application, the problem is notified somewhere (a bugtracker -maybe) and the customization face is repated in order to fix the -problem. To release the new package add a number after `-webenv' -prefix. For example, if some problem is found in -`webapp1-0.0.1-webenv.rpm', when it be fixed the new package will -be named `webapp1-0.0.1-webenv-1.rpm'. If a problem is found in -`webapp1-0.0.1-webenv-1.rpm', when it be fixed the new package -will be named `webapp1-0.0.1-webenv-2.rpm', and so on. -

-

The "customization -- release for testing" process is repeated -until CentOS quality assurance team considers the package is ready for -production. -

-
-
Release for production
-
-

When customized web application packages are considered ready for -production they are moved from [webenv-test] to [webenv] repository. -This action is commited by CentOS quality assurance team. -

-
info

Note

The [webenv] repository is not shipped inside CentOS -distribution default yum configuraiton. In order to use [webenv] -repository you need to configure it first. -

-
-
- - - -

2.16.2.8 The [webenv-test] repository

- -
/etc/yum.repos.d/CentOS-Webenv-test.repo
-
-
[webenv-test]
-name=CentOS-$releasever - Webenv-test
-mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test
-#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/
-gpgcheck=1
-gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
-enabled=1
-priority=10
-
- - -

2.16.2.9 The [webenv] repository

- -
/etc/yum.repos.d/CentOS-Webenv.repo
-
-
[webenv]
-name=CentOS-$releasever - Webenv
-mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv
-#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/
-gpgcheck=1
-gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
-enabled=1
-priority=10
-
- - -

2.16.2.10 Priority configuration

- -

Both [webenv] and [webenv-test] repositories update packages inside -CentOS [base] and CentOS [updates] repositories. -

- -

2.16.3 Usage

+ +

2.13.3 Usage

- -

2.16.4 See also

+ +

2.13.4 See also

-
2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory   +
2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory  
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_21.html b/Manual/repository-html/repository_21.html index 4f686bc..217dec4 100644 --- a/Manual/repository-html/repository_21.html +++ b/Manual/repository-html/repository_21.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.17 The trunk/Identity/Models/Xcf Directory +CentOS Artwork Repository: 2.14 The trunk/Identity/Models/Tpl Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.17 The `trunk/Identity/Models/Xcf' Directory

+ + +

2.14 The `trunk/Identity/Models/Tpl' Directory

- -

2.17.1 Goals

+ +

2.14.1 Goals

- -

2.17.2 Description

+ +

2.14.2 Description

- -

2.17.3 Usage

+ +

2.14.3 Usage

- -

2.17.4 See also

+ +

2.14.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_22.html b/Manual/repository-html/repository_22.html index f651665..9330203 100644 --- a/Manual/repository-html/repository_22.html +++ b/Manual/repository-html/repository_22.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.18 The trunk/Identity/Release Directory +CentOS Artwork Repository: 2.15 The trunk/Identity/Models/Tpl/Brands Directory - - + + @@ -55,58 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.18 The `trunk/Identity/Release' Directory

+ + +

2.15 The `trunk/Identity/Models/Tpl/Brands' Directory

- -

2.18.1 Goals

+ +

2.15.1 Goals

- -

2.18.2 Description

+ +

2.15.2 Description

+ + - -

2.18.3 Usage

+ +

2.15.3 Usage

+ + - -

2.18.4 See also

+ +

2.15.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_23.html b/Manual/repository-html/repository_23.html index 14eb2ab..81687af 100644 --- a/Manual/repository-html/repository_23.html +++ b/Manual/repository-html/repository_23.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.19 The trunk/Identity/Themes Directory +CentOS Artwork Repository: 2.16 The trunk/Identity/Models/Tpl/Promo/Web Directory - - + + @@ -55,76 +55,374 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.19 The `trunk/Identity/Themes' Directory

+ + +

2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory

- -

2.19.1 Goals

+ +

2.16.1 Goals

-

The `trunk/Identity/Themes/' directory exists to organize -production of CentOS themes. +

Organize scalable vector graphics (svg) to help describe the CentOS +web environment.

- -

2.19.2 Description

+ +

2.16.2 The CentOS web environment

+

Inside CentOS corporate identity, the CentOS web environment is +considered a promotion component. The CentOS web environment is formed +by a central web application --to cover base needs (e.g., per-major +release information like release notes, lifetime, downloads, +documentation, support, security advisories, bugs, etc.)-- and many +different free web applications --to cover specific needs (e.g., +wiki, mailing lists, etc.)--. +

+

The CentOS web environment is addressed to solve the following issues: +

+ + +

The CentOS project is attached to a monolithic corporate visual +identity (see section The `trunk/Identity' Directory), where all visual manifestations +have one unique name and one unique visual style. This way, the CentOS +web environment has one unique name (the CentOS brand) and one unique +visual style (the CentOS default theme) for all its visual +manifestations, the web applications in this case.

- - - -
2.20 The `trunk/Identity/Themes/Models' Directory   -
2.36 The `trunk/Identity/Themes/Motifs' Directory   -
+

Since a maintainance point of view, achiving the one unique visual +style inside CentOS web environment is not a simple task. The CentOS +web environment is built upon many different web applications which +have different visual styles and different internal ways to customize +their own visual styles. For example: MoinMoin, the web application +used to support the CentOS wiki (http://wiki.centos.org/) is +highly customizable but Mailman (in its 2.x.x serie), the web +application used to support the CentOS mailing list, doesn't +support(1) a customization system that separates +presentation from logic, similar to that used by MoinMoin. +

+

This visual style diversity complicates our goal of one unique visual +style for all web applications. So, if we want one unique visual style +for all web applications used, it is innevitable to modify the web +applications in order to implement the CentOS one unique visual style +customization in them. Direct modification of upstream applications is +not convenient because upstream applications come with their one +visual style and administrators take the risk of loosing all +customization changes the next time the application be updated (since +not all upstream web applications, used in CentOS web environment, +separate presentation from logic). +

+

To solve the "one unique visual style" issue, installation and +actualization of web applications --used inside CentOS web +environment-- need to be independent from upstream web applications +development line; in a way that CentOS web environment administrators +can install and update web applications freely without risk of loosing +the one unique visual style customization changes. +

+

At the surface of this issue we can see the need of one specific yum +repository to store CentOS web environment customized web applications. +

+ + +

2.16.2.1 Design model (without ads)

+ + + +

2.16.2.2 Design model (with ads)

+ + +

2.16.2.3 HTML definitions

- -

2.19.4 See also

+ + +

2.16.2.4 Controlling visual style

+ +

Inside CentOS web environment, the visual style is controlled by the +following compenents: +

+
+
Webenv header background
+
trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
+
+
+
CSS definitions
+
trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css
+
+
+ + + +

2.16.2.5 Producing visual style

+ +

The visual style of CentOS web environment is defined in the following +files: +

+
trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png
+trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg
+
+

As graphic designer you use `1024x250.xcf' file to produce +`1024x250-bg.png' file. Later, inside `1024x250.svg' file, +you use the `1024x250-bg.png' file as background layer to draw +your vectorial design. When you consider you artwork ready, use the +centos-art.sh script, as described below, to produce the +visual style controller images of CentOS web environment. +

+
centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250'
+
+

Once you have rendered required image files, changing the visual style +of CentOS web environment is a matter of replacing old image files +with new ones, inside webenv repository file system structure. The +visual style changes will take effect the next time customization line +of CentOS web applications be packaged, uploded, and installed from +[webenv] or [webenv-test] repositories. +

+ + +

2.16.2.6 Navigation

+ +

Inside CentOS web environment, the one-step navegation between web +applications is addressed using the web environment navigation bar. +The web environment navigation bar contains links to main applications +and is always visible no matter where you are inside the web +environment. +

+ + +

2.16.2.7 Development and release cycle

+ +

The CentOS web environment development and relase cycle is described +below: +

+
+
Download
+
+

The first action is download the source code of web applications we +want to use inside CentOS web environment. +

+
Important

Important

The source location from which web application are +downloaded is very important. Use SRPMs from CentOS [base] +and [updates] repositories as first choise, and third party +repositories (e.g. RPMForge, EPEL, etc.) as last resource. +

+ +
+
Prepare
+
+

Once web application source code has been downloaded, our duty is +organize its files inside `webenv' version controlled repository. +

+

When preparing the structure keep in mind that different web +applications have different visual styles, and also different ways to +implement it. A convenient way to organize the file system structure +would be create one development line for each web application we use +inside CentOS web environment. For example, consider the following +file system structure: +

+
https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+|   |-- Sources/
+|   |   `-- webapp1-0.0.1/
+|   |-- Rpms/
+|   |   `-- webapp1-0.0.1.rpm
+|   |-- Srpms/
+|   |   `-- webapp1-0.0.1.srpm
+|   `-- Specs/
+|       `-- webapp1-0.0.1.spec
+|-- WebApp2/
+`-- WebAppN/
+
+
+
Customize
+
+

Once web applications have been organized inside the version +controlled repository file system, use subversion to create the CentOS +customization development line of web applications source code. For +example, using the above file system structure, you can create the +customization development line of `webapp1-0.0.1/' with the +following command: +

+
svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv
+
+

The command above creates the following structure: +

+
https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+|   |-- Sources/
+|   |   |-- webapp1-0.0.1/
+|   |   `-- webapp1-0.0.1-webenv/
+|   |-- Rpms/
+|   |   `-- webapp1-0.0.1.rpm
+|   |-- Srpms/
+|   |   `-- webapp1-0.0.1.srpm
+|   `-- Specs/
+|       `-- webapp1-0.0.1.spec
+|-- WebApp2/
+`-- WebAppN/
+
+

In the above structure, the `webapp1-0.0.1-webenv/' directory is +the place where you customize the visual style of +`webapp1-0.0.1/' web application. +

+
Info

Tip

Use the diff command of Subversion between +CentOS customization and upstream development lines to know what you +are changing exactly. +

+ +
+
Build packages
+
+

When web application has been customized, build the web application +RPM and SRPM using the source location with `-webenv' prefix. +

+
https://projects.centos.org/svn/webenv/trunk/
+|-- WebApp1/
+|   |-- Sources/
+|   |   |-- webapp1-0.0.1/
+|   |   `-- webapp1-0.0.1-webenv/
+|   |-- Rpms/
+|   |   |-- webapp1-0.0.1.rpm
+|   |   `-- webapp1-0.0.1-webenv.rpm
+|   |-- Srpms/
+|   |   |-- webapp1-0.0.1.srpm
+|   |   `-- webapp1-0.0.1-webenv.srpm
+|   `-- Specs/
+|       |-- webapp1-0.0.1.spec
+|       `-- webapp1-0.0.1-webenv.spec
+|-- WebApp2/
+`-- WebAppN/
+
+
+
Release for testing
+
+

When the customized web application has been packaged, make packages +available for testing and quality assurance. This can be achives using +a [webenv-test] yum repository. +

+
info

Note

The [webenv-test] repository is not shipped inside +CentOS distribution default yum configuraiton. In order to use +[webenv-test] repository you need to configure it first. +

+ +

If some problem is found to install/update/use the customized version +of web application, the problem is notified somewhere (a bugtracker +maybe) and the customization face is repated in order to fix the +problem. To release the new package add a number after `-webenv' +prefix. For example, if some problem is found in +`webapp1-0.0.1-webenv.rpm', when it be fixed the new package will +be named `webapp1-0.0.1-webenv-1.rpm'. If a problem is found in +`webapp1-0.0.1-webenv-1.rpm', when it be fixed the new package +will be named `webapp1-0.0.1-webenv-2.rpm', and so on. +

+

The "customization -- release for testing" process is repeated +until CentOS quality assurance team considers the package is ready for +production. +

+
+
Release for production
+
+

When customized web application packages are considered ready for +production they are moved from [webenv-test] to [webenv] repository. +This action is commited by CentOS quality assurance team. +

+
info

Note

The [webenv] repository is not shipped inside CentOS +distribution default yum configuraiton. In order to use [webenv] +repository you need to configure it first. +

+
+
+ + + +

2.16.2.8 The [webenv-test] repository

+ +
/etc/yum.repos.d/CentOS-Webenv-test.repo
+
+
[webenv-test]
+name=CentOS-$releasever - Webenv-test
+mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test
+#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
+enabled=1
+priority=10
+
+ + +

2.16.2.9 The [webenv] repository

+ +
/etc/yum.repos.d/CentOS-Webenv.repo
+
+
[webenv]
+name=CentOS-$releasever - Webenv
+mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv
+#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
+enabled=1
+priority=10
+
+ + +

2.16.2.10 Priority configuration

+ +

Both [webenv] and [webenv-test] repositories update packages inside +CentOS [base] and CentOS [updates] repositories. +

+ + +

2.16.3 Usage

+ + + + + +

2.16.4 See also

- -
2.4 The `trunk/Identity' Directory   -
2.3 The `trunk' Directory   +
2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory  
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_24.html b/Manual/repository-html/repository_24.html index c0faaa7..7e68af0 100644 --- a/Manual/repository-html/repository_24.html +++ b/Manual/repository-html/repository_24.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.20 The trunk/Identity/Themes/Models Directory +CentOS Artwork Repository: 2.17 The trunk/Identity/Models/Xcf Directory - - + + @@ -55,72 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.20 The `trunk/Identity/Themes/Models' Directory

+ + +

2.17 The `trunk/Identity/Models/Xcf' Directory

- -

2.20.1 Goals

+ +

2.17.1 Goals

- -

2.20.2 Description

+ +

2.17.2 Description

-

Theme models let you modeling characteristics (e.g., dimensions, -translation markers, position of each element on the display area, -etc.) common to all themes. Theme models let you reduce the time -needed when propagating artistic motifs to different visual -manifestations. -

-

Theme models serves as a central pool of design templates for themes -to use. This way you can produce themes with different artistic motifs -but same characteristics. -

+ - -

2.20.3 Usage

-

Inside the framework location above, you find theme models organized -by name. You can add your own theme models to the structure by adding -a directory to the list. By default you have the `See section Default,' and `See section Alternative,' ready-to-use theme models. -

+ +

2.17.3 Usage

+ + + - -

2.20.4 See also

+ +

2.17.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_25.html b/Manual/repository-html/repository_25.html index 6dca134..681bf6c 100644 --- a/Manual/repository-html/repository_25.html +++ b/Manual/repository-html/repository_25.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.21 The trunk/Identity/Themes/Models/Alternative Directory +CentOS Artwork Repository: 2.18 The trunk/Identity/Release Directory - - + + @@ -55,70 +55,58 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.21 The `trunk/Identity/Themes/Models/Alternative' Directory

+ + +

2.18 The `trunk/Identity/Release' Directory

- -

2.21.1 Goals

+ +

2.18.1 Goals

- -

2.21.2 Description

+ +

2.18.2 Description

-

CentOS alternative theme models exist for people how want to use a -different visual style on their installations of CentOS distribution. -As the visual style is needed for a system already installed -components like Anaconda are not required inside alternative themes. -Inside alternative themes you find post-installation visual style only -(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative -themes are maintained by CentOS Community. -

- - -

2.21.3 Usage

- + +

2.18.3 Usage

- -

2.21.4 See also

+ +

2.18.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_26.html b/Manual/repository-html/repository_26.html index 561e9fa..23e6b70 100644 --- a/Manual/repository-html/repository_26.html +++ b/Manual/repository-html/repository_26.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.22 The trunk/Identity/Themes/Models/Default Directory +CentOS Artwork Repository: 2.19 The trunk/Identity/Themes Directory - - + + @@ -55,142 +55,76 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.22 The `trunk/Identity/Themes/Models/Default' Directory

+ + +

2.19 The `trunk/Identity/Themes' Directory

- -

2.22.1 Goals

+ +

2.19.1 Goals

-

Default Design Models for CentOS Themes provide design models for the -following components: -

-
-
Distribution
-

Design models for CentOS Distribution (e.g., Anaconda, Firstboot, Gdm, -Grub, Gsplash, Kdm, Ksplash, Rhgb and Syslinux, etc.). -See section The `trunk/Identity/Themes/Models/Default/Distro' Directory, for -more information. -

-
-
Concept
-

Design models to illustrate Artistic Motifs Concepts. -See section The `trunk/Identity/Themes/Models/Default/Concept' Directory, for -more information. -

-
-
Promotion
-

Design models for CentOS Promotion stuff (e.g., installation media, -posters, etc.). See section The `trunk/Identity/Themes/Models/Default/Promo' Directory, for more information. -

-
- - - -

2.22.2 Description

- -

This directory implements the concept of Default Design Models -for CentOS Themes. Default Design Models for CentOS Themes provide -the common structural information (e.g., image dimensions, translation -markers, trademark position, etc.) the centos-art script -uses to produce images when no other design model is specified. -

-

Deisgn models in this directory do use the CentOS Release -Brand. The CentOS Release Brand is a combination of both The CentOS -Type and The CentOS Release Schema used to illustrate the major -release of CentOS Distribution the image produced belongs to. -See section The `trunk/Identity/Models/Tpl/Brands' Directory, for more -information. +

The `trunk/Identity/Themes/' directory exists to organize +production of CentOS themes.

- -

2.22.3 Usage

+ +

2.19.2 Description

-

The CentOS Project maintains near to four different major releases of -CentOS Distribution. Each major release of CentOS Distribution has -internal differences that make them unique and, at the same time, each -CentOS Distribution individually is tagged into the one unique visual -manifestation (i.e., Distribution). So, how could we implement the -monolithic visual structure in one visual manifestation that has -internal difference? -

-

To answer this question we broke the question in two parts and later -combined the resultant answers to build a possible solution. -

-
-
How to remark the internal differences visually?
-
-

Merge both The CentOS Project Release Schema into The CentOS Project -Trademark to build The CentOS Project Release Trademark. The CentOS -Project Release Trademark remarks two things: first, it remarks the -image is from The CentOS Project and second, it remarks which major -release of CentOS Distribution does the image belongs to. -See section The `trunk/Identity/Models/Tpl/Brands' Directory, for more -information on how to develop and improve The CentOS Project Brand. -

-
-
How to remark the visual resemblance?
-
-

Use a common artistic motifs as background for all CentOS Distribution -images. See section The `trunk/Identity/Themes/Motifs' Directory, for more -information. + + +

2.19.3 Usage

+ +

In this location themes are organized in "Models" --to store common +information-- and "Motifs"--to store unique information. At +rendering time, both motifs and models are combined to produce the +final CentOS themes. CentOS themes can be tagged as "Default" or +"Alternative". CentOS themes are maintained by CentOS community.

-
-
So, combining answers above, we could conclude that:
-
-

In order to implement the CentOS Monolithic Visual Structure on CentOS -Distribution visual manifestations, a CentOS Release Trademark and a -background information based on one unique artistic motif should be -used in all remarkable images The CentOS Distribution visual -manifestation is made of. -

-
- -
Important

Important

Remarking the CentOS Release Schema inside each -major release of CentOS Distribution --or similar visual -manifestations-- takes high attention inside The CentOS -Project corporate visual identity. It should be very clear for -everyone which major release of CentOS Distribution is being used. -

- - - -

2.22.4 See also

- - + + + +
2.20 The `trunk/Identity/Themes/Models' Directory   +
2.36 The `trunk/Identity/Themes/Motifs' Directory   +
+ + + +

2.19.4 See also

+ + + + +
2.4 The `trunk/Identity' Directory   +
2.3 The `trunk' Directory   +
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_27.html b/Manual/repository-html/repository_27.html index e0d2ff0..43ed78a 100644 --- a/Manual/repository-html/repository_27.html +++ b/Manual/repository-html/repository_27.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.23 The trunk/Identity/Themes/Models/Default/Concept Directory +CentOS Artwork Repository: 2.20 The trunk/Identity/Themes/Models Directory - - + + @@ -55,66 +55,72 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory

+ + +

2.20 The `trunk/Identity/Themes/Models' Directory

- -

2.23.1 Goals

+ +

2.20.1 Goals

- -

2.23.2 Description

+ +

2.20.2 Description

- - - - -

2.23.3 Usage

+

Theme models let you modeling characteristics (e.g., dimensions, +translation markers, position of each element on the display area, +etc.) common to all themes. Theme models let you reduce the time +needed when propagating artistic motifs to different visual +manifestations. +

+

Theme models serves as a central pool of design templates for themes +to use. This way you can produce themes with different artistic motifs +but same characteristics. +

- + +

2.20.3 Usage

+

Inside the framework location above, you find theme models organized +by name. You can add your own theme models to the structure by adding +a directory to the list. By default you have the `See section Default,' and `See section Alternative,' ready-to-use theme models. +

- -

2.23.4 See also

+ +

2.20.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_28.html b/Manual/repository-html/repository_28.html index 9ff7b9d..4062334 100644 --- a/Manual/repository-html/repository_28.html +++ b/Manual/repository-html/repository_28.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.24 The trunk/Identity/Themes/Models/Default/Distro Directory +CentOS Artwork Repository: 2.21 The trunk/Identity/Themes/Models/Alternative Directory - - + + @@ -55,156 +55,70 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory

+ + +

2.21 The `trunk/Identity/Themes/Models/Alternative' Directory

- -

2.24.1 Goals

+ +

2.21.1 Goals

-

This directory provides design models to produce image files for the -following CentOS Distribution components: -

-
-
Syslinux
-

Contains design models for syslinux, the program used to boot the -CentOS Distribution installation media. See section The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory, for more information. -

-
-
Anaconda
-

Contains design models for Anaconda, the program used to install -CentOS Distribution. See section The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory, for more information. -

-
-
Firstboot
-

Contains design models for the first boot program used to configure -the maching onece installed. See section The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory, for more information. -

-
-
Rhgb
-

Contains design models for CentOS Graphical Boot, the program used to -show the boot process from Grub to Display Manager. See section The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory, for more -information. -

-
-
Gdm
-

Contains design models for GNOME Display Manager, the program used to -log into the manchine once installed and configured. See section The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory, for more -information. -

-
-
Kdm
-

Contains design models for KDE Display Manager, the program used to -log into the manchine once installed and configured. See section The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory, for more -information. -

-
-
Grub
-

Contains design models for GRUB (Grand Unified Boot Loader), the -program used to boot the machine into an operating system. -See section The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory, for -more information. -

-
-
Gsplash
-

Contains design models for GNOME splash, the program used to show the -progress information while user's graphical session is loading. -See section The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory, -for more information. -

-
-
Ksplash
-

Contains design models for KDE splash, the program used to show the -progress information while user's graphical session is loading. -See section The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory, -for more information. -

-
- - -

2.24.2 Description

- -

The CentOS Distribution visual style is controlled by image files. -These image files are packaged inside The CentOS Distribution and made -visible once such packages are installed and executed. The way to go -for changing The CentOS Distribution visual style is changing all -those image files to add the desired visual style first and later, -repackage them to make them available inside the final iso files of -CentOS Distribution. -

+ - -

2.24.3 Usage

-

This directory provides organizationl structure to store default -design models for CentOS Themes of CentOS Distribution and so it -should be considered to be used. -

-

When a new component is added to CentOS Distribution, this is the -directory you need to go for specifying design models for image files -inside such component. -

-

The procedure to follow is creatig a directory for each component -using its very same name (e.g., the directory `Anaconda' stores -image files for Anaconda component, the installer program). Inside the -directory, you need to create one scalable vector graphic for each -image file inside the component you want to produce images for. This, -in order to set image dimensions, image file-name, position of -trademarks in the final image, translation markers and whatever common -information you need to have specified in them when rendered by -centos-art script. -

-

Sometimes, between major releases, image files inside packages can be -added, removed or just change their names. In order to describe such -image files variations, the design models directory structure is -organized in the same way the file variations are introduced (i.e., -through The CentOS Project Release Schema). So, each major release of -CentOS Distribution does have its own design model directory structure -in this directory. -

-

When a whole package is removed from one or all CentOS Distribution -major releases, the design models directory structure releated to it -is no longer used. However it could be very useful for historical -reasons. Also, someone could feel motivated enough to keep himself -documenting it or supporting it for whatever reason. + +

2.21.2 Description

+ +

CentOS alternative theme models exist for people how want to use a +different visual style on their installations of CentOS distribution. +As the visual style is needed for a system already installed +components like Anaconda are not required inside alternative themes. +Inside alternative themes you find post-installation visual style only +(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative +themes are maintained by CentOS Community.

- -

2.24.4 See also

+ +

2.21.3 Usage

+ + + + + +

2.21.4 See also

- - -
2.22 The `trunk/Identity/Themes/Models/Default' Directory   -
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_29.html b/Manual/repository-html/repository_29.html index 8f5c603..80301c5 100644 --- a/Manual/repository-html/repository_29.html +++ b/Manual/repository-html/repository_29.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.25 The trunk/Identity/Themes/Models/Default/Distro/Anaconda Directory +CentOS Artwork Repository: 2.22 The trunk/Identity/Themes/Models/Default Directory - - + + @@ -55,58 +55,142 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory

+ + +

2.22 The `trunk/Identity/Themes/Models/Default' Directory

- -

2.25.1 Goals

+ +

2.22.1 Goals

- - - - -

2.25.2 Description

- - - -

2.25.3 Usage

+

Default Design Models for CentOS Themes provide design models for the +following components: +

+
+
Distribution
+

Design models for CentOS Distribution (e.g., Anaconda, Firstboot, Gdm, +Grub, Gsplash, Kdm, Ksplash, Rhgb and Syslinux, etc.). +See section The `trunk/Identity/Themes/Models/Default/Distro' Directory, for +more information. +

+
+
Concept
+

Design models to illustrate Artistic Motifs Concepts. +See section The `trunk/Identity/Themes/Models/Default/Concept' Directory, for +more information. +

+
+
Promotion
+

Design models for CentOS Promotion stuff (e.g., installation media, +posters, etc.). See section The `trunk/Identity/Themes/Models/Default/Promo' Directory, for more information. +

+
+ + + +

2.22.2 Description

+ +

This directory implements the concept of Default Design Models +for CentOS Themes. Default Design Models for CentOS Themes provide +the common structural information (e.g., image dimensions, translation +markers, trademark position, etc.) the centos-art script +uses to produce images when no other design model is specified. +

+

Deisgn models in this directory do use the CentOS Release +Brand. The CentOS Release Brand is a combination of both The CentOS +Type and The CentOS Release Schema used to illustrate the major +release of CentOS Distribution the image produced belongs to. +See section The `trunk/Identity/Models/Tpl/Brands' Directory, for more +information. +

+ +

2.22.3 Usage

- -

2.25.4 See also

+

The CentOS Project maintains near to four different major releases of +CentOS Distribution. Each major release of CentOS Distribution has +internal differences that make them unique and, at the same time, each +CentOS Distribution individually is tagged into the one unique visual +manifestation (i.e., Distribution). So, how could we implement the +monolithic visual structure in one visual manifestation that has +internal difference? +

+

To answer this question we broke the question in two parts and later +combined the resultant answers to build a possible solution. +

+
+
How to remark the internal differences visually?
+
+

Merge both The CentOS Project Release Schema into The CentOS Project +Trademark to build The CentOS Project Release Trademark. The CentOS +Project Release Trademark remarks two things: first, it remarks the +image is from The CentOS Project and second, it remarks which major +release of CentOS Distribution does the image belongs to. +See section The `trunk/Identity/Models/Tpl/Brands' Directory, for more +information on how to develop and improve The CentOS Project Brand. +

+
+
How to remark the visual resemblance?
+
+

Use a common artistic motifs as background for all CentOS Distribution +images. See section The `trunk/Identity/Themes/Motifs' Directory, for more +information. +

+
+
So, combining answers above, we could conclude that:
+
+

In order to implement the CentOS Monolithic Visual Structure on CentOS +Distribution visual manifestations, a CentOS Release Trademark and a +background information based on one unique artistic motif should be +used in all remarkable images The CentOS Distribution visual +manifestation is made of. +

+
+ +
Important

Important

Remarking the CentOS Release Schema inside each +major release of CentOS Distribution --or similar visual +manifestations-- takes high attention inside The CentOS +Project corporate visual identity. It should be very clear for +everyone which major release of CentOS Distribution is being used. +

+ + + +

2.22.4 See also

+ - - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_3.html b/Manual/repository-html/repository_3.html index aacf12c..f9e3a36 100644 --- a/Manual/repository-html/repository_3.html +++ b/Manual/repository-html/repository_3.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 1.2 Send in Your Feedback +CentOS Artwork Repository: 1.2 Authors - - + + @@ -56,46 +56,44 @@ ul.toc {list-style: none} - + - + - +
[ < ][ > ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

1.2 Send in Your Feedback

+ + +

1.2 Authors

-

If you find an error in the CentOS Artwork Repository Manual, -or if you have thought of a way to make this manual better, we would -like to hear from you! Create a new ticket in The CentOS Artwork SIG -web site (https://projects.centos.org/trac/artwork/). +

This section records authoring information of CentOS Artwork +Repository, in alphabetical order.

-

If you have a suggestion for improving the documentation, try to be as -specific as possible. If you have found an error, include the section -number and some of the surrounding text so we can find it easily. -

- +
Ralph Angenendt <ralph@centos.org>
+Marcus Moeller <marcus@moeller.org>
+Alain Reguera Delgado <al@localhost>, 2009, 2010, 2011
+Karanbirn Singh <karan@centos.org>
+
- + - +
[ < ][ > ][ > ]   [ << ] [ Up ][ >> ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_30.html b/Manual/repository-html/repository_30.html index 1a4a65c..4cbf46f 100644 --- a/Manual/repository-html/repository_30.html +++ b/Manual/repository-html/repository_30.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.26 The trunk/Identity/Themes/Models/Default/Distro/Firstboot Directory +CentOS Artwork Repository: 2.23 The trunk/Identity/Themes/Models/Default/Concept Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory

+ + +

2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory

- -

2.26.1 Goals

+ +

2.23.1 Goals

- -

2.26.2 Description

+ +

2.23.2 Description

- -

2.26.3 Usage

+ +

2.23.3 Usage

- -

2.26.4 See also

+ +

2.23.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_31.html b/Manual/repository-html/repository_31.html index 38ac2a7..0ebd36a 100644 --- a/Manual/repository-html/repository_31.html +++ b/Manual/repository-html/repository_31.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.27 The trunk/Identity/Themes/Models/Default/Distro/Gdm Directory +CentOS Artwork Repository: 2.24 The trunk/Identity/Themes/Models/Default/Distro Directory - - + + @@ -55,66 +55,156 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory

+ + +

2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory

- -

2.27.1 Goals

+ +

2.24.1 Goals

- - - - -

2.27.2 Description

- - - - - -

2.27.3 Usage

+

This directory provides design models to produce image files for the +following CentOS Distribution components: +

+
+
Syslinux
+

Contains design models for syslinux, the program used to boot the +CentOS Distribution installation media. See section The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory, for more information. +

+
+
Anaconda
+

Contains design models for Anaconda, the program used to install +CentOS Distribution. See section The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory, for more information. +

+
+
Firstboot
+

Contains design models for the first boot program used to configure +the maching onece installed. See section The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory, for more information. +

+
+
Rhgb
+

Contains design models for CentOS Graphical Boot, the program used to +show the boot process from Grub to Display Manager. See section The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory, for more +information. +

+
+
Gdm
+

Contains design models for GNOME Display Manager, the program used to +log into the manchine once installed and configured. See section The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory, for more +information. +

+
+
Kdm
+

Contains design models for KDE Display Manager, the program used to +log into the manchine once installed and configured. See section The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory, for more +information. +

+
+
Grub
+

Contains design models for GRUB (Grand Unified Boot Loader), the +program used to boot the machine into an operating system. +See section The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory, for +more information. +

+
+
Gsplash
+

Contains design models for GNOME splash, the program used to show the +progress information while user's graphical session is loading. +See section The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory, +for more information. +

+
+
Ksplash
+

Contains design models for KDE splash, the program used to show the +progress information while user's graphical session is loading. +See section The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory, +for more information. +

+
+ + +

2.24.2 Description

+ +

The CentOS Distribution visual style is controlled by image files. +These image files are packaged inside The CentOS Distribution and made +visible once such packages are installed and executed. The way to go +for changing The CentOS Distribution visual style is changing all +those image files to add the desired visual style first and later, +repackage them to make them available inside the final iso files of +CentOS Distribution. +

- + +

2.24.3 Usage

+

This directory provides organizationl structure to store default +design models for CentOS Themes of CentOS Distribution and so it +should be considered to be used. +

+

When a new component is added to CentOS Distribution, this is the +directory you need to go for specifying design models for image files +inside such component. +

+

The procedure to follow is creatig a directory for each component +using its very same name (e.g., the directory `Anaconda' stores +image files for Anaconda component, the installer program). Inside the +directory, you need to create one scalable vector graphic for each +image file inside the component you want to produce images for. This, +in order to set image dimensions, image file-name, position of +trademarks in the final image, translation markers and whatever common +information you need to have specified in them when rendered by +centos-art script. +

+

Sometimes, between major releases, image files inside packages can be +added, removed or just change their names. In order to describe such +image files variations, the design models directory structure is +organized in the same way the file variations are introduced (i.e., +through The CentOS Project Release Schema). So, each major release of +CentOS Distribution does have its own design model directory structure +in this directory. +

+

When a whole package is removed from one or all CentOS Distribution +major releases, the design models directory structure releated to it +is no longer used. However it could be very useful for historical +reasons. Also, someone could feel motivated enough to keep himself +documenting it or supporting it for whatever reason. +

- -

2.27.4 See also

+ +

2.24.4 See also

+ + +
2.22 The `trunk/Identity/Themes/Models/Default' Directory   +
- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_32.html b/Manual/repository-html/repository_32.html index e869936..9446aa6 100644 --- a/Manual/repository-html/repository_32.html +++ b/Manual/repository-html/repository_32.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.28 The trunk/Identity/Themes/Models/Default/Distro/Grub Directory +CentOS Artwork Repository: 2.25 The trunk/Identity/Themes/Models/Default/Distro/Anaconda Directory - - + + @@ -55,66 +55,58 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory

+ + +

2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory

- -

2.28.1 Goals

+ +

2.25.1 Goals

- -

2.28.2 Description

- - + +

2.25.2 Description

- -

2.28.3 Usage

- - + +

2.25.3 Usage

- -

2.28.4 See also

+ +

2.25.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_33.html b/Manual/repository-html/repository_33.html index 39ef104..4b26a45 100644 --- a/Manual/repository-html/repository_33.html +++ b/Manual/repository-html/repository_33.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.29 The trunk/Identity/Themes/Models/Default/Distro/Gsplash Directory +CentOS Artwork Repository: 2.26 The trunk/Identity/Themes/Models/Default/Distro/Firstboot Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory

+ + +

2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory

- -

2.29.1 Goals

+ +

2.26.1 Goals

- -

2.29.2 Description

+ +

2.26.2 Description

- -

2.29.3 Usage

+ +

2.26.3 Usage

- -

2.29.4 See also

+ +

2.26.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_34.html b/Manual/repository-html/repository_34.html index 557c7a1..6e8fdb7 100644 --- a/Manual/repository-html/repository_34.html +++ b/Manual/repository-html/repository_34.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.30 The trunk/Identity/Themes/Models/Default/Distro/Kdm Directory +CentOS Artwork Repository: 2.27 The trunk/Identity/Themes/Models/Default/Distro/Gdm Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory

+ + +

2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory

- -

2.30.1 Goals

+ +

2.27.1 Goals

- -

2.30.2 Description

+ +

2.27.2 Description

- -

2.30.3 Usage

+ +

2.27.3 Usage

- -

2.30.4 See also

+ +

2.27.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_35.html b/Manual/repository-html/repository_35.html index f94366d..69ca022 100644 --- a/Manual/repository-html/repository_35.html +++ b/Manual/repository-html/repository_35.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.31 The trunk/Identity/Themes/Models/Default/Distro/Ksplash Directory +CentOS Artwork Repository: 2.28 The trunk/Identity/Themes/Models/Default/Distro/Grub Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory

+ + +

2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory

- -

2.31.1 Goals

+ +

2.28.1 Goals

- -

2.31.2 Description

+ +

2.28.2 Description

- -

2.31.3 Usage

+ +

2.28.3 Usage

- -

2.31.4 See also

+ +

2.28.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_36.html b/Manual/repository-html/repository_36.html index 880512e..bc8630b 100644 --- a/Manual/repository-html/repository_36.html +++ b/Manual/repository-html/repository_36.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.32 The trunk/Identity/Themes/Models/Default/Distro/Rhgb Directory +CentOS Artwork Repository: 2.29 The trunk/Identity/Themes/Models/Default/Distro/Gsplash Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory

+ + +

2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory

- -

2.32.1 Goals

+ +

2.29.1 Goals

- -

2.32.2 Description

+ +

2.29.2 Description

- -

2.32.3 Usage

+ +

2.29.3 Usage

- -

2.32.4 See also

+ +

2.29.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_37.html b/Manual/repository-html/repository_37.html index fe316ea..51f10e9 100644 --- a/Manual/repository-html/repository_37.html +++ b/Manual/repository-html/repository_37.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.33 The trunk/Identity/Themes/Models/Default/Distro/Syslinux Directory +CentOS Artwork Repository: 2.30 The trunk/Identity/Themes/Models/Default/Distro/Kdm Directory - - + + @@ -55,66 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory

+ + +

2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory

- -

2.33.1 Goals

+ +

2.30.1 Goals

- -

2.33.2 Description

+ +

2.30.2 Description

- -

2.33.3 Usage

+ +

2.30.3 Usage

- -

2.33.4 See also

+ +

2.30.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_38.html b/Manual/repository-html/repository_38.html index 3e34abd..6a00200 100644 --- a/Manual/repository-html/repository_38.html +++ b/Manual/repository-html/repository_38.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.34 The trunk/Identity/Themes/Models/Default/Promo Directory +CentOS Artwork Repository: 2.31 The trunk/Identity/Themes/Models/Default/Distro/Ksplash Directory - - + + @@ -55,71 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory

+ + +

2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory

- -

2.34.1 Goals

+ +

2.31.1 Goals

- -

2.34.2 Description

+ +

2.31.2 Description

-

It applies to all tangible and non tangible items CentOS uses to -promote its existence. Clothes, posters, installation media, -stationery, release countdown images, banners, stickers, are all -examples of promotion designs. -

- -

2.34.3 Usage

+ +

2.31.3 Usage

- -

2.34.4 See also

+ +

2.31.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_39.html b/Manual/repository-html/repository_39.html index 370ab58..6f8602e 100644 --- a/Manual/repository-html/repository_39.html +++ b/Manual/repository-html/repository_39.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.35 The trunk/Identity/Themes/Models/Default/Web Directory +CentOS Artwork Repository: 2.32 The trunk/Identity/Themes/Models/Default/Distro/Rhgb Directory - - + + @@ -55,70 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory

+ + +

2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory

- -

2.35.1 Goals

+ +

2.32.1 Goals

- -

2.35.2 Description

+ +

2.32.2 Description

-

It applies to all web applications CentOS uses to handle its needs -(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving -HTML standards should be consider here. -

- -

2.35.3 Usage

+ +

2.32.3 Usage

- -

2.35.4 See also

+ +

2.32.4 See also

- - + + - - - + + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_4.html b/Manual/repository-html/repository_4.html index b470efa..ebf1625 100644 --- a/Manual/repository-html/repository_4.html +++ b/Manual/repository-html/repository_4.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2. Repository File System +CentOS Artwork Repository: 1.3 Copying Conditions - - + + @@ -55,203 +55,95 @@ ul.toc {list-style: none} - - + + - - + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2. Repository File System

+ + +

1.3 Copying Conditions

-

The CentOS Artwork Repsotiroy File System is the place where we -organize The CentOS Project Corporate Visual Identity. The CentOS -Artwork Repository uses directories to organize files and describe -conceptual idea about corporate identity. Such conceptual ideas are -explained in each directory related documentation entry. +

Inside the CentOS Artwork Repository you can find content branded by +The CentOS Project and content not branded at all. Contents branded by +The CentOS Project contain either The CentOS Trademark, The CentOS +Logo or The CentOS Symbol. Content branded by The CentOS Project +cannot be redistributed without previous conversation with The CentOS +Project. However, you can study and modify both content branded by +The CentOS Project and content not branded at all in the sake of +proposing improvements to The CentOS Project corporate visual +identity.

-

In this chapter you'll learn what each directory inside The CentOS -Artwork Repository is for and so, how you can make use of them. For -that purpose, the following list of directories is available for you -to explore: +

If you are using the CentOS Artwork Repository for producing your own +corporate visual identity, you should remove all The CentOS Trademarks +from your contents and rename the repository to something other than +CentOS Artwork Repository.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.1 The `branches' Directory   -
2.2 The `tags' Directory   -
2.3 The `trunk' Directory   -
2.4 The `trunk/Identity' Directory   -
2.5 The `trunk/Identity/Brands' Directory   -
2.6 The `trunk/Identity/Colors' Directory   -
2.7 The `trunk/Identity/Fonts' Directory   -
2.8 The `trunk/Identity/Icons' Directory   -
2.9 The `trunk/Identity/Isolinux' Directory   -
2.10 The `trunk/Identity/Models' Directory   -
2.11 The `trunk/Identity/Models/Css' Directory   -
2.12 The `trunk/Identity/Models/Html' Directory   -
2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory   -
2.14 The `trunk/Identity/Models/Tpl' Directory   -
2.15 The `trunk/Identity/Models/Tpl/Brands' Directory   -
2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory   -
2.17 The `trunk/Identity/Models/Xcf' Directory   -
2.18 The `trunk/Identity/Release' Directory   -
2.19 The `trunk/Identity/Themes' Directory   -
2.20 The `trunk/Identity/Themes/Models' Directory   -
2.21 The `trunk/Identity/Themes/Models/Alternative' Directory   -
2.22 The `trunk/Identity/Themes/Models/Default' Directory   -
2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory   -
2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory   -
2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory   -
2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory   -
2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory   -
2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory   -
2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory   -
2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory   -
2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory   -
2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory   -
2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory   -
2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory   -
2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory   -
2.36 The `trunk/Identity/Themes/Motifs' Directory   -
2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory   -
2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory   -
2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory   -
2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory   -
2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory   -
2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory   -
2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory   -
2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory   -
2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory   -
2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory   -
2.47 The `trunk/Identity/Widgets' Directory   -
2.48 The `trunk/Locales' Directory   -
2.49 The `trunk/Locales/Identity' Directory   -
2.50 The `trunk/Locales/Identity/Brands' Directory   -
2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory   -
2.52 The `trunk/Locales/Identity/Fonts' Directory   -
2.53 The `trunk/Locales/Identity/Models' Directory   -
2.54 The `trunk/Locales/Identity/Release' Directory   -
2.55 The `trunk/Locales/Identity/Themes' Directory   -
2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory   -
2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory   -
2.58 The `trunk/Locales/Identity/Widgets' Directory   -
2.59 The `trunk/Manual' Directory   -
2.60 The `trunk/Manuals' Directory   -
2.61 The `trunk/Scripts' Directory   -
2.62 The `trunk/Scripts/Bash' Directory   -
2.63 The `trunk/Scripts/Bash/Cli' Directory   -
2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory   -
2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory   -
2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory   -
2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory   -
2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory   -
2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory   -
2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory   -
2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory   -
2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory   -
2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory   -
2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory   -
2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory   -
2.76 The `trunk/Scripts/Python' Directory   -
+

The CentOS Artwork Repository organizes files in a very specific way +to implement The CentOS Project corporate visual identity. This very +specific organization of files is part of centos-art.sh +script, a bash script that automates most of the frequent tasks inside +the repository. +

+ + +

1.3.1 The centos-art.sh script

+

The centos-art.sh script and the organization of files it +needs to work are not in the public domain; they are copyrighted and +there are restrictions on their distribution, but these restrictions +are designed to permit everything that a good cooperating citizen +would want to do. What is not allowed is to try to prevent others +from further sharing any version of this program that they might get +from you. +

+

Specifically, we want to make sure that you have the right to give +away copies of centos-art.sh script, that you receive source +code or else can get it if you want it, that you can change this +program or use pieces of it in new free programs, and that you know +you can do these things. +

+

To make sure that everyone has such rights, we have to forbid you to +deprive anyone else of these rights. For example, if you distribute +copies of the centos-art.sh script, you must give the +recipients all the rights that you have. You must make sure that +they, too, receive or can get the source code. And you must tell them +their rights. +

+

Also, for our own protection, we must make certain that everyone finds +out that there is no warranty for the centos-art.sh script. +If this program is modified by someone else and passed on, we want +their recipients to know that what they have is not what we +distributed, so that any problems introduced by others will not +reflect on our reputation. +

+

The precise conditions of the license for the centos-art.sh +script are found in the General Public Licenses that accompany it. +This manual specifically is covered by the GNU Free Documentation +License. +

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_40.html b/Manual/repository-html/repository_40.html index 78aee2e..6b4dbca 100644 --- a/Manual/repository-html/repository_40.html +++ b/Manual/repository-html/repository_40.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.36 The trunk/Identity/Themes/Motifs Directory +CentOS Artwork Repository: 2.33 The trunk/Identity/Themes/Models/Default/Distro/Syslinux Directory - - + + @@ -55,160 +55,66 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.36 The `trunk/Identity/Themes/Motifs' Directory

+ + +

2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory

- -

2.36.1 Goals

+ +

2.33.1 Goals

-

The `trunk/Identity/Themes/Motifs' directory exists to: -

+ +

2.33.2 Description

- -

2.36.2 Description

- -

The artistic motif of theme is a graphic design component that -provides the visual style of themes, it is used as pattern to connect -all visual manifestations inside one unique theme. -

-

Artistic motifs are based on conceptual ideas. Conceptual ideas bring -the motivation, they are fuel for the engines of human imagination. -Good conceptual ideas may produce good motivation to produce almost -anything, and art works don't escape from it. -

-
-
`TreeFlower'
-

CentOS like trees, has roots, trunk, branches, leaves and flowers. Day -by day they work together in freedom, ruled by the laws of nature and -open standards, to show the beauty of its existence. -

-
`Modern'
-

Modern, squares and circles flowing up. -

-
- -

If you have new conceptual ideas for CentOS, then you can say that you -want to create a new artistic motif for CentOS. To create a new -artistic motif you need to create a directory under -`Identity/Themes/Motifs/' using a name coherent with your -conceptual idea. That name will be the name of your artistic motif. If -possible, when creating new conceptual ideas for CentOS, think about -what CentOS means for you, what does it makes you feel, take your -time, think deep, and share; you can improve the idea as time goes on. -

-

Once you have defined a name for your theme, you need to create the -motif structure of your theme. The motif structure is the basic -direcotry structure you'll use to work your ideas. Here is where you -organize your graphic design projects. -

-

To add a new motif structure to CentOS Artwork Repository, you need to -use the centos-art command line in the -`Identity/Themes/Motifs/' directory as described below: -

-
 
centos-art add --motif=ThemeName
-
-

The previous command will create the basic structure of themes for -you. The basic structure produced by centos-art command is -illustrated in the following figure: -

-
 
trunk/Identity/Themes/Motifs/$ThemeName/
-|-- Backgrounds
-|   |-- Img
-|   `-- Tpl
-|-- Info
-|   |-- Img
-|   `-- Tpl
-|-- Palettes
-`-- Screenshots
-
- - -

2.36.3 Usage

- -

When designing artistic motifs for CentOS, consider the following -recommendations: -

-
  • Feel free to make your art enterprise-level and beautiful. -
  • Add the following information on your artwork (both in a visible -design area and document metadata): + +

    2.33.3 Usage

    +
  • ...
    • - -

    2.36.4 See also

    + +

    2.33.4 See also

    - - - - -
    2.19 The `trunk/Identity/Themes' Directory   -
    2.4 The `trunk/Identity' Directory   -
    2.3 The `trunk' Directory   -
    - - + + - - - + + +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

    - This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
    diff --git a/Manual/repository-html/repository_41.html b/Manual/repository-html/repository_41.html index 9ba5923..bacdffd 100644 --- a/Manual/repository-html/repository_41.html +++ b/Manual/repository-html/repository_41.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.37 The trunk/Identity/Themes/Motifs/Flame Directory +CentOS Artwork Repository: 2.34 The trunk/Identity/Themes/Models/Default/Promo Directory - - + + @@ -55,261 +55,71 @@ ul.toc {list-style: none} - - + + - - - + + + - +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
    - - -

    2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory

    + + +

    2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory

    - -

    2.37.1 Goals

    + +

    2.34.1 Goals

    -

    This section describes the steps we followed to construct the -Flame artistic motif. This section may be useful for anyone -interested in reproducing the Flame artistic motif, or in -creating new artistic motifs for The CentOS Project corporate visual -identity (see section The `trunk/Identity' Directory). -

    + - -

    2.37.2 Description

    -

    The Flame artistic motif was built using the flame filter of -Gimp 2.2 in CentOS 5.5. -

    -

    The flame filter of Gimp can produce stunning, randomly generated -fractal patterns. The flame filter of Gimp gives us a great oportunity -to reduce the time used to produce new artistic motifs, because of its -"randomly generated" nature. Once the artistic motif be created, it -is propagated through all visual manifestations of CentOS Project -corporate visual identity using the `centos-art.sh' script -(see section The `trunk/Scripts/Bash' Directory) inside the CentOS Artwork Repository. -

    -

    To set the time intervals between each new visual style production, we -could reuse the CentOS distribution major release schema. I.e., we -could produce a new visual style, every two years, based on a new -"randomly generated" flame pattern, and publish the whole corporate -visual identity (i.e., distribution stuff, promotion stuff, websites -stuff, etc.) with the new major release of CentOS distribution all -together at once. -

    -

    Producing a new visual style is not one day's task. Once we have -defined the artistic motif, we need to propagate it through all visual -manifestations of The CentOS Project corporate visual identity. When -we say that we could produce one new visual style every two years we -really mean: to work two years long in order to propagate a new visual -style to all visual manifestations of The CentOS Project corporate -visual identity. -

    -

    Obviously, in order to propagate one visual style to all different -visual manifestations of The CentOS Project corporate visual identity, -we need first to know which the visual manifestations are. To define -which visual manifestations are inside The CentOS Project corporate -visual identity is one of the goals the CentOS Artwork Repository and -this documentation manual are both aimed to satisfy. -

    -

    Once we define which the visual manifestation are, it is possible to -define how to produce them, and this way, organize the automation -process. Such automation process is one of the goals of -`centos-art.sh' script. -

    -

    With the combination of both CentOS Artwork Repository and -`centos-art.sh' scripts we define work lines where translators, -programmers, and graphic designers work together to distribute and -reduce the amount of time employed to produce The CentOS Project -monolithic corporate identity. -

    -

    From a monolithic corporate visual identity point of view, notice that -we are producing a new visual style for the same theme (i.e., -Flame). It would be another flame design but still a flame -design. This idea is very important to be aware of, because we are -somehow "refreshing" the theme, not changing it at all. -

    -

    This way, as we are "refreshing" the theme, we still keep oursleves -inside the monolithic conception we are trying to be attached to -(i.e., one unique name, and one unique visual style for all visual -manifestations). -

    -

    Producing artistic motifs is a creative process that may consume long -time, specially for people without experienced knowledge on graphic -design land. Using "randomly generated" conception to produce -artistic motifs could be, practically, a way for anyone to follow in -order to produce maintainable artistic motifs in few steps. -

    -

    Due to the "randomly generated" nature of Flame filter, we find that -Flame pattern is not always the same when we use Flame -filter interface. -

    -

    Using the same pattern design for each visual manifestation is -essential in order to maintain the visual connection among all visual -manifestations inside the same theme. Occasionally, we may introduce -pattern variations in opacity, size, or even position but never change -the pattern design itself, nor the color information used by images -considered part of the same theme. -

    -
    Important

    Important

    -When we design background images, which are considered part of the -same theme, it is essential to use the same design pattern always. -This is what makes theme images to be visually connected among -themeselves, and so, the reason we use to define the word "theme" -as: a set of images visually connected among themeselves. -

    + +

    2.34.2 Description

    -

    In order for us to reproduce the same flame pattern always, -Flame filter interface provides the `Save' and `Open' -options. The `Save' option brings up a file save dialog that -allows you to save the current Flame settings for the plug-in, so that -you can recreate them later. The `Open' option brings up a file -selector that allows you to open a previously saved Flame settings -file. +

    It applies to all tangible and non tangible items CentOS uses to +promote its existence. Clothes, posters, installation media, +stationery, release countdown images, banners, stickers, are all +examples of promotion designs.

    -

    The Flame settings we used in our example are saved in the file: -

    -
    trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
-
    - - -

    2.37.3 Construction

    + - -

    2.37.3.1 Step 1: Set image size

    - -

    Create an empty image and fill the `Background' layer with black -(000000) color. Image dimensions depend on the final -destination you plan to use the image for. For the sake of our -construction example we used an image of 640x480 pixels and 300 pixels -per inch (ppi). -

    + +

    2.34.3 Usage

    - -

    2.37.3.2 Step 2: Add base color and pattern information

    + -

    Create a new layer named `Base', place it over `Background' -layer and fill it with the base color (7800ff) you want to have -your background image set in. Add a mask to `Base' layer using -radial gradient and blur it. You may need to repeat this step more -than once in order to achieve a confortable black radial degradation -on the right side of your design. -

    -

    Duplicate `Base' layer and name it `Paper'. Place -`Paper' layer over `Base' layer. Remove content of -`Paper' layer and fill it with `Paper (100x100)' pattern. -Once you've done with black radial degradation, reduce the -`Paper' layer opacity to 20%. -

    -

    Notice that when we duplicate one layer, the mask information related -to layer is preserved from previous to next layer. This saves us some -of the time required to produce different layers with the same mask -information on them. -

    -

    Duplicate `Paper' layer and rename it `Stripes'. Remove -paper pattern from `Stripes' layer. Fill `Stripes' layer -with `Stripes (48x48)' pattern and reduce the `Stripes' -layer opacity to 15%. -

    - - -

    2.37.3.3 Step 3: Add flame motif

    - -

    Create a new layer named `Flame'. Set the foreground -(003cff) and background (0084ff) colors to the gradient -you want to build the flame motif. -

    -

    To build flame motif, use the flame filter (`Filters > Render > -Nature > Flame...') on `Flame' layer. We used a layer mask, with -a radial gradient on it to control the boundaries of flame motif on -`Flame' layer. -

    -

    Duplicate `Flame' layer and rename it `Flame Blur'. Place `Flame -Blur' below `Flame' layer. Apply Gussian blur filter -(`Filters > Blur > Gussian Blur...') until reaching the desiered -effect. -

    -

    The opacity value, in `Flame' layers, may vary from one image to -another based on the place the image will be finally placed on. For -example, images used as desktop background have the `Flame' layer -opacity set at 100% but `Flame Blur' is set to 70%. However, you -may find that background images used in anaconda progress slides have -opacity reduced differently, in order to reduce brightness in a way -that texts could look clean and readable over it. -

    - - -

    2.37.3.4 Step 4: Add foreground color

    - -

    Create a new layer named `Color', place it on top of all visible -layers and fill it with plain color (4c005a). Reduce -`Color' layer opacity to 20%. You can use the `Color' layer -to control the right side color information you want to produce the -image for. -

    -

    Duplicate `Flame' layer and create a new layer named -`Color#1'. Place `Color#1' layer on top of layer named -`Color'. Remove the mask information from `Color#1' layer -and recreate a new one using an inverted alpha channel as reference. -Remove `Color#1' layer content and fill it back with plain black -(000000) color. Reduce `Color#1' opacity to 20%. In this -step we created a mask to protect the flame artistic motif from black -color, so when we decrement or increment the opacity of layer, the -flame artistic motif wouldn't be affected, just the environment -suround it. -

    -

    When you set color information, remember that the same artistic motif -needs to be indexed to 14 and 16 colors, in order to produce Grub and -Syslinux visual manifestations respectively. Using many different -colors in the artistic motif may reduce the possibility of your design -to fix all different situations in. Likewise, using more colors in -one design, and less colors in another design will reduce the -connectivity among your designs, since color information is relevant -to visual identity. -

    -

    When you propagate your artistic motif visual style to different -visual manifestations of CentOS Project corporate visual identity, it -is up to you to find out justice and compromise among all possible -variables you may face. -

    - -

    2.37.4 See also

    + +

    2.34.4 See also

    - - - - - -
    2.36 The `trunk/Identity/Themes/Motifs' Directory   -
    2.19 The `trunk/Identity/Themes' Directory   -
    2.4 The `trunk/Identity' Directory   -
    2.3 The `trunk' Directory   -
    - - + + - - - + + +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

    - This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
    diff --git a/Manual/repository-html/repository_42.html b/Manual/repository-html/repository_42.html index 95efe65..9d86e14 100644 --- a/Manual/repository-html/repository_42.html +++ b/Manual/repository-html/repository_42.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.38 The trunk/Identity/Themes/Motifs/Modern Directory +CentOS Artwork Repository: 2.35 The trunk/Identity/Themes/Models/Default/Web Directory - - + + @@ -55,58 +55,70 @@ ul.toc {list-style: none} - - + + - - - + + + - +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
    - - -

    2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory

    + + +

    2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory

    - -

    2.38.1 Presentation

    + +

    2.35.1 Goals

    + + + + +

    2.35.2 Description

    - -

    2.38.2 Construction

    +

    It applies to all web applications CentOS uses to handle its needs +(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving +HTML standards should be consider here. +

    + - -

    2.38.3 Usage

    + +

    2.35.3 Usage

    - -

    2.38.4 See also

    + +

    2.35.4 See also

    - - + + - - - + + +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]

    - This document was generated on March, 11 2011 using texi2html 1.76. + This document was generated on March, 22 2011 using texi2html 1.76.
    diff --git a/Manual/repository-html/repository_43.html b/Manual/repository-html/repository_43.html index 9a70ab6..7514b57 100644 --- a/Manual/repository-html/repository_43.html +++ b/Manual/repository-html/repository_43.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.39 The trunk/Identity/Themes/Motifs/Modern/Backgrounds Directory +CentOS Artwork Repository: 2.36 The trunk/Identity/Themes/Motifs Directory - - + + @@ -55,175 +55,160 @@ ul.toc {list-style: none} - - + + - - - + + + - +
    [ < ][ > ]
    [ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
    - - -

    2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory

    + + +

    2.36 The `trunk/Identity/Themes/Motifs' Directory

    - -

    2.39.1 Goals

    + +

    2.36.1 Goals

    +

    The `trunk/Identity/Themes/Motifs' directory exists to: +

    - -

    2.39.2 Description

    -

    Inside `Motifs' directory, the `Backgrounds/' directory is -used to create vectorial designs using Inkscape and background images -using Gimp. Later, you can export background images as `.png' and -load them in your vectorial design project using the import feautre of -Inkscape. -

    -

    You may need to repeat this technic for different screen resoluions. -In that case you need to create one file for each screen resolution -and do the appropriate linking inside .svg to .png files. For example -if you need to produce background images in 800x600 you need to create -the following file: -

    -
     
    xcf/800x600.xcf
+
+
     2.36.2 Description 
    
+
+
    The artistic motif of theme is a graphic design component that
+provides the visual style of themes, it is used as pattern to connect
+all visual manifestations inside one unique theme.
+
    
+
    Artistic motifs are based on conceptual ideas. Conceptual ideas bring
+the motivation, they are fuel for the engines of human imagination.
+Good conceptual ideas may produce good motivation to produce almost
+anything, and art works don't escape from it.
+
    
+
    
+
     `TreeFlower' 
    
+
    CentOS like trees, has roots, trunk, branches, leaves and flowers. Day
+by day they work together in freedom, ruled by the laws of nature and
+open standards, to show the beauty of its existence.
+
    
+
     `Modern' 
    
+
    Modern, squares and circles flowing up.
+
    
+
    
+
+
    If you have new conceptual ideas for CentOS, then you can say that you
+want to create a new artistic motif for CentOS. To create a new
+artistic motif you need to create a directory under
+`Identity/Themes/Motifs/' using a name coherent with your
+conceptual idea. That name will be the name of your artistic motif. If
+possible, when creating new conceptual ideas for CentOS, think about
+what CentOS means for you, what does it makes you feel, take your
+time, think deep, and share; you can improve the idea as time goes on.
+
    
+
    Once you have defined a name for your theme, you need to create the
+motif structure of your theme. The motif structure is the basic
+direcotry structure you'll use to work your ideas. Here is where you
+organize your graphic design projects.
+
    
+
    To add a new motif structure to CentOS Artwork Repository, you need to
+use the centos-art command line in the
+`Identity/Themes/Motifs/' directory as described below:
+
    
+
     
    centos-art add --motif=ThemeName
 
    
-
    to produce the background image:
-
    
-
     
    img/800x600-bg.png
-
    
-
    which is loaded in: 
-
    
-
     
    svg/800x600.svg
-
    
-
    to produce the final background image:
-
    
-
     
    img/800x600.png         
-
    
-
    The `img/800x600.png' background image is produced automatically
-by means of rendering scripts.
-
    
-
    In other cases (e.g. Anaconda), it is possible that you need to make
-some variations to one background image that don't want to appear on
-regular background images of the same resolution. In this case you
-need to create a new and specific background image for that art
-component.  For example, if you need to produce the background image
-used by Anconda (800x600) art works you create the file:
-
    
-
     
    xcf/800x600-anaconda.xcf
+
    The previous command will create the basic structure of themes for
+you.  The basic structure produced by centos-art command is
+illustrated in the following figure:
+
    
+
     
    trunk/Identity/Themes/Motifs/$ThemeName/
+|-- Backgrounds
+|   |-- Img
+|   `-- Tpl
+|-- Info
+|   |-- Img
+|   `-- Tpl
+|-- Palettes
+`-- Screenshots
 
    
-
    to produce the background image:
-
    
-
     
    img/800x600-anaconda-bg.png
-
    
-
    which is loaded in: 
-
    
-
     
    svg/800x600-anaconda.svg
-
    
-
    to produce the file:
-
    
-
     
    img/800x600-anaconda.png
-
    
-
    The 800x600-anaconda.png file is used by all Anaconda art works
-sharing a common 800x600 screen resolution (e.g., Header, Progress,
-Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors
-and 640x480 pixels so you need to create a 640x480 background image
-for it, and take the color limitation into account when designing it.
-
    
-
    Background images without artistic motif are generally used as based
-to build the Background images that do contain the theme artistic
-motif. 
-
    
-
    Background images are linked (using the import feature of
-Inkscape) inside almost all theme art works. This structure let you
-make centralized changes on the visual identity and propagate them
-quickly to other areas. 
-
    
-
    In this structure you design background images for different screen
-resolutions based on the theme artistic motif.
-
    
-
    You may create different artistic motifs propositions based
-on the same conceptual idea. The conceptual idea is what defines a
-theme. Artistic motifs are interpretations of that idea.
-
    
-
    Inside this directory artistic motifs are organized by name (e.g.,
-TreeFlower, Modern, etc.).
-
    
-
    Each artistic motif directory represents just one unique artistic
-motif. 
-
    
-
    The artistic motif is graphic design used as common pattern to connect
-all visual manifestations inside one unique theme.  The artistic motif
-is based on a conceptual idea.  Artistic motifs provide visual style
-to themes.
-
    
-
    Designing artistic motifs is for anyone interested in creating
-beautiful themes for CentOS.  When building a theme for CentOS, the
-first design you need to define is the artistic motif. 
-
    
 
-
    Inside CentOS Artwork Repository, theme visual styles (Motifs) and
-theme visual structures (Models) are two different working lines.
-When you design an artistic motif for CentOS you concentrate on its
-visual style, and eventualy, use the centos-art command line
-interface to render the visual style, you are currently producing,
-against an already-made theme model in order to produce the final
-result.  Final images are stored under `Motifs/' directory using
-the model name, and the model directory structure as reference.
-
    
-
    The artistic motif base structure is used by centos-art to
-produce images automatically. This section describes each directory of
-CentOS artistic motif base structure.
+
+
     2.36.3 Usage 
    
+
+
    When designing artistic motifs for CentOS, consider the following
+recommendations:
 
    
+
      
+
    •  Give a unique (case-sensitive) name to your Motif. This name is
+used as value wherever theme variable ($THEME) or translation marker
+(=THEME=) is.  Optionally, you can add a description about
+inspiration and concepts behind your work.
 
-
-
       2.39.3 Usage 
      
+
    •  Use the location `trunk/Identity/Themes/Motifs/$THEME/' to
+store your work. If it doesn't exist create it. Note that this require
+you to have previous commit access in CentOS Artwork Repository.
 
-
      The `Backgrounds/' directory is probably the core component,
-inside `Motifs/' directory structure.  Inside `Backgrounds/'
-directory you produce background images used by almost all theme
-models (e.g., Distribution, Websites, Promotion, etc.).  The
-`Backgrounds/' directory can contain subdirectories to help you
-organize the design process. 
-
      
+
    •  The CentOS Project is using the blue color (#204c8d) as base
+color for its corporate visual identity. Use such base corporate color
+information as much as possible in your artistic motif designs.
+
+
    •  Try to make your design fit one of the theme models.
+
+
    •  Feel free to make your art enterprise-level and beautiful.
 
-
-
       2.39.4 See also 
      
+
    •  Add the following information on your artwork (both in a visible
+design area and document metadata):
+
+
+
    
+
+
+
+
     2.36.4 See also 
    
 
 
-
-
-
    2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory  
+
    2.19 The `trunk/Identity/Themes' Directory  
 
    2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory  
+
    2.4 The `trunk/Identity' Directory  
 
    2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory  
+
    2.3 The `trunk' Directory  
 
    
 
    
 
 
-
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_44.html b/Manual/repository-html/repository_44.html
index 870bcbd..9a00cb1 100644
--- a/Manual/repository-html/repository_44.html
+++ b/Manual/repository-html/repository_44.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.40 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img Directory
+CentOS Artwork Repository: 2.37 The trunk/Identity/Themes/Motifs/Flame Directory
 
-
-
+
+
 
 
 
@@ -55,63 +55,261 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory 
    
+
+
+
     2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory 
    
 
 
-
-
     2.40.1 Goals 
    
+
+
     2.37.1 Goals 
    
 
-
      
-
    •  ...
-
    
+
    This section describes the steps we followed to construct the
+Flame artistic motif. This section may be useful for anyone
+interested in reproducing the Flame artistic motif, or in
+creating new artistic motifs for The CentOS Project corporate visual
+identity (see section The `trunk/Identity' Directory).
+
    
+
+
+
     2.37.2 Description 
    
+
+
    The Flame artistic motif was built using the flame filter of
+Gimp 2.2 in CentOS 5.5.
+
    
+
    The flame filter of Gimp can produce stunning, randomly generated
+fractal patterns. The flame filter of Gimp gives us a great oportunity
+to reduce the time used to produce new artistic motifs, because of its
+"randomly generated" nature. Once the artistic motif be created, it
+is propagated through all visual manifestations of CentOS Project
+corporate visual identity using the `centos-art.sh' script
+(see section The `trunk/Scripts/Bash' Directory) inside the CentOS Artwork Repository.
+
    
+
    To set the time intervals between each new visual style production, we
+could reuse the CentOS distribution major release schema.  I.e., we
+could produce a new visual style, every two years, based on a new
+"randomly generated" flame pattern, and publish the whole corporate
+visual identity (i.e., distribution stuff, promotion stuff, websites
+stuff, etc.) with the new major release of CentOS distribution all
+together at once.
+
    
+
    Producing a new visual style is not one day's task. Once we have
+defined the artistic motif, we need to propagate it through all visual
+manifestations of The CentOS Project corporate visual identity. When
+we say that we could produce one new visual style every two years we
+really mean: to work two years long in order to propagate a new visual
+style to all visual manifestations of The CentOS Project corporate
+visual identity.
+
    
+
    Obviously, in order to propagate one visual style to all different
+visual manifestations of The CentOS Project corporate visual identity,
+we need first to know which the visual manifestations are.  To define
+which visual manifestations are inside The CentOS Project corporate
+visual identity is one of the goals the CentOS Artwork Repository and
+this documentation manual are both aimed to satisfy.
+
    
+
    Once we define which the visual manifestation are, it is possible to
+define how to produce them, and this way, organize the automation
+process. Such automation process is one of the goals of
+`centos-art.sh' script.
+
    
+
    With the combination of both CentOS Artwork Repository and
+`centos-art.sh' scripts we define work lines where translators,
+programmers, and graphic designers work together to distribute and
+reduce the amount of time employed to produce The CentOS Project
+monolithic corporate identity.
+
    
+
    From a monolithic corporate visual identity point of view, notice that
+we are producing a new visual style for the same theme (i.e.,
+Flame). It would be another flame design but still a flame
+design. This idea is very important to be aware of, because we are
+somehow "refreshing" the theme, not changing it at all. 
+
    
+
    This way, as we are "refreshing" the theme, we still keep oursleves
+inside the monolithic conception we are trying to be attached to
+(i.e., one unique name, and one unique visual style for all visual
+manifestations).
+
    
+
    Producing artistic motifs is a creative process that may consume long
+time, specially for people without experienced knowledge on graphic
+design land. Using "randomly generated" conception to produce
+artistic motifs could be, practically, a way for anyone to follow in
+order to produce maintainable artistic motifs in few steps. 
+
    
+
    Due to the "randomly generated" nature of Flame filter, we find that
+Flame pattern is not always the same when we use Flame
+filter interface.
+
    
+
    Using the same pattern design for each visual manifestation is
+essential in order to maintain the visual connection among all visual
+manifestations inside the same theme.  Occasionally, we may introduce
+pattern variations in opacity, size, or even position but never change
+the pattern design itself, nor the color information used by images
+considered part of the same theme.
+
    
+
    Important
    Important
    
+When we design background images, which are considered part of the
+same theme, it is essential to use the same design pattern always.
+This is what makes theme images to be visually connected among
+themeselves, and so, the reason we use to define the word "theme"
+as: a set of images visually connected among themeselves.
+
    
+
+
    In order for us to reproduce the same flame pattern always,
+Flame filter interface provides the `Save' and `Open'
+options. The `Save' option brings up a file save dialog that
+allows you to save the current Flame settings for the plug-in, so that
+you can recreate them later.  The `Open' option brings up a file
+selector that allows you to open a previously saved Flame settings
+file.
+
    
+
    The Flame settings we used in our example are saved in the file:
+
    
+
    trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
+
    
+
+
+
     2.37.3 Construction 
    
 
 
-
-
     2.40.2 Description 
    
+
+
     2.37.3.1 Step 1: Set image size 
    
 
+
    Create an empty image and fill the `Background' layer with black
+(000000) color. Image dimensions depend on the final
+destination you plan to use the image for. For the sake of our
+construction example we used an image of 640x480 pixels and 300 pixels
+per inch (ppi).
+
    
 
-
-
     2.40.3 Usage 
    
+
+
     2.37.3.2 Step 2: Add base color and pattern information 
    
 
-
    In this directory is where you store all background images (e.g.,
-.png, .jpg, .xpm, etc.).  This directory is required by
-`centos-art' command line interface.
+
    Create a new layer named `Base', place it over `Background'
+layer and fill it with the base color (7800ff) you want to have
+your background image set in.  Add a mask to `Base' layer using
+radial gradient and blur it.  You may need to repeat this step more
+than once in order to achieve a confortable black radial degradation
+on the right side of your design.
+
    
+
    Duplicate `Base' layer and name it `Paper'. Place
+`Paper' layer over `Base' layer. Remove content of
+`Paper' layer and fill it with `Paper (100x100)' pattern.
+Once you've done with black radial degradation, reduce the
+`Paper' layer opacity to 20%. 
+
    
+
    Notice that when we duplicate one layer, the mask information related
+to layer is preserved from previous to next layer. This saves us some
+of the time required to produce different layers with the same mask
+information on them.
 
    
+
    Duplicate `Paper' layer and rename it `Stripes'. Remove
+paper pattern from `Stripes' layer. Fill `Stripes' layer
+with `Stripes (48x48)' pattern and reduce the `Stripes'
+layer opacity to 15%.
+
    
+
+
+
     2.37.3.3 Step 3: Add flame motif 
    
 
-
-
     2.40.4 See also 
    
+
    Create a new layer named `Flame'. Set the foreground
+(003cff) and background (0084ff) colors to the gradient
+you want to build the flame motif. 
+
    
+
    To build flame motif, use the flame filter (`Filters > Render >
+Nature > Flame...') on `Flame' layer. We used a layer mask, with
+a radial gradient on it to control the boundaries of flame motif on
+`Flame' layer.
+
    
+
    Duplicate `Flame' layer and rename it `Flame Blur'. Place `Flame
+Blur' below `Flame' layer. Apply Gussian blur filter
+(`Filters > Blur > Gussian Blur...') until reaching the desiered
+effect.
+
    
+
    The opacity value, in `Flame' layers, may vary from one image to
+another based on the place the image will be finally placed on.  For
+example, images used as desktop background have the `Flame' layer
+opacity set at 100% but `Flame Blur' is set to 70%.  However, you
+may find that background images used in anaconda progress slides have
+opacity reduced differently, in order to reduce brightness in a way
+that texts could look clean and readable over it.
+
    
+
+
+
     2.37.3.4 Step 4: Add foreground color 
    
+
+
    Create a new layer named `Color', place it on top of all visible
+layers and fill it with plain color (4c005a). Reduce
+`Color' layer opacity to 20%. You can use the `Color' layer
+to control the right side color information you want to produce the
+image for.
+
    
+
    Duplicate `Flame' layer and create a new layer named
+`Color#1'. Place `Color#1' layer on top of layer named
+`Color'. Remove the mask information from `Color#1' layer
+and recreate a new one using an inverted alpha channel as reference.
+Remove `Color#1' layer content and fill it back with plain black
+(000000) color. Reduce `Color#1' opacity to 20%.  In this
+step we created a mask to protect the flame artistic motif from black
+color, so when we decrement or increment the opacity of layer, the
+flame artistic motif wouldn't be affected, just the environment
+suround it.
+
    
+
    When you set color information, remember that the same artistic motif
+needs to be indexed to 14 and 16 colors, in order to produce Grub and
+Syslinux visual manifestations respectively. Using many different
+colors in the artistic motif may reduce the possibility of your design
+to fix all different situations in.  Likewise, using more colors in
+one design, and less colors in another design will reduce the
+connectivity among your designs, since color information is relevant
+to visual identity. 
+
    
+
    When you propagate your artistic motif visual style to different
+visual manifestations of CentOS Project corporate visual identity, it
+is up to you to find out justice and compromise among all possible
+variables you may face.
+
    
 
+
+
     2.37.4 See also 
    
 
+
+
+
+
+
+
    2.36 The `trunk/Identity/Themes/Motifs' Directory  
+
    2.19 The `trunk/Identity/Themes' Directory  
+
    2.4 The `trunk/Identity' Directory  
+
    2.3 The `trunk' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_45.html b/Manual/repository-html/repository_45.html
index 2b1c54f..cea2733 100644
--- a/Manual/repository-html/repository_45.html
+++ b/Manual/repository-html/repository_45.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.41 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl Directory
+CentOS Artwork Repository: 2.38 The trunk/Identity/Themes/Motifs/Modern Directory
 
-
-
+
+
 
 
 
@@ -55,62 +55,58 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory 
    
+
+
+
     2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory 
    
 
 
-
-
     2.41.1 Goals 
    
+
+
     2.38.1 Presentation 
    
 
-
      
-
    •  ...
-
    
 
+
+
     2.38.2 Construction 
    
 
-
-
     2.41.2 Description 
    
 
+
+
     2.38.3 Usage 
    
 
-
-
     2.41.3 Usage 
    
+
      
+
    •  ...
+
    
 
-
    In this directory is where you store all the scalable vector graphics
-(e.g., .svg) files. This directory is required by `centos-art'
-command line interface.
-
    
 
-
-
     2.41.4 See also 
    
+
+
     2.38.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_46.html b/Manual/repository-html/repository_46.html
index 982a248..9813218 100644
--- a/Manual/repository-html/repository_46.html
+++ b/Manual/repository-html/repository_46.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.42 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf Directory
+CentOS Artwork Repository: 2.39 The trunk/Identity/Themes/Motifs/Modern/Backgrounds Directory
 
-
-
+
+
 
 
 
@@ -55,71 +55,175 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory 
    
+
+
+
     2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory 
    
 
 
-
-
     2.42.1 Goals 
    
+
+
     2.39.1 Goals 
    
 
 
      
-
    •  ...
+
    •  Organize background images for Modern theme.
 
    
 
 
-
-
     2.42.2 Description 
    
-
-
      
-
    •  ...
-
    
+
+
     2.39.2 Description 
    
 
+
    Inside `Motifs' directory, the `Backgrounds/' directory is
+used to create vectorial designs using Inkscape and background images
+using Gimp. Later, you can export background images as `.png' and
+load them in your vectorial design project using the import feautre of
+Inkscape.
+
    
+
    You may need to repeat this technic for different screen resoluions.
+In that case you need to create one file for each screen resolution
+and do the appropriate linking inside .svg to .png files.  For example
+if you need to produce background images in 800x600 you need to create
+the following file:
+
    
+
     
    xcf/800x600.xcf
+
    
+
    to produce the background image:
+
    
+
     
    img/800x600-bg.png
+
    
+
    which is loaded in: 
+
    
+
     
    svg/800x600.svg
+
    
+
    to produce the final background image:
+
    
+
     
    img/800x600.png         
+
    
+
    The `img/800x600.png' background image is produced automatically
+by means of rendering scripts.
+
    
+
    In other cases (e.g. Anaconda), it is possible that you need to make
+some variations to one background image that don't want to appear on
+regular background images of the same resolution. In this case you
+need to create a new and specific background image for that art
+component.  For example, if you need to produce the background image
+used by Anconda (800x600) art works you create the file:
+
    
+
     
    xcf/800x600-anaconda.xcf
+
    
+
    to produce the background image:
+
    
+
     
    img/800x600-anaconda-bg.png
+
    
+
    which is loaded in: 
+
    
+
     
    svg/800x600-anaconda.svg
+
    
+
    to produce the file:
+
    
+
     
    img/800x600-anaconda.png
+
    
+
    The 800x600-anaconda.png file is used by all Anaconda art works
+sharing a common 800x600 screen resolution (e.g., Header, Progress,
+Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors
+and 640x480 pixels so you need to create a 640x480 background image
+for it, and take the color limitation into account when designing it.
+
    
+
    Background images without artistic motif are generally used as based
+to build the Background images that do contain the theme artistic
+motif. 
+
    
+
    Background images are linked (using the import feature of
+Inkscape) inside almost all theme art works. This structure let you
+make centralized changes on the visual identity and propagate them
+quickly to other areas. 
+
    
+
    In this structure you design background images for different screen
+resolutions based on the theme artistic motif.
+
    
+
    You may create different artistic motifs propositions based
+on the same conceptual idea. The conceptual idea is what defines a
+theme. Artistic motifs are interpretations of that idea.
+
    
+
    Inside this directory artistic motifs are organized by name (e.g.,
+TreeFlower, Modern, etc.).
+
    
+
    Each artistic motif directory represents just one unique artistic
+motif. 
+
    
+
    The artistic motif is graphic design used as common pattern to connect
+all visual manifestations inside one unique theme.  The artistic motif
+is based on a conceptual idea.  Artistic motifs provide visual style
+to themes.
+
    
+
    Designing artistic motifs is for anyone interested in creating
+beautiful themes for CentOS.  When building a theme for CentOS, the
+first design you need to define is the artistic motif. 
+
    
 
+
    Inside CentOS Artwork Repository, theme visual styles (Motifs) and
+theme visual structures (Models) are two different working lines.
+When you design an artistic motif for CentOS you concentrate on its
+visual style, and eventualy, use the centos-art command line
+interface to render the visual style, you are currently producing,
+against an already-made theme model in order to produce the final
+result.  Final images are stored under `Motifs/' directory using
+the model name, and the model directory structure as reference.
+
    
+
    The artistic motif base structure is used by centos-art to
+produce images automatically. This section describes each directory of
+CentOS artistic motif base structure.
+
    
 
-
-
     2.42.3 Usage 
    
+
+
     2.39.3 Usage 
    
 
-
    In this directory is where you store the project files (e.g, .xcf) of
-Gimp.  This directory is not required by `centos-art' command
-line interface. If you can create a beautiful background images using
-scalable vector graphics only, then there is no need to use the
-`Xcf/' directory to store background projects. Of course, you can
-merge both Gimp and Inkscape power to produce images based on them.
-In this last case you need the `Xcf/' directory.
+
    The `Backgrounds/' directory is probably the core component,
+inside `Motifs/' directory structure.  Inside `Backgrounds/'
+directory you produce background images used by almost all theme
+models (e.g., Distribution, Websites, Promotion, etc.).  The
+`Backgrounds/' directory can contain subdirectories to help you
+organize the design process. 
 
    
 
-
-
     2.42.4 See also 
    
+
+
     2.39.4 See also 
    
+
+
+
+
+
+
    2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory  
+
    2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory  
+
    2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory  
+
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_47.html b/Manual/repository-html/repository_47.html
index 93662f5..108b46e 100644
--- a/Manual/repository-html/repository_47.html
+++ b/Manual/repository-html/repository_47.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.43 The trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress Directory
+CentOS Artwork Repository: 2.40 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img Directory
 
-
-
+
+
 
 
 
@@ -55,99 +55,63 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory 
    
+
+
+
     2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory 
    
 
 
-
-
     2.43.1 Goals 
    
+
+
     2.40.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.43.2 Description 
    
+
+
     2.40.2 Description 
    
 
 
-
-
     2.43.3 Usage 
    
+
+
     2.40.3 Usage 
    
 
-
    To render Anaconda progress slide images using the Modern
-artistic motif design, the Default theme model, and available
-translation files (-- Removed(pxref:trunk Translations Identity Themes Distro
-Anaconda Progress) --); use the following commands:
+
    In this directory is where you store all background images (e.g.,
+.png, .jpg, .xpm, etc.).  This directory is required by
+`centos-art' command line interface.
 
    
-
     
    cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
-centos-art render --identity
-
    
-
    The above command will create the following structure:
-
    
-
     
    trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
-|-- 3
-|   |-- en
-|   |   |-- 01-welcome.png
-|   |   |-- 02-donate.png
-|   |   `-- 03-yum.png
-|   `-- es
-|       |-- 01-welcome.png
-|       |-- 02-donate.png
-|       `-- 03-yum.png
-|-- 4
-|   |-- en
-|   |   |-- 01-welcome.png
-|   |   |-- 02-donate.png
-|   |   `-- 03-yum.png
-|   `-- es
-|       |-- 01-welcome.png
-|       |-- 02-donate.png
-|       `-- 03-yum.png
-`-- 5
-    |-- en
-    |   |-- 01-welcome.png
-    |   |-- 02-donate.png
-    |   `-- 03-yum.png
-    `-- es
-        |-- 01-welcome.png
-        |-- 02-donate.png
-        `-- 03-yum.png
-
    
-
-
-
-
     2.43.4 See also 
    
+
+
+
     2.40.4 See also 
    
 
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_48.html b/Manual/repository-html/repository_48.html
index 2b6ea83..f65d221 100644
--- a/Manual/repository-html/repository_48.html
+++ b/Manual/repository-html/repository_48.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.44 The trunk/Identity/Themes/Motifs/Modern/Palettes Directory
+CentOS Artwork Repository: 2.41 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl Directory
 
-
-
+
+
 
 
 
@@ -55,64 +55,62 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory 
    
+
+
+
     2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory 
    
 
 
-
-
     2.44.1 Goals 
    
+
+
     2.41.1 Goals 
    
 
 
      
-
    •  Organize palette files for Modern theme.
+
    •  ...
 
    
 
 
-
-
     2.44.2 Description 
    
+
+
     2.41.2 Description 
    
 
 
-
-
     2.44.3 Usage 
    
+
+
     2.41.3 Usage 
    
 
-
    Here is where graphic designers define theme palettes for
-color-limited art works. Theme palettes contain the color information
-that rendering functions need, in order to produce images with color
-limitations.  Theme palettes contain the unique color information
-required by theme.
+
    In this directory is where you store all the scalable vector graphics
+(e.g., .svg) files. This directory is required by `centos-art'
+command line interface.
 
    
 
-
-
     2.44.4 See also 
    
+
+
     2.41.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_49.html b/Manual/repository-html/repository_49.html
index 018d425..05c8b2c 100644
--- a/Manual/repository-html/repository_49.html
+++ b/Manual/repository-html/repository_49.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.45 The trunk/Identity/Themes/Motifs/TreeFlower Directory
+CentOS Artwork Repository: 2.42 The trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf Directory
 
-
-
+
+
 
 
 
@@ -55,58 +55,71 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory 
    
+
+
+
     2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory 
    
 
 
-
-
     2.45.1 Goals 
    
+
+
     2.42.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.45.2 Description 
    
+
+
     2.42.2 Description 
    
 
+
      
+
    •  ...
+
    
 
-
-
     2.45.3 Usage 
    
 
 
-
-
     2.45.4 See also 
    
+
+
     2.42.3 Usage 
    
+
+
    In this directory is where you store the project files (e.g, .xcf) of
+Gimp.  This directory is not required by `centos-art' command
+line interface. If you can create a beautiful background images using
+scalable vector graphics only, then there is no need to use the
+`Xcf/' directory to store background projects. Of course, you can
+merge both Gimp and Inkscape power to produce images based on them.
+In this last case you need the `Xcf/' directory.
+
    
+
+
+
     2.42.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_5.html b/Manual/repository-html/repository_5.html
index 2f8074f..cff71fd 100644
--- a/Manual/repository-html/repository_5.html
+++ b/Manual/repository-html/repository_5.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.1 The branches Directory
+CentOS Artwork Repository: 1.4 Document Convenctions
 
-
-
+
+
 
 
 
@@ -55,69 +55,158 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.1 The `branches' Directory 
    
+
+
+
     1.4 Document Convenctions 
    
 
-
-
-
     2.1.1 Goals 
    
-
-
    This directory implements the Subversion's branches concept in a
-trunk, branches, tags repository structure.
+
    In this manual the personal pronoun we is used to repesent
+The CentOS Artwork SIG. This is, the group of persons building
+the CentOS Artwork Repository.
 
    
-
-
-
     2.1.2 Description 
    
-
-
    The `branches/' directory structre provides the intermediate
-space for creating several instances of `trunk/' directory
-structure for parallel development and later merging changes back to
-`trunk/' in the same parallel basis.
+
    In this manual the phrase "CentOS Artwork Repository" is used to
+refer the very specific organization of files we use to store The
+CentOS Project corporate visual identity.  It is the source location
+The CentOS Community uses to retrive The CentOS Project branded images
+used to build different visual manifestations like The CentOS
+Distribution, The CentOS Webs and The CentOS Stationery.
+
    
+
    In this manual the word "centos-art" is used to refer the
+command-line interface of centos-art.sh script.  The
+centos-art.sh script is the the automation tool we use to
+realize most of the frequent tasks inside the CentOS Artwork
+Repository.
+
    
+
    In this manual, certain words are represented in different fonts,
+typefaces, sizes, and weights. This highlighting is systematic;
+different words are represented in the same style to indicate their
+inclusion in a specific category. The types of words that are
+represented this way include the following:
+
    
+
    
+
     command
    
+
    
+
    Linux commands (and other operating system commands, when used) are
+represented this way. This style should indicate to you that you can
+type the word or phrase on the command line and press Enter to invoke
+a command. Sometimes a command contains words that would be displayed
+in a different style on their own (such as file names). In these
+cases, they are considered to be part of the command, so the entire
+phrase is displayed as a command. For example:
+
    
+
    Use the centos-art identity --render='path/to/dir' command
+to produce contents inside the `trunk/Identity' directory
+structure.
+
    
+
    
+
+
    
+
     `file name'
    
+
    
+
    File names, directory names, paths, and RPM package names are
+represented this way. This style indicates that a particular file or
+directory exists with that name on your system. Examples:
 
    
+
    The `init.sh' file in `trunk/Scripts/Bash/Cli/' directory is
+the initialization script, written in Bash, used to automate most of
+tasks in the repository.
+
    
+
    The centos-art command uses the `ImageMagick' RPM
+package to convert images from PNG format to other formats.
+
    
+
    
+
+
    
+
     key
    
+
    
+
    A key on the keyboard is shown in this style. For example:
+
    
+
    To use TAB completion to list particular files in a directory,
+type ls, then a character, and finally the Tab key. Your
+terminal displays the list of files in the working directory that
+begin with that character.  
+
    
+
    
+
+
    
+
     key-combination
    
+
    A combination of keystrokes is represented in this way. For example:
+
    
+
    The Ctrl-Alt-Backspace key combination exits your graphical
+session and returns you to the graphical login screen or the console.
+
    
+
    
+
+
    
+
     computer output
    
+
    
+
    Text in this style indicates text displayed to a shell prompt such as
+error messages and responses to commands. For example:
+
    
+
    The ls command displays the contents of a directory. For example:
+
    
+
    Config                           manual_renameEntry.sh
+manual_copyEntry.sh              manual_restoreCrossReferences.sh
+manual_deleteCrossReferences.sh  manual_searchIndex.sh
+
    
+
    The output returned in response to the command (in this case, the
+contents of the directory) is shown in this style.
+
    
+
    
+
+
    Additionally, we use several different strategies to draw your
+attention to certain pieces of information. In order of urgency, these
+items are marked as a note, tip, important, caution, or warning. For
+example:
+
    
+
    info
    Note
     Remember that Linux is case sensitive. In other words, a
+rose is not a ROSE is not a rOsE. 
+
    
 
-
-
     2.1.3 Usage 
    
+
    Info
    Tip
     The directory `/usr/share/doc/' contains additional
+documentation for packages installed on your system. 
+
    
 
-
    The `branches/' directory structure is unused, so far.
-
    
+
    Important
    Important
     If you modify the DHCP configuration file, the
+changes do not take effect until you restart the DHCP daemon. 
+
    
 
-
-
     2.1.4 See also 
    
+
    Caution
    Caution
     Do not perform routine tasks as root -- use a
+regular user account unless you need to use the root account for
+system administration tasks.
+
    
 
-
+
    Warning
    Warning
     Be careful to remove only the necessary partitions.
+Removing other partitions could result in data loss or a corrupted
+system environment.
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_50.html b/Manual/repository-html/repository_50.html
index d27e184..99363de 100644
--- a/Manual/repository-html/repository_50.html
+++ b/Manual/repository-html/repository_50.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.46 The trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds Directory
+CentOS Artwork Repository: 2.43 The trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress Directory
 
-
-
+
+
 
 
 
@@ -55,370 +55,99 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory 
    
+
+
+
     2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory 
    
 
 
-
-
     2.46.1 Goals 
    
-
-
    This section exists to orgnize backgrounds of TreeFlower
-artistic motif.
-
    
-
-
-
     2.46.2 Description 
    
-
-
-
-
     2.46.2.1 Desktop background 
    
-
-
    Once you have defined the vectorial artistic motif design, use the
-centos-art.sh script (as described in usage section below)
-to produce the png version of it. With the png version of your
-vectorial design do the following:
-
    
-
    Open the png version with GIMP.
-
    
-
    Save the png version as a project of GIMP inside
-`trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf'
-directory, using the same name of your vectorial design but with the
-`.xcf' extension.  
-
    
-
    Now use GIMP to improve your design.  Here you may add one layer for
-pattern, another for colors, and so on until you find yourself
-confortable with your artwork. For example,  the following layer
-distribution (from bottom to top) was used to build revision 285 of
-file `1360x768.xcf' using TreeFlower artistic motif at
-revision 241.
-
    
-
    
-
     Layer 1: Background 
    
-
    
-
    The first thing we did with GIMP was to create a layer named
-`Background' to store the artistic motif (File > Open as layer).
-This layer is the lowest layer in the image.  Later, we started to
-create layers one upon another to change the artistic motif visual
-style.
-
    
-
    
-
     Layer 2: Shadow#1
    
-
    
-
    This layer is above `Background' and contains a linear gradient
-from left (000000) to right (transparent) covering the whole image.
-This layer masks the artistic motif to avoid the effect of linear
-gradient. This layer is 100% of opacity.
-
    
-
    
-
     Layer 3: Shadow#2
    
-
    
-
    This layer is above `Shadow#1' and contains a linear gradient
-from left (000000) to right (transparent) covering just the 70% of the
-whole image aproximatly. This layer doesn't mask the artistic motif
-which make the left part of it fall into the dark of linear gradient.
-This layer is 100% of opacity.
-
    
-
    
-
     Layer 4: Pattern (Paper)
    
-
    
-
    This layer is above `Shadow#2' an contains the paper pattern
-shipped with GIMP 2.2. This layer doesn't mask the artistic motif so
-the pattern is applied over the whole image. This layer is set to 15%
-of opacity.
-
    
-
    
-
     Layer 5: Pattern (Stripes)
    
-
    
-
    This layer is above `Pattern (Paper)' and contains the stripes
-used over the artistic motif. This layer do masks the artistic motif
-so the stripes are only applied to it. This layer is set to 10% of
-opacity.
-
    
-
    
-
     Layer 6: Shadow#3
    
-
    
-
    This layer is above `Pattern (Stripes)' and contains a linear
-gradient from right (6600ff) to left (transparent).  This layer masks
-the artistic motif so the linear gradient doesn't affect it. This
-layer is set to 15% of opacity.
-
    
-
    
-
     Layer 7: Shadow#4
    
-
    
-
    This layer is above `Shadow#3' and contains a
-linear gradient from left (000000) to right (transparent). This layer
-do masks the artistic motif so the linear gradient doesn't affect it.
-This layer is set to 10% of opacity.
-
    
-
    
-
     Layer 8: Color#1
    
-
    
-
    This layer is above `Shadow#4' and is filled with orange (ffae00)
-color over the whole image. This layer is set to 10% of opacity.
-
    
-
    
-
     Layer 9: Color#2
    
-
    
-
    This layer is above `Color#1' and is filled with
-blue (010a88) color over the whole image. This layer is set to 10% of
-opacity.
-
    
-
    
-
    
-
-
    info
    Note
     There is no definite combination. To get the appropriate
-visual design is a matter of constant testing and personal taste.
-
    
-
-
    Finally, use `Save as copy ...' option to export the final
-design. To export the final design use the same name of your vectorial
-design plus `-final.png' extension. 
-
    
-
    You can repeat these steps to create images for other screen
-resolutions.
-
    
-
-
-
     2.46.2.2 Anaconda Prompt (syslinux) background 
    
-
-
    When building syslinux backgrounds it is needed to take into account
-that the final image is reduced to 16 colors. In desktop background
-there is no color limitation but syslinux does have. The goal of this
-section is achieving a final syslinux background as close as possible
-to desktop backgrounds using 16 colors only.
-
    
-
    Another point to consider is the forground and background definition
-used by syslinux. The syslinux documentation says that the color set
-in position 0 is the background and color set in position 7 is the
-forground. The final palette of color used by our background will
-match that specification. For great contrast we'll use black as
-background and white as forground. At this poing we have black
-(000000) and white (ffffff) colors in our syslinux palette, which left
-us with 14 colors to play with. 
-
    
-
    Let's begin with `Xcf/640x300.xcf' layer distribution from bottom
-to top:
-
    
-
    
-
     Layer 1: Background
    
-
    
-
    This layer is the lowest layer in the image composition and contains
-the artistic motif image rendered for the same resolution (i.e.,
-`Img/Png/640x300.png'). This layer is set to 100% of opacity.
-
    
-
    
-
     Layer 2: Pattern (Paper)
    
-
    
-
    This layer is placed above `Background' layer and contains the
-paper pattern shipped with GIMP 2.2. This layer doesn't mask the
-artistic motif. This layer is set to 30% of opacity.
-
    
-
    
-
     Layer 3: Pattern (Stripes)
    
-
    
-
    This layer is placed above `Pattern (Paper)' layer and contains
-the stripes pattern shipped with GIMP 2.2. This layer does mask the
-artistic motif in order to apply the stripes over it only. The
-background is not affected by the stripes pattern just the artistic
-motif. This layer is set to 20% of opacity.
-
    
-
    
-
     Layer 4: Shadow#1
    
-
    
-
    This layer is placed above `Pattern (Stripes)' layer and fills
-the entire layer area with violet (6600ff) color. This layer do mask
-the artistic motif in order to applied the violet color to the
-background area outside the artistic motif only. This layer is set to
-15% of opacity.
-
    
-
    
-
     Layer 5: Color#1
    
-
    
-
    This layer is above `Shadow#1' and is filled with orange (ffae00)
-color to cover the whole image. This layer is set to 10% of opacity.
-
    
-
    
-
     Layer 6: Color#2
    
-
    
-
    This layer is above `Color#1' and is filled with blue (010a88)
-color to cover the whole image. This layer is set to 10% of opacity.
-
    
-
    
-
     Layer 7: Shadow#2
    
-
    
-
    This layer is above `Color#1' and contains a linear gradient from
-left (000000) to right (transparent) covering 70% of the image
-approximately. 
-
    
-
    
-
    
-
-
    At this point we have the composition and should look like the desktop
-backgrounds. Compared with desktop backgrounds there are some
-differences in opacity. This is because in our testings the final
-color information found with this composition produces an acceptable
-16 color image. Of course this is something we haven't seen yet.
-
    
-
    To define the color information of our current coposition, save the
-syslinux background composition we've done using `File > Save as
-Copy ...' option in the following location:
-
    
-
    trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png
-
    
-
    Now, create the final png version of syslinux backgrounds using the
-following command:
-
    
-
    centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt
-
    
-
    This command will create syslinux-splash final images for all major
-releases of CentOS distribution the repository has been configured to.
-The important files here are `syslinux-splash.png', other
-files may contain the wrong information because we haven't defined yet
-the correct color information to use.
-
    
-
    Open one `syslinux-splash.png' file with GIMP and use the
-`Image > Mode > Indexed' to reduce image colors up to 16 colors,
-using the `Generate optimum palette' feature of GIMP.  If the
-image looks aceptable after reducing colors, use the `Palettes'
-menu (Ctrl+P) of GIMP to import a new palette from file and name it
-`CentOS-TreeFlower-Syslinux'. Once you've saved the palette, the
-color information is stored at:
-
    
-
    ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
-
    
-
    You need to edit `CentOS-TreeFlower-Syslinux.gpl' file in order
-to set the appropriate order of colors.  Remember black (000000) in
-position 0, and white (ffffff) in position 7. Other positions are
-irrelevant. When editing this file you may find that color reduction
-did not set black and white colors to their respective values exactly.
-Change that manually. For example, consider the following palette:
-
    
-
    GIMP Palette
-Name: CentOS-TreeFlower-Syslinux
-Columns: 16
-#
-  0   0   0	Background (black)
- 23  20  35	Untitled
- 34  25  48	Untitled
- 37  35  60	Untitled
- 47  36  68	Untitled
- 37  54  86	Untitled
- 60  48  90	Untitled
-255 255 255	Foreground (white)
- 66  54  99	Untitled
- 74  61  98	Untitled
- 49  78 126	Untitled
- 43  87 151	Untitled
- 92  89  95	Untitled
- 54 104 183	Untitled
-158 153 156	Untitled
-201 196 195	Untitled
-
    
-
    Update the `Palettes' menu to get the new color positions from
-the file you just edited and open the palette with double click. 
-
    
-
    Update the `syslinux.gpl' file copying the following file:
-
    
-
    ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
-
    
-
    to
-
    
-
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl
-
    
-
    With the `CentOS-TreeFlower-Syslinux' palette opened in the
-`Palette Editor', open (Ctrl+O) the following file:
-
    
-
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm
-
    
-
    and replace its color information with that one in
-`CentOS-TreeFlower-Syslinux' palette.  When you are replacing
-color information inside `syslilnux.ppm', remember to keep the
-order of colors just as they are in the
-`CentOS-TreeFlower-Palette' palette.  
-
    
-
    The `syslinux.ppm' file is 16 pixels width and 1 pixel height, so
-you probably need to zoom it a bit to set the color information in
-their place when using the pen tool with the brush `Circle (01)
-(1 x 1)'.
-
    
-
    Once you've updated the `syslinux.ppm' file, it is time to update
-the following file:
-
    
-
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex
-
    
-
    The `syslinux.hex' file contains the color information in
-hexadecimal notation.  The color information in hexadecimal notation
-is required by ppmtolss16 command.  The ppmtolss16
-command produces the final LSS16 image format that is used by syslinux
-program inside CentOS distribution.
-
    
-
    The color information inside `syslinux.hex' must match the one in
-`syslinux.ppm' and `syslinux.gpl'. For example, based on
-`CentOS-TreeFlower-Syslinux' palette of colors above, consider
-the following `syslinux.hex' file:
-
    
-
    #000000=0
-#171423=1
-#221930=2
-#25233c=3
-#2f2444=4
-#253656=5
-#3c305a=6
-#ffffff=7
-#423663=8
-#4a3d62=9
-#314e7e=10
-#2b5797=11
-#5c595f=12
-#3668b7=13
-#9e999c=14
-#c9c4c3=15
-
    
-
-
-
     2.46.2.3 Grub background 
    
-
-
-
-
     2.46.3 Usage 
    
+
+
     2.43.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.46.4 See also 
    
+
+
     2.43.2 Description 
    
+
+
+
+
     2.43.3 Usage 
    
+
+
    To render Anaconda progress slide images using the Modern
+artistic motif design, the Default theme model, and available
+translation files (-- Removed(pxref:trunk Translations Identity Themes Distro
+Anaconda Progress) --); use the following commands:
+
    
+
     
    cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
+centos-art render --identity
+
    
+
    The above command will create the following structure:
+
    
+
     
    trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
+|-- 3
+|   |-- en
+|   |   |-- 01-welcome.png
+|   |   |-- 02-donate.png
+|   |   `-- 03-yum.png
+|   `-- es
+|       |-- 01-welcome.png
+|       |-- 02-donate.png
+|       `-- 03-yum.png
+|-- 4
+|   |-- en
+|   |   |-- 01-welcome.png
+|   |   |-- 02-donate.png
+|   |   `-- 03-yum.png
+|   `-- es
+|       |-- 01-welcome.png
+|       |-- 02-donate.png
+|       `-- 03-yum.png
+`-- 5
+    |-- en
+    |   |-- 01-welcome.png
+    |   |-- 02-donate.png
+    |   `-- 03-yum.png
+    `-- es
+        |-- 01-welcome.png
+        |-- 02-donate.png
+        `-- 03-yum.png
+
    
+
+
+
+
     2.43.4 See also 
    
+
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_51.html b/Manual/repository-html/repository_51.html
index fa30db8..a6822ab 100644
--- a/Manual/repository-html/repository_51.html
+++ b/Manual/repository-html/repository_51.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.47 The trunk/Identity/Widgets Directory
+CentOS Artwork Repository: 2.44 The trunk/Identity/Themes/Motifs/Modern/Palettes Directory
 
-
-
+
+
 
 
 
@@ -55,58 +55,64 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.47 The `trunk/Identity/Widgets' Directory 
    
+
+
+
     2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory 
    
 
 
-
-
     2.47.1 Goals 
    
+
+
     2.44.1 Goals 
    
 
 
      
-
    •  ...
+
    •  Organize palette files for Modern theme.
 
    
 
 
-
-
     2.47.2 Description 
    
+
+
     2.44.2 Description 
    
 
 
-
-
     2.47.3 Usage 
    
+
+
     2.44.3 Usage 
    
 
+
    Here is where graphic designers define theme palettes for
+color-limited art works. Theme palettes contain the color information
+that rendering functions need, in order to produce images with color
+limitations.  Theme palettes contain the unique color information
+required by theme.
+
    
 
-
-
     2.47.4 See also 
    
+
+
     2.44.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_52.html b/Manual/repository-html/repository_52.html
index 645f8d8..b348cc5 100644
--- a/Manual/repository-html/repository_52.html
+++ b/Manual/repository-html/repository_52.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.48 The trunk/Locales Directory
+CentOS Artwork Repository: 2.45 The trunk/Identity/Themes/Motifs/TreeFlower Directory
 
-
-
+
+
 
 
 
@@ -55,95 +55,58 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.48 The `trunk/Locales' Directory 
    
+
+
+
     2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory 
    
 
-
    The `trunk/Locales' directory exists to store the translation
-messages used to produce content in different languages.
-
    
-
    Translation messages are organized using the directory structure of
-the component being translated. For example, if we want to provide
-translation messages for `trunk/Manuals/Filesystem', then the
-`trunk/Locales/Manuals/Filesystem' directory needs to be created.
-
    
-
    Once the locale directory exists for the component we want to provide
-translation messages for, it is necessary to create the translation
-files where translation messages are. The translation files follows
-the concepts of xml2po and GNU gettext tools.
-
    
-
    The basic translation process is as follow: first, translatable
-strings are extracted from files and a portable object template (.pot)
-is created or updated with the information. Using the portable object
-template, a portable object (.po) is created or updated for translator
-to locale the messages retrived.  Finally, a machine object (.mo) is
-created from portable object to sotore the translated messages.
-
    
-
    Inside the repository there are two ways to retrive translatable
-strings from files. The first one is through xml2po command
-and the second through xgettext command. The xml2po
-is used to retrive translatable strings from XML files (e.g., Scalable
-Vector Graphics, DocBook, etc.) and the xgettext command is
-used to retrive translatable strings from shell scripts files (e.g.,
-the files that make the centos-art.sh command-line
-interface).
-
    
-
    When translatable strings are retrived from XML files, using the
-xml2po command, there is no need to create the machine
-object as we do when translatable strings ar retrived from shell
-files, using the xgettext command. The xml2po
-produces a temporal machine object in order to create a translated XML
-file. Once the translated XML file has been created the machine object
-is no longer needed. On the other hand, the machine object produced by
-the xgettext command is required by the system in order for
-the show shell script localized messages.
-
    
-
    Another difference between xml2po and xgettext we
-need to be aware of is the directory structure used to store machine
-objects. In xml2po, the machine object is created in the
-current working directory as `.xml2po.mo' and can be safetly
-removed once the translated XML file has been created. In the case of
-xgettext, the machine object needs to be stored in the
-`$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo' file in order
-for the system to interpret it and should not be removed since it is
-the file that contain the translation messages themselves.
-
    
-
    Automation of localization tasks is achived through the locale
-functionality of command-line interface.
-
    
-
-
-
    2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory  
-
    
+
+
+
     2.45.1 Goals 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.45.2 Description 
    
+
+
+
+
     2.45.3 Usage 
    
+
+
+
+
     2.45.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_53.html b/Manual/repository-html/repository_53.html
index 635d1eb..a46a014 100644
--- a/Manual/repository-html/repository_53.html
+++ b/Manual/repository-html/repository_53.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.49 The trunk/Locales/Identity Directory
+CentOS Artwork Repository: 2.46 The trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds Directory
 
-
-
+
+
 
 
 
@@ -55,70 +55,370 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.49 The `trunk/Locales/Identity' Directory 
    
+
+
+
     2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory 
    
 
 
-
-
     2.49.1 Goals 
    
+
+
     2.46.1 Goals 
    
 
-
      
-
    •  ...
-
    
+
    This section exists to orgnize backgrounds of TreeFlower
+artistic motif.
+
    
 
+
+
     2.46.2 Description 
    
 
-
-
     2.49.2 Description 
    
 
-
      
-
    •  ...
-
    
+
+
     2.46.2.1 Desktop background 
    
+
+
    Once you have defined the vectorial artistic motif design, use the
+centos-art.sh script (as described in usage section below)
+to produce the png version of it. With the png version of your
+vectorial design do the following:
+
    
+
    Open the png version with GIMP.
+
    
+
    Save the png version as a project of GIMP inside
+`trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf'
+directory, using the same name of your vectorial design but with the
+`.xcf' extension.  
+
    
+
    Now use GIMP to improve your design.  Here you may add one layer for
+pattern, another for colors, and so on until you find yourself
+confortable with your artwork. For example,  the following layer
+distribution (from bottom to top) was used to build revision 285 of
+file `1360x768.xcf' using TreeFlower artistic motif at
+revision 241.
+
    
+
    
+
     Layer 1: Background 
    
+
    
+
    The first thing we did with GIMP was to create a layer named
+`Background' to store the artistic motif (File > Open as layer).
+This layer is the lowest layer in the image.  Later, we started to
+create layers one upon another to change the artistic motif visual
+style.
+
    
+
    
+
     Layer 2: Shadow#1
    
+
    
+
    This layer is above `Background' and contains a linear gradient
+from left (000000) to right (transparent) covering the whole image.
+This layer masks the artistic motif to avoid the effect of linear
+gradient. This layer is 100% of opacity.
+
    
+
    
+
     Layer 3: Shadow#2
    
+
    
+
    This layer is above `Shadow#1' and contains a linear gradient
+from left (000000) to right (transparent) covering just the 70% of the
+whole image aproximatly. This layer doesn't mask the artistic motif
+which make the left part of it fall into the dark of linear gradient.
+This layer is 100% of opacity.
+
    
+
    
+
     Layer 4: Pattern (Paper)
    
+
    
+
    This layer is above `Shadow#2' an contains the paper pattern
+shipped with GIMP 2.2. This layer doesn't mask the artistic motif so
+the pattern is applied over the whole image. This layer is set to 15%
+of opacity.
+
    
+
    
+
     Layer 5: Pattern (Stripes)
    
+
    
+
    This layer is above `Pattern (Paper)' and contains the stripes
+used over the artistic motif. This layer do masks the artistic motif
+so the stripes are only applied to it. This layer is set to 10% of
+opacity.
+
    
+
    
+
     Layer 6: Shadow#3
    
+
    
+
    This layer is above `Pattern (Stripes)' and contains a linear
+gradient from right (6600ff) to left (transparent).  This layer masks
+the artistic motif so the linear gradient doesn't affect it. This
+layer is set to 15% of opacity.
+
    
+
    
+
     Layer 7: Shadow#4
    
+
    
+
    This layer is above `Shadow#3' and contains a
+linear gradient from left (000000) to right (transparent). This layer
+do masks the artistic motif so the linear gradient doesn't affect it.
+This layer is set to 10% of opacity.
+
    
+
    
+
     Layer 8: Color#1
    
+
    
+
    This layer is above `Shadow#4' and is filled with orange (ffae00)
+color over the whole image. This layer is set to 10% of opacity.
+
    
+
    
+
     Layer 9: Color#2
    
+
    
+
    This layer is above `Color#1' and is filled with
+blue (010a88) color over the whole image. This layer is set to 10% of
+opacity.
+
    
+
    
+
    
+
+
    info
    Note
     There is no definite combination. To get the appropriate
+visual design is a matter of constant testing and personal taste.
+
    
+
+
    Finally, use `Save as copy ...' option to export the final
+design. To export the final design use the same name of your vectorial
+design plus `-final.png' extension. 
+
    
+
    You can repeat these steps to create images for other screen
+resolutions.
+
    
+
+
+
     2.46.2.2 Anaconda Prompt (syslinux) background 
    
+
+
    When building syslinux backgrounds it is needed to take into account
+that the final image is reduced to 16 colors. In desktop background
+there is no color limitation but syslinux does have. The goal of this
+section is achieving a final syslinux background as close as possible
+to desktop backgrounds using 16 colors only.
+
    
+
    Another point to consider is the forground and background definition
+used by syslinux. The syslinux documentation says that the color set
+in position 0 is the background and color set in position 7 is the
+forground. The final palette of color used by our background will
+match that specification. For great contrast we'll use black as
+background and white as forground. At this poing we have black
+(000000) and white (ffffff) colors in our syslinux palette, which left
+us with 14 colors to play with. 
+
    
+
    Let's begin with `Xcf/640x300.xcf' layer distribution from bottom
+to top:
+
    
+
    
+
     Layer 1: Background
    
+
    
+
    This layer is the lowest layer in the image composition and contains
+the artistic motif image rendered for the same resolution (i.e.,
+`Img/Png/640x300.png'). This layer is set to 100% of opacity.
+
    
+
    
+
     Layer 2: Pattern (Paper)
    
+
    
+
    This layer is placed above `Background' layer and contains the
+paper pattern shipped with GIMP 2.2. This layer doesn't mask the
+artistic motif. This layer is set to 30% of opacity.
+
    
+
    
+
     Layer 3: Pattern (Stripes)
    
+
    
+
    This layer is placed above `Pattern (Paper)' layer and contains
+the stripes pattern shipped with GIMP 2.2. This layer does mask the
+artistic motif in order to apply the stripes over it only. The
+background is not affected by the stripes pattern just the artistic
+motif. This layer is set to 20% of opacity.
+
    
+
    
+
     Layer 4: Shadow#1
    
+
    
+
    This layer is placed above `Pattern (Stripes)' layer and fills
+the entire layer area with violet (6600ff) color. This layer do mask
+the artistic motif in order to applied the violet color to the
+background area outside the artistic motif only. This layer is set to
+15% of opacity.
+
    
+
    
+
     Layer 5: Color#1
    
+
    
+
    This layer is above `Shadow#1' and is filled with orange (ffae00)
+color to cover the whole image. This layer is set to 10% of opacity.
+
    
+
    
+
     Layer 6: Color#2
    
+
    
+
    This layer is above `Color#1' and is filled with blue (010a88)
+color to cover the whole image. This layer is set to 10% of opacity.
+
    
+
    
+
     Layer 7: Shadow#2
    
+
    
+
    This layer is above `Color#1' and contains a linear gradient from
+left (000000) to right (transparent) covering 70% of the image
+approximately. 
+
    
+
    
+
    
 
+
    At this point we have the composition and should look like the desktop
+backgrounds. Compared with desktop backgrounds there are some
+differences in opacity. This is because in our testings the final
+color information found with this composition produces an acceptable
+16 color image. Of course this is something we haven't seen yet.
+
    
+
    To define the color information of our current coposition, save the
+syslinux background composition we've done using `File > Save as
+Copy ...' option in the following location:
+
    
+
    trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png
+
    
+
    Now, create the final png version of syslinux backgrounds using the
+following command:
+
    
+
    centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt
+
    
+
    This command will create syslinux-splash final images for all major
+releases of CentOS distribution the repository has been configured to.
+The important files here are `syslinux-splash.png', other
+files may contain the wrong information because we haven't defined yet
+the correct color information to use.
+
    
+
    Open one `syslinux-splash.png' file with GIMP and use the
+`Image > Mode > Indexed' to reduce image colors up to 16 colors,
+using the `Generate optimum palette' feature of GIMP.  If the
+image looks aceptable after reducing colors, use the `Palettes'
+menu (Ctrl+P) of GIMP to import a new palette from file and name it
+`CentOS-TreeFlower-Syslinux'. Once you've saved the palette, the
+color information is stored at:
+
    
+
    ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
+
    
+
    You need to edit `CentOS-TreeFlower-Syslinux.gpl' file in order
+to set the appropriate order of colors.  Remember black (000000) in
+position 0, and white (ffffff) in position 7. Other positions are
+irrelevant. When editing this file you may find that color reduction
+did not set black and white colors to their respective values exactly.
+Change that manually. For example, consider the following palette:
+
    
+
    GIMP Palette
+Name: CentOS-TreeFlower-Syslinux
+Columns: 16
+#
+  0   0   0	Background (black)
+ 23  20  35	Untitled
+ 34  25  48	Untitled
+ 37  35  60	Untitled
+ 47  36  68	Untitled
+ 37  54  86	Untitled
+ 60  48  90	Untitled
+255 255 255	Foreground (white)
+ 66  54  99	Untitled
+ 74  61  98	Untitled
+ 49  78 126	Untitled
+ 43  87 151	Untitled
+ 92  89  95	Untitled
+ 54 104 183	Untitled
+158 153 156	Untitled
+201 196 195	Untitled
+
    
+
    Update the `Palettes' menu to get the new color positions from
+the file you just edited and open the palette with double click. 
+
    
+
    Update the `syslinux.gpl' file copying the following file:
+
    
+
    ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl
+
    
+
    to
+
    
+
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl
+
    
+
    With the `CentOS-TreeFlower-Syslinux' palette opened in the
+`Palette Editor', open (Ctrl+O) the following file:
+
    
+
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm
+
    
+
    and replace its color information with that one in
+`CentOS-TreeFlower-Syslinux' palette.  When you are replacing
+color information inside `syslilnux.ppm', remember to keep the
+order of colors just as they are in the
+`CentOS-TreeFlower-Palette' palette.  
+
    
+
    The `syslinux.ppm' file is 16 pixels width and 1 pixel height, so
+you probably need to zoom it a bit to set the color information in
+their place when using the pen tool with the brush `Circle (01)
+(1 x 1)'.
+
    
+
    Once you've updated the `syslinux.ppm' file, it is time to update
+the following file:
+
    
+
    trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex
+
    
+
    The `syslinux.hex' file contains the color information in
+hexadecimal notation.  The color information in hexadecimal notation
+is required by ppmtolss16 command.  The ppmtolss16
+command produces the final LSS16 image format that is used by syslinux
+program inside CentOS distribution.
+
    
+
    The color information inside `syslinux.hex' must match the one in
+`syslinux.ppm' and `syslinux.gpl'. For example, based on
+`CentOS-TreeFlower-Syslinux' palette of colors above, consider
+the following `syslinux.hex' file:
+
    
+
    #000000=0
+#171423=1
+#221930=2
+#25233c=3
+#2f2444=4
+#253656=5
+#3c305a=6
+#ffffff=7
+#423663=8
+#4a3d62=9
+#314e7e=10
+#2b5797=11
+#5c595f=12
+#3668b7=13
+#9e999c=14
+#c9c4c3=15
+
    
+
+
+
     2.46.2.3 Grub background 
    
 
-
-
     2.49.3 Usage 
    
+
+
+
     2.46.3 Usage 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.49.4 See also 
    
+
+
     2.46.4 See also 
    
 
-
-
-
    2.4 The `trunk/Identity' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_54.html b/Manual/repository-html/repository_54.html
index 377be32..cb0c59f 100644
--- a/Manual/repository-html/repository_54.html
+++ b/Manual/repository-html/repository_54.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.50 The trunk/Locales/Identity/Brands Directory
+CentOS Artwork Repository: 2.47 The trunk/Identity/Widgets Directory
 
-
-
+
+
 
 
 
@@ -55,150 +55,58 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.50 The `trunk/Locales/Identity/Brands' Directory 
    
+
+
+
     2.47 The `trunk/Identity/Widgets' Directory 
    
 
 
-
-
     2.50.1 Goals 
    
+
+
     2.47.1 Goals 
    
 
 
      
-
    •  Organize brands' translation files.
+
    •  ...
 
    
 
 
-
-
     2.50.2 Description 
    
-
-
    Translation files, inside `trunk/Translations/Identity/Brands'
-translation entry, don't use default rendering translation
-functionality, they use the following translation pre-rendering
-configuration file instead:
-
    
-
    /home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh
-
    
-
    Inside `trunk/Translations/Identity/Brands' translation entry,
-translation files are symbolic links pointing to the common template
-translation structure, inside the translation template (`Tpl/')
-directory.
-
    
-
    Inside `trunk/Translations/Identity/Brands' translation entry,
-translation files are created using identity design templates as
-reference.  The translation pre-rendering script creates a translation
-structure where the translation template (`Tpl/') directory
-structure applies to each single design template available.
-
    
-
    For example, if the brands' translation template (`Tpl/')
-directory has 30 translation files, and there are 20 design templates;
-the brands' translation pre-rendering script creates a translation
-structure of symbolic links where the 30 translation files apply the
-20 design templates one by one, producing 600 translation symbolic
-links as result. At this point, when rendering identity, the
-centos-art script considers translation symbolic links as
-translation files.
-
    
-
    Translation file names, inside brands' translation template
-(`Tpl') directory have special meaning:
-
    
-
-
-
     2.50.2.1 Conventional file names 
    
-
-
    Convenctional file names look like `blue.sed', `2c-a.sed',
-etc.  Replacement commands inside translation file are applied to
-design templates and translation file names are used as final image
-name.  The image dimensions use the same dimensions that design
-template has.
-
    
+
+
     2.47.2 Description 
    
 
-
-
     2.50.2.2 Numeric file names 
    
-
-
    Numeric file names look like `300.sed', `200.sed', etc.
-Replacements commands inside translation files are applied to design
-templates, and translation file names are used as final image name.
-The final image is saved using an specific `width' defined by the
-number part of the translation file name. The image `height' is
-automatically scaled based on the previous `width' definition to
-maintain the designing ratio.  
-
    
-
    For example, if your design template has 400x200 pixels of dimension,
-and you apply a translation file named `300.sed' to it, the final
-image you get as result will have 300x100 pixels of dimension.   The
-same is true if you use higher numbers like `1024.sed', `2048.sed',
-etc. In these cases you have bigger images proportionally.
-
    
-
    As we are using scalable vector graphics to design identity templates,
-the image size you produce is not limitted in size. You can use one
-design template produced in 400x200 pixels to produce larger or
-shorter PNG images using numeric translation files as described
-above.
-
    
-
-
-
     2.50.2.3 Translation markers 
    
-
-
    Inside `trunk/Translations/Identity/Brands/', translation files
-combine the following translation markers:
-
    
-
    
-
     `#000000'
    
-
    
-
    Specify which color to use when rendering brand images.
-
    
-
    info
    Note
     As translation files inside
-`trunk/Translations/Identity/Brands' are symbolic links that
-point to template translation files, translation markers are defined
-inside template translation files.
-
    
-
    
-
    
 
+
+
     2.47.3 Usage 
    
 
-
-
     2.50.3 Usage 
    
 
-
    To render brands' translation files, use the following command:
-
    
-
    centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
-
    
-
-
-
     2.50.4 See also 
    
+
+
     2.47.4 See also 
    
 
-
-
-
    2.5 The `trunk/Identity/Brands' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_55.html b/Manual/repository-html/repository_55.html
index b330410..1d1894e 100644
--- a/Manual/repository-html/repository_55.html
+++ b/Manual/repository-html/repository_55.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.51 The trunk/Locales/Identity/Brands/Tpl Directory
+CentOS Artwork Repository: 2.48 The trunk/Locales Directory
 
-
-
+
+
 
 
 
@@ -55,54 +55,95 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory 
    
+
+
+
     2.48 The `trunk/Locales' Directory 
    
 
-
-
-
     2.51.1 Goals 
    
-
-
-
-
     2.51.2 Description 
    
-
-
-
-
     2.51.3 Usage 
    
-
-
-
-
     2.51.4 See also 
    
+
    The `trunk/Locales' directory exists to store the translation
+messages used to produce content in different languages.
+
    
+
    Translation messages are organized using the directory structure of
+the component being translated. For example, if we want to provide
+translation messages for `trunk/Manuals/Filesystem', then the
+`trunk/Locales/Manuals/Filesystem' directory needs to be created.
+
    
+
    Once the locale directory exists for the component we want to provide
+translation messages for, it is necessary to create the translation
+files where translation messages are. The translation files follows
+the concepts of xml2po and GNU gettext tools.
+
    
+
    The basic translation process is as follow: first, translatable
+strings are extracted from files and a portable object template (.pot)
+is created or updated with the information. Using the portable object
+template, a portable object (.po) is created or updated for translator
+to locale the messages retrived.  Finally, a machine object (.mo) is
+created from portable object to sotore the translated messages.
+
    
+
    Inside the repository there are two ways to retrive translatable
+strings from files. The first one is through xml2po command
+and the second through xgettext command. The xml2po
+is used to retrive translatable strings from XML files (e.g., Scalable
+Vector Graphics, DocBook, etc.) and the xgettext command is
+used to retrive translatable strings from shell scripts files (e.g.,
+the files that make the centos-art.sh command-line
+interface).
+
    
+
    When translatable strings are retrived from XML files, using the
+xml2po command, there is no need to create the machine
+object as we do when translatable strings ar retrived from shell
+files, using the xgettext command. The xml2po
+produces a temporal machine object in order to create a translated XML
+file. Once the translated XML file has been created the machine object
+is no longer needed. On the other hand, the machine object produced by
+the xgettext command is required by the system in order for
+the show shell script localized messages.
+
    
+
    Another difference between xml2po and xgettext we
+need to be aware of is the directory structure used to store machine
+objects. In xml2po, the machine object is created in the
+current working directory as `.xml2po.mo' and can be safetly
+removed once the translated XML file has been created. In the case of
+xgettext, the machine object needs to be stored in the
+`$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo' file in order
+for the system to interpret it and should not be removed since it is
+the file that contain the translation messages themselves.
+
    
+
    Automation of localization tasks is achived through the locale
+functionality of command-line interface.
+
    
+
+
+
    2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory  
+
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_56.html b/Manual/repository-html/repository_56.html
index e60edf7..ca5e2c6 100644
--- a/Manual/repository-html/repository_56.html
+++ b/Manual/repository-html/repository_56.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.52 The trunk/Locales/Identity/Fonts Directory
+CentOS Artwork Repository: 2.49 The trunk/Locales/Identity Directory
 
-
-
+
+
 
 
 
@@ -55,108 +55,70 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.52 The `trunk/Locales/Identity/Fonts' Directory 
    
+
+
+
     2.49 The `trunk/Locales/Identity' Directory 
    
 
 
-
-
     2.52.1 Goals 
    
+
+
     2.49.1 Goals 
    
 
-
    This section exists to organize fonts translation files.
-
    
-
-
     2.52.2 Description 
    
+
      
+
    •  ...
+
    
 
-
    Translation files, inside `trunk/Translations/Fonts', have the
-following structure:
-
    
-
    s!font-family:Denmark!font-family:DejaVu LGC Sans!
-s!font-weight:normal!font-weight:bold!
-s!font-style:normal!font-style:italic!
-
    
-
    Inside `trunk/Translations/Fonts', there is one translation file
-for each font preview image you want to produce. This way, we create
-one translation file for each font-family we use somewhere inside
-CentOS visual identity.
-
    
-
    Important
    Important
     Do not create translation files for
-font-families not used somewhere inside CentOS visual identity. The
-identity of font entry (see section The `trunk/Identity/Fonts' Directory) is used as
-reference when someone needs to know which font-families are allowed
-to use inside CentOS visual identity.
-
    
 
+
+
     2.49.2 Description 
    
 
-
-
     2.52.2.1 Translation Markers 
    
+
      
+
    •  ...
+
    
 
-
    Inside `trunk/Translations/Identity/Fonts', translation files
-combine the following translation markers:
-
    
-
    
-
     `font-family:Denmark'
    
-
    Specify which font family to use when rendering font preview images.
-
    
-
     `font-weight:normal'
    
-
    Specify which font weight to use when rendering font preview images.
-
    
-
     `font-style:normal'
    
-
    Specify which font style to use when rendering font preview images.
-
    
-
    
-
-
-
-
     2.52.3 Usage 
    
-
-
    Inside `trunk/Translations/Fonts' you use your favorite text
-editor to create translation files.  Inside
-`trunk/Translations/Fonts' there is not translation template
-directory (`Tpl/'), nor translation rendering using
-centos-art script.  For example, to create the
-`dejavu_lgc_sans-boldoblique.sed' translation file using
-vim editor, type the following command:
-
    
-
    vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
-
    
 
-
-
     2.52.4 See also 
    
+
+
     2.49.3 Usage 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.49.4 See also 
    
 
 
-
    2.7 The `trunk/Identity/Fonts' Directory  
+
    2.4 The `trunk/Identity' Directory  
 
    
 
    
 
 
-
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_57.html b/Manual/repository-html/repository_57.html
index b62208a..032665d 100644
--- a/Manual/repository-html/repository_57.html
+++ b/Manual/repository-html/repository_57.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.53 The trunk/Locales/Identity/Models Directory
+CentOS Artwork Repository: 2.50 The trunk/Locales/Identity/Brands Directory
 
-
-
+
+
 
 
 
@@ -55,54 +55,150 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.53 The `trunk/Locales/Identity/Models' Directory 
    
+
+
+
     2.50 The `trunk/Locales/Identity/Brands' Directory 
    
 
 
-
-
     2.53.1 Goals 
    
+
+
     2.50.1 Goals 
    
 
+
      
+
    •  Organize brands' translation files.
+
    
 
-
-
     2.53.2 Description 
    
 
+
+
     2.50.2 Description 
    
+
+
    Translation files, inside `trunk/Translations/Identity/Brands'
+translation entry, don't use default rendering translation
+functionality, they use the following translation pre-rendering
+configuration file instead:
+
    
+
    /home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh
+
    
+
    Inside `trunk/Translations/Identity/Brands' translation entry,
+translation files are symbolic links pointing to the common template
+translation structure, inside the translation template (`Tpl/')
+directory.
+
    
+
    Inside `trunk/Translations/Identity/Brands' translation entry,
+translation files are created using identity design templates as
+reference.  The translation pre-rendering script creates a translation
+structure where the translation template (`Tpl/') directory
+structure applies to each single design template available.
+
    
+
    For example, if the brands' translation template (`Tpl/')
+directory has 30 translation files, and there are 20 design templates;
+the brands' translation pre-rendering script creates a translation
+structure of symbolic links where the 30 translation files apply the
+20 design templates one by one, producing 600 translation symbolic
+links as result. At this point, when rendering identity, the
+centos-art script considers translation symbolic links as
+translation files.
+
    
+
    Translation file names, inside brands' translation template
+(`Tpl') directory have special meaning:
+
    
+
+
+
     2.50.2.1 Conventional file names 
    
+
+
    Convenctional file names look like `blue.sed', `2c-a.sed',
+etc.  Replacement commands inside translation file are applied to
+design templates and translation file names are used as final image
+name.  The image dimensions use the same dimensions that design
+template has.
+
    
+
+
+
     2.50.2.2 Numeric file names 
    
+
+
    Numeric file names look like `300.sed', `200.sed', etc.
+Replacements commands inside translation files are applied to design
+templates, and translation file names are used as final image name.
+The final image is saved using an specific `width' defined by the
+number part of the translation file name. The image `height' is
+automatically scaled based on the previous `width' definition to
+maintain the designing ratio.  
+
    
+
    For example, if your design template has 400x200 pixels of dimension,
+and you apply a translation file named `300.sed' to it, the final
+image you get as result will have 300x100 pixels of dimension.   The
+same is true if you use higher numbers like `1024.sed', `2048.sed',
+etc. In these cases you have bigger images proportionally.
+
    
+
    As we are using scalable vector graphics to design identity templates,
+the image size you produce is not limitted in size. You can use one
+design template produced in 400x200 pixels to produce larger or
+shorter PNG images using numeric translation files as described
+above.
+
    
+
+
+
     2.50.2.3 Translation markers 
    
+
+
    Inside `trunk/Translations/Identity/Brands/', translation files
+combine the following translation markers:
+
    
+
    
+
     `#000000'
    
+
    
+
    Specify which color to use when rendering brand images.
+
    
+
    info
    Note
     As translation files inside
+`trunk/Translations/Identity/Brands' are symbolic links that
+point to template translation files, translation markers are defined
+inside template translation files.
+
    
+
    
+
    
 
-
-
     2.53.3 Usage 
    
 
+
+
     2.50.3 Usage 
    
+
+
    To render brands' translation files, use the following command:
+
    
+
    centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
+
    
 
-
-
     2.53.4 See also 
    
+
+
     2.50.4 See also 
    
 
+
+
+
    2.5 The `trunk/Identity/Brands' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_58.html b/Manual/repository-html/repository_58.html
index 01bb1d9..5c07162 100644
--- a/Manual/repository-html/repository_58.html
+++ b/Manual/repository-html/repository_58.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.54 The trunk/Locales/Identity/Release Directory
+CentOS Artwork Repository: 2.51 The trunk/Locales/Identity/Brands/Tpl Directory
 
-
-
+
+
 
 
 
@@ -55,54 +55,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.54 The `trunk/Locales/Identity/Release' Directory 
    
+
+
+
     2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory 
    
 
 
-
-
     2.54.1 Goals 
    
+
+
     2.51.1 Goals 
    
 
 
-
-
     2.54.2 Description 
    
+
+
     2.51.2 Description 
    
 
 
-
-
     2.54.3 Usage 
    
+
+
     2.51.3 Usage 
    
 
 
-
-
     2.54.4 See also 
    
+
+
     2.51.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_59.html b/Manual/repository-html/repository_59.html
index 7aec707..0743983 100644
--- a/Manual/repository-html/repository_59.html
+++ b/Manual/repository-html/repository_59.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.55 The trunk/Locales/Identity/Themes Directory
+CentOS Artwork Repository: 2.52 The trunk/Locales/Identity/Fonts Directory
 
-
-
+
+
 
 
 
@@ -55,54 +55,108 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.55 The `trunk/Locales/Identity/Themes' Directory 
    
+
+
+
     2.52 The `trunk/Locales/Identity/Fonts' Directory 
    
 
 
-
-
     2.55.1 Goals 
    
+
+
     2.52.1 Goals 
    
 
+
    This section exists to organize fonts translation files.
+
    
+
+
     2.52.2 Description 
    
+
+
    Translation files, inside `trunk/Translations/Fonts', have the
+following structure:
+
    
+
    s!font-family:Denmark!font-family:DejaVu LGC Sans!
+s!font-weight:normal!font-weight:bold!
+s!font-style:normal!font-style:italic!
+
    
+
    Inside `trunk/Translations/Fonts', there is one translation file
+for each font preview image you want to produce. This way, we create
+one translation file for each font-family we use somewhere inside
+CentOS visual identity.
+
    
+
    Important
    Important
     Do not create translation files for
+font-families not used somewhere inside CentOS visual identity. The
+identity of font entry (see section The `trunk/Identity/Fonts' Directory) is used as
+reference when someone needs to know which font-families are allowed
+to use inside CentOS visual identity.
+
    
 
-
-
     2.55.2 Description 
    
 
+
+
     2.52.2.1 Translation Markers 
    
 
-
-
     2.55.3 Usage 
    
+
    Inside `trunk/Translations/Identity/Fonts', translation files
+combine the following translation markers:
+
    
+
    
+
     `font-family:Denmark'
    
+
    Specify which font family to use when rendering font preview images.
+
    
+
     `font-weight:normal'
    
+
    Specify which font weight to use when rendering font preview images.
+
    
+
     `font-style:normal'
    
+
    Specify which font style to use when rendering font preview images.
+
    
+
    
+
+
+
+
     2.52.3 Usage 
    
+
+
    Inside `trunk/Translations/Fonts' you use your favorite text
+editor to create translation files.  Inside
+`trunk/Translations/Fonts' there is not translation template
+directory (`Tpl/'), nor translation rendering using
+centos-art script.  For example, to create the
+`dejavu_lgc_sans-boldoblique.sed' translation file using
+vim editor, type the following command:
+
    
+
    vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
+
    
 
+
+
     2.52.4 See also 
    
 
-
-
     2.55.4 See also 
    
+
+
+
    2.7 The `trunk/Identity/Fonts' Directory  
+
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_6.html b/Manual/repository-html/repository_6.html
index 1a88b3d..ce76424 100644
--- a/Manual/repository-html/repository_6.html
+++ b/Manual/repository-html/repository_6.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.2 The tags Directory
+CentOS Artwork Repository: 1.5 Send in Your Feedback
 
-
-
+
+
 
 
 
@@ -55,70 +55,47 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.2 The `tags' Directory 
    
-
-
+
 
-
     2.2.1 Goals 
    
-
-
    This directory implements the Subversion's tags concept in a trunk,
-branches, tags repository structure.
-
    
-
-
-
     2.2.2 Description 
    
+
     1.5 Send in Your Feedback 
    
 
-
    The `tags/' directory structre provides frozen branches.
-Generally, we use frozen branches to make check-points in time for
-development lines under `branches/' or `trunk/' directory
-structure.
+
    If you find an error in the CentOS Artwork Repository Manual,
+or if you have thought of a way to make this manual better, we would
+like to hear from you! Create a new ticket in The CentOS Artwork SIG
+web site (https://projects.centos.org/trac/artwork/).
 
    
-
-
-
     2.2.3 Usage 
    
-
-
    The `tags/' directory structure is unused, so far.
+
    If you have a suggestion for improving the documentation, try to be as
+specific as possible. If you have found an error, include the section
+number and some of the surrounding text so we can find it easily.
 
    
 
-
-
     2.2.4 See also 
    
-
-
-
-
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_60.html b/Manual/repository-html/repository_60.html
index e949ba9..7eb96bb 100644
--- a/Manual/repository-html/repository_60.html
+++ b/Manual/repository-html/repository_60.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.56 The trunk/Locales/Identity/Themes/Backgrounds Directory
+CentOS Artwork Repository: 2.53 The trunk/Locales/Identity/Models Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory 
    
+
+
+
     2.53 The `trunk/Locales/Identity/Models' Directory 
    
 
 
-
-
     2.56.1 Goals 
    
+
+
     2.53.1 Goals 
    
 
-
      
-
    •  ...
-
    
 
+
+
     2.53.2 Description 
    
 
-
-
     2.56.2 Description 
    
 
-
      
-
    •  ...
-
    
+
+
     2.53.3 Usage 
    
 
 
-
-
     2.56.3 Usage 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.56.4 See also 
    
+
+
     2.53.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_61.html b/Manual/repository-html/repository_61.html
index 8865555..9f8a040 100644
--- a/Manual/repository-html/repository_61.html
+++ b/Manual/repository-html/repository_61.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.57 The trunk/Locales/Identity/Themes/Distro/Anaconda/Progress Directory
+CentOS Artwork Repository: 2.54 The trunk/Locales/Identity/Release Directory
 
-
-
+
+
 
 
 
@@ -55,134 +55,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory 
    
+
+
+
     2.54 The `trunk/Locales/Identity/Release' Directory 
    
 
 
-
-
     2.57.1 Goals 
    
+
+
     2.54.1 Goals 
    
 
-
      
-
    •  Organize Anaconda progress translation templates.
-
    •  Organize Anaconda progress translation files in several
-languages and major releases of CentOS distribution.
-
    
 
+
+
     2.54.2 Description 
    
 
-
-
     2.57.2 Description 
    
-
-
    Use the following command to produce translation files based:
-
    
-
     
    trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
-`-- Tpl
-    |-- en
-    |   |-- 01-welcome.sed
-    |   |-- 02-donate.sed
-    |   `-- 03-yum.sed
-    `-- es
-        |-- 01-welcome.sed
-        |-- 02-donate.sed
-        `-- 03-yum.sed
-
    
-
    In order to produce the slide images in PNG format we need to have the
-translation files first. So we use the following commands to create
-translation files for CentOS 3, 4, and 5 major releases:
-
    
-
     
    centos-art render --translation --filter='3,4,5'
-
    
-
    The above commands will produce the following translation structure:
-
    
-
     
    trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
-|-- 3
-|   |-- en
-|   |   |-- 01-welcome.sed
-|   |   |-- 02-donate.sed
-|   |   `-- 03-yum.sed
-|   `-- es
-|       |-- 01-welcome.sed
-|       |-- 02-donate.sed
-|       `-- 03-yum.sed
-|-- 4
-|   |-- en
-|   |   |-- 01-welcome.sed
-|   |   |-- 02-donate.sed
-|   |   `-- 03-yum.sed
-|   `-- es
-|       |-- 01-welcome.sed
-|       |-- 02-donate.sed
-|       `-- 03-yum.sed
-|-- 5
-|   |-- en
-|   |   |-- 01-welcome.sed
-|   |   |-- 02-donate.sed
-|   |   `-- 03-yum.sed
-|   `-- es
-|       |-- 01-welcome.sed
-|       |-- 02-donate.sed
-|       `-- 03-yum.sed
-`-- Tpl
-    |-- en
-    |   |-- 01-welcome.sed
-    |   |-- 02-donate.sed
-    |   `-- 03-yum.sed
-    `-- es
-        |-- 01-welcome.sed
-        |-- 02-donate.sed
-        `-- 03-yum.sed
-
    
-
    At this point we have all the translation files we need to produce
-Anaconda progress welcome, donate and yum slides images; in English
-and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is,
-a sum of 18 images around. 
-
    
-
    Now, with translation files in place, let's move to
-`trunk/Identity' structure and render them. 
-
    
-
 
+
+
     2.54.3 Usage 
    
 
-
-
     2.57.3 Usage 
    
-
-
    Translation rendering is described in `trunk/Translations'
-documentation entry (-- Removed(pxref:trunk Translations) --).
-
    
 
+
+
     2.54.4 See also 
    
 
-
-
     2.57.4 See also 
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_62.html b/Manual/repository-html/repository_62.html
index 2bd321f..985aaaa 100644
--- a/Manual/repository-html/repository_62.html
+++ b/Manual/repository-html/repository_62.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.58 The trunk/Locales/Identity/Widgets Directory
+CentOS Artwork Repository: 2.55 The trunk/Locales/Identity/Themes Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.58 The `trunk/Locales/Identity/Widgets' Directory 
    
+
+
+
     2.55 The `trunk/Locales/Identity/Themes' Directory 
    
 
 
-
-
     2.58.1 Goals 
    
+
+
     2.55.1 Goals 
    
 
-
      
-
    •  ...
-
    
 
+
+
     2.55.2 Description 
    
 
-
-
     2.58.2 Description 
    
 
-
      
-
    •  ...
-
    
+
+
     2.55.3 Usage 
    
 
 
-
-
     2.58.3 Usage 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.58.4 See also 
    
+
+
     2.55.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_63.html b/Manual/repository-html/repository_63.html
index 454a01f..5113203 100644
--- a/Manual/repository-html/repository_63.html
+++ b/Manual/repository-html/repository_63.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.59 The trunk/Manual Directory
+CentOS Artwork Repository: 2.56 The trunk/Locales/Identity/Themes/Backgrounds Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.59 The `trunk/Manual' Directory 
    
+
+
+
     2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory 
    
 
 
-
-
     2.59.1 Goals 
    
+
+
     2.56.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.59.2 Description 
    
+
+
     2.56.2 Description 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.59.3 Usage 
    
+
+
     2.56.3 Usage 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.59.4 See also 
    
+
+
     2.56.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_64.html b/Manual/repository-html/repository_64.html
index 512ecd2..6856029 100644
--- a/Manual/repository-html/repository_64.html
+++ b/Manual/repository-html/repository_64.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.60 The trunk/Manuals Directory
+CentOS Artwork Repository: 2.57 The trunk/Locales/Identity/Themes/Distro/Anaconda/Progress Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,134 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.60 The `trunk/Manuals' Directory 
    
+
+
+
     2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory 
    
 
 
-
-
     2.60.1 Goals 
    
+
+
     2.57.1 Goals 
    
 
 
      
-
    •  ...
+
    •  Organize Anaconda progress translation templates.
+
    •  Organize Anaconda progress translation files in several
+languages and major releases of CentOS distribution.
 
    
 
 
-
-
     2.60.2 Description 
    
+
+
     2.57.2 Description 
    
 
+
    Use the following command to produce translation files based:
+
    
+
     
    trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+`-- Tpl
+    |-- en
+    |   |-- 01-welcome.sed
+    |   |-- 02-donate.sed
+    |   `-- 03-yum.sed
+    `-- es
+        |-- 01-welcome.sed
+        |-- 02-donate.sed
+        `-- 03-yum.sed
+
    
+
    In order to produce the slide images in PNG format we need to have the
+translation files first. So we use the following commands to create
+translation files for CentOS 3, 4, and 5 major releases:
+
    
+
     
    centos-art render --translation --filter='3,4,5'
+
    
+
    The above commands will produce the following translation structure:
+
    
+
     
    trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+|-- 3
+|   |-- en
+|   |   |-- 01-welcome.sed
+|   |   |-- 02-donate.sed
+|   |   `-- 03-yum.sed
+|   `-- es
+|       |-- 01-welcome.sed
+|       |-- 02-donate.sed
+|       `-- 03-yum.sed
+|-- 4
+|   |-- en
+|   |   |-- 01-welcome.sed
+|   |   |-- 02-donate.sed
+|   |   `-- 03-yum.sed
+|   `-- es
+|       |-- 01-welcome.sed
+|       |-- 02-donate.sed
+|       `-- 03-yum.sed
+|-- 5
+|   |-- en
+|   |   |-- 01-welcome.sed
+|   |   |-- 02-donate.sed
+|   |   `-- 03-yum.sed
+|   `-- es
+|       |-- 01-welcome.sed
+|       |-- 02-donate.sed
+|       `-- 03-yum.sed
+`-- Tpl
+    |-- en
+    |   |-- 01-welcome.sed
+    |   |-- 02-donate.sed
+    |   `-- 03-yum.sed
+    `-- es
+        |-- 01-welcome.sed
+        |-- 02-donate.sed
+        `-- 03-yum.sed
+
    
+
    At this point we have all the translation files we need to produce
+Anaconda progress welcome, donate and yum slides images; in English
+and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is,
+a sum of 18 images around. 
+
    
+
    Now, with translation files in place, let's move to
+`trunk/Identity' structure and render them. 
+
    
 
 
 
-
-
     2.60.3 Usage 
    
-
-
      
-
    •  ...
-
    
+
+
     2.57.3 Usage 
    
 
+
    Translation rendering is described in `trunk/Translations'
+documentation entry (-- Removed(pxref:trunk Translations) --).
+
    
 
-
-
     2.60.4 See also 
    
 
+
+
     2.57.4 See also 
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_65.html b/Manual/repository-html/repository_65.html
index 3b8311d..9c9b52d 100644
--- a/Manual/repository-html/repository_65.html
+++ b/Manual/repository-html/repository_65.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.61 The trunk/Scripts Directory
+CentOS Artwork Repository: 2.58 The trunk/Locales/Identity/Widgets Directory
 
-
-
+
+
 
 
 
@@ -55,69 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.61 The `trunk/Scripts' Directory 
    
+
+
+
     2.58 The `trunk/Locales/Identity/Widgets' Directory 
    
 
 
-
-
     2.61.1 Goals 
    
+
+
     2.58.1 Goals 
    
 
-
    The `trunk/Scripts' directory exists to:
-
    
 
      
-
    •  Organize the "trunk" development line of automation scripts by
-programming language.  
+
    •  ...
 
    
 
 
-
-
     2.61.2 Description 
    
+
+
     2.58.2 Description 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.61.3 Usage 
    
+
+
     2.58.3 Usage 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.61.4 See also 
    
+
+
     2.58.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_66.html b/Manual/repository-html/repository_66.html
index 2f614ad..624ab0a 100644
--- a/Manual/repository-html/repository_66.html
+++ b/Manual/repository-html/repository_66.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.62 The trunk/Scripts/Bash Directory
+CentOS Artwork Repository: 2.59 The trunk/Manual Directory
 
-
-
+
+
 
 
 
@@ -55,197 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.62 The `trunk/Scripts/Bash' Directory 
    
+
+
+
     2.59 The `trunk/Manual' Directory 
    
 
 
-
-
     2.62.1 Goals 
    
+
+
     2.59.1 Goals 
    
 
-
    The `trunk/Scripts/Bash' directory exists to organize the trunk
-development line of `centos-art.sh' automation script.  The
-`centos-art.sh' script standardizes frequent tasks inside your
-working copy of CentOS Artwork Repository.
-
    
+
      
+
    •  ...
+
    
 
-
-
     2.62.2 Description 
    
 
-
    The best way to understand `centos-art.sh' automation script is
-studying its source code.  However, as start point, you may prefer to
-read an introductory resume before diving into the source code
-details.
-
    
-
    The `centos-art.sh' script is written in Bash. Most tasks, inside
-`centos-art.sh' script, have been organized in many specific
-functionalities that you can invoke from the centos-art
-command-line interface.
-
    
-
    When you type the centos-art command in your terminal, the
-operating system trys to execute that command. In order to execute the
-command, the operating system needs to know where it is, so the
-operating system uses the PATH environment variable to look for
-that command location. If your system was prepared to use CentOS
-Artwork Repository correctly (-- Removed(pxref:trunk Scripts Bash Functions
-Verify) --), you should have a symbolic link inside `~/bin/'
-directory that points to the `centos-art.sh' script file. As
-`~/bin/' directory is, by default, inside PATH environment
-variable, the execution of centos-art command runs the
-`centos-art.sh' script.
-
    
-
    When `centos-art.sh' script is executed, the first it does is
-executing the `trunk/Scripts/Bash/initEnvironment.sh' script to
-initialize global variables (e.g., gettext variables) and
-global function scripts.  Global function scripts are located inside
-`trunk/Scripts/Bash/Functions' directory and their file names
-begin with `cli'. Global function scripts provide common
-functionalities that can be used anywhere inside `centos-art.sh'
-script execution environment.
-
    
-
    Once global variables and function scripts have been loaded,
-`centos-art.sh' script executes the cli global function
-from `cli.sh' function script to retrive command-line arguments
-and define some default values that may be used later by specific
-function scripts (-- Removed(pxref:trunk Scripts Bash Functions) --).
-
    
-
    As convenction, the `centos-art.sh' command-line arguments have
-the following format:
-
    
-
    centos-art arg1 --arg2=val2 --arg3=val3
-
    
-
    In the above example, `centos-art' is the command you use to
-invoke `centos-art.sh' script. The `arg1' is required and
-represents the functionality you want to perform (e.g.,
-`verify', `render', `locale', `manual',
-etc.). The remaining arguments are modifiers to `arg1'. The
-`--arg2' definition is required and represets, specifically,
-the action inside the functionality you want to perform.  The
-`--arg3' and on, are optional.
-
    
-
    Once command-line arguments have been retrived, the
-`centos-art.sh' script loads specific functionalities using the
-`cli_getFunctions.sh' function script. Only one specific
-functionality can be loaded at one script execution I.e., you run
-centos-art.sh script to run just one functionality.
-
    
-
    
-
    +----------------------------------------------------------------------+
-| [centos@host]$ centos-art function --action='value' --option='value' |
-+----------------------------------------------------------------------+
-| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh      |
-+---v-----------------------------------------v------------------------+
-    | centos-art.sh                           |
-    +---v---------------------------------v---+
-    .   | initEnvironment.sh              |   .
-    .   +---------------------------------+   .
-    .   | cli $@                          |   .
-    .   +---v-------------------------v---+   .
-    .   .   | cli_getFunctions        |   .   .
-    .   .   +---v-----------------v---+   .   .
-    .   .   .   | function1       |   .   .   .
-    .   .   .   | function2       |   .   .   .
-    .   .   .   | function3       |   .   .   .
-    .   .   .   +-----------------+   .   .   .
-    .   .   ...........................   .   .
-    .   ...................................   .
-    ...........................................
-
    
-
    Figure 2.1: The functionalities initialization environment.
-
-
    
-
    Functionalities are implemented by means of actions.  Once the
-functionality has been initiazalized, actions initialization take
-place for that functionality. Actions initialization model is very
-similar to functions initialization model. But with the difference,
-that actions are loaded inside function environment, and so, share
-variables and functions defined inside function environment.
-
    
-
    
-
    +--------------------------------------+
-| cli_getFunctions                     |
-+---v------------------------------v---+
-.   | function1                    |   .
-.   +---v----------------------v---+   .
-.   .   | function1_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-.   +------------------------------+   .
-.   | function2                    |   .
-.   +---v----------------------v---+   .
-.   .   | function2_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-.   +------------------------------+   .
-.   | function3                    |   .
-.   +---v----------------------v---+   .
-.   .   | function3_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-........................................
-
    
-
    Figure 2.2: The actions initialization environment.
-
-
    
+
+
     2.59.2 Description 
    
 
-
-
     2.62.3 Usage 
    
+
      
+
    •  ...
+
    
+
+
+
+
     2.59.3 Usage 
    
+
+
      
+
    •  ...
+
    
 
-
    The `centos-art.sh' script usage information is described inside
-each specific function documentation (-- Removed(pxref:trunk Scripts Bash
-Functions) --).
-
    
 
-
-
     2.62.4 See also 
    
+
+
     2.59.4 See also 
    
 
-
-
-
    2.61 The `trunk/Scripts' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_67.html b/Manual/repository-html/repository_67.html
index fc381e5..1e4fe3d 100644
--- a/Manual/repository-html/repository_67.html
+++ b/Manual/repository-html/repository_67.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.63 The trunk/Scripts/Bash/Cli Directory
+CentOS Artwork Repository: 2.60 The trunk/Manuals Directory
 
-
-
+
+
 
 
 
@@ -55,38 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.63 The `trunk/Scripts/Bash/Cli' Directory 
    
+
+
+
     2.60 The `trunk/Manuals' Directory 
    
+
+
+
+
     2.60.1 Goals 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.60.2 Description 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.60.3 Usage 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.60.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_68.html b/Manual/repository-html/repository_68.html
index b52f53d..6b9ea20 100644
--- a/Manual/repository-html/repository_68.html
+++ b/Manual/repository-html/repository_68.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.64 The trunk/Scripts/Bash/Cli/Functions Directory
+CentOS Artwork Repository: 2.61 The trunk/Scripts Directory
 
-
-
+
+
 
 
 
@@ -55,1300 +55,69 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory 
    
-
-
-
-
     2.64.1 Goals 
    
-
-
    The `trunk/Scripts/Bash/Functions' directory exists to organize
-`centos-art.sh' specific functionalities.
-
    
-
-
-
     2.64.2 Description 
    
-
-
    The specific functions of `centos-art.sh' script are designed
-with "Software Toolbox" philosophy (see (coreutils.info)Toolbox introduction) in mind: each program "should do one
-thing well".  Inside `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 `centos-art.sh' script are organized
-inside specific directories under `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 render, the specific function
-directory for it would be `trunk/Scripts/Bash/Functions/Render'.
-
    
-
    To better understand how specific functions of `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 `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.
-
    
-
    Info
    Tip
     Join CentOS developers mailing list
-centos-art@centos.org to share your ideas.
-
    
-
-
    It is also worth to know what global functions and variables do we
-have available inside `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
-`trunk/Scripts/Bash/Functions' directory, in files begining with
-`cli' prefix.
-
    
-
    OK, let's begin with our functionality example.
-
    
-
    What function name do we use? Well, lets use greet. Note that
-`hello' word is not a verb; but an expression, a kind of
-greeting, an interjection specifically. In contrast, `greet' is a
-verb and describes what we do when we say `Hello!', `Hi!',
-and similar expressions.
-
    
-
    So far, we've gathered the following function information:
-
    
-
    Name: greet
-Path: trunk/Scripts/Bash/Functions/Greet
-File: trunk/Scripts/Bash/Functions/Greet/greet.sh
-
    
-
    The `greet.sh' function script is the first file
-`centos-art.sh' script loads when the `greet' functionality
-is called using commands like `centos-art greet --hello='World''.
-The `greet.sh' function script contains the greet function
-definition. 
-
    
-
    Inside `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 `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 `centos-art.sh'
-script is released as GPL, so do all its functions--, the $Id$
-keyword of Subversion is later expanded by svn propset
-command.
-
    
-
    In our greet function example, top commentary for
-`greet.sh' function script would look like the following:
-
    
-
    #!/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$
-# ----------------------------------------------------------------------
-
    
-
    After top commentary, separated by one blank line, the greet
-function definition would look like the following:
-
    
-
    function greet {
-
-    # Define global variables.
+
+
+
     2.61 The `trunk/Scripts' Directory 
    
 
-    # Define command-line interface.
-    greet_getActions
-
-}
-
    
-
    The first definition inside greet function, are global
-variables that will be available along greet function execution
-environment. This time we didn't use global variable definitions for
-greet function execution environment, so we left that section
-empty.
-
    
-
    Later, we call greet_getActions function to define the
-command-line interface of greet functionality. The command-line
-interface of greet functionality defines what and how actions
-are performed, based on arguments combination passed to
-`centos-art.sh' script.
-
    
-
    function greet_getActions {
 
-    case "$ACTIONNAM" in
+
+
     2.61.1 Goals 
    
 
-        --hello )
-            greet_doHello
-            ;;
-
-        --bye )
-            greet_doBye
-            ;;
-
-        * )
-            cli_printMessage "`gettext "The option provided is not valid."`"
-            cli_printMessage "$(caller)" 'AsToKnowMoreLine'
-
-    esac
-
-}
-
    
-
    The ACTIONNAM global variable is defined in `cli.sh'
-function script and contains the value passed before the equal sign
-(i.e., `=') in the second command-line argument of
-`centos-art.sh' script. For example, if the second command-line
-argument is `--hello='World'', the value of ACTIONNAM
-variable would be `--hello'.  Using this configuration let us
-deside which action to perform based on the action name passed to
-`centos-art.sh' script as second argument. 
-
    
-
    The greet function definition makes available two valid
-greetings through `--hello' and `--bye' options.  If no
-one of them is provided as second command-line argument, the `*'
-case is evaluated instead. 
-
    
-
    The `*' case and its two lines further on should always be
-present in `_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 greet_doHello and greet_doBye function definitions
-are the core of greet specific functionality.  In such function
-definitions we set what our greet function really does: to
-output different kinds of greetings.
-
    
-
    function greet_doHello {
-
-    cli_printMessage "`gettext "Hello"` $ACTIONVAL"
-
-}
-
    
-
    The greet_doHello function definition is stored in
-`greet_doHello.sh' function script. 
-
    
-
    function greet_doBye {
-
-    cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
-
-}
-
    
-
    The greet_doBye function definition is stored in the
-`greet_doBye.sh' function script. 
-
    
-
    Both `greet_doHello.sh' and `greet_doBye.sh' function
-scripts are stored inside greet function directory path (i.e.
-`trunk/Scripts/Bash/Functions/Greet').
-
    
-
    The ACTIONVAL global variable is defined in `cli.sh'
-function script and contains the value passed after the equal sign
-(i.e., `=') in the second command-line argument of
-`centos-art.sh' script. For example, if the second command-line
-argument is `--hello='World'', the value of ACTIONVAL
-variable would be `World' without quotes.
-
    
-
    Let's see how greet specific functionality files are organzied
-under greet function directory. To see file organization we use
-the tree command:
-
    
-
    trunk/Scripts/Bash/Functions/Greet
-|-- greet_doBye.sh
-|-- greet_doHello.sh
-|-- greet_getActions.sh
-`-- greet.sh
-
    
-
    To try the greet specific functionality we've just created,
-pass the function name (i.e., `greet') as first argument to
-`centos-art.sh' script, and any of the valid options as second
-argument. Some examples are illustrated below:
-
    
-
    [centos@projects ~]$ centos-art greet --hello='World'
-Hello World
-[centos@projects ~]$ centos-art greet --bye='World'
-Goodbye World
-[centos@projects ~]$ 
-
    
-
    The word `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 greet specific functionality,
-we use its directory path and the manual functionality
-(-- Removed(pxref:trunk Scripts Bash Functions Manual) --) of `centos-art.sh'
-script, just as the following command illustrates: 
-
    
-
    centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
-
    
-
    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 `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 `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
-locale functionality (-- Removed(pxref:trunk Scripts Bash Functions
-Locale) --) of `centos-art.sh' script, just as the following command
-illustrates:
-
    
-
    centos-art locale --edit
-
    
-
    Warning
    Warning
     To translate output messages in different languages,
-your system locale information --as in 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
-`es_ES.UTF-8', or similar, first.
-
    
-
-
    Well, it seems that our example is rather complete by now. 
-
    
-
    In greet function example we've described so far, we only use
-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
-`--filter='regex'' and reduce the amount of files to process
-using a regular expression pattern.
-
    
-
    The greet function described in this section may serve you as
-an introduction to understand how specific functionalities work inside
-`centos-art.sh' script. With some of luck this introduction will
-also serve you as motivation to create your own `centos-art.sh'
-script specific functionalities.
-
    
-
    By the way, the greet functionality doesn't exist inside
-`centos-art.sh' script yet. Would you like to create it?
-
    
-
-
-
     2.64.3 Usage 
    
-
-
-
-
     2.64.3.1 Global variables 
    
-
-
    The following global variables of `centos-art.sh' script, are
-available for you to use inside specific functions:
-
    
-
    
-
    Variable: TEXTDOMAIN
-
-
    
-
    Default domain used to retrieve translated messages. This value is set
-in `initFunctions.sh' and shouldn't be changed.
-
    
-
-
    
-
    Variable: TEXTDOMAINDIR
-
-
    
-
    Default directory used to retrieve translated messages. This value is
-set in `initFunctions.sh' and shouldn't be changed.
-
    
-
-
    
-
    Variable: FUNCNAM
-
-
    
-
    Define function name.
-
    
-
    Function names associate sets of actions. There is one set of actions
-for each unique function name inside `centos-art.sh' script.
-
    
-
    Dunction names are passed as first argument in `centos-art.sh'
-command-line interface. For example, in the command `centos-art
-render --entry=path/to/dir --filter=regex', the ACTION passed to
-`centos-art.sh' script is `render'.
-
    
-
    When first argument is not provided, the `centos-art.sh' script
-immediatly ends its execution.
-
    
-
-
    
-
    Variable: FUNCDIR
-
-
    
-
    
-
-
    
-
    Variable: FUNCDIRNAME
-
-
    
-
    
-
-
    
-
    Variable: FUNCSCRIPT
-
-
    
-
    
-
-
    
-
    Variable: FUNCCONFIG
-
-
    
-
    
-
-
    
-
    Variable: 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
-`centos-art.sh' command-line interface. For example, in the
-command `centos-art render --entry=path/to/dir --filter=regex',
-the ACTIONNAM passed to `centos-art.sh' script is
-`--entry'.
-
    
-
    When second argument is not provided, the `centos-art.sh' script
-immediatly ends its execution.
-
    
-
-
    
-
    Variable: 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.
-
    
-
-
    
-
    Variable: REGEX
-
-
    
-
    Define regular expression used as pattern to build the list of files
-to process.
-
    
-
    By default, REGEX variable is set to .+ to match all
-files.
-
    
-
    Functions that need to build a list of files to process use the option
-`--filter' to redefine REGEX variable default value, and
-so, control the amount of files to process.
-
    
-
-
    
-
    Variable: ARGUMENTS
-
-
    
-
    Define optional arguments. 
-
    
-
    Optional arguments, inside `centos-art.sh' script, are considered
-as all command-line arguments passed to `centos-art.sh' script,
-from third argument position on. For example, in the command
-`centos-art render --entry=path/to/dir --filter=regex' , the
-optional arguments are from `--filter=regex' argument on.
-
    
-
    Optional arguments are parsed using getopt command through
-the following base construction: 
-
    
-
    # 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
-
    
-
    Optional arguments provide support to command options inside
-`centos-art.sh' script. For instance, consider the Subversion
-(svn) command, where there are many options (e.g.,
-`copy', `delete', `move', etc), and inside each
-option there are several modifiers (e.g., `--revision',
-`--message', `--username', etc.) that can be combined one
-another in their short or long variants. 
-
    
-
    The ARGUMENTS variable is used to store arguments passed from
-command-line for later use inside `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:
-
    
-
    centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
-
    
-
    In the above command, the `--message', and `--username'
-options are specific to svn copy command. In such cases,
-options are not interpreted by `centos-art.sh' script itself.
-Instead, the `centos-art.sh' script uses getopt to
-retrive them and store them in the ARGUMENTS variable for later
-use, as described in the following command:
-
    
-
    # Build subversion command to duplicate locations inside the
-# workstation.
-eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
-
    
-
    When getopt parses ARGUMENTS, we may use short options
-(e.g., `-m') or long options (e.g., `--message'). When
-we use short options, arguments are separated by one space from the
-option (e.g., `-m 'This is a commit message.'').  When we use
-long options arguments are separated by an equal sign (`=')
-(e.g., `--message='This is a commit message'').
-
    
-
    In order for getopt to parse 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 `centos-art.sh' script, short option
-definitions are set in the ARGSS variable; and long option
-definitions are set in the 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 `:'
-after the option definition (e.g., `-o m: -l message:').  On
-the other hand, to define an option argument as not required, you need
-to set two colons `::' after the option definition (e.g.,
-`-o m:: -l message::').
-
    
-
-
    
-
    Variable: EDITOR
-
-
    
-
    Default text editor. 
-
    
-
    The `centos-art.sh' script uses default text EDITOR to edit
-pre-commit subversion messages, translation files, configuration
-files, script files, and similar text-based files.
-
    
-
    If EDITOR environment variable is not set, `centos-art.sh'
-script uses `/usr/bin/vim' as default text editor. Otherwise, the
-following values are recognized by `centos-art.sh' script:
+
    The `trunk/Scripts' directory exists to:
 
    
 
      
-
    •  `/usr/bin/vim'
-
    •  `/usr/bin/emacs'
-
    •  `/usr/bin/nano'
+
    •  Organize the "trunk" development line of automation scripts by
+programming language.  
 
    
 
-
    If no one of these values is set in EDITOR environment variable,
-`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
-
    
-
-
-
-
     2.64.3.2 Global functions 
    
-
-
    Function scripts stored directly under
-`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 `centos-art.sh' script.
-
    
-
    
-
    Function: cli_checkActionArguments
-
-
    
-
    Validate action value (ACTIONVAL) variable.
-
    
-
    The action value variable can take one of the following values:
-
    
-
      
-
    1.  Path to one directory inside the local working copy,
-
    2.  Path to one file inside the local working copy,
-
    
-
-
    If another value different from that specified above is passed to
-action value variable, the `centos-art.sh' script prints an error
-message and ends script execution.
-
    
-
-
    
-
    Function: cli_checkFiles FILE [TYPE]
-
-
    
-
    Verify file existence.
-
    
-
    cli_checkFiles receives a FILE absolute path and performs
-file verification as specified in TYPE.  When TYPE is not
-specified, cli_checkFiles verifies FILE existence, no
-matter what kind of file it be.  If TYPE is specified, use one
-of the following values:
-
    
-
    
-
     `d'
    
-
     `directory'
    
-
    Ends script execution if FILE is not a directory.
-
    
-
    When you verify directories with cli_checkFiles, if directory doesn't
-exist, `centos-art.sh' script asks you for confirmation in order
-to create that directory. If you answer positively,
-`centos-art.sh' script creates that directory and continues
-script flows normally. Otherwise, if you answer negatively,
-`centos-art.sh' ends script execution with an error and
-documentation message.
-
    
-
    
-
     `f'
    
-
     `regular-file'
    
-
    Ends script execution if FILE is not a regular file.
-
    
-
     `h'
    
-
     `symbolic-link'
    
-
    Ends script execution if FILE is not a symbolic link.
-
    
-
     `x'
    
-
     `execution'
    
-
    Ends script execution if FILE is not executable.
-
    
-
     `fh'
    
-
    Ends script execution if FILE is neither a regular file nor a
-symbolic link.
-
    
-
     `fd'
    
-
    Ends script execution if FILE is neither a regular file nor a
-directory.
-
    
-
     `isInWorkingCopy'
    
-
    Ends script execution if FILE is not inside the working copy.
-
    
-
    
-
-
    As default behaviour, if FILE passes all verifications,
-`centos-art.sh' script continues with its normal flow. 
-
    
-
-
    
-
    Function: cli_commitRepoChanges [LOCATION]
-
-
    
-
    Syncronize changes between repository and working copy.
-
    
-
    The cli_commitRepoChanges function brings changes from the
-central repository down to the working copy--using svn
-update--, checks the working copy changes--using svn
-status command--, prints status report--using both svn
-update and svn status commands output, and finally, commits
-recent changes from the working copy up to the repository--using
-svn commit command--.
-
    
-
    Previous to commit the working copy changes up to the central
-repository, the cli_commitRepoChanges function asks you to
-verify changes--using svn diff command--, and later,
-another confirmation question is shown to be sure you really want to
-commit changes up to central repository.
-
    
-
    If LOCATION argument is not specified, the value of
-ACTIONVAL variable is used as reference instead.
-
    
-
    
-
    ----------------------------------------------------------------------
---> 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.
-----------------------------------------------------------------------
-
    
-
    Figure 2.3: The cli_commitRepoChanges function output.
-
-
    
-
    Call the cli_commitRepoChanges function before or/and after
-calling functions that modify files or directories inside the working
-copy as you may need to.  
-
    
-
-
    
-
    Function: cli_doParseArguments
-
-
    
-
    Redefine arguments (ARGUMENTS) global variable using
-getopt command output. For more information about how to use
-cli_doParseArguments function, see ARGUMENTS variable
-description above.
-
    
-
-
    
-
    Function: cli_doParseArgumentsReDef $@
-
-
    
-
    Initialize/reset arguments (ARGUMENTS) global variable using
-positional parameters variable ($@) 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 cli_doParseArgumentsReDef with the positional
-parameters variable ($@), set as first argument, to that
-specific function you want to redefine positional parameters at.
-
    
-
-
    
-
    Function: cli_getArguments
-
-
    
-
    Initialize function name (FUNCNAM), action name
-(ACTIONNAM), and action value (ACTIONVAL) global
-variables, using positional parameters passed in $@ variable.
-
    
-
    The cli_getArguments function is called from cli.sh
-function script, using 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
-`centos-art.sh' script execution evironment,
-cli_getArguments uses regular expression to retrive
-action variables from first and second argument. The first argument
-defines the value used as function name (FUNCNAM), and the
-second argument defines both values used as action name
-(ACTIONNAM) and action value (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., `render' to
-render images, `manual' to work on documentation, and so on.)
-
    
-
    The second argument has a long option style (e.g.,
-`--option=value'). The `--option' represents the action name
-(ACTIONNAM), and the characters inbetween the equal sign
-(`=') and the first space character, are considered as the action
-value (ACTIONVAL). In order to provide action values with space
-characters inbetween you need to enclose action value with quotes like
-in `--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., FUNCNAM, ACTIONNAM,
-and ACTIONVAL) are defined and validated,
-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 (ARGUMENTS) global
-variable with the new positional parameters information.
-
    
-
-
    
-
    Function: cli_getFunctions
-
-
    
-
    Initialize funtionalities supported by `centos-art.sh' script.
-
    
-
    Functionalities supported by `centos-art.sh' script are organized
-in functionality directories under
-`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 `centos-art.sh' script to recognize a functionality,
-such functionality needs to be stored under
-`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 `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 `camelCase'
-format with the function name as prefix.  Separation between prefix
-and description is done using underscore (`_') character.
-
    
-
    In order for `centos-art.sh' script to load functionalities
-correctly, function definition inside function scripts should be set
-using the `function' reserved word, just as in the following
-example:
-
    
-
    function prefix_doSomething {
-
-    # Do something here...
-
-}
-
    
-
    The above function definition is just a convenction we use, in order
-to make identification of function names easier read and automate by
-`centos-art.sh' script initialization commands, once
-`centos-art.sh' script determines which functionality directory
-to use.  Specifically, in order to initialize and export functions,
-`centos-art.sh' script executes all function scripts inside the
-functionality directory, and later grep on them using a
-regular expression pattern, where the `function' reserved word is
-used as reference to retrive the function names and export them to
-`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, `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:
-
    
-
    #!/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...
-
-}
-
    
-
-
    
-
    Function: cli_getCountryCodes [FILTER]
-
-
    
-
    Output country codes supported by `centos-art.sh' script. 
-
    
-
    The cli_getCountryCodes function outputs a list with country
-codes as defined in ISO3166 standard. When FILTER is provided,
-cli_getCountryCodes outputs country codes that match
-FILTER regular expression pattern.
-
    
-
-
    
-
    Function: cli_getCountryName [FILTER]
-
-
    
-
    Outputs country name supported by `centos-art.sh' script.
-
    
-
    The 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, cli_getCountryName returns the
-country name that matches the locale code specified in FILTER,
-exactly.
-
    
- 
-
    
-
    Function: cli_getCurrentLocale
-
-
    
-
    Output current locale used by `centos-art.sh' script. 
-
    
-
    The cli_getCurrentLocale function uses LANG environment
-variable to build a locale pattern that is later applied to
-cli_getLocales function output in order to return the current
-locale that `centos-art.sh' script works with. 
-
    
-
    The current locale information, returned by
-cli_getCurrentLocale, is output from more specific to less
-specific. For example, if `en_GB' locale exists in
-cli_getLocales function output, the `en_GB' locale would
-take precedence before `en' locale.
-
    
-
    Locale precedence selection is quite important in order to define the
-locale type we use for message translations. For example, if
-`en_GB' is used, we are also saying that the common language
-specification for English language (i.e., `en') is no longer
-used. Instead, we are using English non-common country-specific
-language specifications like `en_AU', `en_BW', `en_GB',
-`en_US', etc., for message translations.  
-
    
-
    Use cli_getCurrentLocale function to know what current locale
-information to use inside `centos-art.sh' script.
-
    
-
-
    
-
    Function: cli_getFilesList [LOCATION]
-
-
    
-
    Output list of files to process.
-
    
-
    The cli_getFilesList function uses LOCATION variable as
-source location to build a list of files just as specified by regular
-expression (REGEX) global variable. Essentially, what the
-cli_getFilesList function does is using find command
-to look for files in the location (LOCATION) just as posix-egrep
-regular expression (REGEX) specifies. 
-
    
-
    If LOCATION is not specified when cli_getFilesList
-function is called, the action value (ACTIONVAL) global variable
-is used as location value instead.
-
    
-
    By default, if the regular expression (REGEX) global variable is
-not redefined after its first definition in the cli function,
-all files that match default regular expression value (i.e.,
-`.+') 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 cli function and before calling
-cli_getFilesList function, the last value you specifed is used
-instead.
-
    
-
    When you need to customize the regular expression (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 `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 cli_getFilesList re-defines the value of
-FILES variable with the list of files the find command
-returned. As example, consider the following construction:
-
    
-
    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)"
+
+
     2.61.2 Description 
    
 
-    # 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
-
-}
-
    
-
    
-
-
    
-
    Function: cli_getLangCodes [FILTER]
-
-
    
-
    Outputs language codes supported by `centos-art.sh' script.
-
    
-
    cli_getLangCodes function outputs a list of language codes as
-defined in ISO639 standard. When FILTER is provided,
-cli_getLangCodes outputs language codes that match FILTER
-regular expression pattern.
-
    
-
-
    
-
    Function: cli_getLangName [FILTER]
-
-
    
-
    Outputs language names supported by `centos-art.sh' script.
-
    
-
    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, cli_getLangName returns the language name
-that matches the locale code specified in FILTER, exactly.
-
    
-
-
    
-
    Function: cli_getLocales
-
-
    
-
    Output locale codes supported by `centos-art.sh' script.
-
    
-
    Occasionally, you use cli_getLocales function to add locale
-information in non-common country-specific language (`LL_CC')
-format for those languages (e.g., `bn_IN', `pt_BR', etc.)
-which locale differences cannot be solved using common language
-specifications (`LL') into one unique common locale specification
-(e.g., `bn', `pt', etc.).  
-
    
-
-
    
-
    Function: cli_getRepoName NAME TYPE
-
-
    
-
    Sanitate file names.
-
    
-
    Inside `centos-art.sh' script, specific functionalities rely both
-in cli_getRepoName and repository file system organization to
-achieve their goals.  Consider cli_getRepoName function as
-central place to manage file name convenctions for other functions
-inside `centos-art.sh' script.
-
    
-
    Important
    Important
     cli_getRepoName function doesn't verify file
-or directory existence, for that purpose use cli_checkFiles
-function instead.
-
    
-
-
    The NAME variable contains the file name or directory name you
-want to sanitate.
-
    
-
    The TYPE variable specifies what type of sanitation you want to
-perform on NAME. The TYPE can be one of the following
-values:
-
    
-
    
-
     `d'
    
-
     `directory'
    
-
    Sanitate directory NAMEs.
-
    
-
     `f'
    
-
     `regular-file'
    
-
    Sanitate regular file NAMEs.
-
    
-
    
-
-
    Use cli_getRepoName function to sanitate file names and
-directory names before their utilization. 
-
    
-
    Use cli_getRepoName when you need to change file name
-convenctions inside `centos-art.sh' script. 
-
    
-
    When we change file name convenctions inside 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 (-- Removed(pxref:trunk Scripts Bash Functions Path) --, for more
-information).
-
    
-
-
    
-
    Function: cli_getRepoStatus [LOCATION]
-
-
    
-
    Request repository status.
-
    
-
    This function requests the status of a LOCATION inside the
-working copy using the svn status command and returns the
-first character in the output line, just as described in svn
-help status. If LOCATION is not a regular file or a directory,
-inside the working copy, the `centos-art.sh' script prints a
-message and ends its execution.
-
    
-
    Use this function to perform verifications based a repository
-LOCATION status.
-
    
-
-
    
-
    Function: cli_getTemporalFile NAME
-
-
    
-
    Output absolute path to temporal file NAME.
-
    
-
    The cli_getTemporalFile function uses `/tmp' directory as
-source location to store temporal files, the `centos-art.sh'
-script name, and a random identification string to let you run more
-than one `centos-art.sh' script simultaneously on the same user
-session.  For example, due the following temporal file defintion:
-
    
-
    cli_getTemporalFile $FILE
-
    
-
    If FILE name is `instance.svg' and the unique random string
-is `f16f7b51-ac12-4b7f-9e66-72df847f12de', the final temporal
-file, built from previous temporal file definition, would be:
-
    
-
    /tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
-
    
-
    When you use the 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:
-
    
-
    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
-
    
-
    Use the cli_getTemporalFile function whenever you need to
-create temporal files inside `centos-art.sh' script.
-
    
-
-
    
-
    Function: cli_getThemeName
-
-
    
-
    Output theme name.
-
    
-
    In order for cli_getThemeName function to extract theme name
-correctly, the ACTIONVAL variable must contain a directory path
-under `trunk/Identity/Themes/Motifs/' directory structure.
-Otherwise, cli_getThemeName returns an empty string.  
-
    
-
-
    
-
    Function: cli_printMessage MESSAGE [FORMAT]
-
-
    
-
    Define standard output message definition supported by
-`centos-art.sh' script.
-
    
-
    When FORMAT is not specified, cli_printMessage outputs
-information just as it was passed in MESSAGE variable.
-Otherwise, FORMAT can take one of the following values:
-
    
-
    
-
     `AsHeadingLine'
    
-
    To print heading messages.
-
    ----------------------------------------------------------------------
-$MESSAGE
-----------------------------------------------------------------------
-
    
-
    
-
     `AsWarningLine'
    
-
    To print warning messages.
-
    ----------------------------------------------------------------------
-WARNING: $MESSAGE
-----------------------------------------------------------------------
-
    
-
    
-
     `AsNoteLine'
    
-
    To print note messages.
-
    ----------------------------------------------------------------------
-NOTE: $MESSAGE
-----------------------------------------------------------------------
-
    
-
    
-
     `AsUpdatingLine'
    
-
    To print `Updating' messages on two-columns format.
-
    Updating        $MESSAGE
-
    
-
    
-
     `AsRemovingLine'
    
-
    To print `Removing' messages on two-columns format.
-
    Removing        $MESSAGE
-
    
-
    
-
     `AsCheckingLine'
    
-
    To print `Checking' messages on two-columns format.
-
    Checking        $MESSAGE
-
    
-
    
-
     `AsCreatingLine'
    
-
    To print `Creating' messages on two-columns format.
-
    Creating        $MESSAGE
-
    
-
    
-
     `AsSavedAsLine'
    
-
    To print `Saved as' messages on two-columns format.
-
    Saved as        $MESSAGE
-
    
-
    
-
     `AsLinkToLine'
    
-
    To print `Linked to' messages on two-columns format.
-
    Linked to       $MESSAGE
-
    
-
    
-
     `AsMovedToLine'
    
-
    To print `Moved to' messages on two-columns format.
-
    Moved to        $MESSAGE
-
    
-
    
-
     `AsTranslationLine'
    
-
    To print `Translation' messages on two-columns format.
-
    Translation     $MESSAGE
-
    
-
    
-
     `AsConfigurationLine'
    
-
    To print `Configuration' messages on two-columns format.
-
    Configuration   $MESSAGE
-
    
-
    
-
     `AsResponseLine'
    
-
    To print response messages on one-column format.
-
    --> $MESSAGE
-
    
-
    
-
     `AsRequestLine'
    
-
    To print request messages on one-column format. Request messages
-output messages with one colon (`:') and without trailing newline
-(`\n') at message end.
-
    $MESSAGE:
-
    
-
    
-
     `AsYesOrNoRequestLine'
    
-
    To print `yes or no' request messages on one-column format. If
-something different from `y' is answered (when using
-en_US.UTF-8 locale), script execution ends immediatly.  
-
    
-
    $MESSAGE [y/N]:
-
    
-
    When we use `centos-art.sh' script in a locale different from
-en_US.UTF-8, confirmation answer may be different from
-`y'. For example, if you use es_ES.UTF-8 locale, the
-confirmation question would look like:
-
    
-
    $MESSAGE [s/N]:
-
    
-
    and the confirmation answer would be `s', as it is on Spanish
-`sí' word.
-
    
-
    Definition of which confirmation word to use is set on translation
-messages for your specific locale information. -- Removed(xref:trunk Scripts
-Bash Functions Locale) --, for more information about locale-specific
-translation messages.
-
    
-
    
-
     `AsToKnowMoreLine'
    
-
    To standardize `to know more, run the following command:'
-messages. When the `AsToKnowMoreLine' option is used, the
-MESSAGE value should be set to "$(caller)". caller
-is a Bash builtin that returns the context of the current subroutine
-call. `AsToKnowMoreLine' option uses caller builtin
-output to build documentation entries dynamically.
-
    
-
    ----------------------------------------------------------------------
-To know more, run the following command:
-centos-art manual --read='path/to/dir'
-----------------------------------------------------------------------
-
    
-
    Use `AsToKnowMoreLine' option after errors and for intentional
-script termination. 
-
    
-
    
-
     `AsRegularLine'
    
-
    To standardize regular messages on one-column format. 
-
    
-
    When MESSAGE contains a colon inside (e.g., `description:
-message'), the cli_printMessage function outputs MESSAGE
-on two-columns format. 
-
    
-
    
-
-
    Use cli_printMessage function whenever you need to output
-information from `centos-art.sh' script.
-
    
-
    Info
    Tip
     To improve two-columns format, change the following file:
-
    trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
-
    
-
    
+
      
+
    •  ...
+
    
 
 
-
-
     2.64.3.3 Specific functions 
    
+
+
     2.61.3 Usage 
    
 
-
    The following specific functions of `centos-art.sh' script, are
-available for you to use:
-
    
+
      
+
    •  ...
+
    
 
 
-
-
     2.64.4 See also 
    
+
+
     2.61.4 See also 
    
 
-
-
-
    2.62 The `trunk/Scripts/Bash' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_69.html b/Manual/repository-html/repository_69.html
index b353c71..8dada30 100644
--- a/Manual/repository-html/repository_69.html
+++ b/Manual/repository-html/repository_69.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.65 The trunk/Scripts/Bash/Cli/Functions/Help Directory
+CentOS Artwork Repository: 2.62 The trunk/Scripts/Bash Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,197 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory 
    
+
+
+
     2.62 The `trunk/Scripts/Bash' Directory 
    
 
 
-
-
     2.65.1 Goals 
    
+
+
     2.62.1 Goals 
    
 
-
      
-
    •  ...
-
    
-
-
-
-
     2.65.2 Description 
    
-
-
      
-
    •  ...
-
    
+
    The `trunk/Scripts/Bash' directory exists to organize the trunk
+development line of `centos-art.sh' automation script.  The
+`centos-art.sh' script standardizes frequent tasks inside your
+working copy of CentOS Artwork Repository.
+
    
 
+
+
     2.62.2 Description 
    
 
-
-
     2.65.3 Usage 
    
+
    The best way to understand `centos-art.sh' automation script is
+studying its source code.  However, as start point, you may prefer to
+read an introductory resume before diving into the source code
+details.
+
    
+
    The `centos-art.sh' script is written in Bash. Most tasks, inside
+`centos-art.sh' script, have been organized in many specific
+functionalities that you can invoke from the centos-art
+command-line interface.
+
    
+
    When you type the centos-art command in your terminal, the
+operating system trys to execute that command. In order to execute the
+command, the operating system needs to know where it is, so the
+operating system uses the PATH environment variable to look for
+that command location. If your system was prepared to use CentOS
+Artwork Repository correctly (-- Removed(pxref:trunk Scripts Bash Functions
+Verify) --), you should have a symbolic link inside `~/bin/'
+directory that points to the `centos-art.sh' script file. As
+`~/bin/' directory is, by default, inside PATH environment
+variable, the execution of centos-art command runs the
+`centos-art.sh' script.
+
    
+
    When `centos-art.sh' script is executed, the first it does is
+executing the `trunk/Scripts/Bash/initEnvironment.sh' script to
+initialize global variables (e.g., gettext variables) and
+global function scripts.  Global function scripts are located inside
+`trunk/Scripts/Bash/Functions' directory and their file names
+begin with `cli'. Global function scripts provide common
+functionalities that can be used anywhere inside `centos-art.sh'
+script execution environment.
+
    
+
    Once global variables and function scripts have been loaded,
+`centos-art.sh' script executes the cli global function
+from `cli.sh' function script to retrive command-line arguments
+and define some default values that may be used later by specific
+function scripts (-- Removed(pxref:trunk Scripts Bash Functions) --).
+
    
+
    As convenction, the `centos-art.sh' command-line arguments have
+the following format:
+
    
+
    centos-art arg1 --arg2=val2 --arg3=val3
+
    
+
    In the above example, `centos-art' is the command you use to
+invoke `centos-art.sh' script. The `arg1' is required and
+represents the functionality you want to perform (e.g.,
+`verify', `render', `locale', `manual',
+etc.). The remaining arguments are modifiers to `arg1'. The
+`--arg2' definition is required and represets, specifically,
+the action inside the functionality you want to perform.  The
+`--arg3' and on, are optional.
+
    
+
    Once command-line arguments have been retrived, the
+`centos-art.sh' script loads specific functionalities using the
+`cli_getFunctions.sh' function script. Only one specific
+functionality can be loaded at one script execution I.e., you run
+centos-art.sh script to run just one functionality.
+
    
+
    
+
    +----------------------------------------------------------------------+
+| [centos@host]$ centos-art function --action='value' --option='value' |
++----------------------------------------------------------------------+
+| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh      |
++---v-----------------------------------------v------------------------+
+    | centos-art.sh                           |
+    +---v---------------------------------v---+
+    .   | initEnvironment.sh              |   .
+    .   +---------------------------------+   .
+    .   | cli $@                          |   .
+    .   +---v-------------------------v---+   .
+    .   .   | cli_getFunctions        |   .   .
+    .   .   +---v-----------------v---+   .   .
+    .   .   .   | function1       |   .   .   .
+    .   .   .   | function2       |   .   .   .
+    .   .   .   | function3       |   .   .   .
+    .   .   .   +-----------------+   .   .   .
+    .   .   ...........................   .   .
+    .   ...................................   .
+    ...........................................
+
    
+
    Figure 2.1: The functionalities initialization environment.
+
+
    
+
    Functionalities are implemented by means of actions.  Once the
+functionality has been initiazalized, actions initialization take
+place for that functionality. Actions initialization model is very
+similar to functions initialization model. But with the difference,
+that actions are loaded inside function environment, and so, share
+variables and functions defined inside function environment.
+
    
+
    
+
    +--------------------------------------+
+| cli_getFunctions                     |
++---v------------------------------v---+
+.   | function1                    |   .
+.   +---v----------------------v---+   .
+.   .   | function1_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function2                    |   .
+.   +---v----------------------v---+   .
+.   .   | function2_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function3                    |   .
+.   +---v----------------------v---+   .
+.   .   | function3_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+........................................
+
    
+
    Figure 2.2: The actions initialization environment.
+
+
    
 
-
      
-
    •  ...
-
    
+
+
     2.62.3 Usage 
    
 
+
    The `centos-art.sh' script usage information is described inside
+each specific function documentation (-- Removed(pxref:trunk Scripts Bash
+Functions) --).
+
    
 
-
-
     2.65.4 See also 
    
+
+
     2.62.4 See also 
    
 
+
+
+
    2.61 The `trunk/Scripts' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_7.html b/Manual/repository-html/repository_7.html
index a8aa867..e2e0f14 100644
--- a/Manual/repository-html/repository_7.html
+++ b/Manual/repository-html/repository_7.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.3 The trunk Directory
+CentOS Artwork Repository: 2. Repository File System
 
-
-
+
+
 
 
 
@@ -55,112 +55,203 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.3 The `trunk' Directory 
    
+
+
+
     2. Repository File System 
    
 
-
-
-
     2.3.1 Goals 
    
-
-
    This directory implements the Subversion's trunk concept in a
-trunk, branches, tags repository structure.
-
    
-
-
-
     2.3.2 Description 
    
-
-
    The `trunk/' directory structure is the main development line
-inside the CentOS Artwork Repository and organizes the following
-sections:
-
    
-
    
-
     Identity
    
-
    This section organizes image production in different formats and some
-non-image formats like XHTML and text files, as well. This is the
-perfect place to consolidate The CentOS Artwork SIG. If you are
-interested in producing art works for The CentOS Project, this place
-is for you. 
-
    
-
    See section The `trunk/Identity' Directory, for more information.
-
    
-
    
-
     Manual
    
-
    This section organizes the CentOS Artwork Repository Manual
-(i.e., the documentation manual you're reading right now).  If you are
-interested on improving The CentOS Artwork Repository Manual, in this
-place you'll find the Texinfo documentation structure you need to work
-with.
-
    
-
    See section The `trunk/Manual' Directory, for more information.
+
    The CentOS Artwork Repsotiroy File System is the place where we
+organize The CentOS Project Corporate Visual Identity. The CentOS
+Artwork Repository uses directories to organize files and describe
+conceptual idea about corporate identity. Such conceptual ideas are
+explained in each directory related documentation entry.
 
    
-
    
-
     Scripts
    
-
    This section organizes production of automation scripts specially
-designed to automate most frequent tasks in the repository (e.g.,
-image rendition, documenting directory structures, translating
-content, etc.).  If you can't resist the idea of automating repeatable
-tasks, then take a look here.
+
    In this chapter you'll learn what each directory inside The CentOS
+Artwork Repository is for and so, how you can make use of them. For
+that purpose, the following list of directories is available for you
+to explore:
 
    
-
    See section The `trunk/Scripts' Directory, for more information.
-
    
-
    
-
     Locales
    
-
    This section organizes production of translation messages for
-Identity, Documentation and Scripts. This place
-is perfect to consolidate The CentOS Translation SIG. If you
-love translating, you'll find lot of messages waiting for you to
-translate here.  
-
    
-
    See section The `trunk/Locales' Directory, for more information.
-
    
-
    
-
-
-
-
     2.3.3 Usage 
    
-
-
    It seems to be no other use for this directory but to organize the
-sections described above.
-
    
-
-
-
     2.3.4 See also 
    
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    2.1 The `branches' Directory  
+
    2.2 The `tags' Directory  
+
    2.3 The `trunk' Directory  
+
    2.4 The `trunk/Identity' Directory  
+
    2.5 The `trunk/Identity/Brands' Directory  
+
    2.6 The `trunk/Identity/Colors' Directory  
+
    2.7 The `trunk/Identity/Fonts' Directory  
+
    2.8 The `trunk/Identity/Icons' Directory  
+
    2.9 The `trunk/Identity/Isolinux' Directory  
+
    2.10 The `trunk/Identity/Models' Directory  
+
    2.11 The `trunk/Identity/Models/Css' Directory  
+
    2.12 The `trunk/Identity/Models/Html' Directory  
+
    2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory  
+
    2.14 The `trunk/Identity/Models/Tpl' Directory  
+
    2.15 The `trunk/Identity/Models/Tpl/Brands' Directory  
+
    2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory  
+
    2.17 The `trunk/Identity/Models/Xcf' Directory  
+
    2.18 The `trunk/Identity/Release' Directory  
+
    2.19 The `trunk/Identity/Themes' Directory  
+
    2.20 The `trunk/Identity/Themes/Models' Directory  
+
    2.21 The `trunk/Identity/Themes/Models/Alternative' Directory  
+
    2.22 The `trunk/Identity/Themes/Models/Default' Directory  
+
    2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory  
+
    2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory  
+
    2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory  
+
    2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory  
+
    2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory  
+
    2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory  
+
    2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory  
+
    2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory  
+
    2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory  
+
    2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory  
+
    2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory  
+
    2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory  
+
    2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory  
+
    2.36 The `trunk/Identity/Themes/Motifs' Directory  
+
    2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory  
+
    2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory  
+
    2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory  
+
    2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory  
+
    2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory  
+
    2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory  
+
    2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory  
+
    2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory  
+
    2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory  
+
    2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory  
+
    2.47 The `trunk/Identity/Widgets' Directory  
+
    2.48 The `trunk/Locales' Directory  
+
    2.49 The `trunk/Locales/Identity' Directory  
+
    2.50 The `trunk/Locales/Identity/Brands' Directory  
+
    2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory  
+
    2.52 The `trunk/Locales/Identity/Fonts' Directory  
+
    2.53 The `trunk/Locales/Identity/Models' Directory  
+
    2.54 The `trunk/Locales/Identity/Release' Directory  
+
    2.55 The `trunk/Locales/Identity/Themes' Directory  
+
    2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory  
+
    2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory  
+
    2.58 The `trunk/Locales/Identity/Widgets' Directory  
+
    2.59 The `trunk/Manual' Directory  
+
    2.60 The `trunk/Manuals' Directory  
+
    2.61 The `trunk/Scripts' Directory  
+
    2.62 The `trunk/Scripts/Bash' Directory  
+
    2.63 The `trunk/Scripts/Bash/Cli' Directory  
+
    2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory  
+
    2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory  
+
    2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory  
+
    2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory  
+
    2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory  
+
    2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory  
+
    2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory  
+
    2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory  
+
    2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory  
+
    2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory  
+
    2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory  
+
    2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory  
+
    2.76 The `trunk/Scripts/Python' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_70.html b/Manual/repository-html/repository_70.html
index 5f152c0..586c419 100644
--- a/Manual/repository-html/repository_70.html
+++ b/Manual/repository-html/repository_70.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.66 The trunk/Scripts/Bash/Cli/Functions/Html Directory
+CentOS Artwork Repository: 2.63 The trunk/Scripts/Bash/Cli Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,38 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory 
    
-
-
-
-
     2.66.1 Goals 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.66.2 Description 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.66.3 Usage 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.66.4 See also 
    
+
+
+
     2.63 The `trunk/Scripts/Bash/Cli' Directory 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_71.html b/Manual/repository-html/repository_71.html
index 2a6a72c..e23ffb2 100644
--- a/Manual/repository-html/repository_71.html
+++ b/Manual/repository-html/repository_71.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.67 The trunk/Scripts/Bash/Cli/Functions/Identity Directory
+CentOS Artwork Repository: 2.64 The trunk/Scripts/Bash/Cli/Functions Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,1300 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory 
    
+
+
+
     2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory 
    
 
 
-
-
     2.67.1 Goals 
    
+
+
     2.64.1 Goals 
    
 
-
      
-
    •  ...
-
    
+
    The `trunk/Scripts/Bash/Functions' directory exists to organize
+`centos-art.sh' specific functionalities.
+
    
 
+
+
     2.64.2 Description 
    
 
-
-
     2.67.2 Description 
    
+
    The specific functions of `centos-art.sh' script are designed
+with "Software Toolbox" philosophy (see (coreutils.info)Toolbox introduction) in mind: each program "should do one
+thing well".  Inside `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 `centos-art.sh' script are organized
+inside specific directories under `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 render, the specific function
+directory for it would be `trunk/Scripts/Bash/Functions/Render'.
+
    
+
    To better understand how specific functions of `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 `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.
+
    
+
    Info
    Tip
     Join CentOS developers mailing list
+centos-art@centos.org to share your ideas.
+
    
 
-
      
-
    •  ...
-
    
+
    It is also worth to know what global functions and variables do we
+have available inside `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
+`trunk/Scripts/Bash/Functions' directory, in files begining with
+`cli' prefix.
+
    
+
    OK, let's begin with our functionality example.
+
    
+
    What function name do we use? Well, lets use greet. Note that
+`hello' word is not a verb; but an expression, a kind of
+greeting, an interjection specifically. In contrast, `greet' is a
+verb and describes what we do when we say `Hello!', `Hi!',
+and similar expressions.
+
    
+
    So far, we've gathered the following function information:
+
    
+
    Name: greet
+Path: trunk/Scripts/Bash/Functions/Greet
+File: trunk/Scripts/Bash/Functions/Greet/greet.sh
+
    
+
    The `greet.sh' function script is the first file
+`centos-art.sh' script loads when the `greet' functionality
+is called using commands like `centos-art greet --hello='World''.
+The `greet.sh' function script contains the greet function
+definition. 
+
    
+
    Inside `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 `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 `centos-art.sh'
+script is released as GPL, so do all its functions--, the $Id$
+keyword of Subversion is later expanded by svn propset
+command.
+
    
+
    In our greet function example, top commentary for
+`greet.sh' function script would look like the following:
+
    
+
    #!/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$
+# ----------------------------------------------------------------------
+
    
+
    After top commentary, separated by one blank line, the greet
+function definition would look like the following:
+
    
+
    function greet {
+
+    # Define global variables.
+
+    # Define command-line interface.
+    greet_getActions
+
+}
+
    
+
    The first definition inside greet function, are global
+variables that will be available along greet function execution
+environment. This time we didn't use global variable definitions for
+greet function execution environment, so we left that section
+empty.
+
    
+
    Later, we call greet_getActions function to define the
+command-line interface of greet functionality. The command-line
+interface of greet functionality defines what and how actions
+are performed, based on arguments combination passed to
+`centos-art.sh' script.
+
    
+
    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
+
+}
+
    
+
    The ACTIONNAM global variable is defined in `cli.sh'
+function script and contains the value passed before the equal sign
+(i.e., `=') in the second command-line argument of
+`centos-art.sh' script. For example, if the second command-line
+argument is `--hello='World'', the value of ACTIONNAM
+variable would be `--hello'.  Using this configuration let us
+deside which action to perform based on the action name passed to
+`centos-art.sh' script as second argument. 
+
    
+
    The greet function definition makes available two valid
+greetings through `--hello' and `--bye' options.  If no
+one of them is provided as second command-line argument, the `*'
+case is evaluated instead. 
+
    
+
    The `*' case and its two lines further on should always be
+present in `_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 greet_doHello and greet_doBye function definitions
+are the core of greet specific functionality.  In such function
+definitions we set what our greet function really does: to
+output different kinds of greetings.
+
    
+
    function greet_doHello {
+
+    cli_printMessage "`gettext "Hello"` $ACTIONVAL"
+
+}
+
    
+
    The greet_doHello function definition is stored in
+`greet_doHello.sh' function script. 
+
    
+
    function greet_doBye {
+
+    cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
+
+}
+
    
+
    The greet_doBye function definition is stored in the
+`greet_doBye.sh' function script. 
+
    
+
    Both `greet_doHello.sh' and `greet_doBye.sh' function
+scripts are stored inside greet function directory path (i.e.
+`trunk/Scripts/Bash/Functions/Greet').
+
    
+
    The ACTIONVAL global variable is defined in `cli.sh'
+function script and contains the value passed after the equal sign
+(i.e., `=') in the second command-line argument of
+`centos-art.sh' script. For example, if the second command-line
+argument is `--hello='World'', the value of ACTIONVAL
+variable would be `World' without quotes.
+
    
+
    Let's see how greet specific functionality files are organzied
+under greet function directory. To see file organization we use
+the tree command:
+
    
+
    trunk/Scripts/Bash/Functions/Greet
+|-- greet_doBye.sh
+|-- greet_doHello.sh
+|-- greet_getActions.sh
+`-- greet.sh
+
    
+
    To try the greet specific functionality we've just created,
+pass the function name (i.e., `greet') as first argument to
+`centos-art.sh' script, and any of the valid options as second
+argument. Some examples are illustrated below:
+
    
+
    [centos@projects ~]$ centos-art greet --hello='World'
+Hello World
+[centos@projects ~]$ centos-art greet --bye='World'
+Goodbye World
+[centos@projects ~]$ 
+
    
+
    The word `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 greet specific functionality,
+we use its directory path and the manual functionality
+(-- Removed(pxref:trunk Scripts Bash Functions Manual) --) of `centos-art.sh'
+script, just as the following command illustrates: 
+
    
+
    centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
+
    
+
    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 `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 `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
+locale functionality (-- Removed(pxref:trunk Scripts Bash Functions
+Locale) --) of `centos-art.sh' script, just as the following command
+illustrates:
+
    
+
    centos-art locale --edit
+
    
+
    Warning
    Warning
     To translate output messages in different languages,
+your system locale information --as in 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
+`es_ES.UTF-8', or similar, first.
+
    
+
+
    Well, it seems that our example is rather complete by now. 
+
    
+
    In greet function example we've described so far, we only use
+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
+`--filter='regex'' and reduce the amount of files to process
+using a regular expression pattern.
+
    
+
    The greet function described in this section may serve you as
+an introduction to understand how specific functionalities work inside
+`centos-art.sh' script. With some of luck this introduction will
+also serve you as motivation to create your own `centos-art.sh'
+script specific functionalities.
+
    
+
    By the way, the greet functionality doesn't exist inside
+`centos-art.sh' script yet. Would you like to create it?
+
    
+
+
+
     2.64.3 Usage 
    
+
+
+
+
     2.64.3.1 Global variables 
    
+
+
    The following global variables of `centos-art.sh' script, are
+available for you to use inside specific functions:
+
    
+
    
+
    Variable: TEXTDOMAIN
+
+
    
+
    Default domain used to retrieve translated messages. This value is set
+in `initFunctions.sh' and shouldn't be changed.
+
    
+
+
    
+
    Variable: TEXTDOMAINDIR
+
+
    
+
    Default directory used to retrieve translated messages. This value is
+set in `initFunctions.sh' and shouldn't be changed.
+
    
+
+
    
+
    Variable: FUNCNAM
+
+
    
+
    Define function name.
+
    
+
    Function names associate sets of actions. There is one set of actions
+for each unique function name inside `centos-art.sh' script.
+
    
+
    Dunction names are passed as first argument in `centos-art.sh'
+command-line interface. For example, in the command `centos-art
+render --entry=path/to/dir --filter=regex', the ACTION passed to
+`centos-art.sh' script is `render'.
+
    
+
    When first argument is not provided, the `centos-art.sh' script
+immediatly ends its execution.
+
    
+
+
    
+
    Variable: FUNCDIR
+
+
    
+
    
+
+
    
+
    Variable: FUNCDIRNAME
+
+
    
+
    
+
+
    
+
    Variable: FUNCSCRIPT
+
+
    
+
    
+
+
    
+
    Variable: FUNCCONFIG
+
+
    
+
    
+
+
    
+
    Variable: 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
+`centos-art.sh' command-line interface. For example, in the
+command `centos-art render --entry=path/to/dir --filter=regex',
+the ACTIONNAM passed to `centos-art.sh' script is
+`--entry'.
+
    
+
    When second argument is not provided, the `centos-art.sh' script
+immediatly ends its execution.
+
    
+
+
    
+
    Variable: 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.
+
    
+
+
    
+
    Variable: REGEX
+
+
    
+
    Define regular expression used as pattern to build the list of files
+to process.
+
    
+
    By default, REGEX variable is set to .+ to match all
+files.
+
    
+
    Functions that need to build a list of files to process use the option
+`--filter' to redefine REGEX variable default value, and
+so, control the amount of files to process.
+
    
 
+
    
+
    Variable: ARGUMENTS
+
+
    
+
    Define optional arguments. 
+
    
+
    Optional arguments, inside `centos-art.sh' script, are considered
+as all command-line arguments passed to `centos-art.sh' script,
+from third argument position on. For example, in the command
+`centos-art render --entry=path/to/dir --filter=regex' , the
+optional arguments are from `--filter=regex' argument on.
+
    
+
    Optional arguments are parsed using getopt command through
+the following base construction: 
+
    
+
    # Define short options we want to support.
+local ARGSS=""
+
+# Define long options we want to support.
+local ARGSL="filter:,to:"
 
-
-
     2.67.3 Usage 
    
+# 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
+
    
+
    Optional arguments provide support to command options inside
+`centos-art.sh' script. For instance, consider the Subversion
+(svn) command, where there are many options (e.g.,
+`copy', `delete', `move', etc), and inside each
+option there are several modifiers (e.g., `--revision',
+`--message', `--username', etc.) that can be combined one
+another in their short or long variants. 
+
    
+
    The ARGUMENTS variable is used to store arguments passed from
+command-line for later use inside `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:
+
    
+
    centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
+
    
+
    In the above command, the `--message', and `--username'
+options are specific to svn copy command. In such cases,
+options are not interpreted by `centos-art.sh' script itself.
+Instead, the `centos-art.sh' script uses getopt to
+retrive them and store them in the ARGUMENTS variable for later
+use, as described in the following command:
+
    
+
    # Build subversion command to duplicate locations inside the
+# workstation.
+eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
+
    
+
    When getopt parses ARGUMENTS, we may use short options
+(e.g., `-m') or long options (e.g., `--message'). When
+we use short options, arguments are separated by one space from the
+option (e.g., `-m 'This is a commit message.'').  When we use
+long options arguments are separated by an equal sign (`=')
+(e.g., `--message='This is a commit message'').
+
    
+
    In order for getopt to parse 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 `centos-art.sh' script, short option
+definitions are set in the ARGSS variable; and long option
+definitions are set in the 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 `:'
+after the option definition (e.g., `-o m: -l message:').  On
+the other hand, to define an option argument as not required, you need
+to set two colons `::' after the option definition (e.g.,
+`-o m:: -l message::').
+
    
+
+
    
+
    Variable: EDITOR
+
+
    
+
    Default text editor. 
+
    
+
    The `centos-art.sh' script uses default text EDITOR to edit
+pre-commit subversion messages, translation files, configuration
+files, script files, and similar text-based files.
+
    
+
    If EDITOR environment variable is not set, `centos-art.sh'
+script uses `/usr/bin/vim' as default text editor. Otherwise, the
+following values are recognized by `centos-art.sh' script:
+
    
 
      
-
    •  ...
+
    •  `/usr/bin/vim'
+
    •  `/usr/bin/emacs'
+
    •  `/usr/bin/nano'
 
    
 
+
    If no one of these values is set in EDITOR environment variable,
+`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
+
    
+
+
+
+
     2.64.3.2 Global functions 
    
+
+
    Function scripts stored directly under
+`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 `centos-art.sh' script.
+
    
+
    
+
    Function: cli_checkActionArguments
+
+
    
+
    Validate action value (ACTIONVAL) variable.
+
    
+
    The action value variable can take one of the following values:
+
    
+
      
+
    1.  Path to one directory inside the local working copy,
+
    2.  Path to one file inside the local working copy,
+
    
+
+
    If another value different from that specified above is passed to
+action value variable, the `centos-art.sh' script prints an error
+message and ends script execution.
+
    
+
+
    
+
    Function: cli_checkFiles FILE [TYPE]
+
+
    
+
    Verify file existence.
+
    
+
    cli_checkFiles receives a FILE absolute path and performs
+file verification as specified in TYPE.  When TYPE is not
+specified, cli_checkFiles verifies FILE existence, no
+matter what kind of file it be.  If TYPE is specified, use one
+of the following values:
+
    
+
    
+
     `d'
    
+
     `directory'
    
+
    Ends script execution if FILE is not a directory.
+
    
+
    When you verify directories with cli_checkFiles, if directory doesn't
+exist, `centos-art.sh' script asks you for confirmation in order
+to create that directory. If you answer positively,
+`centos-art.sh' script creates that directory and continues
+script flows normally. Otherwise, if you answer negatively,
+`centos-art.sh' ends script execution with an error and
+documentation message.
+
    
+
    
+
     `f'
    
+
     `regular-file'
    
+
    Ends script execution if FILE is not a regular file.
+
    
+
     `h'
    
+
     `symbolic-link'
    
+
    Ends script execution if FILE is not a symbolic link.
+
    
+
     `x'
    
+
     `execution'
    
+
    Ends script execution if FILE is not executable.
+
    
+
     `fh'
    
+
    Ends script execution if FILE is neither a regular file nor a
+symbolic link.
+
    
+
     `fd'
    
+
    Ends script execution if FILE is neither a regular file nor a
+directory.
+
    
+
     `isInWorkingCopy'
    
+
    Ends script execution if FILE is not inside the working copy.
+
    
+
    
+
+
    As default behaviour, if FILE passes all verifications,
+`centos-art.sh' script continues with its normal flow. 
+
    
+
+
    
+
    Function: cli_commitRepoChanges [LOCATION]
+
+
    
+
    Syncronize changes between repository and working copy.
+
    
+
    The cli_commitRepoChanges function brings changes from the
+central repository down to the working copy--using svn
+update--, checks the working copy changes--using svn
+status command--, prints status report--using both svn
+update and svn status commands output, and finally, commits
+recent changes from the working copy up to the repository--using
+svn commit command--.
+
    
+
    Previous to commit the working copy changes up to the central
+repository, the cli_commitRepoChanges function asks you to
+verify changes--using svn diff command--, and later,
+another confirmation question is shown to be sure you really want to
+commit changes up to central repository.
+
    
+
    If LOCATION argument is not specified, the value of
+ACTIONVAL variable is used as reference instead.
+
    
+
    
+
    ----------------------------------------------------------------------
+--> 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.
+----------------------------------------------------------------------
+
    
+
    Figure 2.3: The cli_commitRepoChanges function output.
+
+
    
+
    Call the cli_commitRepoChanges function before or/and after
+calling functions that modify files or directories inside the working
+copy as you may need to.  
+
    
+
+
    
+
    Function: cli_doParseArguments
+
+
    
+
    Redefine arguments (ARGUMENTS) global variable using
+getopt command output. For more information about how to use
+cli_doParseArguments function, see ARGUMENTS variable
+description above.
+
    
+
+
    
+
    Function: cli_doParseArgumentsReDef $@
+
+
    
+
    Initialize/reset arguments (ARGUMENTS) global variable using
+positional parameters variable ($@) 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 cli_doParseArgumentsReDef with the positional
+parameters variable ($@), set as first argument, to that
+specific function you want to redefine positional parameters at.
+
    
+
+
    
+
    Function: cli_getArguments
+
+
    
+
    Initialize function name (FUNCNAM), action name
+(ACTIONNAM), and action value (ACTIONVAL) global
+variables, using positional parameters passed in $@ variable.
+
    
+
    The cli_getArguments function is called from cli.sh
+function script, using 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
+`centos-art.sh' script execution evironment,
+cli_getArguments uses regular expression to retrive
+action variables from first and second argument. The first argument
+defines the value used as function name (FUNCNAM), and the
+second argument defines both values used as action name
+(ACTIONNAM) and action value (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., `render' to
+render images, `manual' to work on documentation, and so on.)
+
    
+
    The second argument has a long option style (e.g.,
+`--option=value'). The `--option' represents the action name
+(ACTIONNAM), and the characters inbetween the equal sign
+(`=') and the first space character, are considered as the action
+value (ACTIONVAL). In order to provide action values with space
+characters inbetween you need to enclose action value with quotes like
+in `--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., FUNCNAM, ACTIONNAM,
+and ACTIONVAL) are defined and validated,
+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 (ARGUMENTS) global
+variable with the new positional parameters information.
+
    
+
+
    
+
    Function: cli_getFunctions
+
+
    
+
    Initialize funtionalities supported by `centos-art.sh' script.
+
    
+
    Functionalities supported by `centos-art.sh' script are organized
+in functionality directories under
+`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 `centos-art.sh' script to recognize a functionality,
+such functionality needs to be stored under
+`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 `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 `camelCase'
+format with the function name as prefix.  Separation between prefix
+and description is done using underscore (`_') character.
+
    
+
    In order for `centos-art.sh' script to load functionalities
+correctly, function definition inside function scripts should be set
+using the `function' reserved word, just as in the following
+example:
+
    
+
    function prefix_doSomething {
+
+    # Do something here...
+
+}
+
    
+
    The above function definition is just a convenction we use, in order
+to make identification of function names easier read and automate by
+`centos-art.sh' script initialization commands, once
+`centos-art.sh' script determines which functionality directory
+to use.  Specifically, in order to initialize and export functions,
+`centos-art.sh' script executes all function scripts inside the
+functionality directory, and later grep on them using a
+regular expression pattern, where the `function' reserved word is
+used as reference to retrive the function names and export them to
+`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, `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:
+
    
+
    #!/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...
+
+}
+
    
+
+
    
+
    Function: cli_getCountryCodes [FILTER]
+
+
    
+
    Output country codes supported by `centos-art.sh' script. 
+
    
+
    The cli_getCountryCodes function outputs a list with country
+codes as defined in ISO3166 standard. When FILTER is provided,
+cli_getCountryCodes outputs country codes that match
+FILTER regular expression pattern.
+
    
+
+
    
+
    Function: cli_getCountryName [FILTER]
+
+
    
+
    Outputs country name supported by `centos-art.sh' script.
+
    
+
    The 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, cli_getCountryName returns the
+country name that matches the locale code specified in FILTER,
+exactly.
+
    
+ 
+
    
+
    Function: cli_getCurrentLocale
+
+
    
+
    Output current locale used by `centos-art.sh' script. 
+
    
+
    The cli_getCurrentLocale function uses LANG environment
+variable to build a locale pattern that is later applied to
+cli_getLocales function output in order to return the current
+locale that `centos-art.sh' script works with. 
+
    
+
    The current locale information, returned by
+cli_getCurrentLocale, is output from more specific to less
+specific. For example, if `en_GB' locale exists in
+cli_getLocales function output, the `en_GB' locale would
+take precedence before `en' locale.
+
    
+
    Locale precedence selection is quite important in order to define the
+locale type we use for message translations. For example, if
+`en_GB' is used, we are also saying that the common language
+specification for English language (i.e., `en') is no longer
+used. Instead, we are using English non-common country-specific
+language specifications like `en_AU', `en_BW', `en_GB',
+`en_US', etc., for message translations.  
+
    
+
    Use cli_getCurrentLocale function to know what current locale
+information to use inside `centos-art.sh' script.
+
    
+
+
    
+
    Function: cli_getFilesList [LOCATION]
+
+
    
+
    Output list of files to process.
+
    
+
    The cli_getFilesList function uses LOCATION variable as
+source location to build a list of files just as specified by regular
+expression (REGEX) global variable. Essentially, what the
+cli_getFilesList function does is using find command
+to look for files in the location (LOCATION) just as posix-egrep
+regular expression (REGEX) specifies. 
+
    
+
    If LOCATION is not specified when cli_getFilesList
+function is called, the action value (ACTIONVAL) global variable
+is used as location value instead.
+
    
+
    By default, if the regular expression (REGEX) global variable is
+not redefined after its first definition in the cli function,
+all files that match default regular expression value (i.e.,
+`.+') 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 cli function and before calling
+cli_getFilesList function, the last value you specifed is used
+instead.
+
    
+
    When you need to customize the regular expression (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 `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 cli_getFilesList re-defines the value of
+FILES variable with the list of files the find command
+returned. As example, consider the following construction:
+
    
+
    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
+
+}
+
    
+
    
+
+
    
+
    Function: cli_getLangCodes [FILTER]
+
+
    
+
    Outputs language codes supported by `centos-art.sh' script.
+
    
+
    cli_getLangCodes function outputs a list of language codes as
+defined in ISO639 standard. When FILTER is provided,
+cli_getLangCodes outputs language codes that match FILTER
+regular expression pattern.
+
    
+
+
    
+
    Function: cli_getLangName [FILTER]
+
+
    
+
    Outputs language names supported by `centos-art.sh' script.
+
    
+
    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, cli_getLangName returns the language name
+that matches the locale code specified in FILTER, exactly.
+
    
+
+
    
+
    Function: cli_getLocales
+
+
    
+
    Output locale codes supported by `centos-art.sh' script.
+
    
+
    Occasionally, you use cli_getLocales function to add locale
+information in non-common country-specific language (`LL_CC')
+format for those languages (e.g., `bn_IN', `pt_BR', etc.)
+which locale differences cannot be solved using common language
+specifications (`LL') into one unique common locale specification
+(e.g., `bn', `pt', etc.).  
+
    
+
+
    
+
    Function: cli_getRepoName NAME TYPE
+
+
    
+
    Sanitate file names.
+
    
+
    Inside `centos-art.sh' script, specific functionalities rely both
+in cli_getRepoName and repository file system organization to
+achieve their goals.  Consider cli_getRepoName function as
+central place to manage file name convenctions for other functions
+inside `centos-art.sh' script.
+
    
+
    Important
    Important
     cli_getRepoName function doesn't verify file
+or directory existence, for that purpose use cli_checkFiles
+function instead.
+
    
+
+
    The NAME variable contains the file name or directory name you
+want to sanitate.
+
    
+
    The TYPE variable specifies what type of sanitation you want to
+perform on NAME. The TYPE can be one of the following
+values:
+
    
+
    
+
     `d'
    
+
     `directory'
    
+
    Sanitate directory NAMEs.
+
    
+
     `f'
    
+
     `regular-file'
    
+
    Sanitate regular file NAMEs.
+
    
+
    
+
+
    Use cli_getRepoName function to sanitate file names and
+directory names before their utilization. 
+
    
+
    Use cli_getRepoName when you need to change file name
+convenctions inside `centos-art.sh' script. 
+
    
+
    When we change file name convenctions inside 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 (-- Removed(pxref:trunk Scripts Bash Functions Path) --, for more
+information).
+
    
+
+
    
+
    Function: cli_getRepoStatus [LOCATION]
+
+
    
+
    Request repository status.
+
    
+
    This function requests the status of a LOCATION inside the
+working copy using the svn status command and returns the
+first character in the output line, just as described in svn
+help status. If LOCATION is not a regular file or a directory,
+inside the working copy, the `centos-art.sh' script prints a
+message and ends its execution.
+
    
+
    Use this function to perform verifications based a repository
+LOCATION status.
+
    
+
+
    
+
    Function: cli_getTemporalFile NAME
+
+
    
+
    Output absolute path to temporal file NAME.
+
    
+
    The cli_getTemporalFile function uses `/tmp' directory as
+source location to store temporal files, the `centos-art.sh'
+script name, and a random identification string to let you run more
+than one `centos-art.sh' script simultaneously on the same user
+session.  For example, due the following temporal file defintion:
+
    
+
    cli_getTemporalFile $FILE
+
    
+
    If FILE name is `instance.svg' and the unique random string
+is `f16f7b51-ac12-4b7f-9e66-72df847f12de', the final temporal
+file, built from previous temporal file definition, would be:
+
    
+
    /tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
+
    
+
    When you use the 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:
+
    
+
    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
+
    
+
    Use the cli_getTemporalFile function whenever you need to
+create temporal files inside `centos-art.sh' script.
+
    
+
+
    
+
    Function: cli_getThemeName
+
+
    
+
    Output theme name.
+
    
+
    In order for cli_getThemeName function to extract theme name
+correctly, the ACTIONVAL variable must contain a directory path
+under `trunk/Identity/Themes/Motifs/' directory structure.
+Otherwise, cli_getThemeName returns an empty string.  
+
    
+
+
    
+
    Function: cli_printMessage MESSAGE [FORMAT]
+
+
    
+
    Define standard output message definition supported by
+`centos-art.sh' script.
+
    
+
    When FORMAT is not specified, cli_printMessage outputs
+information just as it was passed in MESSAGE variable.
+Otherwise, FORMAT can take one of the following values:
+
    
+
    
+
     `AsHeadingLine'
    
+
    To print heading messages.
+
    ----------------------------------------------------------------------
+$MESSAGE
+----------------------------------------------------------------------
+
    
+
    
+
     `AsWarningLine'
    
+
    To print warning messages.
+
    ----------------------------------------------------------------------
+WARNING: $MESSAGE
+----------------------------------------------------------------------
+
    
+
    
+
     `AsNoteLine'
    
+
    To print note messages.
+
    ----------------------------------------------------------------------
+NOTE: $MESSAGE
+----------------------------------------------------------------------
+
    
+
    
+
     `AsUpdatingLine'
    
+
    To print `Updating' messages on two-columns format.
+
    Updating        $MESSAGE
+
    
+
    
+
     `AsRemovingLine'
    
+
    To print `Removing' messages on two-columns format.
+
    Removing        $MESSAGE
+
    
+
    
+
     `AsCheckingLine'
    
+
    To print `Checking' messages on two-columns format.
+
    Checking        $MESSAGE
+
    
+
    
+
     `AsCreatingLine'
    
+
    To print `Creating' messages on two-columns format.
+
    Creating        $MESSAGE
+
    
+
    
+
     `AsSavedAsLine'
    
+
    To print `Saved as' messages on two-columns format.
+
    Saved as        $MESSAGE
+
    
+
    
+
     `AsLinkToLine'
    
+
    To print `Linked to' messages on two-columns format.
+
    Linked to       $MESSAGE
+
    
+
    
+
     `AsMovedToLine'
    
+
    To print `Moved to' messages on two-columns format.
+
    Moved to        $MESSAGE
+
    
+
    
+
     `AsTranslationLine'
    
+
    To print `Translation' messages on two-columns format.
+
    Translation     $MESSAGE
+
    
+
    
+
     `AsConfigurationLine'
    
+
    To print `Configuration' messages on two-columns format.
+
    Configuration   $MESSAGE
+
    
+
    
+
     `AsResponseLine'
    
+
    To print response messages on one-column format.
+
    --> $MESSAGE
+
    
+
    
+
     `AsRequestLine'
    
+
    To print request messages on one-column format. Request messages
+output messages with one colon (`:') and without trailing newline
+(`\n') at message end.
+
    $MESSAGE:
+
    
+
    
+
     `AsYesOrNoRequestLine'
    
+
    To print `yes or no' request messages on one-column format. If
+something different from `y' is answered (when using
+en_US.UTF-8 locale), script execution ends immediatly.  
+
    
+
    $MESSAGE [y/N]:
+
    
+
    When we use `centos-art.sh' script in a locale different from
+en_US.UTF-8, confirmation answer may be different from
+`y'. For example, if you use es_ES.UTF-8 locale, the
+confirmation question would look like:
+
    
+
    $MESSAGE [s/N]:
+
    
+
    and the confirmation answer would be `s', as it is on Spanish
+`sí' word.
+
    
+
    Definition of which confirmation word to use is set on translation
+messages for your specific locale information. -- Removed(xref:trunk Scripts
+Bash Functions Locale) --, for more information about locale-specific
+translation messages.
+
    
+
    
+
     `AsToKnowMoreLine'
    
+
    To standardize `to know more, run the following command:'
+messages. When the `AsToKnowMoreLine' option is used, the
+MESSAGE value should be set to "$(caller)". caller
+is a Bash builtin that returns the context of the current subroutine
+call. `AsToKnowMoreLine' option uses caller builtin
+output to build documentation entries dynamically.
+
    
+
    ----------------------------------------------------------------------
+To know more, run the following command:
+centos-art manual --read='path/to/dir'
+----------------------------------------------------------------------
+
    
+
    Use `AsToKnowMoreLine' option after errors and for intentional
+script termination. 
+
    
+
    
+
     `AsRegularLine'
    
+
    To standardize regular messages on one-column format. 
+
    
+
    When MESSAGE contains a colon inside (e.g., `description:
+message'), the cli_printMessage function outputs MESSAGE
+on two-columns format. 
+
    
+
    
+
+
    Use cli_printMessage function whenever you need to output
+information from `centos-art.sh' script.
+
    
+
    Info
    Tip
     To improve two-columns format, change the following file:
+
    trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
+
    
+
    
+
+
+
+
     2.64.3.3 Specific functions 
    
+
+
    The following specific functions of `centos-art.sh' script, are
+available for you to use:
+
    
+
 
-
-
     2.67.4 See also 
    
+
+
     2.64.4 See also 
    
 
+
+
+
    2.62 The `trunk/Scripts/Bash' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_72.html b/Manual/repository-html/repository_72.html
index 9c55fc6..2ec8d70 100644
--- a/Manual/repository-html/repository_72.html
+++ b/Manual/repository-html/repository_72.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.68 The trunk/Scripts/Bash/Cli/Functions/Locale Directory
+CentOS Artwork Repository: 2.65 The trunk/Scripts/Bash/Cli/Functions/Help Directory
 
-
-
+
+
 
 
 
@@ -55,131 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory 
    
+
+
+
     2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory 
    
 
 
-
-
     2.68.1 Goals 
    
+
+
     2.65.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.68.2 Description 
    
-
-
    This command looks for `.sh' files inside Bash directory and
-extracts translatable strings from files, using xgettext
-command, in order to create a portable object template
-(`centos-art.sh.pot') file for them.
-
    
-
    With the `centos-art.sh.pot' file up to date, the
-centos-art command removes the temporal list of files sotred
-inside `/tmp' directory and checks the current language of your
-user's session to create a portable object file for it, in the
-location `$CLI_LANG/$CLI_LANG.po'. 
-
    
-
    The CLI_LANG variable discribes the locale language used to
-output messages inside centos-art command. The locale
-language used inside centos-art command is taken from the
-LANG environment variable.  The CLI_LANG variable has the
-`LL_CC' format, where `LL' is a language code from the
-ISO-639 standard, and `CC' a country code from the ISO-3166
-standard.
-
    
-
    The 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 LANG
-environment variable to the correct value. On the other side, if you
-are using a text session edit your `~/.bash_profile' file to set
-and export the LANG environment variable to your native locale
-as defines the locale -a command output; do logout, and do
-login again.
-
    
-
    At this point, the LANG environment variable has the appropriate
-value you need, in order to translate centos-art.sh messages
-to your native language (the one set in LANG environment
-variable). 
-
    
-
    With the `$CLI_LANG/$CLI_LANG.po' file up to date, the
-centos-art opens it for you to update translation strings.
-The centos-art command uses the value of EDITOR
-environment variable to determine your favorite text editor. If no
-value is defined on EDITOR, the `/usr/bin/vim' text editor
-is used as default.
-
    
-
    When you finishd PO file edition and quit text editor, the
-centos-art command creates the related machine object in the
-location `$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 centos-art.sh script. 
-
    
-
    In order to make the centos-art.sh internationalization, the
-centos-art.sh script was modified as described in the
-gettext info documentation (info gettext).  You
-can find such modifications in the following files:
-
    
-
      
-
    •  `trunk/Scripts/Bash/initFunctions.sh'
-
    •  `trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh'
-
    •  `trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh'
-
    
+
+
     2.65.2 Description 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.68.3 Usage 
    
+
+
     2.65.3 Usage 
    
 
-
    
-
     `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 LANG
-environment variable).
-
    
-
     `centos-art locale --list'
    
-
    Use this command to see the command-line interface locale report.
-
    
-
    
+
      
+
    •  ...
+
    
 
 
-
-
     2.68.4 See also 
    
+
+
     2.65.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_73.html b/Manual/repository-html/repository_73.html
index 1484be1..bbe91f0 100644
--- a/Manual/repository-html/repository_73.html
+++ b/Manual/repository-html/repository_73.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.69 The trunk/Scripts/Bash/Cli/Functions/Manual Directory
+CentOS Artwork Repository: 2.66 The trunk/Scripts/Bash/Cli/Functions/Html Directory
 
-
-
+
+
 
 
 
@@ -55,66 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory 
    
+
+
+
     2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory 
    
 
 
-
-
     2.69.1 Goals 
    
+
+
     2.66.1 Goals 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.69.2 Description 
    
+
+
     2.66.2 Description 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.69.3 Usage 
    
+
+
     2.66.3 Usage 
    
 
 
      
 
    •  ...
 
    
 
 
-
-
     2.69.4 See also 
    
+
+
     2.66.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_74.html b/Manual/repository-html/repository_74.html
index 9fbcde9..adf1f0e 100644
--- a/Manual/repository-html/repository_74.html
+++ b/Manual/repository-html/repository_74.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.70 The trunk/Scripts/Bash/Cli/Functions/Path Directory
+CentOS Artwork Repository: 2.67 The trunk/Scripts/Bash/Cli/Functions/Identity Directory
 
-
-
+
+
 
 
 
@@ -55,383 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory 
    
+
+
+
     2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory 
    
 
 
-
-
     2.70.1 Goals 
    
+
+
     2.67.1 Goals 
    
 
-
    This section exists to organize files related to path
-functiontionality.  The path functionality standardizes
-movement, syncronization, branching, tagging, and general file
-maintainance inside the repository. 
-
    
-
-
-
     2.70.2 Description 
    
-
-
    "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."
-
    
+
      
+
    •  ...
+
    
 
-
-
     2.70.2.1 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: `trunk/', `branches/',
-and `tags/'. 
-
    
-
    The `trunk/' directory (see section The `trunk' Directory) organizes the main
-development line of CentOS corporate visual identity. Inside
-`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
-`trunk/' directory structure is mainly used to perform
-development tasks related to CentOS corporate visual identity.
-
    
-
    The `branches/' directory () oranizes
-parallel development lines to `trunk/' directory. The
-`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 `branches/' directory is mainly used to perform
-quality assurance tasks related to CentOS corporate visual identity.
-
    
-
    The `tags/' directory (see section The `tags' Directory) organizes parallel frozen
-lines to `branches/' directory.  The parallel frozen lines are
-immutable, nothing change inside them once they has been created.  The
-`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 (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.
-
    
+
+
     2.67.2 Description 
    
 
-
-
     2.70.2.2 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
-(`01-welcome.png', `splash.png', `anaconda_header.png',
-etc.) and directory names are all written capitalized (e.g.,
-`Identity', `Themes', `Motifs', `TreeFlower',
-etc.).
-
    
-
    Repository name convenctions are implemented inside the
-cli_getRepoName function of `centos-art.sh' script. With
-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.
-
    
 
-
-
     2.70.2.3 Repository work flow 
    
+
+
     2.67.3 Usage 
    
 
-
    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., `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.,
-`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 `tags/' directory (e.g.,
-`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., `1') and increment one unit for each
-branch created from the same trunk development line.  Tags start at
-zero (i.e., `0') and increment one unit for each tag created from
-the same branch development line.
-
    
-
    Convenction
    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.
-
    
-
-
    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 `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.
-
    
-
-
-
     2.70.2.4 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 `trunk/Identity' location.  The
-`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
-`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory
-structure, the `centos-art.sh' script removes the
-`Motifs/TreeFlower/' directory levels from path, in order to
-build the parallel directory used to retrived translations, and
-pre-rendering configuration scripts required by render
-functionality.
-
    
-
    Another example of parallel directory is the documentation structure
-created by manual functionality. This time,
-`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.
-
    
-
-
-
     2.70.2.5 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 manual (`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 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 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 (`trunk/Manuals') and change what must be
-changed to match the new parent directory structure.
-
    
-
    There is no immediate way for 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.
-
    
-
    Warning
    Warning
     There is not support for URL reference inside
-`centos-art.sh' script.  The `centos-art.sh' script is
-designed to work with local files inside the working copy only.
-
    
-
-
    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
-`centos-art.sh' script needs to know when such changes happen, in
-a way they could be noted and handled without producing errors.
-
    
-
-
-
     2.70.2.6 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:
-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 (see section The `trunk/Identity' Directory) 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
-`trunk/Identity/Themes/Motifs/TreeFlower' directory as example.
-It is the trunk development line of 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 `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
-`trunk/Identity/Themes/Distro/Motifs/TreeFlower' location are
-described in the following commands, respectively:
-
    
-
    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/
-
    
-
    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.
-
    
-
-
-
     2.70.3 Usage 
    
-
-
    
-
     centos-art path --copy='SRC' --to='DST'
    
-
    
-
    Copy `SRC' to `DST' and schedule `DST' for
-addition (with history).  In this command, `SRC' and `DST'
-are both working copy (WC) entries.
-
    
-
    
-
     centos-art path --delete='SRC'
    
-
    
-
    Delete `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, `SRC' is a working copy (WC) entry.  
-
    
-
    
-
    
+
      
+
    •  ...
+
    
 
 
-
-
     2.70.4 See also 
    
+
+
     2.67.4 See also 
    
 
-
-
-
    2.62 The `trunk/Scripts/Bash' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_75.html b/Manual/repository-html/repository_75.html
index 71af0db..0a633b2 100644
--- a/Manual/repository-html/repository_75.html
+++ b/Manual/repository-html/repository_75.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.71 The trunk/Scripts/Bash/Cli/Functions/Render Directory
+CentOS Artwork Repository: 2.68 The trunk/Scripts/Bash/Cli/Functions/Locale Directory
 
-
-
+
+
 
 
 
@@ -55,767 +55,131 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory 
    
+
+
+
     2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory 
    
 
-
    The render functionality exists to produce both identity and
-translation files on different levels of information (i.e., different
-languages, release numbers, architectures, etc.).
-
    
-
    The 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.
-
    
-
-
-
     2.71.1 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 `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, `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).
-
    
 
-
-
     2.71.1.1 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:
-
    
-
    
-
     One renderable identity directory structure:
    
-
    
-
    In this example we used `Identity/Path/To/Dir' as the identity
-component we want to produce untranslated images for.  Identity
-components can be either under `trunk/' or `branches/'
-directory structure.
-
    
-
    The identity component (i.e., `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
-`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.
-
    
-
          | 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.
-
    
-
    Inside design template directory, design template files are based on
-SVG (Scalable Vector Graphics) and use the extension
-.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 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 CENTOSARTWORK
-object id inside.
-
    
-
    The CENTOSARTWORK word itself is a convenction name we use to
-define which object/design area, inside a design template, the
-`centos-art.sh' script will use to export as
-PNG (Portable Network Graphic) image at rendition time.
-Whithout such object id specification, the `centos-art.sh' script
-cannot know what object/design area you (as designer) want to export
-as PNG (Portable Network Graphic) image file.
-
    
-
    info
    Note
     At rendition time, the content of `Img/' directory
-structure is produced by `centos-art.sh' automatically.
-
    
+
+
     2.68.1 Goals 
    
 
-
    When a renderable identity directory structure is configured to
-produce image-based content, `centos-art.sh' produces
-PNG (Portable Network Graphics) files with the .png
-extension. Once the base image format has been produced, it is
-possible for `centos-art.sh' to use it in order to automatically
-create other image formats that may be needed (-- Removed(pxref:trunk Scripts
-Bash Functions Render Config) --).
-
    
-
    Inside the working copy, you can find an example of "design template
-without translation" configuration at `trunk/Identity/Models/'.
-
    
-
    See section The `trunk/Identity' Directory, for more information.
-
    
-
    
-
     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),
-`centos-art.sh' interprets the identity renderable directory
-structure as a "design templates without translation" configuration.
-
    
-
                       | The bond component
-                   |----------------->|
-trunk/Translations/Identity/Path/To/Dir
-`-- (empty)
-
    
-
    If the translation entry is not empty, `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 (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, one
-translation files is applied to one design template, to produce
-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.
-
    
-
    -- Removed(xref:trunk Translations) --, for more information.
-
    
-
    
-
     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 `centos-art.sh' will perform over the identity directory
-structure and how does it do that.
-
    
-
                                               | The bond component
-                                           |----------------->|
-trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-
    
-
    In this configuration the pre-rendition configuration script
-(`render.conf.sh') would look like the following:
-
    
-
    function render_loadConfig {
+
      
+
    •  ...
+
    
 
-    # Define rendition actions.
-    ACTIONS[0]='BASE:renderImage'
 
-}
-
    
-
    Since translation directory structure is empty, `centos-art.sh'
-assumes a "design template without translation" configuration to
-produce untranslated images.
-
    
-
    To produce untranslated images, `centos-art.sh' takes one design
-template and creates one temporal instance from it.  Later,
-`centos-art.sh' uses the temporal design template instance as
-source file to export the final untranslated image. The action of
-exporting images from SVG (Scalable Vector Graphics) to
-PNG (Portable Network Graphics) is possible thanks to
-Inkscape's command-line interface and the CENTOSARTWORK object
-id we previously set inside design templates.
+
+
     2.68.2 Description 
    
+
+
    This command looks for `.sh' files inside Bash directory and
+extracts translatable strings from files, using xgettext
+command, in order to create a portable object template
+(`centos-art.sh.pot') file for them.
+
    
+
    With the `centos-art.sh.pot' file up to date, the
+centos-art command removes the temporal list of files sotred
+inside `/tmp' directory and checks the current language of your
+user's session to create a portable object file for it, in the
+location `$CLI_LANG/$CLI_LANG.po'. 
+
    
+
    The CLI_LANG variable discribes the locale language used to
+output messages inside centos-art command. The locale
+language used inside centos-art command is taken from the
+LANG environment variable.  The CLI_LANG variable has the
+`LL_CC' format, where `LL' is a language code from the
+ISO-639 standard, and `CC' a country code from the ISO-3166
+standard.
+
    
+
    The 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 LANG
+environment variable to the correct value. On the other side, if you
+are using a text session edit your `~/.bash_profile' file to set
+and export the LANG environment variable to your native locale
+as defines the locale -a command output; do logout, and do
+login again.
+
    
+
    At this point, the LANG environment variable has the appropriate
+value you need, in order to translate centos-art.sh messages
+to your native language (the one set in LANG environment
+variable). 
+
    
+
    With the `$CLI_LANG/$CLI_LANG.po' file up to date, the
+centos-art opens it for you to update translation strings.
+The centos-art command uses the value of EDITOR
+environment variable to determine your favorite text editor. If no
+value is defined on EDITOR, the `/usr/bin/vim' text editor
+is used as default.
+
    
+
    When you finishd PO file edition and quit text editor, the
+centos-art command creates the related machine object in the
+location `$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 centos-art.sh script. 
+
    
+
    In order to make the centos-art.sh internationalization, the
+centos-art.sh script was modified as described in the
+gettext info documentation (info gettext).  You
+can find such modifications in the following files:
 
    
-
    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.
-
    
-
    Finally, when the untranslated image has been created, the temporal
-design template instance is removed. At this point,
-`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.
-
    
-
    -- Removed(xref:trunk Scripts Bash Functions Render Config) --, for more
-information.
-
    
-
    
-
-
-
-
     2.71.1.2 Design template with translation (one-to-one) 
    
+
      
+
    •  `trunk/Scripts/Bash/initFunctions.sh'
+
    •  `trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh'
+
    •  `trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh'
+
    
 
-
    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 `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,
-`centos-art.sh' will not produce the final image related to the
-missing component.
-
    
-
    In order for `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
-`trunk/Translations/Identity/Path/To/Dir/file.sed' translation
-file does match `trunk/Identity/Path/To/Dir/Tpl/file.svg' design
-template, but it doesn't match
-`trunk/Identity/Path/To/Dir/File.svg' or
-`trunk/Identity/Path/To/Dir/Tpl/File.svg' or
-`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.
-
    
-
    info
    Note
     If we use no translation file in the translation entry
-(i.e., an empty directory), `centos-art.sh' assumes the
-untranslated image production. If we fill the translation entry with
-translation files, `centos-art.sh' assumes the translated image
-production.  
-
    
+
      
+
    •  ...
+
    
 
-
    To produce final images, `centos-art.sh' applies one translation
-file to one design template and produce a translated design template
-instance. Later, `centos-art.sh' uses the translated template
-instance to produce the translated image. Finally, when the translated
-image has been produced, `centos-art.sh' removes the translated
-design template instance. This production flow is repeated for each
-translation file available in the translatio entry. 
-
    
-
    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.
-
    
 
-
-
     2.71.1.3 Design template with translation (optimized) 
    
+
+
     2.68.3 Usage 
    
 
-
    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 (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 MATCHINGLIST variable is set in the pre-rendition
-configuration script of the component we want to produce images for.
-By default, the MATCHINGLIST variable is empty which means no
-matching list is used. Otherwise, if MATCHINGLIST variable has a
-value different to empty value then, `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:
-
    
 
    
-
     One entry under `trunk/Identity/':
    
-
    
-
    In this configuration we want to produce three images using a
-paragraph-based style, controlled by `paragraph.svg' design
-template; and one image using a list-based style, controlled by
-`list.svg' design template.
-
    
-
    trunk/Identity/Path/To/Dir
-|-- Tpl
-|   |-- paragraph.svg
-|   `-- list.svg
-`-- Img
-    |-- 01-welcome.png
-    |-- 02-donate.png
-    |-- 03-docs.png
-    `-- 04-support.png
-
    
-
    
-
     One entry under `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.
-
    
-
    trunk/Translations/Identity/Path/To/Dir
-|-- 01-welcome.sed
-|-- 02-donate.sed
-|-- 03-docs.sed
-`-- 04-support.sed
-
    
-
    
-
     One entry under `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 `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 MATCHINGLIST variable inside the pre-rendition
-configuration script of the component we want to produce images for.  
-
    
-
    trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-
    
-
    In this configuration the pre-rendition configuration script
-(`render.conf.sh') would look like the following:
-
    
-
    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
-    "
-
-}
-
    
-
    As result, `centos-art.sh' will produce `01-welcome.png',
-`02-donate.png' and `04-support.png' using the
-paragraph-based design template, but `03-docs.png' using the
-list-based design template.
+
     `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 LANG
+environment variable).
+
    
+
     `centos-art locale --list'
    
+
    Use this command to see the command-line interface locale report.
 
    
 
    
 
 
-
-
     2.71.1.4 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 almost does.
-
    
-
    Generally, we use design templates to define how final images will
-look like. Generally, each renderable directory structure has one
-`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
-`centos-art.sh'. 
-
    
-
    For example, consider the following configuration:
-
    
-
    
-
     One entry under `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 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.
-
    
-
                            THEMEMODEL | | The bond component
-                             |<----| |--------------------->|
-trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
-|-- paragraph.svg
-`-- list.svg
-
    
-
    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.
-
    
-
    
-
     One entry under `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
-`centos-art.sh' (e.g., Backgrounds, Color information,
-Screenshots, etc.).
-
    
-
                      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
-
    
-
    
-
     One entry under `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.
-
    
-
                                       | 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
-
    
-
    
-
     One entry under `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
-`centos-art.sh' how to render the component.
-
    
-
    trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
-`-- render.conf.sh
-
    
-
    In this configuration the pre-rendition configuration script
-(`render.conf.sh') would look like the following:
-
    
-
    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'
-
-}
-
    
-
    
-
-
    The production flow of "optimize+flexibility" configuration…
-
    
-
-
     2.71.2 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
-(`Tpl/') directory structure to handle common content inside
-translation files.  This way, we work on translation templates and
-later use `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 `centos-art.sh' is executed to produce translation files
-from translation templates.
-
    
-
    Inside renderable translation directory structures,
-`centos-art.sh' can produce text-based files only.
-
    
-
-
-
     2.71.3 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:
-
    
-
      
-
    1.  To have a unique directory structure under
-`trunk/Identity', organized by any one of the above
-organizational designs above.
-
-
    2.  To have a unique directory structure under
-`trunk/Translations' to store translation files.
-
-
    3.  To have a unique directory structure under
-`trunk/Scripts/Bash/Functions/Render/Config' to set pre-rendition
-configuration script.
-
    
-
-
    As convenction, the render_doCopy function uses
-`trunk/Identity' directory structure as source location.  Once
-the `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 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. 
-
    
-
-
-
     2.71.4 Usage 
    
-
-
      
-
    •  ...
-
    
-
-
-
-
     2.71.5 See also 
    
+
+
     2.68.4 See also 
    
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_76.html b/Manual/repository-html/repository_76.html
index 7aed682..e13170c 100644
--- a/Manual/repository-html/repository_76.html
+++ b/Manual/repository-html/repository_76.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.72 The trunk/Scripts/Bash/Cli/Functions/Render/Config Directory
+CentOS Artwork Repository: 2.69 The trunk/Scripts/Bash/Cli/Functions/Manual Directory
 
-
-
+
+
 
 
 
@@ -55,233 +55,66 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory 
    
+
+
+
     2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory 
    
 
 
-
-
     2.72.1 Goals 
    
+
+
     2.69.1 Goals 
    
 
-
    The `trunk/Scripts/Bash/Config' directory exists to oraganize
-pre-rendering configuration scripts.
-
    
-
-
-
     2.72.2 Description 
    
-
-
    Pre-rendering configuration scripts let you customize the way
-centos-art.sh script renders identity and translation
-repository entries.  Pre-rendering configuration scripts are
-`render.conf.sh' files with render_loadConfig function
-definition inside. 
-
    
-
    There is one `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. 
-
    
-
-
-
     2.72.2.1 The `render.conf.sh' identity model 
    
-
-
    Inside CentOS Artwork Repository, we consider identity entries to all
-directories under `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:
-
    
-
    #!/bin/bash
-
-function render_loadConfig {
-
-    # Define rendering actions.
-    ACTIONS[0]='BASE:renderImage'
-    ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
-
-}
-
    
-
    Inside identity pre-rendering configuration scripts, text-based
-pre-rendering configuration scripts look like the following:
-
    
-
    #!/bin/bash
-
-function render_loadConfig {
-
-    # Define rendering actions.
-    ACTIONS[0]='BASE:renderText'
-    ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
-
-}
-
    
-
    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. 
-
    
+
      
+
    •  ...
+
    
 
-
-
     2.72.2.2 The `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.
-
    
+
+
     2.69.2 Description 
    
 
-
-
     2.72.2.3 The `render.conf.sh' rendering actions 
    
+
      
+
    •  ...
+
    
 
-
    Inside both image-based and text-based identity pre-rendering
-configuration scripts, we use the `ACTIONS' array variable to
-define the way centos-art.sh script performs identity
-rendering.  Identity rendering is organized by one `BASE' action,
-and optional `POST' and `LAST' rendering actions.
-
    
-
    The `BASE' action specifies what kind of rendering does the
-centos-art.sh script will perform with the files related to
-the pre-rendering configuration script. The `BASE' action is
-required. Possible values to `BASE' action are either
-`renderImage' or `renderText' only.
-
    
-
    To specify the `BASE' action you need to set the `BASE:'
-string followed by one of the possible values. For example, if you
-want to render images, consider the following definition of
-`BASE' action:
-
    
-
    ACTIONS[0]='BASE:renderImage'
-
    
-
    Only one `BASE' action must be specified. If more than one
-`BASE' action is specified, the last one is used. If no
-`BASE' action is specified at all, an error is triggered and the
-centos-art.sh script ends its execution.
-
    
-
    The `POST' action specifies which action to apply for
-each file rendered (at the rendering time). This action is optional.
-You can set many different `POST' actions to apply many different
-actions over the same already rendered file. Possible values to
-`POST' action are `renderFormats', `renderSyslinux',
-`renderGrub', etc. 
-
    
-
    To specify the `POST' action, you need to use set the
-`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 `xpm', `jpg', and
-`tif' images, based on already rendered `png' image, and
-also organize the produced files in directories named as their own
-extensions:
-
    
-
    ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
-
    
-
    In the previous example, file organization takes place at the moment
-of rendering, just after producing the `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 `POST:groupByFormat' action line:
-
    
-
    ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-
    
-
    The `LAST' action specifies which actions to apply once the last
-file in the list of files to process has been rendered. The
-`LAST' action is optional. Possible values for `LAST'
-actions may be `groupByFormat', `renderGdmTgz', etc.
-
    
-
    info
    Note
     -- Removed(xref:trunk Scripts Bash Functions Render) --, to know more
-about possible values for `BASE', `POST' and `LAST'
-action definitions.
-
    
 
-
    To specify the `LAST' action, you need to set the `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:
-
    
-
    ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
-
    
-
-
-
     2.72.3 Usage 
    
+
+
     2.69.3 Usage 
    
 
-
    Use the following commands to administer both identity and translation
-pre-rendering configuration scripts:
-
    
-
    
-
     `centos-art config --create='path/to/dir/''
    
-
    
-
    Use this command to create `path/to/dir' related pre-rendering
-configuration script.
-
    
-
    
-
     `centos-art config --edit='path/to/dir/''
    
-
    
-
    Use this command to edit `path/to/dir' related pre-rendering
-configuration script.  
-
    
-
    
-
     `centos-art config --read='path/to/dir/''
    
-
    
-
    Use this command to read `path/to/dir' related pre-rendering
-configuration script.  
-
    
-
    
-
     `centos-art config --remove='path/to/dir/''
    
-
    
-
    Use this command to remove `path/to/dir' related pre-rendering
-configuration script.
-
    
-
    
-
    
+
      
+
    •  ...
+
    
 
-
    In the commands above, `path/to/dir' refers to one renderable
-directory path under `trunk/Identity' or
-`trunk/Translations' structures only. 
-
    
 
-
-
     2.72.4 See also 
    
+
+
     2.69.4 See also 
    
 
-
-
-
    2.62 The `trunk/Scripts/Bash' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_77.html b/Manual/repository-html/repository_77.html
index 4a0e0d5..6edf225 100644
--- a/Manual/repository-html/repository_77.html
+++ b/Manual/repository-html/repository_77.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.73 The trunk/Scripts/Bash/Cli/Functions/Shell Directory
+CentOS Artwork Repository: 2.70 The trunk/Scripts/Bash/Cli/Functions/Path Directory
 
-
-
+
+
 
 
 
@@ -55,223 +55,383 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory 
    
-
-
-
-
     2.73.1 Goals 
    
-
-
    This section exists to organize files related to shell
-functionality of `centos-art.sh' script.
-
    
-
-
-
     2.73.2 Description 
    
-
-
    The shell functionality of `centos-art.sh' script helps
-you to maintain bash scripts inside repository. For example, suppose
-you've created many functionalities for `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 shell functionality
-exists to solve maintainance tasks just as the one previously
-mentioned.
-
    
-
    When you use shell functionality to update copyright inside
-script files, it is required that your script files contain (at least)
-the following top commentary structure:
-
    
-
    
-
     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| }
-
    
-
    Figure 2.4: The functions script base comment structure
-
-
    
-
    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 shell
-functionality,  the `centos-art.sh' script replaces everything
-in-between line 5 --the first one matching `^# Copyright .+$'
-string-- and line 9--the first long dash separator matching `^#
--+$'-- with the content of copyright template instance.
-
    
-
    Caution
    Caution
     Be sure to add the long dash separator that matches
-`^# -+$' regular expression before the function
-definition. Otherwise, if the `Copyright' line is present but no
-long dash separator exists, `centos-art.sh' will remove anything
-in-between the `Copyright' line and the end of file. This way you
-may lost your function definitions entirely.
-
    
+
+
+
     2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory 
    
 
-
    The copyright template instance is created from one copyright template
-stored in the `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
-`centos-art.sh' script takes advantage of automation in order to
-set copyright full name and date dynamically.
-
    
-
    When you use shell functionality to update copyright, the first
-thing `shell' functionality does is requesting copyright
-information to user, and later, if values were left empty (i.e., no
-value was typed before pressing RET key), the `shell'
-functionality uses its own default values.
-
    
-
    When shell functionality uses its own default values, the final
-copyright note looks like the following:
-
    
-
    
-
     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| }
-
    
-
    Figure 2.5: The function script comment example
-
+
+
+
     2.70.1 Goals 
    
+
+
    This section exists to organize files related to path
+functiontionality.  The path functionality standardizes
+movement, syncronization, branching, tagging, and general file
+maintainance inside the repository. 
 
    
-
    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. 
+
+
+
     2.70.2 Description 
    
+
+
    "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."
 
    
-
    To change copyright information (i.e., full name or year information),
-run the 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
-shell functionality as many times as you need to.
+
+
+
     2.70.2.1 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: `trunk/', `branches/',
+and `tags/'. 
+
    
+
    The `trunk/' directory (see section The `trunk' Directory) organizes the main
+development line of CentOS corporate visual identity. Inside
+`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
+`trunk/' directory structure is mainly used to perform
+development tasks related to CentOS corporate visual identity.
+
    
+
    The `branches/' directory () oranizes
+parallel development lines to `trunk/' directory. The
+`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 `branches/' directory is mainly used to perform
+quality assurance tasks related to CentOS corporate visual identity.
 
    
-
    To change copyright license (i.e., the text in-between lines 7 and
-20), you need to edit the `Config/tpl_forCopyright.sed' file, set
-the appropriate information, and run the shell functionality
-once again for changes to take effect over the files you specify.
+
    The `tags/' directory (see section The `tags' Directory) organizes parallel frozen
+lines to `branches/' directory.  The parallel frozen lines are
+immutable, nothing change inside them once they has been created.  The
+`tags/' directory is mainly used to publish final releases of
+CentOS corporate visual identity.
 
    
-
    Important
    Important
     The `centos-art.sh' script is released as: 
+
    The CentOS Artwork Repository layout is firmly grounded on a
+Subversion base.  Subversion (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.
 
    
-
    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.
-
    
-
    Do not change the license information under which `centos-art.sh'
-script is released. Instead, if you think a different license must be
-used, please share your reasons at CentOS Developers mailing list.
+
+
     2.70.2.2 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
+(`01-welcome.png', `splash.png', `anaconda_header.png',
+etc.) and directory names are all written capitalized (e.g.,
+`Identity', `Themes', `Motifs', `TreeFlower',
+etc.).
+
    
+
    Repository name convenctions are implemented inside the
+cli_getRepoName function of `centos-art.sh' script. With
+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.
+
    
+
+
+
     2.70.2.3 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., `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.,
+`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 `tags/' directory (e.g.,
+`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., `1') and increment one unit for each
+branch created from the same trunk development line.  Tags start at
+zero (i.e., `0') and increment one unit for each tag created from
+the same branch development line.
+
    
+
    Convenction
    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.
 
    
 
+
    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 `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.
+
    
 
-
-
     2.73.3 Usage 
    
+
+
     2.70.2.4 Parallel directories 
    
 
-
    
-
     centos-art sh --update-copyright='path/to/dir'
    
-
     centos-art sh --update-copyright='path/to/dir' --filter='regex'
    
-
    Use these commands to update copyright information in `.sh' files
-under `path/to/dir' directory. 
-
    
-
    
+
    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 `trunk/Identity' location.  The
+`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
+`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory
+structure, the `centos-art.sh' script removes the
+`Motifs/TreeFlower/' directory levels from path, in order to
+build the parallel directory used to retrived translations, and
+pre-rendering configuration scripts required by render
+functionality.
+
    
+
    Another example of parallel directory is the documentation structure
+created by manual functionality. This time,
+`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.
+
    
+
+
+
     2.70.2.5 Syncronizing path information 
    
 
-
    When you provide `--filter='regex'' argument, the list of files
-to process is reduced as specified in `regex' regular expression.
-Inside `centos-art.sh' script, the `regex' regular
-expression is used in combination with find command to look
-for files matching the regular expression path pattern.
+
    Parallel directories are very useful to keep repository organized but
+introduce some complications.  For instance, consider what would
+happen to functionalities like manual (`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 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 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 (`trunk/Manuals') and change what must be
+changed to match the new parent directory structure.
 
    
-
    Warning
    Warning
     In order for `regex' regular expression to match
-a file, the `regex' regular expresion must match the whole file
-path not just the file name. 
+
    There is no immediate way for 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.
+
    
+
    Warning
    Warning
     There is not support for URL reference inside
+`centos-art.sh' script.  The `centos-art.sh' script is
+designed to work with local files inside the working copy only.
 
    
 
-
    For example, if you want to match all `render.conf.sh' files
-inside `path/to/dir', use the .+/render.conf regular
-expression.  Later, `centos-art.sh' script uses this value inside
-^$REGEX\.sh$ expression in order to build the final regular
-expression (i.e., ^.+/render.conf\.sh$) that is evaluated
-against available file paths inside the list of files to process.
+
    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
+`centos-art.sh' script needs to know when such changes happen, in
+a way they could be noted and handled without producing errors.
+
    
+
+
+
     2.70.2.6 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:
+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 (see section The `trunk/Identity' Directory) 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
+`trunk/Identity/Themes/Motifs/TreeFlower' directory as example.
+It is the trunk development line of 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 `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
+`trunk/Identity/Themes/Distro/Motifs/TreeFlower' location are
+described in the following commands, respectively:
+
    
+
    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/
+
    
+
    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.
+
    
+
+
+
     2.70.3 Usage 
    
+
+
    
+
     centos-art path --copy='SRC' --to='DST'
    
+
    
+
    Copy `SRC' to `DST' and schedule `DST' for
+addition (with history).  In this command, `SRC' and `DST'
+are both working copy (WC) entries.
 
    
-
    Exceptionally, when you provide `--filter='regex'' in the way
-that `regex', appended to `path/to/dir/' (i.e.
-`path/to/dir/regex'), matches a regular file; the
-`centos-art.sh' script uses the file matching as only file in the
-list of files to process. 
+
    
+
     centos-art path --delete='SRC'
    
+
    
+
    Delete `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, `SRC' is a working copy (WC) entry.  
 
    
+
    
+
    
+
 
-
-
     2.73.4 See also 
    
+
+
     2.70.4 See also 
    
 
 
-
    2.62 The `trunk/Scripts/Bash' Directory  
+
    2.62 The `trunk/Scripts/Bash' Directory  
 
    
 
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_78.html b/Manual/repository-html/repository_78.html
index 1cb8073..cc8de85 100644
--- a/Manual/repository-html/repository_78.html
+++ b/Manual/repository-html/repository_78.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.74 The trunk/Scripts/Bash/Cli/Functions/Svg Directory
+CentOS Artwork Repository: 2.71 The trunk/Scripts/Bash/Cli/Functions/Render Directory
 
-
-
+
+
 
 
 
@@ -55,255 +55,767 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory 
    
-
-
-
-
     2.74.1 Goals 
    
-
-
    This section exists to organize files related to svg
-functionality of `centos-art.sh' script.
-
    
-
-
-
     2.74.2 Description 
    
-
-
    The svg functionality of `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 `trunk/Identity/Themes/Models/', and you want to set common
-metadata to all of them, and later remove all unused SVG defintions
-from `*.svg' files. Doing so file by file may be a tedious task,
-so the `centos-art.sh' script provides the svg
-functionality to aid you maintain such actions.
-
    
-
-
-
-
     2.74.2.1 Metadata maintainance 
    
-
-
    The metadata used is defined by Inkscape 0.46 using the SVG standard
-markup. The `centos-art.sh' script replaces everything
-in-between <metadata and </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 `=SOMETEXT=', where
-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 `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 `centos-art.sh' script is currently creating metadata
-information for.
-
    
-
    With metadata template instance in place, the `centos-art.sh'
-script uses it to replace real values inside all `.svg' files
-under the current location you're running the `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
-RET key, `centos-art.sh' uses its default value.
-
    
-
    The `centos-art.sh' script modifies the following metadata:
+
+
+
     2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory 
    
+
+
    The render functionality exists to produce both identity and
+translation files on different levels of information (i.e., different
+languages, release numbers, architectures, etc.).
+
    
+
    The 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.
+
    
+
+
+
     2.71.1 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 `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, `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).
+
    
+
+
+
     2.71.1.1 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:
 
    
 
    
-
     `Title'
    
-
    Name by which this document is formally known. If no value is set
-here, `centos-art.sh' script uses the file name as title.
+
     One renderable identity directory structure:
    
+
    
+
    In this example we used `Identity/Path/To/Dir' as the identity
+component we want to produce untranslated images for.  Identity
+components can be either under `trunk/' or `branches/'
+directory structure.
 
    
-
    
-
     `Date'
    
-
    Date associated with the creation of this document (YYYY-MM-DD). If no
-value is set here, `centos-art.sh' script uses the current date
-information as in date +%Y-%m-%d.
+
    The identity component (i.e., `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
+`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.
 
    
-
    
-
     `Creator'
    
-
    Name of entity primarily responsible for making the content of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
+
          | 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.
+
    
+
    Inside design template directory, design template files are based on
+SVG (Scalable Vector Graphics) and use the extension
+.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.
 
    
-
    
-
     `Rights'
    
-
    Name of entity with rights to the intellectual Property of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
+
    In order for 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 CENTOSARTWORK
+object id inside.
 
    
-
    
-
     `Publisher'
    
-
    Name of entity responsible for making this document available. If no
-value is set here, `centos-art.sh' script uses the string
-`The CentOS Project'.
+
    The CENTOSARTWORK word itself is a convenction name we use to
+define which object/design area, inside a design template, the
+`centos-art.sh' script will use to export as
+PNG (Portable Network Graphic) image at rendition time.
+Whithout such object id specification, the `centos-art.sh' script
+cannot know what object/design area you (as designer) want to export
+as PNG (Portable Network Graphic) image file.
 
    
-
    
-
     `Identifier'
    
-
    Unique URI to reference this document. If no value is set here,
-`centos-art.sh' script uses the current file path to build the
-related url that points to current file location inside repository
-central server.
+
    info
    Note
     At rendition time, the content of `Img/' directory
+structure is produced by `centos-art.sh' automatically.
+
    
+
+
    When a renderable identity directory structure is configured to
+produce image-based content, `centos-art.sh' produces
+PNG (Portable Network Graphics) files with the .png
+extension. Once the base image format has been produced, it is
+possible for `centos-art.sh' to use it in order to automatically
+create other image formats that may be needed (-- Removed(pxref:trunk Scripts
+Bash Functions Render Config) --).
 
    
-
    
-
     `Source'
    
-
    Unique URI to reference the source of this document. If no value is
-set here, `centos-art.sh' script uses current file path to build
-the related url that points to current file location inside repository
-central server.
+
    Inside the working copy, you can find an example of "design template
+without translation" configuration at `trunk/Identity/Models/'.
 
    
-
    
-
     `Relation'
    
-
    Unique URI to a related document. If no value is set here,
-`centos-art.sh' script uses current file path to build the
-related url that points to current file location inside repository
-central server.
+
    See section The `trunk/Identity' Directory, for more information.
 
    
 
    
-
     `Language'
    
-
    Two-letter language tag with optional subtags for the language of this
-document. (e.g. `en-GB'). If no value is set here,
-`centos-art.sh' script uses the current locale information as in
-cli_getCurrentLocale function.
+
     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.
 
    
-
    
-
     `Keywords'
    
-
    The topic of this document as comma-separated key words, prhases, or
-classifications. If no value is set here, `centos-art.sh' script
-uses file path to build 
+
    If the translation entry is empty (i.e., there is no file inside it),
+`centos-art.sh' interprets the identity renderable directory
+structure as a "design templates without translation" configuration.
 
    
-
    
-
     `Coverage'
    
-
    Extent or scope of this document. If no value is set here,
-`centos-art.sh' script uses the string `The CentOS Project'.
+
                       | The bond component
+                   |----------------->|
+trunk/Translations/Identity/Path/To/Dir
+`-- (empty)
+
    
+
    If the translation entry is not empty, `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 (MATCHINGLIST) variable in the
+pre-rendition configuration script of the renderable identity
+directory structure we are producing images for.
 
    
-
    
-
     `Description'
    
-
    Description about the document. If no value is set here,
-`centos-art.sh' script uses uses empty value as default.
+
    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, one
+translation files is applied to one design template, to produce
+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.
+
    
+
    -- Removed(xref:trunk Translations) --, for more information.
 
    
 
    
-
     `Contributors'
    
-
    People that contributes in the creation/maintainance of the document.
-If no value is set here, `centos-art.sh' script uses uses empty
-value as default.
+
     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 `centos-art.sh' will perform over the identity directory
+structure and how does it do that.
+
    
+
                                               | The bond component
+                                           |----------------->|
+trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
+
    
+
    In this configuration the pre-rendition configuration script
+(`render.conf.sh') would look like the following:
+
    
+
    function render_loadConfig {
+
+    # Define rendition actions.
+    ACTIONS[0]='BASE:renderImage'
+
+}
+
    
+
    Since translation directory structure is empty, `centos-art.sh'
+assumes a "design template without translation" configuration to
+produce untranslated images.
+
    
+
    To produce untranslated images, `centos-art.sh' takes one design
+template and creates one temporal instance from it.  Later,
+`centos-art.sh' uses the temporal design template instance as
+source file to export the final untranslated image. The action of
+exporting images from SVG (Scalable Vector Graphics) to
+PNG (Portable Network Graphics) is possible thanks to
+Inkscape's command-line interface and the CENTOSARTWORK object
+id we previously set inside design templates.
+
    
+
    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.
+
    
+
    Finally, when the untranslated image has been created, the temporal
+design template instance is removed. At this point,
+`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.
+
    
+
    -- Removed(xref:trunk Scripts Bash Functions Render Config) --, for more
+information.
 
    
 
    
 
-
    The `License' metadatum is not set as a choise, by now. It is
-fixed 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.
-
    
-
 
-
-
     2.74.2.2 Unused definitions 
    
+
+
     2.71.1.2 Design template with translation (one-to-one) 
    
 
-
    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 `Vacuum Defs' command
-in `File' menu. It will remove any gradients, patterns, or
-markers which are not used by anything in the document, making the
-file smaller. 
+
    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.
 
    
-
    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.
+
    In order for `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,
+`centos-art.sh' will not produce the final image related to the
+missing component.
 
    
-
    To remove unused definitions from several scalable vector graphics
-files, the `centos-art.sh' script uses Inkscape command-line
-interface, specifically with the `--vaccum-defs' option.
+
    In order for `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
+`trunk/Translations/Identity/Path/To/Dir/file.sed' translation
+file does match `trunk/Identity/Path/To/Dir/Tpl/file.svg' design
+template, but it doesn't match
+`trunk/Identity/Path/To/Dir/File.svg' or
+`trunk/Identity/Path/To/Dir/Tpl/File.svg' or
+`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.
+
    
+
    info
    Note
     If we use no translation file in the translation entry
+(i.e., an empty directory), `centos-art.sh' assumes the
+untranslated image production. If we fill the translation entry with
+translation files, `centos-art.sh' assumes the translated image
+production.  
+
    
+
+
    To produce final images, `centos-art.sh' applies one translation
+file to one design template and produce a translated design template
+instance. Later, `centos-art.sh' uses the translated template
+instance to produce the translated image. Finally, when the translated
+image has been produced, `centos-art.sh' removes the translated
+design template instance. This production flow is repeated for each
+translation file available in the translatio entry. 
+
    
+
    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.
+
    
 
-
-
     2.74.3 Usage 
    
+
+
     2.71.1.3 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 (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 MATCHINGLIST variable is set in the pre-rendition
+configuration script of the component we want to produce images for.
+By default, the MATCHINGLIST variable is empty which means no
+matching list is used. Otherwise, if MATCHINGLIST variable has a
+value different to empty value then, `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:
+
    
 
    
-
     centos-art svg --update-metadata='path/to/dir'
    
-
     centos-art svg --update-metadata='path/to/dir' --filter='regex'
    
-
    Use these commands to update metadata information to `.svg' files
-under `path/to/dir' directory.
+
     One entry under `trunk/Identity/':
    
+
    
+
    In this configuration we want to produce three images using a
+paragraph-based style, controlled by `paragraph.svg' design
+template; and one image using a list-based style, controlled by
+`list.svg' design template.
+
    
+
    trunk/Identity/Path/To/Dir
+|-- Tpl
+|   |-- paragraph.svg
+|   `-- list.svg
+`-- Img
+    |-- 01-welcome.png
+    |-- 02-donate.png
+    |-- 03-docs.png
+    `-- 04-support.png
+
    
+
    
+
     One entry under `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.
 
    
+
    trunk/Translations/Identity/Path/To/Dir
+|-- 01-welcome.sed
+|-- 02-donate.sed
+|-- 03-docs.sed
+`-- 04-support.sed
+
    
 
    
-
     centos-art svg --vacuum-defs='path/to/dir'
    
-
     centos-art svg --vacuum-defs='path/to/dir' --filter='regex'
    
-
    Use these commands to remove unused definitions inside `.svg'
-files under `path/to/dir' directory. 
+
     One entry under `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 `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 MATCHINGLIST variable inside the pre-rendition
+configuration script of the component we want to produce images for.  
+
    
+
    trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
+
    
+
    In this configuration the pre-rendition configuration script
+(`render.conf.sh') would look like the following:
+
    
+
    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
+    "
+
+}
+
    
+
    As result, `centos-art.sh' will produce `01-welcome.png',
+`02-donate.png' and `04-support.png' using the
+paragraph-based design template, but `03-docs.png' using the
+list-based design template.
 
    
 
    
 
-
    When you provide `--filter='regex'' argument, the list of files
-to process is reduced as specified in `regex' regular expression.
-Inside `centos-art.sh' script, the `regex' regular
-expression is used in combination with find command to look
-for files matching the regular expression path pattern.
+
+
+
     2.71.1.4 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 almost does.
 
    
-
    Warning
    Warning
     In order for `regex' regular expression to match
-a file, the `regex' regular expresion must match the whole file
-path not just the file name. 
-
    
+
    Generally, we use design templates to define how final images will
+look like. Generally, each renderable directory structure has one
+`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
+`centos-art.sh'. 
+
    
+
    For example, consider the following configuration:
+
    
+
    
+
     One entry under `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 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.
+
    
+
                            THEMEMODEL | | The bond component
+                             |<----| |--------------------->|
+trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
+|-- paragraph.svg
+`-- list.svg
+
    
+
    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.
+
    
+
    
+
     One entry under `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
+`centos-art.sh' (e.g., Backgrounds, Color information,
+Screenshots, etc.).
+
    
+
                      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
+
    
+
    
+
     One entry under `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.
+
    
+
                                       | 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
+
    
+
    
+
     One entry under `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
+`centos-art.sh' how to render the component.
+
    
+
    trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
+`-- render.conf.sh
+
    
+
    In this configuration the pre-rendition configuration script
+(`render.conf.sh') would look like the following:
+
    
+
    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'
+
+}
+
    
+
    
+
+
    The production flow of "optimize+flexibility" configuration…
+
    
+
+
     2.71.2 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
+(`Tpl/') directory structure to handle common content inside
+translation files.  This way, we work on translation templates and
+later use `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 `centos-art.sh' is executed to produce translation files
+from translation templates.
+
    
+
    Inside renderable translation directory structures,
+`centos-art.sh' can produce text-based files only.
+
    
+
+
+
     2.71.3 Copying renderable directory structures 
    
 
-
    For example, if you want to match all `summary.svg' files inside
-`path/to/dir', use the .+/summary regular expression.
-Later, `centos-art.sh' script uses this value inside
-^$REGEX\.svg$ expression in order to build the final regular
-expression (i.e., ^.+/summary\.svg$) that is evaluated against
-available file paths inside the list of files to process.
+
    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).
 
    
-
    Exceptionally, when you provide `--filter='regex'' in the way
-that `regex', appended to `path/to/dir/' (i.e.
-`path/to/dir/regex'), matches a regular file; the
-`centos-art.sh' script uses the file matching as only file in the
-list of files to process. 
+
    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:
+
    
+
      
+
    1.  To have a unique directory structure under
+`trunk/Identity', organized by any one of the above
+organizational designs above.
+
+
    2.  To have a unique directory structure under
+`trunk/Translations' to store translation files.
+
+
    3.  To have a unique directory structure under
+`trunk/Scripts/Bash/Functions/Render/Config' to set pre-rendition
+configuration script.
+
    
+
+
    As convenction, the render_doCopy function uses
+`trunk/Identity' directory structure as source location.  Once
+the `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 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. 
+
    
+
+
+
     2.71.4 Usage 
    
+
+
      
+
    •  ...
+
    
+
 
-
-
     2.74.4 See also 
    
+
+
     2.71.5 See also 
    
 
-
-
-
    2.62 The `trunk/Scripts/Bash' Directory  
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_79.html b/Manual/repository-html/repository_79.html
index 6c028f5..7ab676b 100644
--- a/Manual/repository-html/repository_79.html
+++ b/Manual/repository-html/repository_79.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.75 The trunk/Scripts/Bash/Cli/Functions/Verify Directory
+CentOS Artwork Repository: 2.72 The trunk/Scripts/Bash/Cli/Functions/Render/Config Directory
 
-
-
+
+
 
 
 
@@ -55,302 +55,233 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory 
    
+
+
+
     2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory 
    
 
 
-
-
     2.75.1 Goals 
    
+
+
     2.72.1 Goals 
    
 
-
    This section exists to organize files related to `centos-art.sh'
-script `verify' functionality.  The `verify'
-functionality of `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.
+
    The `trunk/Scripts/Bash/Config' directory exists to oraganize
+pre-rendering configuration scripts.
 
    
 
-
-
     2.75.2 Description 
    
+
+
     2.72.2 Description 
    
 
-
    The first time you download CentOS Artwork Repository you need to
-configure your workstation in order to use `centos-art.sh'
-script.  These preliminar configurations are based mainly on auxiliar
-RPM packages installation, symbolic links creations, and environment
-variables definitions.  The `verify' functionality of
-`centos-art.sh' script guides you through this preliminar
-configuration process.  
+
    Pre-rendering configuration scripts let you customize the way
+centos-art.sh script renders identity and translation
+repository entries.  Pre-rendering configuration scripts are
+`render.conf.sh' files with render_loadConfig function
+definition inside. 
 
    
-
    If this is the first time you run `centos-art.sh' script, the
-appropriate way to use its `verify' functionality is not using
-the `centos-art.sh' script directly, but the absolute path to
-centos-art.sh script instead (i.e.,
-`~/artwork/trunk/Scripts/Bash/centos-art.sh').  This is necessary
-because `centos-art' symbolic link, under `~/bin/'
-directory, has not been created yet.
+
    There is one `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. 
 
    
 
-
-
     2.75.2.1 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 centos-art.sh script uses are shipped with
-CentOS distribution, and can be installed from CentOS base repository.
-The only exception is `inkscape', the package we use to
-manipulate SVG files.  The `inkscape' package is not inside
-CentOS distribution so it needs to be installed from third party
-repositories.
-
    
-
    info
    Note
     Configuration of third party repositories inside CentOS
-distribution is described in CentOS wiki, specifically in the
-following URL:
-http://wiki.centos.org/AdditionalResources/Repositories
+
+
     2.72.2.1 The `render.conf.sh' identity model 
    
+
+
    Inside CentOS Artwork Repository, we consider identity entries to all
+directories under `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:
+
    
+
    #!/bin/bash
+
+function render_loadConfig {
+
+    # Define rendering actions.
+    ACTIONS[0]='BASE:renderImage'
+    ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
+
+}
+
    
+
    Inside identity pre-rendering configuration scripts, text-based
+pre-rendering configuration scripts look like the following:
+
    
+
    #!/bin/bash
+
+function render_loadConfig {
+
+    # Define rendering actions.
+    ACTIONS[0]='BASE:renderText'
+    ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
+
+}
+
    
+
    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. 
+
    
+
+
+
     2.72.2.2 The `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.
+
    
+
+
+
     2.72.2.3 The `render.conf.sh' rendering actions 
    
+
+
    Inside both image-based and text-based identity pre-rendering
+configuration scripts, we use the `ACTIONS' array variable to
+define the way centos-art.sh script performs identity
+rendering.  Identity rendering is organized by one `BASE' action,
+and optional `POST' and `LAST' rendering actions.
+
    
+
    The `BASE' action specifies what kind of rendering does the
+centos-art.sh script will perform with the files related to
+the pre-rendering configuration script. The `BASE' action is
+required. Possible values to `BASE' action are either
+`renderImage' or `renderText' only.
+
    
+
    To specify the `BASE' action you need to set the `BASE:'
+string followed by one of the possible values. For example, if you
+want to render images, consider the following definition of
+`BASE' action:
+
    
+
    ACTIONS[0]='BASE:renderImage'
+
    
+
    Only one `BASE' action must be specified. If more than one
+`BASE' action is specified, the last one is used. If no
+`BASE' action is specified at all, an error is triggered and the
+centos-art.sh script ends its execution.
+
    
+
    The `POST' action specifies which action to apply for
+each file rendered (at the rendering time). This action is optional.
+You can set many different `POST' actions to apply many different
+actions over the same already rendered file. Possible values to
+`POST' action are `renderFormats', `renderSyslinux',
+`renderGrub', etc. 
+
    
+
    To specify the `POST' action, you need to use set the
+`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 `xpm', `jpg', and
+`tif' images, based on already rendered `png' image, and
+also organize the produced files in directories named as their own
+extensions:
+
    
+
    ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
+
    
+
    In the previous example, file organization takes place at the moment
+of rendering, just after producing the `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 `POST:groupByFormat' action line:
+
    
+
    ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+
    
+
    The `LAST' action specifies which actions to apply once the last
+file in the list of files to process has been rendered. The
+`LAST' action is optional. Possible values for `LAST'
+actions may be `groupByFormat', `renderGdmTgz', etc.
+
    
+
    info
    Note
     -- Removed(xref:trunk Scripts Bash Functions Render) --, to know more
+about possible values for `BASE', `POST' and `LAST'
+action definitions.
 
    
 
-
    Before installing packages, the `centos-art.sh' script uses
-sudo to request root privileges to execute yum
-installation functionality.  If your user isn't defined as a
-privileged user--at least to run yum commands-- inside
-`/etc/sudoers' configuration file, you will not be able to
-perform package installation tasks as set in `centos-art.sh'
-script `verify' functionality. 
-
    
-
    Setting sudo privileges to users is an administrative task you have to
-do by yourself. If you don't have experience with sudo
-command, please read its man page running the command: man
-sudo. This reading will be very useful, and with some practice, you
-will be able to configure your users to have sudo
-privileges.
-
    
-
-
-
     2.75.2.2 Links 
    
-
-
    Creation of symbolic links helps us to alternate between different
-implementations of `centos-art.sh' script-line (e.g.,
-`centos-art.sh', for Bash implementation; `centos-art.py',
-for Python implementation; `centos-art.pl', for Perl
-implementation; and so on for other implementations). The
-`centos-art.sh' script-line definition takes place inside your
-personal binary (`~/bin/') directory in order to make the script
-implementation --the one that `centos-art' links to-- available
-to 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 `centos-art.sh'
-script functionalities available outside `trunk/' repository
-directory structure, but at its same level in repository tree. This is
-useful if you need to use the "render" functionality of
-centos-art.sh under `branches/' repository directory
-structure as you usually do inside `trunk/' repository directory
-structure. As consequence of this configuration, automation scripts
-cannot be branched under `branches/Scripts' directory structure.
+
    To specify the `LAST' action, you need to set the `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:
 
    
+
    ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
+
    
 
-
-
     2.75.2.3 Environment variables 
    
+
+
     2.72.3 Usage 
    
 
-
    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 `~/.bash_profile' file.  The
-`verify' functionality of `centos-art.sh' script doesn't
-modify your `~/.bash_profile' file.  
-
    
-
    The `verify' functionality of `centos-art.sh' script
-evaluates the following environment variables:
+
    Use the following commands to administer both identity and translation
+pre-rendering configuration scripts:
 
    
 
    
-
     EDITOR
    
-
    Default text editor. 
-
    
-
    The `centos-art.sh' script uses default text EDITOR to edit
-pre-commit subversion messages, translation files, configuration
-files, script files, and similar text-based files.
-
    
-
    If EDITOR environment variable is not set, `centos-art.sh'
-script uses `/usr/bin/vim' as default text editor. Otherwise, the
-following values are recognized by `centos-art.sh' script:
-
    
-
      
-
    •  `/usr/bin/vim'
-
    •  `/usr/bin/emacs'
-
    •  `/usr/bin/nano'
-
    
-
-
    If no one of these values is set in EDITOR environment variable,
-`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
-
    
-
    
-
     TEXTDOMAIN
    
+
     `centos-art config --create='path/to/dir/''
    
 
    
-
    Default domain used to retrieve translated messages.  This variable is
-set in `initFunctions.sh' and shouldn't be changed.
+
    Use this command to create `path/to/dir' related pre-rendering
+configuration script.
 
    
 
    
-
     TEXTDOMAINDIR
    
+
     `centos-art config --edit='path/to/dir/''
    
 
    
-
    Default directory used to retrieve translated messages.  This variable
-is set in `initFunctions.sh' and shouldn't be changed.
+
    Use this command to edit `path/to/dir' related pre-rendering
+configuration script.  
 
    
 
    
-
     LANG
    
+
     `centos-art config --read='path/to/dir/''
    
 
    
-
    Default locale information.
-
    
-
    This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-`Language' step; or once installed using the
-system-config-language tool.
-
    
-
    The `centos-art.sh' script uses the LANG environment
-variable to know in which language the script messages are printed
-out.
+
    Use this command to read `path/to/dir' related pre-rendering
+configuration script.  
 
    
 
    
-
     TZ
    
+
     `centos-art config --remove='path/to/dir/''
    
 
    
-
    Default time zone representation.
-
    
-
    This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-`Date and time' step; or once installed using the
-system-config-date tool.
-
    
-
    The `centos-art.sh' script doesn't use the 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 TZ variable may be
-necessary.
-
    
-
    Convenction
    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.
-
    
-
-
    The format of TZ environment variable is described in
-`tzset(3)' manual page.
+
    Use this command to remove `path/to/dir' related pre-rendering
+configuration script.
 
    
 
    
 
    
 
-
-
-
     2.75.3 Usage 
    
-
-
    
-
     centos-art verify --packages
    
-
    
-
    Verify required packages your workstation needs in order to run the
-`centos-art.sh' script correctly.  If there are missing packages,
-the `centos-art.sh' script asks you to confirm their
-installation. When installing packages, the `centos-art.sh'
-script uses the yum application in order to achieve the
-task.
-
    
-
    In case all packages required by `centos-art.sh' script are
-already installed in your workstation, the message `The required
-packages are already installed.' is output for you to know. 
-
    
-
    
-
     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
-centos-art.sh script asks you to confirm their installation.
-To install required links, the centos-art.sh script uses the
-ln command.
+
    In the commands above, `path/to/dir' refers to one renderable
+directory path under `trunk/Identity' or
+`trunk/Translations' structures only. 
 
    
-
    In case all links required by `centos-art.sh' script are already
-created in your workstation, the message `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 `centos-art.sh' script outputs the `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 `centos-art.sh'
-script will fall into a continue installation request for that missing
-link.  To end this continue request you can answer `No', or
-remove the existent regular file to let `centos-art.sh' script
-install the link on its place.
-
    
-
    
-
     centos-art verify --environment
    
-
     centos-art verify --environment --filter='regex'
    
-
    
-
    Output a brief description of environment variables used by
-`centos-art.sh' script. 
-
    
-
    If `--filter' option is provided, output is reduced as defined in
-the `regex' regular expression value. If `--filter' option
-is specified but `regex' value is not, the `centos-art.sh'
-script outputs information as if `--filter' option had not been
-provided at all.  
-
    
-
    
-
    
-
 
-
-
     2.75.4 See also 
    
+
+
     2.72.4 See also 
    
 
 
-
    2.62 The `trunk/Scripts/Bash' Directory  
+
    2.62 The `trunk/Scripts/Bash' Directory  
 
    
 
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_8.html b/Manual/repository-html/repository_8.html
index 6e6915b..7d441dd 100644
--- a/Manual/repository-html/repository_8.html
+++ b/Manual/repository-html/repository_8.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.4 The trunk/Identity Directory
+CentOS Artwork Repository: 2.1 The branches Directory
 
-
-
+
+
 
 
 
@@ -55,276 +55,69 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.4 The `trunk/Identity' Directory 
    
+
+
+
     2.1 The `branches' Directory 
    
 
 
-
-
     2.4.1 Goals 
    
+
+
     2.1.1 Goals 
    
 
-
    The `trunk/Identity' directory structure implements The
-CentOS Project Corporate Identity.
+
    This directory implements the Subversion's branches concept in a
+trunk, branches, tags repository structure.
 
    
 
-
-
     2.4.2 Description 
    
+
+
     2.1.2 Description 
    
 
-
    The CentOS Project corporate identity is the "persona" of the
-organization known as The CentOS Project.  The CentOS Project
-corporate identity plays a significant role in the way the CentOS
-Project, as organization, presents itself to both internal and
-external stakeholders. In general terms, the CentOS Project corporate
-visual identity expresses the values and ambitions of the CentOS
-Project organization, its business, and its characteristics.  
-
    
-
    The CentOS Project corporate identity provides visibility,
-recognizability, reputation, structure and identification to The
-CentOS Project organization by means of Corporate Design,
-Corporate Communication, and Corporate Behaviour.
+
    The `branches/' directory structre provides the intermediate
+space for creating several instances of `trunk/' directory
+structure for parallel development and later merging changes back to
+`trunk/' in the same parallel basis.
 
    
 
-
-
     2.4.2.1 Corporate Design 
    
+
+
     2.1.3 Usage 
    
 
-
    The CentOS Project corporate design is applied to every single visual
-manifestations The CentOS Project as organization wants to express its
-existence. Examples of the most relevant visual manifestations inside
-The CentOS Project are The CentOS Distribution, The
-CentOS Web and The CentOS Stationery.
-
    
-
    The CentOS Project corporate design is organized in the following
-work-lines:
-
    
-
    
-
     The CentOS Brand
    
-
    The CentOS Brand is the name or trademark that connects the producer
-with their products. In this case, the producer is The CentOS Project
-and the products are The CentOS Project visual manifestations. 
-
    
-
    See section The `trunk/Identity/Brands' Directory, for more information.
-
    
-
    
-
     The CentOS Colors
    
-
    
-
    The CentOS Fonts provides the color information used along The CentOS
-Project visual manifestations.
+
    The `branches/' directory structure is unused, so far.
 
    
-
    See section The `trunk/Identity/Colors' Directory, for more information.
-
    
-
     The CentOS Fonts
    
-
    
-
    The CentOS Fonts provides the typography information used along The
-CentOS Project visual manifestations.
-
    
-
    See section The `trunk/Identity/Fonts' Directory, for more information.
-
    
-
     The CentOS Themes
    
-
    
-
    The CentOS Themes provides structural information and visual style
-information, as well, used along The CentOS Project visual
-manifestations.
-
    
-
    See section The `trunk/Identity/Themes' Directory, for more information.
-
    
-
    
 
+
+
     2.1.4 See also 
    
 
-
-
     2.4.2.2 Corporate Communication 
    
-
-
    The CentOS Project corporate communication is based on community
-communication.  In that sake, the following media are available for
-corporate communication:
-
    
 
 
 
-
-
     2.4.2.3 Corporate Behaviour 
    
-
-
    The CentOS Project corporate behaviour is based on community
-behaviour.
-
    
-
-
-
     2.4.2.4 Corporate Structure 
    
-
-
    The CentOS Project corporate structure is based on a monolithic
-corporate visual identity structure. In this structure, we use one
-unique name (The CentOS Brand) and one unique visual style (The CentOS
-Theme) in all The CentOS Project visual manifestations.
-
    
-
    Inside a monolithic corporate visual identity structure, internal and
-external stakeholders use to feel a strong sensation of uniformity,
-orientation, and identification with the organization. No matter if
-you are visiting web sites, using the distribution, or acting on
-social events, the one unique name and one unique visual style
-connects them all to say: Hey! we are all part of The CentOS
-Project.
-
    
-
    Other corporate structures have been considered as well, but they
-introduce visual contradictions we need to be aware of.  In that sake,
-lets describe the idea of: Producing one different visual style
-for each major release of The CentOS Distribution.
-
    
-
    The CentOS Project maintains near to four different major releases of
-The CentOS Distribution parallely in time and that fact makes one part
-of The CentOS Project structural design, but just one part, not the
-complete structural design.  In order to produce the correct corporate
-structure for The CentOS Project we need to concider all the visual
-manifestations The CentOS Project is made of, not just one of them.
-
    
-
    If one different visual style is used for each major release of The
-CentOS Distribution, which one of those different visual styles would
-be used to cover the remaining visual manifestations The CentOS
-Project is made of. Would we end up with four different visual styles,
-one for each distribution?  In that case, why The CentOS Distribution
-we use shows one visual style, The CentOS Web sites another and The
-CentOS Stationery even another completly different one?  Isn't them
-all part of the same project?
-
    
-
    Probably you be thinking, that's right, but The CentOS Brand connects
-them all already, why would we need to join them up into the same
-visual style too, isn't it more work to do, and harder to maintain?
-
    
-
    Harder to maintain, more work to do, it is probably. Specially when
-you consider that The CentOS Project has proven stability and
-consistency through time and that, certainly, didn't come through
-swinging magical wangs or something but hardly working out to automate
-tasks and so providing maintainance through time. Said that, we
-consider that The CentOS Project visual structure should be consequent
-with such stability and consistency tradition. It is true The CentOS
-Brand does connect all the visual manifestations it is present on, but
-that connection would be stronger if one unique visual style backups
-it.  In fact, whatever thing you do to strength the visual connection
-among The CentOS Project visual manifestations would be very good in
-favor of The CentOS Project recognition.
-
    
-
    Obviously, having just one visual style in all visual manifestations
-for eternity would be a very boring thing and would give the idea of a
-visually dead project. So, there is no problem on creating a brand new
-visual style for each new major release of The CentOS Distribution, in
-order to refresh The CentOS Distribution visual style; the problem
-does is in not propagating the brand new visual style created for the
-new release of CentOS Distribution to all other visual manifestations
-The CentOS Project is made of, in a way The CentOS Project could be
-recognized no matter what visual manifestation be in front of us. Such
-lack of uniformity is what introduces the visual contradition we are
-precisely trying to solve by mean of themes production in the CentOS
-Artwork Repository.
-
    
-
-
-
     2.4.3 Usage 
    
-
-
    The `trunk/' directory structure is organized in
-renderable and non-renderable directories. Generally,
-renderable directories contain two non-renderable directories inside,
-one to store design templates (the `Tpl/' directory), and other
-to store the content produced (the `Img/' directory).
-
    
-
    In order to produce content inside rendereble directories, you can use
-the following command:
-
    
-
    centos-art identity --render='trunk/Identity/Path/To/Dir'
-
    
-
    Warning
    Warning
     If the centos-art command-line
-is not found in your workstation, it is probably because you haven't
-prepared it for using The CentOS Artwork Repository yet.
-See section The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory, for more
-information.  
-
    
-
-
    This command takes one design template from the template directory and
-creates an instance of it in order to apply translation messages on
-it, if any. Later, using the design template instance, the command
-renders the final content based on whether the design template
-instance is a SVG file or a Docbook file. If the design template
-instace is a SVG file, the final content produced is a PNG image. On
-the other hand, if the design template instance is a Docbook file, the
-final content produced is a XHTML file. Final content is stored in the
-image directory using the design template directory paths as referece.
-The rendition flow described so far is known as the
-base-rendition flow.
-
    
-
    Besides the base-rendition flow, the centos-art provides the
-post-rendition and last-rendition flows.  The
-post-rendition flow is applied to files produced as result of
-base-rendition flow under the same directory structure. For example,
-you can use post-rendition action to convert the PNG base output into
-different outputs (e.g., JPG, PDF, etc.) before passing to process the
-next file in the same directory structure.  The last-rendition flow is
-applied to all files produced as result of both base-rendition and
-post-rendition flows in the same directory structure, just before
-passing to process a different directory structure.  For example, the
-`Preview.png' image from Ksplash component is made of three
-images. In order to build the `Preview.png' image through
-centos-art we need to wait for all the three images the
-`Preview.png' image is made of to be rendered, so we can combine
-them all together into just one image (i.e., the `Preview.png'
-image).  This is something we can't do using post-rendition flow.
-
    
-
    Inside `trunk/Identity' directory structure, you can find that
-base-rendition, post-rendition and last-rendition flows can be
-combined to build directory-specific rendition.  The
-directory-specific rendition exists to automatically process specific
-renderable directories in very specific ways. Using directory-specific
-rendition speeds up production of different components like Syslinux,
-Grub, Gdm, Kdm and Ksplash that require intermediate formats or even
-several independent files, in order to reach its final construction.
-Directory-specific rendition is a way to programmatically describe how
-specific art works are built in and organized inside The CentOS
-Artwork Repository.  Such descriptions have been added to
-centos-art command-line to let you produce them all with
-just one single command, as fast as your machine can be able to handle
-it. 
-
    
-
    See section The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory, for more
-information about the identity functionality of
-centos-art command-line interface.
-
    
-
-
-
     2.4.4 See also 
    
-
-
    See http://en.wikipedia.org/Corporate_identity (and related
-links), for general information on corporate identity. 
-
    
-
    Specially useful has been, and still be, the book Corporate
-Identity by Wally Olins (1989). This book provides many conceptual
-ideas we've used as base to build The CentOS Artwork Repository. 
-
    
-
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_80.html b/Manual/repository-html/repository_80.html
index 452f94b..81082b8 100644
--- a/Manual/repository-html/repository_80.html
+++ b/Manual/repository-html/repository_80.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.76 The trunk/Scripts/Python Directory
+CentOS Artwork Repository: 2.73 The trunk/Scripts/Bash/Cli/Functions/Shell Directory
 
-
-
+
+
 
 
 
@@ -55,69 +55,223 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.76 The `trunk/Scripts/Python' Directory 
    
+
+
+
     2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory 
    
 
 
-
-
     2.76.1 Goals 
    
-
-
      
-
    •  ...
-
    
+
+
     2.73.1 Goals 
    
 
+
    This section exists to organize files related to shell
+functionality of `centos-art.sh' script.
+
    
 
-
-
     2.76.2 Description 
    
+
+
     2.73.2 Description 
    
 
-
      
-
    •  ...
-
    
+
    The shell functionality of `centos-art.sh' script helps
+you to maintain bash scripts inside repository. For example, suppose
+you've created many functionalities for `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 shell functionality
+exists to solve maintainance tasks just as the one previously
+mentioned.
+
    
+
    When you use shell functionality to update copyright inside
+script files, it is required that your script files contain (at least)
+the following top commentary structure:
+
    
+
    
+
     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| }
+
    
+
    Figure 2.4: The functions script base comment structure
+
+
    
+
    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 shell
+functionality,  the `centos-art.sh' script replaces everything
+in-between line 5 --the first one matching `^# Copyright .+$'
+string-- and line 9--the first long dash separator matching `^#
+-+$'-- with the content of copyright template instance.
+
    
+
    Caution
    Caution
     Be sure to add the long dash separator that matches
+`^# -+$' regular expression before the function
+definition. Otherwise, if the `Copyright' line is present but no
+long dash separator exists, `centos-art.sh' will remove anything
+in-between the `Copyright' line and the end of file. This way you
+may lost your function definitions entirely.
+
    
 
+
    The copyright template instance is created from one copyright template
+stored in the `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
+`centos-art.sh' script takes advantage of automation in order to
+set copyright full name and date dynamically.
+
    
+
    When you use shell functionality to update copyright, the first
+thing `shell' functionality does is requesting copyright
+information to user, and later, if values were left empty (i.e., no
+value was typed before pressing RET key), the `shell'
+functionality uses its own default values.
+
    
+
    When shell functionality uses its own default values, the final
+copyright note looks like the following:
+
    
+
    
+
     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| }
+
    
+
    Figure 2.5: The function script comment example
+
+
    
+
    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 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
+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 `Config/tpl_forCopyright.sed' file, set
+the appropriate information, and run the shell functionality
+once again for changes to take effect over the files you specify.
+
    
+
    Important
    Important
     The `centos-art.sh' script is released as: 
+
    
+
    GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991
 
-
-
     2.76.3 Usage 
    
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
    
+
    Do not change the license information under which `centos-art.sh'
+script is released. Instead, if you think a different license must be
+used, please share your reasons at CentOS Developers mailing list.
+
    
 
-
      
-
    •  ...
-
    
 
+
+
     2.73.3 Usage 
    
 
-
-
     2.76.4 See also 
    
+
    
+
     centos-art sh --update-copyright='path/to/dir'
    
+
     centos-art sh --update-copyright='path/to/dir' --filter='regex'
    
+
    Use these commands to update copyright information in `.sh' files
+under `path/to/dir' directory. 
+
    
+
    
 
+
    When you provide `--filter='regex'' argument, the list of files
+to process is reduced as specified in `regex' regular expression.
+Inside `centos-art.sh' script, the `regex' regular
+expression is used in combination with find command to look
+for files matching the regular expression path pattern.
+
    
+
    Warning
    Warning
     In order for `regex' regular expression to match
+a file, the `regex' regular expresion must match the whole file
+path not just the file name. 
+
    
 
+
    For example, if you want to match all `render.conf.sh' files
+inside `path/to/dir', use the .+/render.conf regular
+expression.  Later, `centos-art.sh' script uses this value inside
+^$REGEX\.sh$ expression in order to build the final regular
+expression (i.e., ^.+/render.conf\.sh$) that is evaluated
+against available file paths inside the list of files to process.
+
    
+
    Exceptionally, when you provide `--filter='regex'' in the way
+that `regex', appended to `path/to/dir/' (i.e.
+`path/to/dir/regex'), matches a regular file; the
+`centos-art.sh' script uses the file matching as only file in the
+list of files to process. 
+
    
 
+
+
     2.73.4 See also 
    
 
+
+
+
    2.62 The `trunk/Scripts/Bash' Directory  
+
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_81.html b/Manual/repository-html/repository_81.html
index b3ce7c7..c444479 100644
--- a/Manual/repository-html/repository_81.html
+++ b/Manual/repository-html/repository_81.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: Index
+CentOS Artwork Repository: 2.74 The trunk/Scripts/Bash/Cli/Functions/Svg Directory
 
-
-
+
+
 
 
 
@@ -55,177 +55,255 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     Index 
    
-
    Jump to:   D
-   
-F
-   
-H
-   
-I
-   
-M
-   
-R
-   
-T
-   
-U
-   
-
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
     2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory 
    
+
+
+
+
     2.74.1 Goals 
    
+
+
    This section exists to organize files related to svg
+functionality of `centos-art.sh' script.
+
    
+
+
+
     2.74.2 Description 
    
+
+
    The svg functionality of `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 `trunk/Identity/Themes/Models/', and you want to set common
+metadata to all of them, and later remove all unused SVG defintions
+from `*.svg' files. Doing so file by file may be a tedious task,
+so the `centos-art.sh' script provides the svg
+functionality to aid you maintain such actions.
+
    
+
+
+
+
     2.74.2.1 Metadata maintainance 
    
+
+
    The metadata used is defined by Inkscape 0.46 using the SVG standard
+markup. The `centos-art.sh' script replaces everything
+in-between <metadata and </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 `=SOMETEXT=', where
+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 `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 `centos-art.sh' script is currently creating metadata
+information for.
+
    
+
    With metadata template instance in place, the `centos-art.sh'
+script uses it to replace real values inside all `.svg' files
+under the current location you're running the `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
+RET key, `centos-art.sh' uses its default value.
+
    
+
    The `centos-art.sh' script modifies the following metadata:
+
    
+
    
+
     `Title'
    
+
    Name by which this document is formally known. If no value is set
+here, `centos-art.sh' script uses the file name as title.
+
    
+
    
+
     `Date'
    
+
    Date associated with the creation of this document (YYYY-MM-DD). If no
+value is set here, `centos-art.sh' script uses the current date
+information as in date +%Y-%m-%d.
+
    
+
    
+
     `Creator'
    
+
    Name of entity primarily responsible for making the content of this
+document. If no value is set here, `centos-art.sh' script uses
+the string `The CentOS Project'.
+
    
+
    
+
     `Rights'
    
+
    Name of entity with rights to the intellectual Property of this
+document. If no value is set here, `centos-art.sh' script uses
+the string `The CentOS Project'.
+
    
+
    
+
     `Publisher'
    
+
    Name of entity responsible for making this document available. If no
+value is set here, `centos-art.sh' script uses the string
+`The CentOS Project'.
+
    
+
    
+
     `Identifier'
    
+
    Unique URI to reference this document. If no value is set here,
+`centos-art.sh' script uses the current file path to build the
+related url that points to current file location inside repository
+central server.
+
    
+
    
+
     `Source'
    
+
    Unique URI to reference the source of this document. If no value is
+set here, `centos-art.sh' script uses current file path to build
+the related url that points to current file location inside repository
+central server.
+
    
+
    
+
     `Relation'
    
+
    Unique URI to a related document. If no value is set here,
+`centos-art.sh' script uses current file path to build the
+related url that points to current file location inside repository
+central server.
+
    
+
    
+
     `Language'
    
+
    Two-letter language tag with optional subtags for the language of this
+document. (e.g. `en-GB'). If no value is set here,
+`centos-art.sh' script uses the current locale information as in
+cli_getCurrentLocale function.
+
    
+
    
+
     `Keywords'
    
+
    The topic of this document as comma-separated key words, prhases, or
+classifications. If no value is set here, `centos-art.sh' script
+uses file path to build 
+
    
+
    
+
     `Coverage'
    
+
    Extent or scope of this document. If no value is set here,
+`centos-art.sh' script uses the string `The CentOS Project'.
+
    
+
    
+
     `Description'
    
+
    Description about the document. If no value is set here,
+`centos-art.sh' script uses uses empty value as default.
+
    
+
    
+
     `Contributors'
    
+
    People that contributes in the creation/maintainance of the document.
+If no value is set here, `centos-art.sh' script uses uses empty
+value as default.
+
    
+
    
+
+
    The `License' metadatum is not set as a choise, by now. It is
+fixed 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.
+
    
+
+
+
+
     2.74.2.2 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 `Vacuum Defs' command
+in `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 `centos-art.sh' script uses Inkscape command-line
+interface, specifically with the `--vaccum-defs' option.
+
    
+
+
+
     2.74.3 Usage 
    
+
+
    
+
     centos-art svg --update-metadata='path/to/dir'
    
+
     centos-art svg --update-metadata='path/to/dir' --filter='regex'
    
+
    Use these commands to update metadata information to `.svg' files
+under `path/to/dir' directory.
+
    
+
    
+
     centos-art svg --vacuum-defs='path/to/dir'
    
+
     centos-art svg --vacuum-defs='path/to/dir' --filter='regex'
    
+
    Use these commands to remove unused definitions inside `.svg'
+files under `path/to/dir' directory. 
+
    
+
    
+
+
    When you provide `--filter='regex'' argument, the list of files
+to process is reduced as specified in `regex' regular expression.
+Inside `centos-art.sh' script, the `regex' regular
+expression is used in combination with find command to look
+for files matching the regular expression path pattern.
+
    
+
    Warning
    Warning
     In order for `regex' regular expression to match
+a file, the `regex' regular expresion must match the whole file
+path not just the file name. 
+
    
+
+
    For example, if you want to match all `summary.svg' files inside
+`path/to/dir', use the .+/summary regular expression.
+Later, `centos-art.sh' script uses this value inside
+^$REGEX\.svg$ expression in order to build the final regular
+expression (i.e., ^.+/summary\.svg$) that is evaluated against
+available file paths inside the list of files to process.
+
    
+
    Exceptionally, when you provide `--filter='regex'' in the way
+that `regex', appended to `path/to/dir/' (i.e.
+`path/to/dir/regex'), matches a regular file; the
+`centos-art.sh' script uses the file matching as only file in the
+list of files to process. 
+
    
+
+
+
     2.74.4 See also 
    
+
+
    Index Entry Section
     
    D
    Document convenctions1.1 Document Convenctions
     
    F
    Feedback1.2 Send in Your Feedback
    Filesystem branches2.1 The `branches' Directory
    Filesystem tags2.2 The `tags' Directory
    Filesystem trunk2.3 The `trunk' Directory
    Filesystem trunk Identity2.4 The `trunk/Identity' Directory
    Filesystem trunk Identity Brands2.5 The `trunk/Identity/Brands' Directory
    Filesystem trunk Identity Colors2.6 The `trunk/Identity/Colors' Directory
    Filesystem trunk Identity Fonts2.7 The `trunk/Identity/Fonts' Directory
    Filesystem trunk Identity Icons2.8 The `trunk/Identity/Icons' Directory
    Filesystem trunk Identity Isolinux2.9 The `trunk/Identity/Isolinux' Directory
    Filesystem trunk Identity Models2.10 The `trunk/Identity/Models' Directory
    Filesystem trunk Identity Models Css2.11 The `trunk/Identity/Models/Css' Directory
    Filesystem trunk Identity Models Html2.12 The `trunk/Identity/Models/Html' Directory
    Filesystem trunk Identity Models Img Promo Web2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory
    Filesystem trunk Identity Models Tpl2.14 The `trunk/Identity/Models/Tpl' Directory
    Filesystem trunk Identity Models Tpl Brands2.15 The `trunk/Identity/Models/Tpl/Brands' Directory
    Filesystem trunk Identity Models Tpl Promo Web2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory
    Filesystem trunk Identity Models Xcf2.17 The `trunk/Identity/Models/Xcf' Directory
    Filesystem trunk Identity Release2.18 The `trunk/Identity/Release' Directory
    Filesystem trunk Identity Themes2.19 The `trunk/Identity/Themes' Directory
    Filesystem trunk Identity Themes Models2.20 The `trunk/Identity/Themes/Models' Directory
    Filesystem trunk Identity Themes Models Alternative2.21 The `trunk/Identity/Themes/Models/Alternative' Directory
    Filesystem trunk Identity Themes Models Default2.22 The `trunk/Identity/Themes/Models/Default' Directory
    Filesystem trunk Identity Themes Models Default Concept2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory
    Filesystem trunk Identity Themes Models Default Distro2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory
    Filesystem trunk Identity Themes Models Default Distro Anaconda2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory
    Filesystem trunk Identity Themes Models Default Distro Firstboot2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory
    Filesystem trunk Identity Themes Models Default Distro Gdm2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory
    Filesystem trunk Identity Themes Models Default Distro Grub2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory
    Filesystem trunk Identity Themes Models Default Distro Gsplash2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory
    Filesystem trunk Identity Themes Models Default Distro Kdm2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory
    Filesystem trunk Identity Themes Models Default Distro Ksplash2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory
    Filesystem trunk Identity Themes Models Default Distro Rhgb2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory
    Filesystem trunk Identity Themes Models Default Distro Syslinux2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory
    Filesystem trunk Identity Themes Models Default Promo2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory
    Filesystem trunk Identity Themes Models Default Web2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory
    Filesystem trunk Identity Themes Motifs2.36 The `trunk/Identity/Themes/Motifs' Directory
    Filesystem trunk Identity Themes Motifs Flame2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory
    Filesystem trunk Identity Themes Motifs Modern2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Img2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Tpl2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Xcf2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory
    Filesystem trunk Identity Themes Motifs Modern Distro Anaconda Progress2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory
    Filesystem trunk Identity Themes Motifs Modern Palettes2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory
    Filesystem trunk Identity Themes Motifs TreeFlower2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory
    Filesystem trunk Identity Themes Motifs TreeFlower Backgrounds2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory
    Filesystem trunk Identity Widgets2.47 The `trunk/Identity/Widgets' Directory
    Filesystem trunk Locales2.48 The `trunk/Locales' Directory
    Filesystem trunk Locales Identity2.49 The `trunk/Locales/Identity' Directory
    Filesystem trunk Locales Identity Brands2.50 The `trunk/Locales/Identity/Brands' Directory
    Filesystem trunk Locales Identity Brands Tpl2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory
    Filesystem trunk Locales Identity Fonts2.52 The `trunk/Locales/Identity/Fonts' Directory
    Filesystem trunk Locales Identity Models2.53 The `trunk/Locales/Identity/Models' Directory
    Filesystem trunk Locales Identity Release2.54 The `trunk/Locales/Identity/Release' Directory
    Filesystem trunk Locales Identity Themes2.55 The `trunk/Locales/Identity/Themes' Directory
    Filesystem trunk Locales Identity Themes Backgrounds2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory
    Filesystem trunk Locales Identity Themes Distro Anaconda Progress2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory
    Filesystem trunk Locales Identity Widgets2.58 The `trunk/Locales/Identity/Widgets' Directory
    Filesystem trunk Manual2.59 The `trunk/Manual' Directory
    Filesystem trunk Manuals2.60 The `trunk/Manuals' Directory
    Filesystem trunk Scripts2.61 The `trunk/Scripts' Directory
    Filesystem trunk Scripts Bash2.62 The `trunk/Scripts/Bash' Directory
    Filesystem trunk Scripts Bash Cli2.63 The `trunk/Scripts/Bash/Cli' Directory
    Filesystem trunk Scripts Bash Cli Functions2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory
    Filesystem trunk Scripts Bash Cli Functions Help2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory
    Filesystem trunk Scripts Bash Cli Functions Html2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory
    Filesystem trunk Scripts Bash Cli Functions Identity2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory
    Filesystem trunk Scripts Bash Cli Functions Locale2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory
    Filesystem trunk Scripts Bash Cli Functions Manual2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory
    Filesystem trunk Scripts Bash Cli Functions Path2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory
    Filesystem trunk Scripts Bash Cli Functions Render2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory
    Filesystem trunk Scripts Bash Cli Functions Render Config2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory
    Filesystem trunk Scripts Bash Cli Functions Shell2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory
    Filesystem trunk Scripts Bash Cli Functions Svg2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory
    Filesystem trunk Scripts Bash Cli Functions Verify2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory
    Filesystem trunk Scripts Python2.76 The `trunk/Scripts/Python' Directory
     
    H
    How to render brands' translation files2.50.3 Usage
    How to render fonts' translation files2.52.3 Usage
     
    I
    Introduction1. Introduction
     
    M
    Metadata maintainance2.74.2 Description
     
    R
    Repository file system2. Repository File System
     
    T
    Translation brands file names2.50.2.1 Conventional file names
    Translation brands file names2.50.2.2 Numeric file names
     
    U
    Unused definitions2.74.2.1 Metadata maintainance
     
    
+
    2.62 The `trunk/Scripts/Bash' Directory  
+
    
 
    
-
    Jump to:   D
-   
-F
-   
-H
-   
-I
-   
-M
-   
-R
-   
-T
-   
-U
-   
-
    
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_82.html b/Manual/repository-html/repository_82.html
index 214ff7c..4c803ac 100644
--- a/Manual/repository-html/repository_82.html
+++ b/Manual/repository-html/repository_82.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: List of Figures
+CentOS Artwork Repository: 2.75 The trunk/Scripts/Bash/Cli/Functions/Verify Directory
 
-
-
+
+
 
 
 
@@ -55,49 +55,302 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
+
+
+
     2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory 
    
+
+
+
+
     2.75.1 Goals 
    
+
+
    This section exists to organize files related to `centos-art.sh'
+script `verify' functionality.  The `verify'
+functionality of `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.
+
    
+
+
+
     2.75.2 Description 
    
+
+
    The first time you download CentOS Artwork Repository you need to
+configure your workstation in order to use `centos-art.sh'
+script.  These preliminar configurations are based mainly on auxiliar
+RPM packages installation, symbolic links creations, and environment
+variables definitions.  The `verify' functionality of
+`centos-art.sh' script guides you through this preliminar
+configuration process.  
+
    
+
    If this is the first time you run `centos-art.sh' script, the
+appropriate way to use its `verify' functionality is not using
+the `centos-art.sh' script directly, but the absolute path to
+centos-art.sh script instead (i.e.,
+`~/artwork/trunk/Scripts/Bash/centos-art.sh').  This is necessary
+because `centos-art' symbolic link, under `~/bin/'
+directory, has not been created yet.
+
    
+
+
+
     2.75.2.1 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 centos-art.sh script uses are shipped with
+CentOS distribution, and can be installed from CentOS base repository.
+The only exception is `inkscape', the package we use to
+manipulate SVG files.  The `inkscape' package is not inside
+CentOS distribution so it needs to be installed from third party
+repositories.
+
    
+
    info
    Note
     Configuration of third party repositories inside CentOS
+distribution is described in CentOS wiki, specifically in the
+following URL:
+http://wiki.centos.org/AdditionalResources/Repositories
+
    
+
+
    Before installing packages, the `centos-art.sh' script uses
+sudo to request root privileges to execute yum
+installation functionality.  If your user isn't defined as a
+privileged user--at least to run yum commands-- inside
+`/etc/sudoers' configuration file, you will not be able to
+perform package installation tasks as set in `centos-art.sh'
+script `verify' functionality. 
+
    
+
    Setting sudo privileges to users is an administrative task you have to
+do by yourself. If you don't have experience with sudo
+command, please read its man page running the command: man
+sudo. This reading will be very useful, and with some practice, you
+will be able to configure your users to have sudo
+privileges.
+
    
+
+
+
     2.75.2.2 Links 
    
+
+
    Creation of symbolic links helps us to alternate between different
+implementations of `centos-art.sh' script-line (e.g.,
+`centos-art.sh', for Bash implementation; `centos-art.py',
+for Python implementation; `centos-art.pl', for Perl
+implementation; and so on for other implementations). The
+`centos-art.sh' script-line definition takes place inside your
+personal binary (`~/bin/') directory in order to make the script
+implementation --the one that `centos-art' links to-- available
+to 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 `centos-art.sh'
+script functionalities available outside `trunk/' repository
+directory structure, but at its same level in repository tree. This is
+useful if you need to use the "render" functionality of
+centos-art.sh under `branches/' repository directory
+structure as you usually do inside `trunk/' repository directory
+structure. As consequence of this configuration, automation scripts
+cannot be branched under `branches/Scripts' directory structure.
+
    
+
+
+
     2.75.2.3 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 `~/.bash_profile' file.  The
+`verify' functionality of `centos-art.sh' script doesn't
+modify your `~/.bash_profile' file.  
+
    
+
    The `verify' functionality of `centos-art.sh' script
+evaluates the following environment variables:
+
    
+
    
+
     EDITOR
    
+
    Default text editor. 
+
    
+
    The `centos-art.sh' script uses default text EDITOR to edit
+pre-commit subversion messages, translation files, configuration
+files, script files, and similar text-based files.
+
    
+
    If EDITOR environment variable is not set, `centos-art.sh'
+script uses `/usr/bin/vim' as default text editor. Otherwise, the
+following values are recognized by `centos-art.sh' script:
+
    
+
      
+
    •  `/usr/bin/vim'
+
    •  `/usr/bin/emacs'
+
    •  `/usr/bin/nano'
+
    
+
+
    If no one of these values is set in EDITOR environment variable,
+`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
+
    
+
    
+
     TEXTDOMAIN
    
+
    
+
    Default domain used to retrieve translated messages.  This variable is
+set in `initFunctions.sh' and shouldn't be changed.
+
    
+
    
+
     TEXTDOMAINDIR
    
+
    
+
    Default directory used to retrieve translated messages.  This variable
+is set in `initFunctions.sh' and shouldn't be changed.
+
    
+
    
+
     LANG
    
+
    
+
    Default locale information.
+
    
+
    This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+`Language' step; or once installed using the
+system-config-language tool.
+
    
+
    The `centos-art.sh' script uses the LANG environment
+variable to know in which language the script messages are printed
+out.
+
    
+
    
+
     TZ
    
+
    
+
    Default time zone representation.
+
    
+
    This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+`Date and time' step; or once installed using the
+system-config-date tool.
+
    
+
    The `centos-art.sh' script doesn't use the 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 TZ variable may be
+necessary.
+
    
+
    Convenction
    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.
+
    
+
+
    The format of TZ environment variable is described in
+`tzset(3)' manual page.
+
    
+
    
+
    
+
+
 
-
     List of Figures 
    
-
    
-
    Figure 2.1
    The functionalities initialization environment.
-
    
-
    Figure 2.2
    The actions initialization environment.
-
    
-
    Figure 2.3
    The cli_commitRepoChanges function output.
-
    
-
    Figure 2.4
    The functions script base comment structure
-
    
-
    Figure 2.5
    The function script comment example
-
    
+
     2.75.3 Usage 
    
+
+
    
+
     centos-art verify --packages
    
+
    
+
    Verify required packages your workstation needs in order to run the
+`centos-art.sh' script correctly.  If there are missing packages,
+the `centos-art.sh' script asks you to confirm their
+installation. When installing packages, the `centos-art.sh'
+script uses the yum application in order to achieve the
+task.
+
    
+
    In case all packages required by `centos-art.sh' script are
+already installed in your workstation, the message `The required
+packages are already installed.' is output for you to know. 
+
    
+
    
+
     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
+centos-art.sh script asks you to confirm their installation.
+To install required links, the centos-art.sh script uses the
+ln command.
+
    
+
    In case all links required by `centos-art.sh' script are already
+created in your workstation, the message `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 `centos-art.sh' script outputs the `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 `centos-art.sh'
+script will fall into a continue installation request for that missing
+link.  To end this continue request you can answer `No', or
+remove the existent regular file to let `centos-art.sh' script
+install the link on its place.
+
    
+
    
+
     centos-art verify --environment
    
+
     centos-art verify --environment --filter='regex'
    
+
    
+
    Output a brief description of environment variables used by
+`centos-art.sh' script. 
+
    
+
    If `--filter' option is provided, output is reduced as defined in
+the `regex' regular expression value. If `--filter' option
+is specified but `regex' value is not, the `centos-art.sh'
+script outputs information as if `--filter' option had not been
+provided at all.  
+
    
+
    
 
    
 
 
+
+
     2.75.4 See also 
    
+
+
+
+
    2.62 The `trunk/Scripts/Bash' Directory  
+
    
+
+
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_83.html b/Manual/repository-html/repository_83.html
new file mode 100755
index 0000000..9e08b47
--- /dev/null
+++ b/Manual/repository-html/repository_83.html
@@ -0,0 +1,126 @@
+
+
+
+
+
+
+CentOS Artwork Repository: 2.76 The trunk/Scripts/Python Directory
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]            [Top][Contents][Index][ ? ]
    
+
+
+
     2.76 The `trunk/Scripts/Python' Directory 
    
+
+
+
+
     2.76.1 Goals 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.76.2 Description 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.76.3 Usage 
    
+
+
      
+
    •  ...
+
    
+
+
+
+
     2.76.4 See also 
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]
    
+
    
+ 
+  This document was generated on March, 22 2011 using texi2html 1.76.
+ 
+ 
    
+
+
    
+
+
diff --git a/Manual/repository-html/repository_84.html b/Manual/repository-html/repository_84.html
new file mode 100755
index 0000000..fec85a9
--- /dev/null
+++ b/Manual/repository-html/repository_84.html
@@ -0,0 +1,249 @@
+
+
+
+
+
+
+CentOS Artwork Repository: Index
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]            [Top][Contents][Index][ ? ]
    
+
+
+
     Index 
    
+
    Jump to:   A
+   
+C
+   
+D
+   
+F
+   
+H
+   
+I
+   
+M
+   
+R
+   
+T
+   
+U
+   
+
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    Index Entry Section
     
    A
    Authors1.2 Authors
     
    C
    Copying conditions1.3 Copying Conditions
     
    D
    Document convenctions1.4 Document Convenctions
     
    F
    Feedback1.5 Send in Your Feedback
    Filesystem branches2.1 The `branches' Directory
    Filesystem tags2.2 The `tags' Directory
    Filesystem trunk2.3 The `trunk' Directory
    Filesystem trunk Identity2.4 The `trunk/Identity' Directory
    Filesystem trunk Identity Brands2.5 The `trunk/Identity/Brands' Directory
    Filesystem trunk Identity Colors2.6 The `trunk/Identity/Colors' Directory
    Filesystem trunk Identity Fonts2.7 The `trunk/Identity/Fonts' Directory
    Filesystem trunk Identity Icons2.8 The `trunk/Identity/Icons' Directory
    Filesystem trunk Identity Isolinux2.9 The `trunk/Identity/Isolinux' Directory
    Filesystem trunk Identity Models2.10 The `trunk/Identity/Models' Directory
    Filesystem trunk Identity Models Css2.11 The `trunk/Identity/Models/Css' Directory
    Filesystem trunk Identity Models Html2.12 The `trunk/Identity/Models/Html' Directory
    Filesystem trunk Identity Models Img Promo Web2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory
    Filesystem trunk Identity Models Tpl2.14 The `trunk/Identity/Models/Tpl' Directory
    Filesystem trunk Identity Models Tpl Brands2.15 The `trunk/Identity/Models/Tpl/Brands' Directory
    Filesystem trunk Identity Models Tpl Promo Web2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory
    Filesystem trunk Identity Models Xcf2.17 The `trunk/Identity/Models/Xcf' Directory
    Filesystem trunk Identity Release2.18 The `trunk/Identity/Release' Directory
    Filesystem trunk Identity Themes2.19 The `trunk/Identity/Themes' Directory
    Filesystem trunk Identity Themes Models2.20 The `trunk/Identity/Themes/Models' Directory
    Filesystem trunk Identity Themes Models Alternative2.21 The `trunk/Identity/Themes/Models/Alternative' Directory
    Filesystem trunk Identity Themes Models Default2.22 The `trunk/Identity/Themes/Models/Default' Directory
    Filesystem trunk Identity Themes Models Default Concept2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory
    Filesystem trunk Identity Themes Models Default Distro2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory
    Filesystem trunk Identity Themes Models Default Distro Anaconda2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory
    Filesystem trunk Identity Themes Models Default Distro Firstboot2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory
    Filesystem trunk Identity Themes Models Default Distro Gdm2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory
    Filesystem trunk Identity Themes Models Default Distro Grub2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory
    Filesystem trunk Identity Themes Models Default Distro Gsplash2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory
    Filesystem trunk Identity Themes Models Default Distro Kdm2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory
    Filesystem trunk Identity Themes Models Default Distro Ksplash2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory
    Filesystem trunk Identity Themes Models Default Distro Rhgb2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory
    Filesystem trunk Identity Themes Models Default Distro Syslinux2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory
    Filesystem trunk Identity Themes Models Default Promo2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory
    Filesystem trunk Identity Themes Models Default Web2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory
    Filesystem trunk Identity Themes Motifs2.36 The `trunk/Identity/Themes/Motifs' Directory
    Filesystem trunk Identity Themes Motifs Flame2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory
    Filesystem trunk Identity Themes Motifs Modern2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Img2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Tpl2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory
    Filesystem trunk Identity Themes Motifs Modern Backgrounds Xcf2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory
    Filesystem trunk Identity Themes Motifs Modern Distro Anaconda Progress2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory
    Filesystem trunk Identity Themes Motifs Modern Palettes2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory
    Filesystem trunk Identity Themes Motifs TreeFlower2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory
    Filesystem trunk Identity Themes Motifs TreeFlower Backgrounds2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory
    Filesystem trunk Identity Widgets2.47 The `trunk/Identity/Widgets' Directory
    Filesystem trunk Locales2.48 The `trunk/Locales' Directory
    Filesystem trunk Locales Identity2.49 The `trunk/Locales/Identity' Directory
    Filesystem trunk Locales Identity Brands2.50 The `trunk/Locales/Identity/Brands' Directory
    Filesystem trunk Locales Identity Brands Tpl2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory
    Filesystem trunk Locales Identity Fonts2.52 The `trunk/Locales/Identity/Fonts' Directory
    Filesystem trunk Locales Identity Models2.53 The `trunk/Locales/Identity/Models' Directory
    Filesystem trunk Locales Identity Release2.54 The `trunk/Locales/Identity/Release' Directory
    Filesystem trunk Locales Identity Themes2.55 The `trunk/Locales/Identity/Themes' Directory
    Filesystem trunk Locales Identity Themes Backgrounds2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory
    Filesystem trunk Locales Identity Themes Distro Anaconda Progress2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory
    Filesystem trunk Locales Identity Widgets2.58 The `trunk/Locales/Identity/Widgets' Directory
    Filesystem trunk Manual2.59 The `trunk/Manual' Directory
    Filesystem trunk Manuals2.60 The `trunk/Manuals' Directory
    Filesystem trunk Scripts2.61 The `trunk/Scripts' Directory
    Filesystem trunk Scripts Bash2.62 The `trunk/Scripts/Bash' Directory
    Filesystem trunk Scripts Bash Cli2.63 The `trunk/Scripts/Bash/Cli' Directory
    Filesystem trunk Scripts Bash Cli Functions2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory
    Filesystem trunk Scripts Bash Cli Functions Help2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory
    Filesystem trunk Scripts Bash Cli Functions Html2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory
    Filesystem trunk Scripts Bash Cli Functions Identity2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory
    Filesystem trunk Scripts Bash Cli Functions Locale2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory
    Filesystem trunk Scripts Bash Cli Functions Manual2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory
    Filesystem trunk Scripts Bash Cli Functions Path2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory
    Filesystem trunk Scripts Bash Cli Functions Render2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory
    Filesystem trunk Scripts Bash Cli Functions Render Config2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory
    Filesystem trunk Scripts Bash Cli Functions Shell2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory
    Filesystem trunk Scripts Bash Cli Functions Svg2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory
    Filesystem trunk Scripts Bash Cli Functions Verify2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory
    Filesystem trunk Scripts Python2.76 The `trunk/Scripts/Python' Directory
     
    H
    History1.1 History
    How to render brands' translation files2.50.3 Usage
    How to render fonts' translation files2.52.3 Usage
     
    I
    Introduction1. Introduction
     
    M
    Metadata maintainance2.74.2 Description
     
    R
    Repository file system2. Repository File System
     
    T
    Translation brands file names2.50.2.1 Conventional file names
    Translation brands file names2.50.2.2 Numeric file names
     
    U
    Unused definitions2.74.2.1 Metadata maintainance
     
    
+
    Jump to:   A
+   
+C
+   
+D
+   
+F
+   
+H
+   
+I
+   
+M
+   
+R
+   
+T
+   
+U
+   
+
    
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]
    
+
    
+ 
+  This document was generated on March, 22 2011 using texi2html 1.76.
+ 
+ 
    
+
+
    
+
+
diff --git a/Manual/repository-html/repository_85.html b/Manual/repository-html/repository_85.html
new file mode 100755
index 0000000..e6b7979
--- /dev/null
+++ b/Manual/repository-html/repository_85.html
@@ -0,0 +1,106 @@
+
+
+
+
+
+
+CentOS Artwork Repository: List of Figures
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]            [Top][Contents][Index][ ? ]
    
+
+
+
     List of Figures 
    
+
    
+
    Figure 2.1
    The functionalities initialization environment.
+
    
+
    Figure 2.2
    The actions initialization environment.
+
    
+
    Figure 2.3
    The cli_commitRepoChanges function output.
+
    
+
    Figure 2.4
    The functions script base comment structure
+
    
+
    Figure 2.5
    The function script comment example
+
    
+
    
+
+
+
+
+
+
+
+
+
+
    [ < ][ > ]   [ << ][ Up ][ >> ]
    
+
    
+ 
+  This document was generated on March, 22 2011 using texi2html 1.76.
+ 
+ 
    
+
+
    
+
+
diff --git a/Manual/repository-html/repository_9.html b/Manual/repository-html/repository_9.html
index 36cb992..9f27ba4 100644
--- a/Manual/repository-html/repository_9.html
+++ b/Manual/repository-html/repository_9.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.5 The trunk/Identity/Brands Directory
+CentOS Artwork Repository: 2.2 The tags Directory
 
-
-
+
+
 
 
 
@@ -55,58 +55,70 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 
    
-
-
-
     2.5 The `trunk/Identity/Brands' Directory 
    
+
+
+
     2.2 The `tags' Directory 
    
 
 
-
-
     2.5.1 Goals 
    
+
+
     2.2.1 Goals 
    
 
-
      
-
    •  ...
-
    
+
    This directory implements the Subversion's tags concept in a trunk,
+branches, tags repository structure.
+
    
 
+
+
     2.2.2 Description 
    
 
-
-
     2.5.2 Description 
    
+
    The `tags/' directory structre provides frozen branches.
+Generally, we use frozen branches to make check-points in time for
+development lines under `branches/' or `trunk/' directory
+structure.
+
    
 
+
+
     2.2.3 Usage 
    
 
-
-
     2.5.3 Usage 
    
+
    The `tags/' directory structure is unused, so far.
+
    
 
+
+
     2.2.4 See also 
    
 
-
-
     2.5.4 See also 
    
+
 
 
 
 
-
-
+
+
-
-
-
+
+
+
    [ < ][ > ]
    [ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
 
    
 
    
  
-  This document was generated on March, 11 2011 using texi2html 1.76.
+  This document was generated on March, 22 2011 using texi2html 1.76.
  
  
    
 
diff --git a/Manual/repository-html/repository_abt.html b/Manual/repository-html/repository_abt.html
index d53a26e..d83cc9b 100644
--- a/Manual/repository-html/repository_abt.html
+++ b/Manual/repository-html/repository_abt.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
-
+
 
-
+