From 4a9d2a24772af85678363fc1f03624fd509f3bb9 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Feb 25 2011 21:30:48 +0000 Subject: Update Repository documentation manual. --- diff --git a/Manuals/Repository/repository-html/repository.html b/Manuals/Repository/repository-html/repository.html index 15b1fe6..1761831 100644 --- a/Manuals/Repository/repository-html/repository.html +++ b/Manuals/Repository/repository-html/repository.html @@ -9,7 +9,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: 3.34 trunk/Manuals +CentOS Artwork Repository: 3.34 trunk/Locales - - + + @@ -57,61 +57,666 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] - + -

3.34 trunk/Manuals

+

3.34 trunk/Locales

3.34.1 Goals

+

The `trunk/Translations' directory exists to: +

3.34.2 Description

+

When you create artwork for CentOS distribution you find that some +artworks need to be created for different major releases of CentOS +distribution and inside each major release that needs to be created for +different locales. To get an approximate idea of how many files we are +talking about, consider the followig approximate statistic: +

+

In order to aliviate maintainance of artwork production for such +environment, we divided artwork production in three production lines: +

+
    +
  1. See section trunk/Identity/Themes/Models, to define artworks +characteristics (e.g., dimensions, position on the screen, etc.). +
  2. See section trunk/Identity/Themes/Motifs, to define artworks visual +styles (e.g., the look and feel). +
  3. Translations, to define which major releases and locales +artworks are produced for. +
+ +

Inside CentOS Artwork Repository, the artworks' translation production +line is stored under `trunk/Translations' directory. +

+

Inside `trunk/Translations' directory, we use "translation +entries" to organize artworks' "translation files" and artworks' +"translation templates". +

-

3.34.3 Usage

+

3.34.2.1 Translation Entries

- +

Translation entries exists for each artwork you want to produce. +Translation entries can be empty directories, or directories +containing translation files and translation templates. +

+

When translation entries are empty directories, the identity entry is +used as reference to create file names and directories layout for +rendered files. In this case, the centos-art script takes +one design template and outputs one non-translated file for each +design template available. This configuration is mainly used to +produce non-translatable artworks like themes' backgrounds. +

+

When translation entries contain translation files, the translation +entry implements the CentOS release schema and is used as reference to +create file names and directories layout for translated artworks. In +this case, the centos-art script applies one translation +file to one design template to create one translated instance which is +used to output one translated file. When the translated file is +rendered, the centos-art script remove the previous instance +and takes the next file in the list of translation files to repate the +whole process once again, and so on for all files in the list. This +configuration is mainly used to produce translatable artworks like +Anaconda progress slide images. +

+

To find out correspondence between translation entries and identity +entries, you need to look the path of both translation entries and +identity entries. For example, if you are using the Modern +artisitic motif, the identity entry for Anaconda progress artwork is: +

+
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
+
+

and its translation entry is: +

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+
+

Note how the `Translations/' directory prefixes `Identity/' +directory, also how static values (e.g., Identity, Themes, Distro, +etc.) in the identity entry path remain in translation entry path, and +how variable values like theme names (e.g., Modern) are stript +out from translation entry path. The same convenction can be applied +to other identity entries in order to determine their translation +entries, or to other translation entries to determine their identity +entries. +

+
info

Note

Translation entries related to identity entries under +`trunk/Identity/Themes/Motifs' do not use `Motifs/' in the +path. We've done this because `trunk/Identity/Themes/Models' +structure, the other structure under `trunk/Identity/Themes', +doesn't require translation paths so far. So in the sake of saving +characters space when building translation entries for +`trunk/Identity/Themes/Motifs' structure, we organize Motifs +translation entries under `trunk/Translations/Identity/Themes/' +directly. +

+

If for some reason `trunk/Identity/Themes/Models' structure +requires translation entries, we need to re-oraganize the current +directory structure accordingly. +

+

Translation entries, as described above, can be re-used by similar +identity entries. For example the following identity entries: +

+
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
+trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Progress/
+trunk/Identity/Themes/Motifs/Mettle/Distro/Anaconda/Progress/
+
+

are all valid identity entries able to re-use translation files inside +Anaconda progress translation entry (the one shown in our example +above). This way, you can create several identity entries and maintain +just one translation entry for all of them. Once you change the +translation files inside the common translation entry, changes inside +identity entries will take effect inside the next you render them. +

+

Trying to make things plain and simple: inside CentOS Artwork +Repository, graphic designers can concentrate their efforts in +artworks look and feel (the identity entries), and translators in +artworks translations (the translation entries). +

+

3.34.2.2 Translation Markers

+

+ +

+

Translation markers are used in "Theme Model Designs" and +"Translation Files" as replacement patterns to commit content +translation. When you are rendering content using +centos-art script inisde `trunk/Identity' structure, +artistic motifs and translation files are applied to model designs to +produce translated content as result. In order to have the appropriate +translation in content rendered, markers defintion in translation +files should match markers in model designs exactly. +

+

Translation markers can be whatever text you want, but as convenction +we use the following to represent releases of CentOS distribution: +

+
+
`=MINOR_RELEASE='
+

Replace with minor release of CentOS distribution. In the schema M.N, the minor +release is represented by the N letter. +

+
`=MAJOR_RELEASE='
+

Replace with major release of CentOS distribution. In the schema M.N, +the major release is represented by the M letter. +

+
`=RELEASE='
+

Replace the full release of CentOS distribution. It is +`=MAJOR_RELEASE=.=MINOR_RELEASE=' basically. +

+
+ +

Specific translation markers convenctions are described inside +specific translation entries. Read translation entries documentation +to know more about supported translation markers. +

+

Translation markers standardization creates a common point of +reference for translators and graphic designers. To have translation +markers well defined makes possible that translators and graphic +designers can work together but independently one another. +

+ + +

3.34.2.3 Translation Files

+ +

Translation files are text files with sed commands inside, +replacement commands mainly. As convenction, translation file names +end in `.sed'. Translation files are used by centos-art +script to produce translated artworks for specific major releases of +CentOS Distribution. There are common translation files, specific +translation, and template translation files. +

+

For example, the Firstboot artwork of CentOS distribution uses the +images `splash-small.png' and `firstboot-left.png' as based +to control its visual style. The `splash-small.png' image +contains, in its graphic design, the release number information of +CentOS distribution. So the `splash-small.png' is +release-specific. In the other hand, the `firstboot-left.png' +doesn't contain release number information. So the +`firstboot-left.png' is not release-specific. +

+

If we want to produce Firstboot artwork for different major releases +of CentOS distribution, using a monolithic visual identity, all +Firstboot images should have the same visual style and, at the same +time, the release-specific information in the release-specific images. +

+
info

Note

The monolithic visual identity is implemented using +theme models (see section trunk/Identity/Themes/Models) and artistic +motifs (see section trunk/Identity/Themes/Motifs). +

+ +

Assuming that both theme models and theme motifs are ready for using, +the initial translation entry to produce Firstboot artworks would look +like the following: +

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+
+

With the translation entry above, centos-art command is able +to produce the image `firstboot-left.png' only. To produce +`splash-small.png' images for major releases (e.g., 3, 4, 5, and +6) of CentOS distribution we need to produce the release-specific +translation files using the centos-art script as following: +

+
centos-art render --entry=/home/centos/artwork/trunk/Translations/Identity/Themes/BootUp/Firstboot --filter='3,4,5,6'
+
+

The above command produces the following translation entiry: +

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+
+

At this point centos-art is able to produce the Firstboot +artwork images for major releases of CentOS distribution. To add new +release-specific translation files, run the translation rendering +command with the release number you want to produce translation files +for in the `--filter='release-number'' argument. +

+ + +

3.34.2.4 Template Translation Files

+ +

Template translation files are translation files stored inside +translation template directory. Template translation files are used by +centos-art script to produce specific translation files +only. Template translation files may be empty or contain sed +replacement commands. If template translation files are empty files, +the final specifc translation file built from it contains +release-specific replacement commands only. For example, see the +following translation entry: +

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed    <-- template translation file.
+`-- firstboot-left.sed
+
+

In the above exmaple, the `splash-small.sed' file is a template +translation file and looks like: +

+
# -------------------------------------
+# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
+# -------------------------------------
+
+

In the above template translation file there are three comments lines, +but when you render it, the centos-art adds the +release-specific replacement commands. In our Firstboot example, after +rendering Firstboot translation entry, the `splash-small.sed' +translation file specific to CentOS 5, looks like the following: +

+
# Warning: Do not modify this file directly. This file is created
+# automatically using 'centos-art' command line interface.  Any change
+# you do in this file will be lost the next time you update
+# translation files using 'centos-art' command line interface. If you
+# want to improve the content of this translation file, improve its
+# template file instead and run the 'centos-art' command line
+# interface later to propagate your changes.
+# -------------------------------------
+# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
+# -------------------------------------
+
+# Release number information.
+s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
+s!=MINOR_RELEASE=!0!g
+s!=MAJOR_RELEASE=!5!g
+
+

If template translation files are not empty, replacement commands +inside template translation files are preserved inside +release-specific translation files. For example, consider the English +template translation file of Anaconda progress welcome slide. The +translation template directory structure looks like the following: +

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+`-- Tpl
+    `-- en
+        `-- 01-welcome.sed
+
+

and if we render translation files for CentOS 4 and CentOS 5 major +releases, the translation entry would look like the following: +

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+|-- 4
+|   `-- en
+|       `-- 01-welcome.sed
+|-- 5
+|   `-- en
+|       `-- 01-welcome.sed
+`-- Tpl
+    `-- en
+        `-- 01-welcome.sed
+
+
info

Note

Release-specific translation directories preserve +template translation directory structure and file names. +

+ +

In the example above, the template translation file looks like the +following: +

+
# ------------------------------------------------------------
+# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
+# ------------------------------------------------------------
+s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
+s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
+s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor./
+s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. CentOS mainly changes packages to remove upstream vendor branding and artwork./
+s/=TEXT4=//
+s/=TEXT5=//
+s/=TEXT6=//
+s!=URL=!http://www.centos.org/!
+
+

and, after render the translation entry, specific translation files +look like the following: +

+
# Warning: Do not modify this file directly. This file is created
+# automatically using 'centos-art' command line interface.  Any change
+# you do in this file will be lost the next time you update
+# translation files using 'centos-art' command line interface. If you
+# want to improve the content of this translation file, improve its
+# template file instead and run the 'centos-art' command line
+# interface later to propagate your changes.
+# ------------------------------------------------------------
+# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
+# ------------------------------------------------------------
+
+s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
+s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
+s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominen t North American Enterprise Linux vendor./
+s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. Cent OS mainly changes packages to remove upstream vendor branding and artwork./
+s/=TEXT4=//
+s/=TEXT5=//
+s/=TEXT6=//
+s!=URL=!http://www.centos.org/!
+
+# Release number information.
+s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
+s!=MINOR_RELEASE=!0!g
+s!=MAJOR_RELEASE=!5!g
+
+

In the example above, relevant lines begin with the `s' word +followed by a separation character (e.g., `/', `!', etc.). +These lines have the following format: +

+
s/REGEXP/REPLACEMENT/FLAGS
+
+

The `/' characters may be uniformly replaced by any other single +character within any given s command. The `/' +character (or whatever other character is used in its stead) can +appear in the REGEXP or REPLACEMENT only if it is preceded by a +`\' character. +

+

The s command is probably the most important in +sed and has a lot of different options. Its basic concept +is simple: the s command attempts to match the pattern space +against the supplied REGEXP; if the match is successful, then that +portion of the pattern space which was matched is replaced with +REPLACEMENT. +

+

In the context of our translation files, the REGEXP is where you +define translation markers and REPLACEMENT where you define the +translation text you want to have after artworks rendering. Sometimes +we use the FLAG component with the `g' command to apply the +replacements globally. +

+
Info

Tip

More information about how to use sed +replacement commands and flags is available in sed +documentation manual. To read sed documentation manual type +the following command: +

info sed
+
+ +

Inside translation files, you can use translation markers not only +inside the REGEXP but in the REPLACEMENT too. In order for this +configuration to work, the REPLACEMENT of translation markers needs to +be define after its definition. For example, see in the +release-specific translation file above, how the +`s!=MAJOR_RELASE=!5!g' replacement command is defined +after `=MAJOR_RELASE=' translation marker definition in +the REPLACEMENT of `=TITLE=' translation marker replacement +command. +

+ + +

3.34.2.5 Common Translation Files

+ +

Common translation files contain common translations or no +translation at all for their related artworks. They are in the root +directory of the translation entry. Common translation files create +common artworks for all major releases of CentOS Distribution. +

+

Translation entries, with common translation files inside, look like +the following: +

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed      <-- common translation file.
+
+ + +

3.34.2.6 Specific Translation Files

+ +

Specific translation files contain specific translations for their +related artworks. Specific translation files are not in the root +directory of the translation entry, but inside directories which +describe the type of translation they are doing. Specific translation +files are produced automatically using the centos-art +script. +

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed    <-- CentOS 3 specific translation file.
+|-- 4
+|   `-- splash-small.sed    <-- CentOS 4 specific translation file.
+|-- 5
+|   `-- splash-small.sed    <-- CentOS 5 specific translation file.
+|-- 6
+|   `-- splash-small.sed    <-- CentOS 6 specific translation file.
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+
+ + +

3.34.2.7 Translation Rendering

+ +

When rendering translations, the centos-art script checks +the translation entry to verify that it has a translation template +directory inside. The translation template directory (`Tpl/') +contains common translation files used to build release-specific +translation files. If the translation template directory doesn't exist +inside the translation entry the translation rendering fails. In this +case the centos-art script outputs a message and quits +script execution. +

+ + +

3.34.2.8 Translation (Pre-)Rendering Configuration Scripts

+ +

When the centos-art script finds a translation template +directory inside translation entry, it looks for translations +pre-rendering configuration scripts for that translation entry. +Translation pre-rendering configuration scripts let you extend +translation default functionality (described below). +

+

Translation pre-rendering configuration scripts are stored under +`trunk/Scripts' directory, specifically under the appropriate +language implementation. If you are using centos-art Bash +implementation, the translation pre-rendering scripts are store in the +`trunk/Scripts/Bash/Config' location; if you are using +centos-art Python implementation, then translation +pre-rendering scripts are stored in the +`trunk/Scripts/Python/Config' location, and so on for other +implementations. +

+

Bash translation pre-rendering configuration scripts look like the +following: +

+
#!/bin/bash
+#
+# render_loadConfig.sh -- brief description here.
+#
+# Copyright (C) YEAR YOURNAME
+# 
+# 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: render_loadConfig.sh 94 2010-09-18 10:59:42Z al $
+# ----------------------------------------------------------------------
+
+function render_loadConfig {
+...
+}
+
+

Translation pre-rendering scripts are function scripts loaded and +executed when rendering a translation entry. Translation pre-rendering +scripts are loaded using the translation entry being rendered as +reference. For example, suppose you are using the +centos-art Bash implementation, and you are rendering +translations for CentOS brands, in this situation the translation +entry would be: +

+
trunk/Translations/Identity/Brands
+
+

and the entry inside the translation pre-rendering configuration +structure would be: +

+
trunk/Scripts/Bash/Config/Identity/Brands
+
+

Once the centos-art script detects that translation +pre-rendering configuration directory exists, the centos-art +script looks for the translation pre-rendering configuration file. If +the translation pre-rendering configuration file exists, it is loaded +and executed. Once the translation pre-rendering configuration file +has been executed the translation rendering process is over, and so +the script execution. +

+
info

Note

Translation pre-rendering configuration files have the +following form: +

render.conf.extension
+

where `extension' refers the programming language implementation +you are using. For example, `sh' for Bash, `py' for Python, +`pl' for Perl, and so on for other implementations. +

+ +

As we are using Bash implementation to describe the translation +pre-rendering configuration example, the translation pre-rendering +configuration file that centos-art looks for, inside the +above translation pre-rendering configuration directory, is +`render.conf.sh'. +

+ + +

3.34.2.9 Translation Rendering Default Functionality

+ +

In the other hand, if the translation pre-rendering configuration file +doesn't exist, or it isn't written as function script, the +centos-art script ignore translation pre-rendering +configuration functionality and passes to render translation using +default functionality instead. +

+

The translation rendering default functionality takes template +translation directory structure, duplicates it for each release number +specified in the `--filter='release-number'' argument and +produces release-specific directories. As part of template translation +duplication process take place, the centos-art script adds +release-specific replacement commands for each specific translation +file inside release-specific directories. As result, specific +translation files, inside release-specific directories, contain +template translation replacement commands plus, +release-specific replacement commands. +

+
info

Note

Release-specific replacement commands are standardized +inside centos-art script using predifined release +translation markers. Release translation markers are described in the +translation marker section +(see Translation Markers). +

+ + + + +

3.34.3 Usage

+ +
+
`centos-art render --entry='path/to/dir''
+
+

When `path/to/dir' refers one directory under +`trunk/Translations', this command orverwrites available +translation files using translation templates. +

+
+
`centos-art render --entry='path/to/dir' --filter='pattern''
+
+

When `path/to/dir' refers one directory under +`trunk/Translations', this command renders release-specific +translation files as you specify in the `--filter='pattern'' +argument. In this case, `pattern' not a regular expression but an +number (e.g., `5') or a list of numbers separated by commas +(e.g., `3,4,5,6') that specify the major release of CentOS +distribution you want to render translations for. +

+
+ + +

3.34.4 See also

+ + + + + + + +
3.63 trunk/Translations/Identity/Brands   +
3.65 trunk/Translations/Identity/Fonts   +
3.66 trunk/Translations/Identity/Models   +
3.67 trunk/Translations/Identity/Release   +
3.68 trunk/Translations/Identity/Themes   +
3.1 trunk/Identity   +
- - + + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_38.html b/Manuals/Repository/repository-html/repository_38.html index 9710d51..7e21be7 100644 --- a/Manuals/Repository/repository-html/repository_38.html +++ b/Manuals/Repository/repository-html/repository_38.html @@ -9,7 +9,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: 3.35 trunk/Scripts +CentOS Artwork Repository: 3.35 trunk/Locales/Identity - - + + @@ -52,38 +52,35 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.35 trunk/Scripts

+ + +

3.35 trunk/Locales/Identity

- +

3.35.1 Goals

-

The `trunk/Scripts' directory exists to: -

- +

3.35.2 Description

- +

3.35.3 Usage

- +

3.35.4 See also

+ + + + + + + + +
3.63 trunk/Translations/Identity/Brands   +
3.65 trunk/Translations/Identity/Fonts   +
3.66 trunk/Translations/Identity/Models   +
3.67 trunk/Translations/Identity/Release   +
3.68 trunk/Translations/Identity/Themes   +
3.71 trunk/Translations/Identity/Widgets   +
3.1 trunk/Identity   +
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_39.html b/Manuals/Repository/repository-html/repository_39.html index cc33f85..04f789b 100644 --- a/Manuals/Repository/repository-html/repository_39.html +++ b/Manuals/Repository/repository-html/repository_39.html @@ -9,7 +9,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: 3.36 trunk/Scripts/Bash +CentOS Artwork Repository: 3.36 trunk/Locales/Identity/Brands - - + + @@ -52,199 +52,152 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.36 trunk/Scripts/Bash

+ + +

3.36 trunk/Locales/Identity/Brands

- +

3.36.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. -

+ + - +

3.36.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. +

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:

-

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. +

/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.

-

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 (see section 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. +

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.

-

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. +

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.

-

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 (see section trunk/Scripts/Bash/Functions). +

Translation file names, inside brands' translation template +(`Tpl') directory have special meaning:

-

As convenction, the `centos-art.sh' command-line arguments have -the following format: + + +

3.36.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.

-
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. + + +

3.36.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.

-

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. +

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.

-
-
+----------------------------------------------------------------------+
-| [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 3.1: The functionalities initialization environment. - +

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.

-

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. + + +

3.36.2.3 Translation markers

+ +

Inside `trunk/Translations/Identity/Brands/', translation files +combine the following translation markers:

-
-
+--------------------------------------+
-| 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 3.2: The actions initialization environment. - +

+
`#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. +

+
+
- + +

3.36.3 Usage

-

The `centos-art.sh' script usage information is described inside -each specific function documentation (see section trunk/Scripts/Bash/Functions). +

To render brands' translation files, use the following command:

+
centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
+
- +

3.36.4 See also

- - -
3.35 trunk/Scripts   -
3.37 trunk/Scripts/Bash/Functions   +
3.64 trunk/Translations/Identity/Brands/Tpl  
3.47 trunk/Scripts/Bash/Locale   +
3.2 trunk/Identity/Brands  
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_4.html b/Manuals/Repository/repository-html/repository_4.html index 4e75cea..8d67bbc 100644 --- a/Manuals/Repository/repository-html/repository_4.html +++ b/Manuals/Repository/repository-html/repository_4.html @@ -9,7 +9,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: 3.37 trunk/Scripts/Bash/Functions +CentOS Artwork Repository: 3.37 trunk/Locales/Identity/Brands/Tpl - - + + @@ -52,1320 +52,54 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.37 trunk/Scripts/Bash/Functions

+ + +

3.37 trunk/Locales/Identity/Brands/Tpl

- +

3.37.1 Goals

-

The `trunk/Scripts/Bash/Functions' directory exists to organize -`centos-art.sh' specific functionalities. -

- +

3.37.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 -(see section 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 (see section 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? -

- - +

3.37.3 Usage

- -

3.37.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: -

-
    -
  • `/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. -

- - - -

3.37.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 3.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 (see section 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. See section 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
-
-
- - - -

3.37.3.3 Specific functions

- -

The following specific functions of `centos-art.sh' script, are -available for you to use: -

- - - - - - - - - - -
3.38 trunk/Scripts/Bash/Functions/Html   -
3.39 trunk/Scripts/Bash/Functions/Locale   -
3.40 trunk/Scripts/Bash/Functions/Manual   -
3.41 trunk/Scripts/Bash/Functions/Path   -
3.42 trunk/Scripts/Bash/Functions/Render   -
3.43 trunk/Scripts/Bash/Functions/Render/Config   -
3.44 trunk/Scripts/Bash/Functions/Shell   -
3.45 trunk/Scripts/Bash/Functions/Svg   -
3.46 trunk/Scripts/Bash/Functions/Verify   -
- - - +

3.37.4 See also

- - - -
3.36 trunk/Scripts/Bash   -
3.47 trunk/Scripts/Bash/Locale   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_41.html b/Manuals/Repository/repository-html/repository_41.html index 5cf98ae..aa7060d 100644 --- a/Manuals/Repository/repository-html/repository_41.html +++ b/Manuals/Repository/repository-html/repository_41.html @@ -9,7 +9,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: 3.38 trunk/Scripts/Bash/Functions/Html +CentOS Artwork Repository: 3.38 trunk/Locales/Identity/Fonts - - + + @@ -52,66 +52,108 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.38 trunk/Scripts/Bash/Functions/Html

+ + +

3.38 trunk/Locales/Identity/Fonts

- +

3.38.1 Goals

- - - - +

This section exists to organize fonts translation files. +

+

3.38.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 trunk/Identity/Fonts) is used as +reference when someone needs to know which font-families are allowed +to use inside CentOS visual identity. +

+ + +

3.38.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. +

+
+ + +

3.38.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
+
- +

3.38.4 See also

+ + +
3.3 trunk/Identity/Fonts   +
+ - - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_42.html b/Manuals/Repository/repository-html/repository_42.html index 3af5b23..3282f27 100644 --- a/Manuals/Repository/repository-html/repository_42.html +++ b/Manuals/Repository/repository-html/repository_42.html @@ -9,7 +9,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: 3.39 trunk/Scripts/Bash/Functions/Locale +CentOS Artwork Repository: 3.39 trunk/Locales/Identity/Models - - + + @@ -52,131 +52,54 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.39 trunk/Scripts/Bash/Functions/Locale

+ + +

3.39 trunk/Locales/Identity/Models

- +

3.39.1 Goals

- - - +

3.39.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: -

- - - - - +

3.39.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. -

-
- - +

3.39.4 See also

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

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_43.html b/Manuals/Repository/repository-html/repository_43.html index 85f06be..bc7ab0a 100644 --- a/Manuals/Repository/repository-html/repository_43.html +++ b/Manuals/Repository/repository-html/repository_43.html @@ -9,7 +9,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: 3.40 trunk/Scripts/Bash/Functions/Manual +CentOS Artwork Repository: 3.40 trunk/Locales/Identity/Release - - + + @@ -52,66 +52,54 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.40 trunk/Scripts/Bash/Functions/Manual

+ + +

3.40 trunk/Locales/Identity/Release

- +

3.40.1 Goals

- - - +

3.40.2 Description

- - - +

3.40.3 Usage

- - - +

3.40.4 See also

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

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_44.html b/Manuals/Repository/repository-html/repository_44.html index 8bfd4b2..01ebe90 100644 --- a/Manuals/Repository/repository-html/repository_44.html +++ b/Manuals/Repository/repository-html/repository_44.html @@ -9,7 +9,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: 3.41 trunk/Scripts/Bash/Functions/Path +CentOS Artwork Repository: 3.41 trunk/Locales/Identity/Themes - - + + @@ -52,385 +52,54 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.41 trunk/Scripts/Bash/Functions/Path

+ + +

3.41 trunk/Locales/Identity/Themes

- +

3.41.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. -

- +

3.41.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." -

- - -

3.41.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 trunk) 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 (see section branches) 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 tags) 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. -

- - -

3.41.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. -

- - -

3.41.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. -

- - -

3.41.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. -

- -

3.41.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. -

- - -

3.41.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 trunk/Identity) would be probaly the best -advice we could offer, the rest is just matter of choosing appropriate -names. To illustrate this desition process let's consider the -`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. -

- - +

3.41.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. -

-
-
- - +

3.41.4 See also

- - - -
3.36 trunk/Scripts/Bash   -
3.37 trunk/Scripts/Bash/Functions   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_45.html b/Manuals/Repository/repository-html/repository_45.html index 63fc88c..2eb4513 100644 --- a/Manuals/Repository/repository-html/repository_45.html +++ b/Manuals/Repository/repository-html/repository_45.html @@ -9,7 +9,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: 3.42 trunk/Scripts/Bash/Functions/Render +CentOS Artwork Repository: 3.42 trunk/Locales/Identity/Themes/Backgrounds - - + + @@ -52,770 +52,66 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.42 trunk/Scripts/Bash/Functions/Render

- -

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. -

- - -

3.42.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). -

- - -

3.42.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. -

- -

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 (see section 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 trunk/Identity, 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. -

-

See section 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. -

-
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. -

-

See section trunk/Scripts/Bash/Functions/Render/Config, for more -information. -

-
- - - -

3.42.1.2 Design template with translation (one-to-one)

- -

Producing untranslated images is fine in many cases, but not always. -Sometimes it is required to produce images in different languages and -that is something that untrasnlated image production cannot achieve. -However, if we fill its empty translation entry with translation files -(one for each design template) we extend the production flow from -untranslated image production to translated image production. -

-

In order for `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.
-
- + -

3.42.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: -

-
-
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. -

-
+

3.42 trunk/Locales/Identity/Themes/Backgrounds

-

3.42.1.4 Design template with translation (optimized+flexibility)

+

3.42.1 Goals

-

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… -

-

3.42.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. -

- - -

3.42.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. +

    3.42.2 Description

    -
  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. -

- -

3.42.4 Usage

+ +

3.42.3 Usage

- -

3.42.5 See also

+ +

3.42.4 See also

- - -
3.43 trunk/Scripts/Bash/Functions/Render/Config   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_46.html b/Manuals/Repository/repository-html/repository_46.html index 0eb98d3..5651f61 100644 --- a/Manuals/Repository/repository-html/repository_46.html +++ b/Manuals/Repository/repository-html/repository_46.html @@ -9,7 +9,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: 3.43 trunk/Scripts/Bash/Functions/Render/Config +CentOS Artwork Repository: 3.43 trunk/Locales/Identity/Themes/Distro/Anaconda/Progress - - + + @@ -52,237 +52,134 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.43 trunk/Scripts/Bash/Functions/Render/Config

+ + +

3.43 trunk/Locales/Identity/Themes/Distro/Anaconda/Progress

- +

3.43.1 Goals

-

The `trunk/Scripts/Bash/Config' directory exists to oraganize -pre-rendering configuration scripts. -

- - -

3.43.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. -

- - -

3.43.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. -

- - -

3.43.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. -

- -

3.43.2.3 The `render.conf.sh' rendering actions

+ +

3.43.2 Description

-

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

See section trunk/Scripts/Bash/Functions/Render, to know more -about possible values for `BASE', `POST' and `LAST' -action definitions. -

+

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. +

+ -

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'
-
- +

3.43.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. +

Translation rendering is described in `trunk/Translations' +documentation entry (see section trunk/Translations).

-
-
`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. -

- +

3.43.4 See also

- - - - -
3.36 trunk/Scripts/Bash   -
3.37 trunk/Scripts/Bash/Functions   -
3.42 trunk/Scripts/Bash/Functions/Render   -
- - - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_47.html b/Manuals/Repository/repository-html/repository_47.html index 4422025..800b764 100644 --- a/Manuals/Repository/repository-html/repository_47.html +++ b/Manuals/Repository/repository-html/repository_47.html @@ -9,7 +9,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: 3.44 trunk/Scripts/Bash/Functions/Shell +CentOS Artwork Repository: 3.44 trunk/Locales/Identity/Widgets - - + + @@ -52,225 +52,70 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.44 trunk/Scripts/Bash/Functions/Shell

+ + +

3.44 trunk/Locales/Identity/Widgets

- +

3.44.1 Goals

-

This section exists to organize files related to shell -functionality of `centos-art.sh' script. -

- - -

3.44.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 3.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 3.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
+
+
 3.44.2 Description 

 
-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. -

+ - +

3.44.3 Usage

-
-
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. -

- +

3.44.4 See also

- -
3.36 trunk/Scripts/Bash   -
3.37 trunk/Scripts/Bash/Functions   +
3.71 trunk/Translations/Identity/Widgets  
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_48.html b/Manuals/Repository/repository-html/repository_48.html index 3503e5d..183b4a6 100644 --- a/Manuals/Repository/repository-html/repository_48.html +++ b/Manuals/Repository/repository-html/repository_48.html @@ -9,7 +9,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: 3.45 trunk/Scripts/Bash/Functions/Svg +CentOS Artwork Repository: 3.45 trunk/Manuals - - + + @@ -52,257 +52,66 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.45 trunk/Scripts/Bash/Functions/Svg

+ + +

3.45 trunk/Manuals

- +

3.45.1 Goals

-

This section exists to organize files related to svg -functionality of `centos-art.sh' script. -

+ - -

3.45.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. -

- - -

3.45.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. -

-
+ +

3.45.2 Description

-

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. -

- + - -

3.45.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. -

- - +

3.45.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. -

- +

3.45.4 See also

- - - -
3.36 trunk/Scripts/Bash   -
3.37 trunk/Scripts/Bash/Functions   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_49.html b/Manuals/Repository/repository-html/repository_49.html index 4ff9431..0a6da23 100644 --- a/Manuals/Repository/repository-html/repository_49.html +++ b/Manuals/Repository/repository-html/repository_49.html @@ -9,7 +9,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: 3.46 trunk/Scripts/Bash/Functions/Verify +CentOS Artwork Repository: 3.46 trunk/Scripts - - + + @@ -52,304 +52,69 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.46 trunk/Scripts/Bash/Functions/Verify

+ + +

3.46 trunk/Scripts

- +

3.46.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' directory exists to:

+ - -

3.46.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. -

- - -

3.46.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. -

- - -

3.46.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. -

- -

3.46.2.3 Environment variables

+ +

3.46.2 Description

-

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. -

-
-
- - +

3.46.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. -

-
-
+ - +

3.46.4 See also

- - - -
3.36 trunk/Scripts/Bash   -
3.37 trunk/Scripts/Bash/Functions   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_5.html b/Manuals/Repository/repository-html/repository_5.html index f90111e..7f7dbda 100644 --- a/Manuals/Repository/repository-html/repository_5.html +++ b/Manuals/Repository/repository-html/repository_5.html @@ -9,7 +9,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: 3.47 trunk/Scripts/Bash/Locale +CentOS Artwork Repository: 3.47 trunk/Scripts/Bash - - + + @@ -52,73 +52,199 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.47 trunk/Scripts/Bash/Locale

+ + +

3.47 trunk/Scripts/Bash

- +

3.47.1 Goals

-

This section exists to organize translation messages and templates -used by `centos-art.sh' script. +

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.

- +

3.47.2 Description

-

Translated messages of `centos-art.sh' script are managed using -GNU gettext utilities. Most translation actions have been -automated through `centos-art.sh' script "locale" functionality -(see section trunk/Scripts/Bash/Functions/Locale). +

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 (see section 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 (see section 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 3.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 3.2: The actions initialization environment. +

- +

3.47.3 Usage

-

The content of `trunk/Scripts/Bash/Locale' directory should not -be managed manually. Instead, use the "locale" functionality of -`centos-art.sh' script. See section trunk/Scripts/Bash/Functions/Locale, for more information on how to use `centos-art.sh' -"locale" functionality. +

The `centos-art.sh' script usage information is described inside +each specific function documentation (see section trunk/Scripts/Bash/Functions).

- +

3.47.4 See also

- + -
3.37 trunk/Scripts/Bash/Functions   +
3.46 trunk/Scripts   +
3.48 trunk/Scripts/Bash/Functions  
3.35 trunk/Scripts   +
3.58 trunk/Scripts/Bash/Locale  
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_51.html b/Manuals/Repository/repository-html/repository_51.html index 2df17e7..45f9b81 100644 --- a/Manuals/Repository/repository-html/repository_51.html +++ b/Manuals/Repository/repository-html/repository_51.html @@ -9,7 +9,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: 3.48 trunk/Scripts/Perl +CentOS Artwork Repository: 3.48 trunk/Scripts/Bash/Functions - - + + @@ -52,58 +52,1320 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.48 trunk/Scripts/Perl

+ + +

3.48 trunk/Scripts/Bash/Functions

- +

3.48.1 Goals

+

The `trunk/Scripts/Bash/Functions' directory exists to organize +`centos-art.sh' specific functionalities. +

+ + +

3.48.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 +(see section 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 (see section 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? +

+ + +

3.48.3 Usage

+ + + +

3.48.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: +

    -
  • ... +
  • `/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. +

- -

3.48.2 Description

+ +

3.48.3.2 Global functions

- -

3.48.3 Usage

+

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 3.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 (see section 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. See section 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
+
+
+ + + +

3.48.3.3 Specific functions

+ +

The following specific functions of `centos-art.sh' script, are +available for you to use: +

+ + + + + + + + + + +
3.49 trunk/Scripts/Bash/Functions/Html   +
3.50 trunk/Scripts/Bash/Functions/Locale   +
3.51 trunk/Scripts/Bash/Functions/Manual   +
3.52 trunk/Scripts/Bash/Functions/Path   +
3.53 trunk/Scripts/Bash/Functions/Render   +
3.54 trunk/Scripts/Bash/Functions/Render/Config   +
3.55 trunk/Scripts/Bash/Functions/Shell   +
3.56 trunk/Scripts/Bash/Functions/Svg   +
3.57 trunk/Scripts/Bash/Functions/Verify   +
- +

3.48.4 See also

+ + + +
3.47 trunk/Scripts/Bash   +
3.58 trunk/Scripts/Bash/Locale   +
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_52.html b/Manuals/Repository/repository-html/repository_52.html index 9535e30..9b7eac2 100644 --- a/Manuals/Repository/repository-html/repository_52.html +++ b/Manuals/Repository/repository-html/repository_52.html @@ -9,7 +9,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: 3.49 trunk/Scripts/Python +CentOS Artwork Repository: 3.49 trunk/Scripts/Bash/Functions/Html - - + + @@ -52,27 +52,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.49 trunk/Scripts/Python

+ + +

3.49 trunk/Scripts/Bash/Functions/Html

- +

3.49.1 Goals

- +

3.49.2 Description

- +

3.49.3 Usage

- +

3.49.4 See also

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

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_53.html b/Manuals/Repository/repository-html/repository_53.html index 7732474..893b33d 100644 --- a/Manuals/Repository/repository-html/repository_53.html +++ b/Manuals/Repository/repository-html/repository_53.html @@ -9,7 +9,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: 3.50 trunk/Translations +CentOS Artwork Repository: 3.50 trunk/Scripts/Bash/Functions/Locale - - + + @@ -52,671 +52,131 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.50 trunk/Translations

+ + +

3.50 trunk/Scripts/Bash/Functions/Locale

- +

3.50.1 Goals

-

The `trunk/Translations' directory exists to: -

- +

3.50.2 Description

-

When you create artwork for CentOS distribution you find that some -artworks need to be created for different major releases of CentOS -distribution and inside each major release that needs to be created for -different locales. To get an approximate idea of how many files we are -talking about, consider the followig approximate statistic: +

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:

-

In order to aliviate maintainance of artwork production for such -environment, we divided artwork production in three production lines: -

-
    -
  1. See section trunk/Identity/Themes/Models, to define artworks -characteristics (e.g., dimensions, position on the screen, etc.). -
  2. See section trunk/Identity/Themes/Motifs, to define artworks visual -styles (e.g., the look and feel). -
  3. Translations, to define which major releases and locales -artworks are produced for. -
- -

Inside CentOS Artwork Repository, the artworks' translation production -line is stored under `trunk/Translations' directory. -

-

Inside `trunk/Translations' directory, we use "translation -entries" to organize artworks' "translation files" and artworks' -"translation templates". -

- - -

3.50.2.1 Translation Entries

- -

Translation entries exists for each artwork you want to produce. -Translation entries can be empty directories, or directories -containing translation files and translation templates. -

-

When translation entries are empty directories, the identity entry is -used as reference to create file names and directories layout for -rendered files. In this case, the centos-art script takes -one design template and outputs one non-translated file for each -design template available. This configuration is mainly used to -produce non-translatable artworks like themes' backgrounds. -

-

When translation entries contain translation files, the translation -entry implements the CentOS release schema and is used as reference to -create file names and directories layout for translated artworks. In -this case, the centos-art script applies one translation -file to one design template to create one translated instance which is -used to output one translated file. When the translated file is -rendered, the centos-art script remove the previous instance -and takes the next file in the list of translation files to repate the -whole process once again, and so on for all files in the list. This -configuration is mainly used to produce translatable artworks like -Anaconda progress slide images. -

-

To find out correspondence between translation entries and identity -entries, you need to look the path of both translation entries and -identity entries. For example, if you are using the Modern -artisitic motif, the identity entry for Anaconda progress artwork is: -

-
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
-
-

and its translation entry is: -

-
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
-
-

Note how the `Translations/' directory prefixes `Identity/' -directory, also how static values (e.g., Identity, Themes, Distro, -etc.) in the identity entry path remain in translation entry path, and -how variable values like theme names (e.g., Modern) are stript -out from translation entry path. The same convenction can be applied -to other identity entries in order to determine their translation -entries, or to other translation entries to determine their identity -entries. -

-
info

Note

Translation entries related to identity entries under -`trunk/Identity/Themes/Motifs' do not use `Motifs/' in the -path. We've done this because `trunk/Identity/Themes/Models' -structure, the other structure under `trunk/Identity/Themes', -doesn't require translation paths so far. So in the sake of saving -characters space when building translation entries for -`trunk/Identity/Themes/Motifs' structure, we organize Motifs -translation entries under `trunk/Translations/Identity/Themes/' -directly. -

-

If for some reason `trunk/Identity/Themes/Models' structure -requires translation entries, we need to re-oraganize the current -directory structure accordingly. -

- -

Translation entries, as described above, can be re-used by similar -identity entries. For example the following identity entries: -

-
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
-trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Progress/
-trunk/Identity/Themes/Motifs/Mettle/Distro/Anaconda/Progress/
-
-

are all valid identity entries able to re-use translation files inside -Anaconda progress translation entry (the one shown in our example -above). This way, you can create several identity entries and maintain -just one translation entry for all of them. Once you change the -translation files inside the common translation entry, changes inside -identity entries will take effect inside the next you render them. -

-

Trying to make things plain and simple: inside CentOS Artwork -Repository, graphic designers can concentrate their efforts in -artworks look and feel (the identity entries), and translators in -artworks translations (the translation entries). -

- - -

3.50.2.2 Translation Markers

-

- -

-

Translation markers are used in "Theme Model Designs" and -"Translation Files" as replacement patterns to commit content -translation. When you are rendering content using -centos-art script inisde `trunk/Identity' structure, -artistic motifs and translation files are applied to model designs to -produce translated content as result. In order to have the appropriate -translation in content rendered, markers defintion in translation -files should match markers in model designs exactly. -

-

Translation markers can be whatever text you want, but as convenction -we use the following to represent releases of CentOS distribution: -

-
-
`=MINOR_RELEASE='
-

Replace with minor release of CentOS distribution. In the schema M.N, the minor -release is represented by the N letter. -

-
`=MAJOR_RELEASE='
-

Replace with major release of CentOS distribution. In the schema M.N, -the major release is represented by the M letter. -

-
`=RELEASE='
-

Replace the full release of CentOS distribution. It is -`=MAJOR_RELEASE=.=MINOR_RELEASE=' basically. -

-
- -

Specific translation markers convenctions are described inside -specific translation entries. Read translation entries documentation -to know more about supported translation markers. -

-

Translation markers standardization creates a common point of -reference for translators and graphic designers. To have translation -markers well defined makes possible that translators and graphic -designers can work together but independently one another. -

- - -

3.50.2.3 Translation Files

- -

Translation files are text files with sed commands inside, -replacement commands mainly. As convenction, translation file names -end in `.sed'. Translation files are used by centos-art -script to produce translated artworks for specific major releases of -CentOS Distribution. There are common translation files, specific -translation, and template translation files. -

-

For example, the Firstboot artwork of CentOS distribution uses the -images `splash-small.png' and `firstboot-left.png' as based -to control its visual style. The `splash-small.png' image -contains, in its graphic design, the release number information of -CentOS distribution. So the `splash-small.png' is -release-specific. In the other hand, the `firstboot-left.png' -doesn't contain release number information. So the -`firstboot-left.png' is not release-specific. -

-

If we want to produce Firstboot artwork for different major releases -of CentOS distribution, using a monolithic visual identity, all -Firstboot images should have the same visual style and, at the same -time, the release-specific information in the release-specific images. -

-
info

Note

The monolithic visual identity is implemented using -theme models (see section trunk/Identity/Themes/Models) and artistic -motifs (see section trunk/Identity/Themes/Motifs). -

- -

Assuming that both theme models and theme motifs are ready for using, -the initial translation entry to produce Firstboot artworks would look -like the following: -

-
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
-|-- Tpl
-|   `-- splash-small.sed
-`-- firstboot-left.sed
-
-

With the translation entry above, centos-art command is able -to produce the image `firstboot-left.png' only. To produce -`splash-small.png' images for major releases (e.g., 3, 4, 5, and -6) of CentOS distribution we need to produce the release-specific -translation files using the centos-art script as following: -

-
centos-art render --entry=/home/centos/artwork/trunk/Translations/Identity/Themes/BootUp/Firstboot --filter='3,4,5,6'
-
-

The above command produces the following translation entiry: -

-
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
-|-- 3
-|   `-- splash-small.sed
-|-- 4
-|   `-- splash-small.sed
-|-- 5
-|   `-- splash-small.sed
-|-- 6
-|   `-- splash-small.sed
-|-- Tpl
-|   `-- splash-small.sed
-`-- firstboot-left.sed
-
-

At this point centos-art is able to produce the Firstboot -artwork images for major releases of CentOS distribution. To add new -release-specific translation files, run the translation rendering -command with the release number you want to produce translation files -for in the `--filter='release-number'' argument. -

- - -

3.50.2.4 Template Translation Files

- -

Template translation files are translation files stored inside -translation template directory. Template translation files are used by -centos-art script to produce specific translation files -only. Template translation files may be empty or contain sed -replacement commands. If template translation files are empty files, -the final specifc translation file built from it contains -release-specific replacement commands only. For example, see the -following translation entry: -

-
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
-|-- 3
-|   `-- splash-small.sed
-|-- 4
-|   `-- splash-small.sed
-|-- 5
-|   `-- splash-small.sed
-|-- 6
-|   `-- splash-small.sed
-|-- Tpl
-|   `-- splash-small.sed    <-- template translation file.
-`-- firstboot-left.sed
-
-

In the above exmaple, the `splash-small.sed' file is a template -translation file and looks like: -

-
# -------------------------------------
-# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
-# -------------------------------------
-
-

In the above template translation file there are three comments lines, -but when you render it, the centos-art adds the -release-specific replacement commands. In our Firstboot example, after -rendering Firstboot translation entry, the `splash-small.sed' -translation file specific to CentOS 5, looks like the following: -

-
# Warning: Do not modify this file directly. This file is created
-# automatically using 'centos-art' command line interface.  Any change
-# you do in this file will be lost the next time you update
-# translation files using 'centos-art' command line interface. If you
-# want to improve the content of this translation file, improve its
-# template file instead and run the 'centos-art' command line
-# interface later to propagate your changes.
-# -------------------------------------
-# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
-# -------------------------------------
-
-# Release number information.
-s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
-s!=MINOR_RELEASE=!0!g
-s!=MAJOR_RELEASE=!5!g
-
-

If template translation files are not empty, replacement commands -inside template translation files are preserved inside -release-specific translation files. For example, consider the English -template translation file of Anaconda progress welcome slide. The -translation template directory structure looks like the following: -

-
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
-`-- Tpl
-    `-- en
-        `-- 01-welcome.sed
-
-

and if we render translation files for CentOS 4 and CentOS 5 major -releases, the translation entry would look like the following: -

-
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
-|-- 4
-|   `-- en
-|       `-- 01-welcome.sed
-|-- 5
-|   `-- en
-|       `-- 01-welcome.sed
-`-- Tpl
-    `-- en
-        `-- 01-welcome.sed
-
-
info

Note

Release-specific translation directories preserve -template translation directory structure and file names. -

- -

In the example above, the template translation file looks like the -following: -

-
# ------------------------------------------------------------
-# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
-# ------------------------------------------------------------
-s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
-s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
-s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor./
-s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. CentOS mainly changes packages to remove upstream vendor branding and artwork./
-s/=TEXT4=//
-s/=TEXT5=//
-s/=TEXT6=//
-s!=URL=!http://www.centos.org/!
-
-

and, after render the translation entry, specific translation files -look like the following: -

-
# Warning: Do not modify this file directly. This file is created
-# automatically using 'centos-art' command line interface.  Any change
-# you do in this file will be lost the next time you update
-# translation files using 'centos-art' command line interface. If you
-# want to improve the content of this translation file, improve its
-# template file instead and run the 'centos-art' command line
-# interface later to propagate your changes.
-# ------------------------------------------------------------
-# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
-# ------------------------------------------------------------
-
-s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
-s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
-s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominen t North American Enterprise Linux vendor./
-s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. Cent OS mainly changes packages to remove upstream vendor branding and artwork./
-s/=TEXT4=//
-s/=TEXT5=//
-s/=TEXT6=//
-s!=URL=!http://www.centos.org/!
-
-# Release number information.
-s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
-s!=MINOR_RELEASE=!0!g
-s!=MAJOR_RELEASE=!5!g
-
-

In the example above, relevant lines begin with the `s' word -followed by a separation character (e.g., `/', `!', etc.). -These lines have the following format: -

-
s/REGEXP/REPLACEMENT/FLAGS
-
-

The `/' characters may be uniformly replaced by any other single -character within any given s command. The `/' -character (or whatever other character is used in its stead) can -appear in the REGEXP or REPLACEMENT only if it is preceded by a -`\' character. -

-

The s command is probably the most important in -sed and has a lot of different options. Its basic concept -is simple: the s command attempts to match the pattern space -against the supplied REGEXP; if the match is successful, then that -portion of the pattern space which was matched is replaced with -REPLACEMENT. -

-

In the context of our translation files, the REGEXP is where you -define translation markers and REPLACEMENT where you define the -translation text you want to have after artworks rendering. Sometimes -we use the FLAG component with the `g' command to apply the -replacements globally. -

-
Info

Tip

More information about how to use sed -replacement commands and flags is available in sed -documentation manual. To read sed documentation manual type -the following command: -

info sed
-
- -

Inside translation files, you can use translation markers not only -inside the REGEXP but in the REPLACEMENT too. In order for this -configuration to work, the REPLACEMENT of translation markers needs to -be define after its definition. For example, see in the -release-specific translation file above, how the -`s!=MAJOR_RELASE=!5!g' replacement command is defined -after `=MAJOR_RELASE=' translation marker definition in -the REPLACEMENT of `=TITLE=' translation marker replacement -command. -

- - -

3.50.2.5 Common Translation Files

- -

Common translation files contain common translations or no -translation at all for their related artworks. They are in the root -directory of the translation entry. Common translation files create -common artworks for all major releases of CentOS Distribution. -

-

Translation entries, with common translation files inside, look like -the following: -

-
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
-|-- 3
-|   `-- splash-small.sed
-|-- 4
-|   `-- splash-small.sed
-|-- 5
-|   `-- splash-small.sed
-|-- 6
-|   `-- splash-small.sed
-|-- Tpl
-|   `-- splash-small.sed
-`-- firstboot-left.sed      <-- common translation file.
-
- - -

3.50.2.6 Specific Translation Files

- -

Specific translation files contain specific translations for their -related artworks. Specific translation files are not in the root -directory of the translation entry, but inside directories which -describe the type of translation they are doing. Specific translation -files are produced automatically using the centos-art -script. -

-
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
-|-- 3
-|   `-- splash-small.sed    <-- CentOS 3 specific translation file.
-|-- 4
-|   `-- splash-small.sed    <-- CentOS 4 specific translation file.
-|-- 5
-|   `-- splash-small.sed    <-- CentOS 5 specific translation file.
-|-- 6
-|   `-- splash-small.sed    <-- CentOS 6 specific translation file.
-|-- Tpl
-|   `-- splash-small.sed
-`-- firstboot-left.sed
-
- - -

3.50.2.7 Translation Rendering

- -

When rendering translations, the centos-art script checks -the translation entry to verify that it has a translation template -directory inside. The translation template directory (`Tpl/') -contains common translation files used to build release-specific -translation files. If the translation template directory doesn't exist -inside the translation entry the translation rendering fails. In this -case the centos-art script outputs a message and quits -script execution. -

- - -

3.50.2.8 Translation (Pre-)Rendering Configuration Scripts

- -

When the centos-art script finds a translation template -directory inside translation entry, it looks for translations -pre-rendering configuration scripts for that translation entry. -Translation pre-rendering configuration scripts let you extend -translation default functionality (described below). -

-

Translation pre-rendering configuration scripts are stored under -`trunk/Scripts' directory, specifically under the appropriate -language implementation. If you are using centos-art Bash -implementation, the translation pre-rendering scripts are store in the -`trunk/Scripts/Bash/Config' location; if you are using -centos-art Python implementation, then translation -pre-rendering scripts are stored in the -`trunk/Scripts/Python/Config' location, and so on for other -implementations. -

-

Bash translation pre-rendering configuration scripts look like the -following: -

-
#!/bin/bash
-#
-# render_loadConfig.sh -- brief description here.
-#
-# Copyright (C) YEAR YOURNAME
-# 
-# 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: render_loadConfig.sh 94 2010-09-18 10:59:42Z al $
-# ----------------------------------------------------------------------
-
-function render_loadConfig {
-...
-}
-
-

Translation pre-rendering scripts are function scripts loaded and -executed when rendering a translation entry. Translation pre-rendering -scripts are loaded using the translation entry being rendered as -reference. For example, suppose you are using the -centos-art Bash implementation, and you are rendering -translations for CentOS brands, in this situation the translation -entry would be: -

-
trunk/Translations/Identity/Brands
-
-

and the entry inside the translation pre-rendering configuration -structure would be: -

-
trunk/Scripts/Bash/Config/Identity/Brands
-
-

Once the centos-art script detects that translation -pre-rendering configuration directory exists, the centos-art -script looks for the translation pre-rendering configuration file. If -the translation pre-rendering configuration file exists, it is loaded -and executed. Once the translation pre-rendering configuration file -has been executed the translation rendering process is over, and so -the script execution. -

-
info

Note

Translation pre-rendering configuration files have the -following form: -

render.conf.extension
-

where `extension' refers the programming language implementation -you are using. For example, `sh' for Bash, `py' for Python, -`pl' for Perl, and so on for other implementations. -

- -

As we are using Bash implementation to describe the translation -pre-rendering configuration example, the translation pre-rendering -configuration file that centos-art looks for, inside the -above translation pre-rendering configuration directory, is -`render.conf.sh'. -

- - -

3.50.2.9 Translation Rendering Default Functionality

- -

In the other hand, if the translation pre-rendering configuration file -doesn't exist, or it isn't written as function script, the -centos-art script ignore translation pre-rendering -configuration functionality and passes to render translation using -default functionality instead. -

-

The translation rendering default functionality takes template -translation directory structure, duplicates it for each release number -specified in the `--filter='release-number'' argument and -produces release-specific directories. As part of template translation -duplication process take place, the centos-art script adds -release-specific replacement commands for each specific translation -file inside release-specific directories. As result, specific -translation files, inside release-specific directories, contain -template translation replacement commands plus, -release-specific replacement commands. -

-
info

Note

Release-specific replacement commands are standardized -inside centos-art script using predifined release -translation markers. Release translation markers are described in the -translation marker section -(see Translation Markers). -

- + - +

3.50.3 Usage

-
`centos-art render --entry='path/to/dir''
-
-

When `path/to/dir' refers one directory under -`trunk/Translations', this command orverwrites available -translation files using translation templates. -

-
-
`centos-art render --entry='path/to/dir' --filter='pattern''
-
-

When `path/to/dir' refers one directory under -`trunk/Translations', this command renders release-specific -translation files as you specify in the `--filter='pattern'' -argument. In this case, `pattern' not a regular expression but an -number (e.g., `5') or a list of numbers separated by commas -(e.g., `3,4,5,6') that specify the major release of CentOS -distribution you want to render translations for. +

`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.

- +

3.50.4 See also

- - - - - - - -
3.52 trunk/Translations/Identity/Brands   -
3.54 trunk/Translations/Identity/Fonts   -
3.55 trunk/Translations/Identity/Models   -
3.56 trunk/Translations/Identity/Release   -
3.57 trunk/Translations/Identity/Themes   -
3.1 trunk/Identity   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_54.html b/Manuals/Repository/repository-html/repository_54.html index 3612ec1..f50358a 100644 --- a/Manuals/Repository/repository-html/repository_54.html +++ b/Manuals/Repository/repository-html/repository_54.html @@ -9,7 +9,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: 3.51 trunk/Translations/Identity +CentOS Artwork Repository: 3.51 trunk/Scripts/Bash/Functions/Manual - - + + @@ -52,27 +52,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.51 trunk/Translations/Identity

+ + +

3.51 trunk/Scripts/Bash/Functions/Manual

- +

3.51.1 Goals

- +

3.51.2 Description

- +

3.51.3 Usage

- +

3.51.4 See also

- - - - - - - - -
3.52 trunk/Translations/Identity/Brands   -
3.54 trunk/Translations/Identity/Fonts   -
3.55 trunk/Translations/Identity/Models   -
3.56 trunk/Translations/Identity/Release   -
3.57 trunk/Translations/Identity/Themes   -
3.60 trunk/Translations/Identity/Widgets   -
3.1 trunk/Identity   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on February, 24 2011 using texi2html 1.76. + This document was generated on February, 25 2011 using texi2html 1.76.
diff --git a/Manuals/Repository/repository-html/repository_55.html b/Manuals/Repository/repository-html/repository_55.html index 49e9261..8f975ea 100644 --- a/Manuals/Repository/repository-html/repository_55.html +++ b/Manuals/Repository/repository-html/repository_55.html @@ -9,7 +9,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: 3.52 trunk/Translations/Identity/Brands +CentOS Artwork Repository: 3.52 trunk/Scripts/Bash/Functions/Path - - + + @@ -52,152 +52,385 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

3.52 trunk/Translations/Identity/Brands

+ + +

3.52 trunk/Scripts/Bash/Functions/Path

- +

3.52.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. +

- +

3.52.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: +

"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."

-
/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: -

- - -

3.52.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. -

- - -

3.52.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. -

- - -

3.52.2.3 Translation markers

- -

Inside `trunk/Translations/Identity/Brands/', translation files -combine the following translation markers: + + +

3.52.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.

-
-
`#000000'
-
-

Specify which color to use when rendering brand images. +

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 trunk) 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 (see section branches) 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.

-
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. +

The `tags/' directory (see section tags) 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. +

+ + +

3.52.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. +

+ + +

3.52.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. +

+ + +

3.52.2.4 Parallel directories

- -

3.52.3 Usage

+

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. +

-

To render brands' translation files, use the following command: + +

3.52.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. +

+ + +

3.52.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.

-
centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
+
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 trunk/Identity) would be probaly the best
+advice we could offer, the rest is just matter of choosing appropriate
+names.  To illustrate this desition process let's consider the
+`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.
+

+
+
+
 3.52.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.  
+

+

+

+
 
-
+
 
 3.52.4 See also 

 
 
-
-
3.53 trunk/Translations/Identity/Brands/Tpl  
+
3.47 trunk/Scripts/Bash  
 
3.2 trunk/Identity/Brands  
+
3.48 trunk/Scripts/Bash/Functions  
 

 

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_56.html b/Manuals/Repository/repository-html/repository_56.html
index 26fac0c..377d10e 100644
--- a/Manuals/Repository/repository-html/repository_56.html
+++ b/Manuals/Repository/repository-html/repository_56.html
@@ -9,7 +9,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: 3.53 trunk/Translations/Identity/Brands/Tpl
+CentOS Artwork Repository: 3.53 trunk/Scripts/Bash/Functions/Render
 
-
-
+
+
 
 
 
@@ -52,54 +52,770 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 3.53 trunk/Translations/Identity/Brands/Tpl 

+
+
+
 3.53 trunk/Scripts/Bash/Functions/Render 

 
+
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.
+

+
+
+
 3.53.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).
+

+
+
+
 3.53.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.
+

+
+
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 (see section 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 trunk/Identity, 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.
+

+
See section 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.
+

+
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.
+

+
See section trunk/Scripts/Bash/Functions/Render/Config, for more
+information.
+

+

+
+
+
+
 3.53.1.2 Design template with translation (one-to-one) 

+
+
Producing untranslated images is fine in many cases, but not always.
+Sometimes it is required to produce images in different languages and
+that is something that untrasnlated image production cannot achieve.
+However, if we fill its empty translation entry with translation files
+(one for each design template) we extend the production flow from
+untranslated image production to translated image production.
+

+
In order for `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.
+

+
+
+
 3.53.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:
+

+

+
 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 {
 
-
-
 3.53.1 Goals 

+    # 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
+    "
 
-
-
 3.53.2 Description 

+}
+

+
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.
+

+

+
+
+
+
 3.53.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…
+

+
+
 3.53.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.
+

+
+
+
 3.53.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. 
+

 
+
+
 3.53.4 Usage 

 
-
-
 3.53.3 Usage 

+
 
 
-
-
 3.53.4 See also 

+
+
 3.53.5 See also 

 
+
+
+
3.54 trunk/Scripts/Bash/Functions/Render/Config  
+

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_57.html b/Manuals/Repository/repository-html/repository_57.html
index de0673d..23f73c3 100644
--- a/Manuals/Repository/repository-html/repository_57.html
+++ b/Manuals/Repository/repository-html/repository_57.html
@@ -9,7 +9,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: 3.54 trunk/Translations/Identity/Fonts
+CentOS Artwork Repository: 3.54 trunk/Scripts/Bash/Functions/Render/Config
 
-
-
+
+
 
 
 
@@ -52,108 +52,237 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 3.54 trunk/Translations/Identity/Fonts 

+
+
+
 3.54 trunk/Scripts/Bash/Functions/Render/Config 

 
 
-
+
 
 3.54.1 Goals 

 
-
This section exists to organize fonts translation files.
+
The `trunk/Scripts/Bash/Config' directory exists to oraganize
+pre-rendering configuration scripts.
 

-
+
+
 
 3.54.2 Description 

 
-
Translation files, inside `trunk/Translations/Fonts', have the
-following structure:
+
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. 
+

+
+
+
 3.54.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.
 

-
s!font-family:Denmark!font-family:DejaVu LGC Sans!
-s!font-weight:normal!font-weight:bold!
-s!font-style:normal!font-style:italic!
+
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 `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 trunk/Identity/Fonts) is used as
-reference when someone needs to know which font-families are allowed
-to use inside CentOS visual identity.
-

+
Inside identity pre-rendering configuration scripts, text-based
+pre-rendering configuration scripts look like the following:
+

+
#!/bin/bash
 
+function render_loadConfig {
 
-
-
 3.54.2.1 Translation Markers 

+    # Define rendering actions.
+    ACTIONS[0]='BASE:renderText'
+    ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
 
-
Inside `trunk/Translations/Identity/Fonts', translation files
-combine the following translation markers:
+}
+

+
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. 
 

-

-
 `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.
-

-

 
+
+
 3.54.2.2 The `render.conf.sh' translation model 

 
-
-
 3.54.3 Usage 

+
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.
+

+
+
+
 3.54.2.3 The `render.conf.sh' rendering actions 

 
-
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:
+
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:
 

-
vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
+
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
 See section 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'
+

+
+
+
 3.54.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. 
+

+
+
 
 3.54.4 See also 

 
 
-
+
+
3.3 trunk/Identity/Fonts  
+
3.47 trunk/Scripts/Bash  
+
3.48 trunk/Scripts/Bash/Functions  
+
3.53 trunk/Scripts/Bash/Functions/Render  
 

 

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_58.html b/Manuals/Repository/repository-html/repository_58.html
index 9554cc5..b329095 100644
--- a/Manuals/Repository/repository-html/repository_58.html
+++ b/Manuals/Repository/repository-html/repository_58.html
@@ -9,7 +9,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: 3.55 trunk/Translations/Identity/Models
+CentOS Artwork Repository: 3.55 trunk/Scripts/Bash/Functions/Shell
 
-
-
+
+
 
 
 
@@ -52,54 +52,225 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 3.55 trunk/Translations/Identity/Models 

+
+
+
 3.55 trunk/Scripts/Bash/Functions/Shell 

 
 
-
+
 
 3.55.1 Goals 

 
+
This section exists to organize files related to shell
+functionality of `centos-art.sh' script.
+

 
-
+
 
 3.55.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 3.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 3.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
+
+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.
+

+
 
-
+
 
 3.55.3 Usage 

 
+

+
 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. 
+

 
-
+
 
 3.55.4 See also 

 
+
+
+
+
3.47 trunk/Scripts/Bash  
+
3.48 trunk/Scripts/Bash/Functions  
+

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_59.html b/Manuals/Repository/repository-html/repository_59.html
index 257b63c..10d9c68 100644
--- a/Manuals/Repository/repository-html/repository_59.html
+++ b/Manuals/Repository/repository-html/repository_59.html
@@ -9,7 +9,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: 3.56 trunk/Translations/Identity/Release
+CentOS Artwork Repository: 3.56 trunk/Scripts/Bash/Functions/Svg
 
-
-
+
+
 
 
 
@@ -52,54 +52,257 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 3.56 trunk/Translations/Identity/Release 

+
+
+
 3.56 trunk/Scripts/Bash/Functions/Svg 

 
 
-
+
 
 3.56.1 Goals 

 
+
This section exists to organize files related to svg
+functionality of `centos-art.sh' script.
+

 
-
+
 
 3.56.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.
+

+
+
+
+
 3.56.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.
+

+
+
+
+
 3.56.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.
+

+
+
 
 3.56.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. 
+

+
+
 
 3.56.4 See also 

 
+
+
+
+
3.47 trunk/Scripts/Bash  
+
3.48 trunk/Scripts/Bash/Functions  
+

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_6.html b/Manuals/Repository/repository-html/repository_6.html
index 1c8eaa2..80d4878 100644
--- a/Manuals/Repository/repository-html/repository_6.html
+++ b/Manuals/Repository/repository-html/repository_6.html
@@ -9,7 +9,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: 3.57 trunk/Translations/Identity/Themes
+CentOS Artwork Repository: 3.57 trunk/Scripts/Bash/Functions/Verify
 
-
-
+
+
 
 
 
@@ -52,41 +52,291 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
+
+
+
 3.57 trunk/Scripts/Bash/Functions/Verify 

+
+
+
+
 3.57.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.
+

+
+
+
 3.57.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.
+

+
 
-
 3.57 trunk/Translations/Identity/Themes 

+
 3.57.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.
+

 
 
-
 3.57.1 Goals 

+
 3.57.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.
+

 
 
-
 3.57.2 Description 

+
 3.57.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.
+

+

+

 
 
 
 
 3.57.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.  
+

+

+

+
 
 
 
 3.57.4 See also 

 
+
+
+
+
3.47 trunk/Scripts/Bash  
+
3.48 trunk/Scripts/Bash/Functions  
+

 
 
 
@@ -94,12 +344,12 @@ ul.toc {list-style: none}
 
-
-
+
+
[ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_61.html b/Manuals/Repository/repository-html/repository_61.html
index 6eb0d73..f088d20 100644
--- a/Manuals/Repository/repository-html/repository_61.html
+++ b/Manuals/Repository/repository-html/repository_61.html
@@ -9,7 +9,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: 3.58 trunk/Translations/Identity/Themes/Backgrounds
+CentOS Artwork Repository: 3.58 trunk/Scripts/Bash/Locale
 
-
-
+
+
 
 
 
@@ -57,48 +57,55 @@ ul.toc {list-style: none}
    
 [ << ]
 [ Up ]
-[ >> ]
+[ >> ]
    
    
    
    
 [Top]
 [Contents]
-[Index]
+[Index]
 [ ? ]
 
-
+
 
-
 3.58 trunk/Translations/Identity/Themes/Backgrounds 

+
 3.58 trunk/Scripts/Bash/Locale 

 
 
 
 
 3.58.1 Goals 

 
-
    
-
  •  ...
-

-
+
This section exists to organize translation messages and templates
+used by `centos-art.sh' script.
+

 
 
 
 3.58.2 Description 

 
-
    
-
  •  ...
-

-
+
Translated messages of `centos-art.sh' script are managed using
+GNU gettext utilities. Most translation actions have been
+automated through `centos-art.sh' script "locale" functionality
+(see section trunk/Scripts/Bash/Functions/Locale).
+

 
 
 
 3.58.3 Usage 

 
-
    
-
  •  ...
-

-
+
The content of `trunk/Scripts/Bash/Locale' directory should not
+be managed manually. Instead, use the "locale" functionality of
+`centos-art.sh' script.  See section trunk/Scripts/Bash/Functions/Locale, for more information on how to use `centos-art.sh'
+"locale" functionality.
+

 
 
 
 3.58.4 See also 

 
+
+
+
+
3.48 trunk/Scripts/Bash/Functions  
+
3.46 trunk/Scripts  
+

 
 
 
@@ -107,11 +114,11 @@ ul.toc {list-style: none}
 
-
+
   
 [ << ]
 [ Up ][ >> ][ >> ]
 

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_62.html b/Manuals/Repository/repository-html/repository_62.html
index e399a60..bd420ac 100644
--- a/Manuals/Repository/repository-html/repository_62.html
+++ b/Manuals/Repository/repository-html/repository_62.html
@@ -9,7 +9,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: 3.59 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+CentOS Artwork Repository: 3.59 trunk/Scripts/Perl
 
-
-
+
+
 
 
 
@@ -57,129 +57,53 @@ ul.toc {list-style: none}
    
 [ << ]
 [ Up ]
-[ >> ]
+[ >> ]
    
    
    
    
 [Top]
 [Contents]
-[Index]
+[Index]
 [ ? ]
 
-
+
 
-
 3.59 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress 

+
 3.59 trunk/Scripts/Perl 

 
 
 
 
 3.59.1 Goals 

 
 
    
-
  •  Organize Anaconda progress translation templates.
-
  •  Organize Anaconda progress translation files in several
-languages and major releases of CentOS distribution.
+
  •  ...
 

 
 
 
 
 3.59.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. 
-

-
-
 
 
 
 3.59.3 Usage 

 
-
Translation rendering is described in `trunk/Translations'
-documentation entry (see section trunk/Translations).
-

-
 
 
 
 3.59.4 See also 

 
 
+
 
-
+

 
[ < ]
 [ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
 

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_63.html b/Manuals/Repository/repository-html/repository_63.html
index 521ee0b..9761a4b 100644
--- a/Manuals/Repository/repository-html/repository_63.html
+++ b/Manuals/Repository/repository-html/repository_63.html
@@ -9,7 +9,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: 3.60 trunk/Translations/Identity/Widgets
+CentOS Artwork Repository: 3.60 trunk/Scripts/Python
 
-
-
+
+
 
 
 
@@ -57,19 +57,19 @@ ul.toc {list-style: none}
    
 [ << ]
 [ Up ]
-[ >> ]
+[ >> ]
    
    
    
    
 [Top]
 [Contents]
-[Index]
+[Index]
 [ ? ]
 
-
+
 
-
 3.60 trunk/Translations/Identity/Widgets 

+
 3.60 trunk/Scripts/Python 

 
 
 
@@ -99,13 +99,6 @@ ul.toc {list-style: none}
 
 
 3.60.4 See also 

 
-
-
-
3.60 trunk/Translations/Identity/Widgets  
-

-
-
-
 
 
 
@@ -114,11 +107,11 @@ ul.toc {list-style: none}
 
-
+
   
 [ << ]
 [ Up ][ >> ][ >> ]
 

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_64.html b/Manuals/Repository/repository-html/repository_64.html
index 3a31c87..5530be5 100644
--- a/Manuals/Repository/repository-html/repository_64.html
+++ b/Manuals/Repository/repository-html/repository_64.html
@@ -9,7 +9,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: 3.61 trunk/Translations
 
-
-
+
+
 
 
 
@@ -53,165 +53,670 @@ ul.toc {list-style: none}
 
 
-
+
-
-
+
+
-
+

 
[ < ][ > ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
+
 
-
 Index 

-
Jump to:   B
-   
-C
-   
-H
-   
-M
-   
-S
-   
-T
-   
-U
-   
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
 3.61 trunk/Translations 

+
+
+
+
 3.61.1 Goals 

+
+
The `trunk/Translations' directory exists to:
+

+
    
+
  •  Organize translation files.
+
  •  Organize translation templates used to produce translation files.
+

+
+
+
+
 3.61.2 Description 

+
+
When you create artwork for CentOS distribution you find that some
+artworks need to be created for different major releases of CentOS
+distribution and inside each major release that needs to be created for
+different locales. To get an approximate idea of how many files we are
+talking about, consider the followig approximate statistic:
+

+
    
+
  •  Inside CentOS distribution, there are around 30 images to
+rebrand.(5)
+
+
  •  There are near to four major releases of CentOS distribution to
+rebrand in parallel development.(6) 
+
+
  •  Each CentOS distribution in parallel development supports more
+than two hundreds locales.(7)
+

+
+
In order to aliviate maintainance of artwork production for such
+environment, we divided artwork production in three production lines:
+

+
    
+
  1.  See section trunk/Identity/Themes/Models, to define artworks
+characteristics (e.g., dimensions, position on the screen, etc.).
+
  2.  See section trunk/Identity/Themes/Motifs, to define artworks visual
+styles (e.g., the look and feel).
+
  3.  Translations, to define which major releases and locales
+artworks are produced for. 
+

+
+
Inside CentOS Artwork Repository, the artworks' translation production
+line is stored under `trunk/Translations' directory.
+

+
Inside `trunk/Translations' directory, we use "translation
+entries" to organize artworks' "translation files" and artworks'
+"translation templates".
+

+
+
+
 3.61.2.1 Translation Entries 

+
+
Translation entries exists for each artwork you want to produce.
+Translation entries can be empty directories, or directories
+containing translation files and translation templates.  
+

+
When translation entries are empty directories, the identity entry is
+used as reference to create file names and directories layout for
+rendered files.  In this case, the centos-art script takes
+one design template and outputs one non-translated file for each
+design template available.  This configuration is mainly used to
+produce non-translatable artworks like themes' backgrounds.
+

+
When translation entries contain translation files, the translation
+entry implements the CentOS release schema and is used as reference to
+create file names and directories layout for translated artworks. In
+this case, the centos-art script applies one translation
+file to one design template to create one translated instance which is
+used to output one translated file. When the translated file is
+rendered, the centos-art script remove the previous instance
+and takes the next file in the list of translation files to repate the
+whole process once again, and so on for all files in the list. This
+configuration is mainly used to produce translatable artworks like
+Anaconda progress slide images.
+

+
To find out correspondence between translation entries and identity
+entries, you need to look the path of both translation entries and
+identity entries. For example, if you are using the Modern
+artisitic motif, the identity entry for Anaconda progress artwork is:
+

+
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
+

+
and its translation entry is:
+

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
+

+
Note how the `Translations/' directory prefixes `Identity/'
+directory, also how static values (e.g., Identity, Themes, Distro,
+etc.) in the identity entry path remain in translation entry path, and
+how variable values like theme names (e.g., Modern) are stript
+out from translation entry path. The same convenction can be applied
+to other identity entries in order to determine their translation
+entries, or to other translation entries to determine their identity
+entries.
+

+
info
Note
 Translation entries related to identity entries under
+`trunk/Identity/Themes/Motifs' do not use `Motifs/' in the
+path.  We've done this because `trunk/Identity/Themes/Models'
+structure, the other structure under `trunk/Identity/Themes',
+doesn't require translation paths so far. So in the sake of saving
+characters space when building translation entries for
+`trunk/Identity/Themes/Motifs' structure, we organize Motifs
+translation entries under `trunk/Translations/Identity/Themes/'
+directly. 
+

+
If for some reason `trunk/Identity/Themes/Models' structure
+requires translation entries, we need to re-oraganize the current
+directory structure accordingly.
+

+
+
Translation entries, as described above, can be re-used by similar
+identity entries. For example the following identity entries:
+

+
trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/
+trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Progress/
+trunk/Identity/Themes/Motifs/Mettle/Distro/Anaconda/Progress/
+

+
are all valid identity entries able to re-use translation files inside
+Anaconda progress translation entry (the one shown in our example
+above). This way, you can create several identity entries and maintain
+just one translation entry for all of them.  Once you change the
+translation files inside the common translation entry, changes inside
+identity entries will take effect inside the next you render them.
+

+
Trying to make things plain and simple: inside CentOS Artwork
+Repository, graphic designers can concentrate their efforts in
+artworks look and feel (the identity entries), and translators in
+artworks translations (the translation entries).
+

+
+
+
 3.61.2.2 Translation Markers 

+
+
+
+
Translation markers are used in "Theme Model Designs" and
+"Translation Files" as replacement patterns to commit content
+translation.  When you are rendering content using
+centos-art script inisde `trunk/Identity' structure,
+artistic motifs and translation files are applied to model designs to
+produce translated content as result. In order to have the appropriate
+translation in content rendered, markers defintion in translation
+files should match markers in model designs exactly. 
+

+
Translation markers can be whatever text you want, but as convenction
+we use the following to represent releases of CentOS distribution:
+

+

+
 `=MINOR_RELEASE='

+
Replace with minor release of CentOS distribution. In the schema M.N, the minor
+release is represented by the N letter.
+

+
 `=MAJOR_RELEASE='

+
Replace with major release of CentOS distribution. In the schema M.N,
+the major release is represented by the M letter.
+

+
 `=RELEASE='

+
Replace the full release of CentOS distribution. It is
+`=MAJOR_RELEASE=.=MINOR_RELEASE=' basically. 
+

+

+
+
Specific translation markers convenctions are described inside
+specific translation entries. Read translation entries documentation
+to know more about supported translation markers.
+

+
Translation markers standardization creates a common point of
+reference for translators and graphic designers. To have translation
+markers well defined makes possible that translators and graphic
+designers can work together but independently one another.
+

+
+
+
 3.61.2.3 Translation Files 

+
+
Translation files are text files with sed commands inside,
+replacement commands mainly. As convenction, translation file names
+end in `.sed'. Translation files are used by centos-art
+script to produce translated artworks for specific major releases of
+CentOS Distribution. There are common translation files, specific
+translation, and template translation files.
+

+
For example, the Firstboot artwork of CentOS distribution uses the
+images `splash-small.png' and `firstboot-left.png' as based
+to control its visual style. The `splash-small.png' image
+contains, in its graphic design, the release number information of
+CentOS distribution. So the `splash-small.png' is
+release-specific. In the other hand, the `firstboot-left.png'
+doesn't contain release number information. So the
+`firstboot-left.png' is not release-specific.
+

+
If we want to produce Firstboot artwork for different major releases
+of CentOS distribution, using a monolithic visual identity, all
+Firstboot images should have the same visual style and, at the same
+time, the release-specific information in the release-specific images. 
+

+
info
Note
 The monolithic visual identity is implemented using
+theme models (see section trunk/Identity/Themes/Models) and artistic
+motifs (see section trunk/Identity/Themes/Motifs).
+

+
+
Assuming that both theme models and theme motifs are ready for using,
+the initial translation entry to produce Firstboot artworks would look
+like the following:
+

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+

+
With the translation entry above, centos-art command is able
+to produce the image `firstboot-left.png' only. To produce
+`splash-small.png' images for major releases (e.g., 3, 4, 5, and
+6) of CentOS distribution we need to produce the release-specific
+translation files using the centos-art script as following:
+

+
centos-art render --entry=/home/centos/artwork/trunk/Translations/Identity/Themes/BootUp/Firstboot --filter='3,4,5,6'
+

+
The above command produces the following translation entiry:
+

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+

+
At this point centos-art is able to produce the Firstboot
+artwork images for major releases of CentOS distribution. To add new
+release-specific translation files, run the translation rendering
+command with the release number you want to produce translation files
+for in the `--filter='release-number'' argument.
+

+
+
+
 3.61.2.4 Template Translation Files 

+
+
Template translation files are translation files stored inside
+translation template directory. Template translation files are used by
+centos-art script to produce specific translation files
+only. Template translation files may be empty or contain sed
+replacement commands. If template translation files are empty files,
+the final specifc translation file built from it contains
+release-specific replacement commands only. For example, see the
+following translation entry:
+

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed    <-- template translation file.
+`-- firstboot-left.sed
+

+
In the above exmaple, the `splash-small.sed' file is a template
+translation file and looks like:
+

+
# -------------------------------------
+# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
+# -------------------------------------
+

+
In the above template translation file there are three comments lines,
+but when you render it, the centos-art adds the
+release-specific replacement commands. In our Firstboot example, after
+rendering Firstboot translation entry, the `splash-small.sed'
+translation file specific to CentOS 5, looks like the following:
+

+
# Warning: Do not modify this file directly. This file is created
+# automatically using 'centos-art' command line interface.  Any change
+# you do in this file will be lost the next time you update
+# translation files using 'centos-art' command line interface. If you
+# want to improve the content of this translation file, improve its
+# template file instead and run the 'centos-art' command line
+# interface later to propagate your changes.
+# -------------------------------------
+# $Id: splash-small.sed 94 2010-09-18 10:59:42Z al $
+# -------------------------------------
+
+# Release number information.
+s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
+s!=MINOR_RELEASE=!0!g
+s!=MAJOR_RELEASE=!5!g
+

+
If template translation files are not empty, replacement commands
+inside template translation files are preserved inside
+release-specific translation files.  For example, consider the English
+template translation file of Anaconda progress welcome slide.  The
+translation template directory structure looks like the following:
+

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+`-- Tpl
+    `-- en
+        `-- 01-welcome.sed
+

+
and if we render translation files for CentOS 4 and CentOS 5 major
+releases, the translation entry would look like the following:
+

+
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+|-- 4
+|   `-- en
+|       `-- 01-welcome.sed
+|-- 5
+|   `-- en
+|       `-- 01-welcome.sed
+`-- Tpl
+    `-- en
+        `-- 01-welcome.sed
+

+
info
Note
 Release-specific translation directories preserve
+template translation directory structure and file names.
+

+
+
In the example above, the template translation file looks like the
+following:
+

+
# ------------------------------------------------------------
+# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
+# ------------------------------------------------------------
+s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
+s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
+s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor./
+s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. CentOS mainly changes packages to remove upstream vendor branding and artwork./
+s/=TEXT4=//
+s/=TEXT5=//
+s/=TEXT6=//
+s!=URL=!http://www.centos.org/!
+

+
and, after render the translation entry, specific translation files
+look like the following:
+

+
# Warning: Do not modify this file directly. This file is created
+# automatically using 'centos-art' command line interface.  Any change
+# you do in this file will be lost the next time you update
+# translation files using 'centos-art' command line interface. If you
+# want to improve the content of this translation file, improve its
+# template file instead and run the 'centos-art' command line
+# interface later to propagate your changes.
+# ------------------------------------------------------------
+# $Id: 01-welcome.sed 94 2010-09-18 10:59:42Z al $
+# ------------------------------------------------------------
+
+s/=TITLE=/Welcome to CentOS =MAJOR_RELEASE= !/
+s/=TEXT1=/Thank you for installing CentOS =MAJOR_RELEASE=./
+s/=TEXT2=/CentOS is an enterprise-class Linux Distribution derived from sources freely provided to the public by a prominen t North American Enterprise Linux vendor./
+s/=TEXT3=/CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. Cent OS mainly changes packages to remove upstream vendor branding and artwork./
+s/=TEXT4=//
+s/=TEXT5=//
+s/=TEXT6=//
+s!=URL=!http://www.centos.org/!
+
+# Release number information.
+s!=RELEASE=!=MAJOR_RELEASE=.=MINOR_RELEASE=!g
+s!=MINOR_RELEASE=!0!g
+s!=MAJOR_RELEASE=!5!g
+

+
In the example above, relevant lines begin with the `s' word
+followed by a separation character (e.g., `/', `!', etc.).
+These lines have the following format:
+

+
s/REGEXP/REPLACEMENT/FLAGS
+

+
The `/' characters may be uniformly replaced by any other single
+character within any given s command.  The `/'
+character (or whatever other character is used in its stead) can
+appear in the REGEXP or REPLACEMENT only if it is preceded by a
+`\' character.
+

+
The s command is probably the most important in
+sed and has a lot of different options.  Its basic concept
+is simple: the s command attempts to match the pattern space
+against the supplied REGEXP; if the match is successful, then that
+portion of the pattern space which was matched is replaced with
+REPLACEMENT.
+

+
In the context of our translation files, the REGEXP is where you
+define translation markers and REPLACEMENT where you define the
+translation text you want to have after artworks rendering.  Sometimes
+we use the FLAG component with the `g' command to apply the
+replacements globally.
+

+
Info
Tip
 More information about how to use sed
+replacement commands and flags is available in sed
+documentation manual. To read sed documentation manual type
+the following command: 
+
info sed
+

+
+
Inside translation files, you can use translation markers not only
+inside the REGEXP but in the REPLACEMENT too. In order for this
+configuration to work, the REPLACEMENT of translation markers needs to
+be define after its definition. For example, see in the
+release-specific translation file above, how the
+`s!=MAJOR_RELASE=!5!g' replacement command is defined
+after `=MAJOR_RELASE=' translation marker definition in
+the REPLACEMENT of `=TITLE=' translation marker replacement
+command.
+

+
+
+
 3.61.2.5 Common Translation Files 

+
+
Common translation files contain common translations or no
+translation at all for their related artworks.  They are in the root
+directory of the translation entry. Common translation files create
+common artworks for all major releases of CentOS Distribution. 
+

+
Translation entries, with common translation files inside, look like
+the following:
+

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed
+|-- 4
+|   `-- splash-small.sed
+|-- 5
+|   `-- splash-small.sed
+|-- 6
+|   `-- splash-small.sed
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed      <-- common translation file.
+

+
+
+
 3.61.2.6 Specific Translation Files 

+
+
Specific translation files contain specific translations for their
+related artworks. Specific translation files are not in the root
+directory of the translation entry, but inside directories which
+describe the type of translation they are doing. Specific translation
+files are produced automatically using the centos-art
+script.
+

+
trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/
+|-- 3
+|   `-- splash-small.sed    <-- CentOS 3 specific translation file.
+|-- 4
+|   `-- splash-small.sed    <-- CentOS 4 specific translation file.
+|-- 5
+|   `-- splash-small.sed    <-- CentOS 5 specific translation file.
+|-- 6
+|   `-- splash-small.sed    <-- CentOS 6 specific translation file.
+|-- Tpl
+|   `-- splash-small.sed
+`-- firstboot-left.sed
+

+
+
+
 3.61.2.7 Translation Rendering 

+
+
When rendering translations, the centos-art script checks
+the translation entry to verify that it has a translation template
+directory inside. The translation template directory (`Tpl/')
+contains common translation files used to build release-specific
+translation files. If the translation template directory doesn't exist
+inside the translation entry the translation rendering fails. In this
+case the centos-art script outputs a message and quits
+script execution.
+

+
+
+
 3.61.2.8 Translation (Pre-)Rendering Configuration Scripts 

+
+
When the centos-art script finds a translation template
+directory inside translation entry, it looks for translations
+pre-rendering configuration scripts for that translation entry.
+Translation pre-rendering configuration scripts let you extend
+translation default functionality (described below). 
+

+
Translation pre-rendering configuration scripts are stored under
+`trunk/Scripts' directory, specifically under the appropriate
+language implementation. If you are using centos-art Bash
+implementation, the translation pre-rendering scripts are store in the
+`trunk/Scripts/Bash/Config' location; if you are using
+centos-art Python implementation, then translation
+pre-rendering scripts are stored in the
+`trunk/Scripts/Python/Config' location, and so on for other
+implementations.
+

+
Bash translation pre-rendering configuration scripts look like the
+following:
+

+
#!/bin/bash
+#
+# render_loadConfig.sh -- brief description here.
+#
+# Copyright (C) YEAR YOURNAME
+# 
+# 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: render_loadConfig.sh 94 2010-09-18 10:59:42Z al $
+# ----------------------------------------------------------------------
+
+function render_loadConfig {
+...
+}
+

+
Translation pre-rendering scripts are function scripts loaded and
+executed when rendering a translation entry. Translation pre-rendering
+scripts are loaded using the translation entry being rendered as
+reference. For example, suppose you are using the
+centos-art Bash implementation, and you are rendering
+translations for CentOS brands, in this situation the translation
+entry would be:
+

+
trunk/Translations/Identity/Brands
+

+
and the entry inside the translation pre-rendering configuration
+structure would be:
+

+
trunk/Scripts/Bash/Config/Identity/Brands
+

+
Once the centos-art script detects that translation
+pre-rendering configuration directory exists, the centos-art
+script looks for the translation pre-rendering configuration file.  If
+the translation pre-rendering configuration file exists, it is loaded
+and executed.  Once the translation pre-rendering configuration file
+has been executed the translation rendering process is over, and so
+the script execution.
+

+
info
Note
 Translation pre-rendering configuration files have the
+following form:
+
render.conf.extension
+
where `extension' refers the programming language implementation
+you are using. For example, `sh' for Bash, `py' for Python,
+`pl' for Perl, and so on for other implementations.
+

+
+
As we are using Bash implementation to describe the translation
+pre-rendering configuration example, the translation pre-rendering
+configuration file that centos-art looks for, inside the
+above translation pre-rendering configuration directory, is
+`render.conf.sh'.
+

+
+
+
 3.61.2.9 Translation Rendering Default Functionality 

+
+
In the other hand, if the translation pre-rendering configuration file
+doesn't exist, or it isn't written as function script, the
+centos-art script ignore translation pre-rendering
+configuration functionality and passes to render translation using
+default functionality instead.
+

+
The translation rendering default functionality takes template
+translation directory structure, duplicates it for each release number
+specified in the `--filter='release-number'' argument and
+produces release-specific directories. As part of template translation
+duplication process take place, the centos-art script adds
+release-specific replacement commands for each specific translation
+file inside release-specific directories. As result, specific
+translation files, inside release-specific directories, contain
+template translation replacement commands plus,
+release-specific replacement commands.
+

+
info
Note
 Release-specific replacement commands are standardized
+inside centos-art script using predifined release
+translation markers. Release translation markers are described in the
+translation marker section
+(see Translation Markers).
+

+
+
+
+
+
 3.61.3 Usage 

+
+

+
 `centos-art render --entry='path/to/dir'' 

+

+
When `path/to/dir' refers one directory under
+`trunk/Translations', this command orverwrites available
+translation files using translation templates.
+

+

+
 `centos-art render --entry='path/to/dir' --filter='pattern'' 

+

+
When `path/to/dir' refers one directory under
+`trunk/Translations', this command renders release-specific
+translation files as you specify in the `--filter='pattern''
+argument. In this case, `pattern' not a regular expression but an
+number (e.g., `5') or a list of numbers separated by commas
+(e.g., `3,4,5,6') that specify the major release of CentOS
+distribution you want to render translations for.  
+

+

+
+
+
+
 3.61.4 See also 

+
+
Index Entry Section
 
B
branches1. branches
 
C
Common translation files3.50.2.5 Common Translation Files
 
H
How to render brands' translation files3.52.3 Usage
How to render fonts' translation files3.54.3 Usage
How to render translation files3.50.3 Usage
 
M
Metadata maintainance3.45.2 Description
 
S
Specific translation files3.50.2.6 Specific Translation Files
 
T
tags2. tags
Template translation files3.50.2.4 Template Translation Files
Translation brands file names3.52.2.1 Conventional file names
Translation brands file names3.52.2.2 Numeric file names
Translation configuration scripts3.50.2.8 Translation (Pre-)Rendering Configuration Scripts
Translation entries3.50.2.1 Translation Entries
Translation files3.50.2.3 Translation Files
Translation markers3.50.2.2 Translation Markers
Translation paths3.50.2.1 Translation Entries
Translation pre-rendering configuration scripts3.50.2.8 Translation (Pre-)Rendering Configuration Scripts
Translation rendering3.50.2.7 Translation Rendering
Translation rendering default functionality3.50.2.9 Translation Rendering Default Functionality
trunk3. trunk
trunk Identity3.1 trunk/Identity
trunk Identity Brands3.2 trunk/Identity/Brands
trunk Identity Fonts3.3 trunk/Identity/Fonts
trunk Identity Icons3.4 trunk/Identity/Icons
trunk Identity Isolinux3.5 trunk/Identity/Isolinux
trunk Identity Models3.6 trunk/Identity/Models
trunk Identity Models Css3.7 trunk/Identity/Models/Css
trunk Identity Models Html3.8 trunk/Identity/Models/Html
trunk Identity Models Img Promo Web3.9 trunk/Identity/Models/Img/Promo/Web
trunk Identity Models Tpl3.10 trunk/Identity/Models/Tpl
trunk Identity Models Tpl Promo Web3.11 trunk/Identity/Models/Tpl/Promo/Web
trunk Identity Models Xcf3.12 trunk/Identity/Models/Xcf
trunk Identity Release3.13 trunk/Identity/Release
trunk Identity Themes3.14 trunk/Identity/Themes
trunk Identity Themes Models3.15 trunk/Identity/Themes/Models
trunk Identity Themes Models Alternative3.16 trunk/Identity/Themes/Models/Alternative
trunk Identity Themes Models Default3.17 trunk/Identity/Themes/Models/Default
trunk Identity Themes Models Default Distro3.18 trunk/Identity/Themes/Models/Default/Distro
trunk Identity Themes Models Default Distro Anaconda3.19 trunk/Identity/Themes/Models/Default/Distro/Anaconda
trunk Identity Themes Models Default Promo3.20 trunk/Identity/Themes/Models/Default/Promo
trunk Identity Themes Models Default Web3.21 trunk/Identity/Themes/Models/Default/Web
trunk Identity Themes Motifs3.22 trunk/Identity/Themes/Motifs
trunk Identity Themes Motifs Flame3.23 trunk/Identity/Themes/Motifs/Flame
trunk Identity Themes Motifs Modern3.24 trunk/Identity/Themes/Motifs/Modern
trunk Identity Themes Motifs Modern Backgrounds3.25 trunk/Identity/Themes/Motifs/Modern/Backgrounds
trunk Identity Themes Motifs Modern Backgrounds Img3.26 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
trunk Identity Themes Motifs Modern Backgrounds Tpl3.27 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
trunk Identity Themes Motifs Modern Backgrounds Xcf3.28 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf
trunk Identity Themes Motifs Modern Distro Anaconda Progress3.29 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
trunk Identity Themes Motifs Modern Palettes3.30 trunk/Identity/Themes/Motifs/Modern/Palettes
trunk Identity Themes Motifs TreeFlower3.31 trunk/Identity/Themes/Motifs/TreeFlower
trunk Identity Themes Motifs TreeFlower Backgrounds3.32 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
trunk Identity Widgets3.33 trunk/Identity/Widgets
trunk Manuals3.34 trunk/Manuals
trunk Scripts3.35 trunk/Scripts
trunk Scripts Bash3.36 trunk/Scripts/Bash
trunk Scripts Bash Functions3.37 trunk/Scripts/Bash/Functions
trunk Scripts Bash Functions Html3.38 trunk/Scripts/Bash/Functions/Html
trunk Scripts Bash Functions Locale3.39 trunk/Scripts/Bash/Functions/Locale
trunk Scripts Bash Functions Manual3.40 trunk/Scripts/Bash/Functions/Manual
trunk Scripts Bash Functions Path3.41 trunk/Scripts/Bash/Functions/Path
trunk Scripts Bash Functions Render3.42 trunk/Scripts/Bash/Functions/Render
trunk Scripts Bash Functions Render Config3.43 trunk/Scripts/Bash/Functions/Render/Config
trunk Scripts Bash Functions Shell3.44 trunk/Scripts/Bash/Functions/Shell
trunk Scripts Bash Functions Svg3.45 trunk/Scripts/Bash/Functions/Svg
trunk Scripts Bash Functions Verify3.46 trunk/Scripts/Bash/Functions/Verify
trunk Scripts Bash Locale3.47 trunk/Scripts/Bash/Locale
trunk Scripts Perl3.48 trunk/Scripts/Perl
trunk Scripts Python3.49 trunk/Scripts/Python
trunk Translations3.50 trunk/Translations
trunk Translations Identity3.51 trunk/Translations/Identity
trunk Translations Identity Brands3.52 trunk/Translations/Identity/Brands
trunk Translations Identity Brands Tpl3.53 trunk/Translations/Identity/Brands/Tpl
trunk Translations Identity Fonts3.54 trunk/Translations/Identity/Fonts
trunk Translations Identity Models3.55 trunk/Translations/Identity/Models
trunk Translations Identity Release3.56 trunk/Translations/Identity/Release
trunk Translations Identity Themes3.57 trunk/Translations/Identity/Themes
trunk Translations Identity Themes Backgrounds3.58 trunk/Translations/Identity/Themes/Backgrounds
trunk Translations Identity Themes Distro Anaconda Progress3.59 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
trunk Translations Identity Widgets3.60 trunk/Translations/Identity/Widgets
 
U
Unused definitions3.45.2.1 Metadata maintainance
 

+
+
+
+
+
+
3.63 trunk/Translations/Identity/Brands  
+
3.65 trunk/Translations/Identity/Fonts  
+
3.66 trunk/Translations/Identity/Models  
+
3.67 trunk/Translations/Identity/Release  
+
3.68 trunk/Translations/Identity/Themes  
+
3.1 trunk/Identity  
+

 

-
Jump to:   B
-   
-C
-   
-H
-   
-M
-   
-S
-   
-T
-   
-U
-   
-

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_65.html b/Manuals/Repository/repository-html/repository_65.html
index 7782a29..faa87a7 100644
--- a/Manuals/Repository/repository-html/repository_65.html
+++ b/Manuals/Repository/repository-html/repository_65.html
@@ -9,7 +9,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: 3.62 trunk/Translations/Identity
 
-
-
+
+
 
 
 
@@ -52,49 +52,82 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 List of Figures 

-

-
Figure 3.1
The functionalities initialization environment.
-

-
Figure 3.2
The actions initialization environment.
-

-
Figure 3.3
The cli_commitRepoChanges function output.
-

-
Figure 3.4
The functions script base comment structure
-

-
Figure 3.5
The function script comment example
-

-

+
+
+
 3.62 trunk/Translations/Identity 

+
+
+
+
 3.62.1 Goals 

+
+
    
+
  •  ...
+

+
+
+
+
 3.62.2 Description 

+
+
    
+
  •  ...
+

+
+
+
+
 3.62.3 Usage 

+
+
    
+
  •  ...
+

+
+
+
+
 3.62.4 See also 

+
+
+
+
+
+
+
+
+
+
3.63 trunk/Translations/Identity/Brands  
+
3.65 trunk/Translations/Identity/Fonts  
+
3.66 trunk/Translations/Identity/Models  
+
3.67 trunk/Translations/Identity/Release  
+
3.68 trunk/Translations/Identity/Themes  
+
3.71 trunk/Translations/Identity/Widgets  
+
3.1 trunk/Identity  
+

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

 

  
-  This document was generated on February, 24 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_66.html b/Manuals/Repository/repository-html/repository_66.html
index 11302ee..8f2e400 100644
--- a/Manuals/Repository/repository-html/repository_66.html
+++ b/Manuals/Repository/repository-html/repository_66.html
@@ -1,8 +1,6 @@
 
 
-
-
+
 
 
-The CentOS Artwork Repository: Index
+CentOS Artwork Repository: 3.63 trunk/Translations/Identity/Brands
 
-
-
+
+
 
 
 
@@ -54,168 +52,152 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 Index 

-
Jump to:   B
-   
-C
-   
-H
-   
-M
-   
-S
-   
-T
-   
-U
-   
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
 3.63 trunk/Translations/Identity/Brands 

+
+
+
+
 3.63.1 Goals 

+
+
    
+
  •  Organize brands' translation files.
+

+
+
+
+
 3.63.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:
+

+
+
+
 3.63.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.
+

+
+
+
 3.63.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.
+

+
+
+
 3.63.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.
+

+

+

+
+
+
+
 3.63.3 Usage 

+
+
To render brands' translation files, use the following command:
+

+
centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
+

+
+
+
 3.63.4 See also 

+
+
Index Entry Section
 
B
branches1. branches
 
C
Common translation files3.52.2.5 Common Translation Files
 
H
How to render brands' translation files3.54.3 Usage
How to render fonts' translation files3.56.3 Usage
How to render translation files3.52.3 Usage
 
M
Metadata maintainance3.47.2 Description
 
S
Specific translation files3.52.2.6 Specific Translation Files
 
T
tags2. tags
Template translation files3.52.2.4 Template Translation Files
Translation brands file names3.54.2.1 Conventional file names
Translation brands file names3.54.2.2 Numeric file names
Translation configuration scripts3.52.2.8 Translation (Pre-)Rendering Configuration Scripts
Translation entries3.52.2.1 Translation Entries
Translation files3.52.2.3 Translation Files
Translation markers3.52.2.2 Translation Markers
Translation paths3.52.2.1 Translation Entries
Translation pre-rendering configuration scripts3.52.2.8 Translation (Pre-)Rendering Configuration Scripts
Translation rendering3.52.2.7 Translation Rendering
Translation rendering default functionality3.52.2.9 Translation Rendering Default Functionality
trunk3. trunk
trunk Identity3.1 trunk/Identity
trunk Identity Brands3.2 trunk/Identity/Brands
trunk Identity Budokan3.3 trunk/Identity/Budokan
trunk Identity Budokan Ozzy3.4 trunk/Identity/Budokan/Ozzy
trunk Identity Fonts3.5 trunk/Identity/Fonts
trunk Identity Icons3.6 trunk/Identity/Icons
trunk Identity Isolinux3.7 trunk/Identity/Isolinux
trunk Identity Models3.8 trunk/Identity/Models
trunk Identity Models Css3.9 trunk/Identity/Models/Css
trunk Identity Models Html3.10 trunk/Identity/Models/Html
trunk Identity Models Img Promo Web3.11 trunk/Identity/Models/Img/Promo/Web
trunk Identity Models Tpl3.12 trunk/Identity/Models/Tpl
trunk Identity Models Tpl Promo Web3.13 trunk/Identity/Models/Tpl/Promo/Web
trunk Identity Models Xcf3.14 trunk/Identity/Models/Xcf
trunk Identity Release3.15 trunk/Identity/Release
trunk Identity Themes3.16 trunk/Identity/Themes
trunk Identity Themes Models3.17 trunk/Identity/Themes/Models
trunk Identity Themes Models Alternative3.18 trunk/Identity/Themes/Models/Alternative
trunk Identity Themes Models Default3.19 trunk/Identity/Themes/Models/Default
trunk Identity Themes Models Default Distro3.20 trunk/Identity/Themes/Models/Default/Distro
trunk Identity Themes Models Default Distro Anaconda3.21 trunk/Identity/Themes/Models/Default/Distro/Anaconda
trunk Identity Themes Models Default Promo3.22 trunk/Identity/Themes/Models/Default/Promo
trunk Identity Themes Models Default Web3.23 trunk/Identity/Themes/Models/Default/Web
trunk Identity Themes Motifs3.24 trunk/Identity/Themes/Motifs
trunk Identity Themes Motifs Flame3.25 trunk/Identity/Themes/Motifs/Flame
trunk Identity Themes Motifs Modern3.26 trunk/Identity/Themes/Motifs/Modern
trunk Identity Themes Motifs Modern Backgrounds3.27 trunk/Identity/Themes/Motifs/Modern/Backgrounds
trunk Identity Themes Motifs Modern Backgrounds Img3.28 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
trunk Identity Themes Motifs Modern Backgrounds Tpl3.29 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
trunk Identity Themes Motifs Modern Backgrounds Xcf3.30 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf
trunk Identity Themes Motifs Modern Distro Anaconda Progress3.31 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
trunk Identity Themes Motifs Modern Palettes3.32 trunk/Identity/Themes/Motifs/Modern/Palettes
trunk Identity Themes Motifs TreeFlower3.33 trunk/Identity/Themes/Motifs/TreeFlower
trunk Identity Themes Motifs TreeFlower Backgrounds3.34 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
trunk Identity Widgets3.35 trunk/Identity/Widgets
trunk Manuals3.36 trunk/Manuals
trunk Scripts3.37 trunk/Scripts
trunk Scripts Bash3.38 trunk/Scripts/Bash
trunk Scripts Bash Functions3.39 trunk/Scripts/Bash/Functions
trunk Scripts Bash Functions Html3.40 trunk/Scripts/Bash/Functions/Html
trunk Scripts Bash Functions Locale3.41 trunk/Scripts/Bash/Functions/Locale
trunk Scripts Bash Functions Manual3.42 trunk/Scripts/Bash/Functions/Manual
trunk Scripts Bash Functions Path3.43 trunk/Scripts/Bash/Functions/Path
trunk Scripts Bash Functions Render3.44 trunk/Scripts/Bash/Functions/Render
trunk Scripts Bash Functions Render Config3.45 trunk/Scripts/Bash/Functions/Render/Config
trunk Scripts Bash Functions Shell3.46 trunk/Scripts/Bash/Functions/Shell
trunk Scripts Bash Functions Svg3.47 trunk/Scripts/Bash/Functions/Svg
trunk Scripts Bash Functions Verify3.48 trunk/Scripts/Bash/Functions/Verify
trunk Scripts Bash Locale3.49 trunk/Scripts/Bash/Locale
trunk Scripts Perl3.50 trunk/Scripts/Perl
trunk Scripts Python3.51 trunk/Scripts/Python
trunk Translations3.52 trunk/Translations
trunk Translations Identity3.53 trunk/Translations/Identity
trunk Translations Identity Brands3.54 trunk/Translations/Identity/Brands
trunk Translations Identity Brands Tpl3.55 trunk/Translations/Identity/Brands/Tpl
trunk Translations Identity Fonts3.56 trunk/Translations/Identity/Fonts
trunk Translations Identity Models3.57 trunk/Translations/Identity/Models
trunk Translations Identity Release3.58 trunk/Translations/Identity/Release
trunk Translations Identity Themes3.59 trunk/Translations/Identity/Themes
trunk Translations Identity Themes Backgrounds3.60 trunk/Translations/Identity/Themes/Backgrounds
trunk Translations Identity Themes Distro Anaconda Progress3.61 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
trunk Translations Identity Widgets3.62 trunk/Translations/Identity/Widgets
 
U
Unused definitions3.47.2.1 Metadata maintainance
 

+
+
3.64 trunk/Translations/Identity/Brands/Tpl  
+
3.2 trunk/Identity/Brands  
+

 

-
Jump to:   B
-   
-C
-   
-H
-   
-M
-   
-S
-   
-T
-   
-U
-   
-

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

 

  
-  This document was generated on February, 21 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_67.html b/Manuals/Repository/repository-html/repository_67.html
index f2cf096..15da3d8 100644
--- a/Manuals/Repository/repository-html/repository_67.html
+++ b/Manuals/Repository/repository-html/repository_67.html
@@ -1,8 +1,6 @@
 
 
-
-
+
 
 
-The CentOS Artwork Repository: List of Figures
+CentOS Artwork Repository: 3.64 trunk/Translations/Identity/Brands/Tpl
 
-
-
+
+
 
 
 
@@ -54,83 +52,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 List of Figures 

-

-
Figure 3.1
The CentOS web customization design model.
-

-
Figure 3.2
The CentOS web customization using promotion design model.
-

-
Figure 3.3
Web environment html definitions
-

-
Figure 3.4
The CentOS web navigation design model.
-

-
Figure 3.5
The Flame artistic motif.
-

-
Figure 3.6
The Flame artistic motif construction step 1.
-

-
Figure 3.7
The Flame artistic motif construction step 2.
-

-
Figure 3.8
The Flame artistic motif construction step 3.
-

-
Figure 3.9
The Flame artistic motif construction step 4.
-

-
Figure 3.10
The Modern artistic motif.
-

-
Figure 3.11
The TreeFlower artistic motif.
-

-
Figure 3.12
The functionalities initialization environment.
-

-
Figure 3.13
The actions initialization environment.
-

-
Figure 3.14
The cli_commitRepoChanges function output.
-

-
Figure 3.15
The CentOS Artwork Repository layout.
-

-
Figure 3.16
Name convention for tags and branches creation.
-

-
Figure 3.17
Parallel directories removing uncommon information.
-

-
Figure 3.18
Parallel directories adding uncommon information.
-

-
Figure 3.19
Wrong construction of parallel directories.
-

-
Figure 3.20
The functions script base comment structure
-

-
Figure 3.21
The function script comment example
-

-
Figure 3.22
The image rendering flow.
-

-

+
+
+
 3.64 trunk/Translations/Identity/Brands/Tpl 

+
+
+
+
 3.64.1 Goals 

+
+
+
+
 3.64.2 Description 

+
+
+
+
 3.64.3 Usage 

+
+
+
+
 3.64.4 See also 

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

 

  
-  This document was generated on February, 21 2011 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_68.html b/Manuals/Repository/repository-html/repository_68.html
index a27c09f..d03f267 100644
--- a/Manuals/Repository/repository-html/repository_68.html
+++ b/Manuals/Repository/repository-html/repository_68.html
@@ -1,13 +1,6 @@
 
 
-
-
+
 
 
-CentOS Artwork Repository: List of Figures
+CentOS Artwork Repository: 3.65 trunk/Translations/Identity/Fonts
 
-
-
+
+
 
 
 
@@ -59,69 +52,108 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 List of Figures 

-

-
Figure 3.1
The CentOS Type.
-

-
Figure 3.2
The CentOS Type plus release information (i.e., CentOS Release Brand).
-

-
Figure 3.3
The CentOS Type plus release information plus description (i.e., CentOS Release Brand with description).
-

-
Figure 3.4
The CentOS web customization design model.
-

-
Figure 3.5
The CentOS web customization using promotion design model.
-

-
Figure 3.6
Web environment html definitions
-

-
Figure 3.7
The CentOS web navigation design model.
-

-
Figure 3.8
The `centos-art.sh' initialization environment.
-

-
Figure 3.9
The cli_commitRepoChanges function output.
-

-
Figure 3.10
The CentOS Artwork Repository layout.
-

-
Figure 3.11
Name convention for tags and branches creation.
-

-
Figure 3.12
Parallel directories removing uncommon information.
-

-
Figure 3.13
Parallel directories adding uncommon information.
+
+
+
 3.65 trunk/Translations/Identity/Fonts 

+
+
+
+
 3.65.1 Goals 

+
+
This section exists to organize fonts translation files.
+

+
+
 3.65.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 trunk/Identity/Fonts) is used as
+reference when someone needs to know which font-families are allowed
+to use inside CentOS visual identity.
+

+
+
+
+
 3.65.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.
 

-
Figure 3.14
Wrong construction of parallel directories.
+
 `font-weight:normal'

+
Specify which font weight to use when rendering font preview images.
 

-
Figure 3.15
The image rendering flow.
+
 `font-style:normal'

+
Specify which font style to use when rendering font preview images.
 

 

 
 
+
+
 3.65.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
+

+
+
+
 3.65.4 See also 

+
+
+
+
3.3 trunk/Identity/Fonts  
+

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

 

  
-  This document was generated on December, 2 2010 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_69.html b/Manuals/Repository/repository-html/repository_69.html
index fd23c4e..51c5833 100644
--- a/Manuals/Repository/repository-html/repository_69.html
+++ b/Manuals/Repository/repository-html/repository_69.html
@@ -1,10 +1,6 @@
 
 
-
-
+
 
 
-CentOS Artwork Repository: List of Figures
+CentOS Artwork Repository: 3.66 trunk/Translations/Identity/Models
 
-
-
+
+
 
 
 
@@ -56,51 +52,54 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
-
+
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ Up ][ >> ][ << ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 List of Figures 

-

-
Figure 3.1
The CentOS web customization design model.
-

-
Figure 3.2
The CentOS web customization using promotion design model.
-

-
Figure 3.3
Web environment html definitions
-

-
Figure 3.4
The CentOS web navigation design model.
-

-
Figure 3.5
The centos-art.sh initialization environment.
-

-
Figure 3.6
The image rendering flow.
-

-

+
+
+
 3.66 trunk/Translations/Identity/Models 

+
+
+
+
 3.66.1 Goals 

+
+
+
+
 3.66.2 Description 

+
+
+
+
 3.66.3 Usage 

+
+
+
+
 3.66.4 See also 

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

 

  
-  This document was generated on October, 27 2010 using texi2html 1.76.
+  This document was generated on February, 25 2011 using texi2html 1.76.
  
  

 
diff --git a/Manuals/Repository/repository-html/repository_7.html b/Manuals/Repository/repository-html/repository_7.html
index 789d105..b347da6 100644
--- a/Manuals/Repository/repository-html/repository_7.html
+++ b/Manuals/Repository/repository-html/repository_7.html
@@ -9,7 +9,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: 3.17.1 Goals
+CentOS Artwork Repository: 3.67 trunk/Translations/Identity/Release
 
-
-
+
+