Table of Contents ***************** CentOS Artwork Repository 1 branches 2 tags 3 trunk 3.1 trunk/Identity 3.1.1 Goals 3.1.2 Description 3.1.3 Usage 3.1.4 Renderable directories 3.1.4.1 Layout 1: Simple image rendering 3.1.4.2 Layout 2: Simple image rendering (extended) 3.1.4.3 Layout 3: Language specific image rendering 3.1.4.4 Layout 4: Release and language specific image rendering 3.1.4.5 Layout 5: Brands specific image rendering 3.1.4.6 Layout 6: Themes specific image rendering 3.1.5 File name convenctions 3.1.5.1 When text-based files are rendered 3.1.5.2 When image-based files are rendered 3.1.6 See also 3.1.7 References 3.2 trunk/Identity/Brands 3.2.1 Goals 3.2.2 Description 3.2.3 Usage 3.2.4 See also 3.3 trunk/Identity/Fonts 3.3.1 Goals 3.3.2 Description 3.3.3 Usage 3.3.4 See also 3.4 trunk/Identity/Icons 3.4.1 Goals 3.4.2 Description 3.4.3 Usage 3.4.4 See also 3.5 trunk/Identity/Isolinux 3.5.1 Goals 3.5.2 Description 3.5.3 Usage 3.5.4 See also 3.6 trunk/Identity/Models 3.6.1 Goals 3.6.2 Description 3.6.3 Usage 3.6.4 See also 3.7 trunk/Identity/Models/Css 3.7.1 Goals 3.7.2 Description 3.7.3 Usage 3.7.4 See also 3.8 trunk/Identity/Models/Html 3.8.1 Goals 3.8.2 Description 3.8.3 Usage 3.8.4 See also 3.9 trunk/Identity/Models/Img/Promo/Web 3.9.1 Goals 3.9.2 Description 3.9.3 Usage 3.9.4 See also 3.10 trunk/Identity/Models/Tpl 3.10.1 Goals 3.10.2 Description 3.10.3 Usage 3.10.4 See also 3.11 trunk/Identity/Models/Tpl/Promo/Web 3.11.1 Goals 3.11.2 The CentOS web environment 3.11.2.1 Design model (without ads) 3.11.2.2 Design model (with ads) 3.11.2.3 HTML definitions 3.11.2.4 Controlling visual style 3.11.2.5 Producing visual style 3.11.2.6 Navigation 3.11.2.7 Development and release cycle 3.11.2.8 The [webenv-test] repository 3.11.2.9 The [webenv] repository 3.11.2.10 Priority configuration 3.11.3 Usage 3.11.4 See also 3.12 trunk/Identity/Models/Xcf 3.12.1 Goals 3.12.2 Description 3.12.3 Usage 3.12.4 See also 3.13 trunk/Identity/Release 3.13.1 Goals 3.13.2 Description 3.13.3 Usage 3.13.4 See also 3.14 trunk/Identity/Themes 3.14.1 Goals 3.14.2 Description 3.14.3 Usage 3.14.4 See also 3.15 trunk/Identity/Themes/Models 3.15.1 Goals 3.15.2 Description 3.15.3 Usage 3.15.4 See also 3.16 trunk/Identity/Themes/Models/Alternative 3.16.1 Goals 3.16.2 Description 3.16.3 Usage 3.16.4 See also 3.17 trunk/Identity/Themes/Models/Default 3.17.1 Goals 3.17.2 Description 3.17.3 Usage 3.17.4 See also 3.18 trunk/Identity/Themes/Models/Default/Distro 3.18.1 Goals 3.18.2 Description 3.18.2.1 One theme for all major releases 3.18.2.2 One theme for each major release 3.18.3 Usage 3.18.4 See also 3.19 trunk/Identity/Themes/Models/Default/Distro/Anaconda 3.19.1 Goals 3.19.2 Description 3.19.3 Usage 3.19.4 See also 3.20 trunk/Identity/Themes/Models/Default/Promo 3.20.1 Goals 3.20.2 Description 3.20.3 Usage 3.20.4 See also 3.21 trunk/Identity/Themes/Models/Default/Web 3.21.1 Goals 3.21.2 Description 3.21.3 Usage 3.21.4 See also 3.22 trunk/Identity/Themes/Motifs 3.22.1 Goals 3.22.2 Description 3.22.3 Usage 3.22.4 See also 3.23 trunk/Identity/Themes/Motifs/Flame 3.23.1 Step 1: Set image size 3.23.2 Step 2: Add patterns 3.23.3 Step 3: Add flame motif 3.23.4 Step 4: Add foreground color 3.23.5 See also 3.24 trunk/Identity/Themes/Motifs/Modern 3.24.1 Presentation 3.24.2 Construction 3.24.3 Usage 3.24.4 See also 3.25 trunk/Identity/Themes/Motifs/Modern/Backgrounds 3.25.1 Goals 3.25.2 Description 3.25.3 Usage 3.25.4 See also 3.26 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img 3.26.1 Goals 3.26.2 Description 3.26.3 Usage 3.26.4 See also 3.27 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl 3.27.1 Goals 3.27.2 Description 3.27.3 Usage 3.27.4 See also 3.28 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf 3.28.1 Goals 3.28.2 Description 3.28.3 Usage 3.28.4 See also 3.29 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress 3.29.1 Goals 3.29.2 Description 3.29.3 Usage 3.29.4 See also 3.30 trunk/Identity/Themes/Motifs/Modern/Palettes 3.30.1 Goals 3.30.2 Description 3.30.3 Usage 3.30.4 See also 3.31 trunk/Identity/Themes/Motifs/TreeFlower 3.31.1 Goals 3.31.2 Description 3.31.3 Usage 3.31.4 See also 3.32 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds 3.32.1 Goals 3.32.2 Description 3.32.2.1 Desktop background 3.32.2.2 Anaconda Prompt (syslinux) background 3.32.2.3 Grub background 3.32.3 Usage 3.32.4 See also 3.33 trunk/Identity/Widgets 3.33.1 Goals 3.33.2 Description 3.33.3 Usage 3.33.4 See also 3.34 trunk/Manuals 3.34.1 Goals 3.34.2 Description 3.34.3 Usage 3.34.4 See also 3.35 trunk/Scripts 3.35.1 Goals 3.35.2 Description 3.35.3 Usage 3.35.4 See also 3.36 trunk/Scripts/Bash 3.36.1 Goals 3.36.2 Description 3.36.3 Usage 3.36.4 See also 3.37 trunk/Scripts/Bash/Functions 3.37.1 Goals 3.37.2 Description 3.37.3 Usage 3.37.3.1 Global variables 3.37.3.2 Global functions 3.37.3.3 Specific functions 3.37.4 See also 3.38 trunk/Scripts/Bash/Functions/Html 3.38.1 Goals 3.38.2 Description 3.38.3 Usage 3.38.4 See also 3.39 trunk/Scripts/Bash/Functions/Locale 3.39.1 Goals 3.39.2 Description 3.39.3 Usage 3.39.4 See also 3.40 trunk/Scripts/Bash/Functions/Manual 3.40.1 Goals 3.40.2 Description 3.40.3 Usage 3.40.4 See also 3.41 trunk/Scripts/Bash/Functions/Path 3.41.1 Goals 3.41.2 Description 3.41.2.1 Repository layout 3.41.2.2 Repository name convenctions 3.41.2.3 Repository work flow 3.41.2.4 Parallel directories 3.41.2.5 Syncronizing path information 3.41.2.6 What is the right location to store it? 3.41.3 Usage 3.41.4 See also 3.42 trunk/Scripts/Bash/Functions/Render 3.42.1 Goals 3.42.2 Description 3.42.3 Usage 3.42.4 See also 3.43 trunk/Scripts/Bash/Functions/Render/Config 3.43.1 Goals 3.43.2 Description 3.43.2.1 The `render.conf.sh' identity model 3.43.2.2 The `render.conf.sh' translation model 3.43.2.3 The `render.conf.sh' rendering actions 3.43.3 Usage 3.43.4 See also 3.44 trunk/Scripts/Bash/Functions/Shell 3.44.1 Goals 3.44.2 Description 3.44.3 Usage 3.44.4 See also 3.45 trunk/Scripts/Bash/Functions/Svg 3.45.1 Goals 3.45.2 Description 3.45.2.1 Metadata maintainance 3.45.2.2 Unused definitions 3.45.3 Usage 3.45.4 See also 3.46 trunk/Scripts/Bash/Functions/Verify 3.46.1 Goals 3.46.2 Description 3.46.2.1 Packages 3.46.2.2 Links 3.46.2.3 Environment variables 3.46.3 Usage 3.46.4 See also 3.47 trunk/Scripts/Bash/Locale 3.47.1 Goals 3.47.2 Description 3.47.3 Usage 3.47.4 See also 3.48 trunk/Scripts/Perl 3.48.1 Goals 3.48.2 Description 3.48.3 Usage 3.48.4 See also 3.49 trunk/Scripts/Python 3.49.1 Goals 3.49.2 Description 3.49.3 Usage 3.49.4 See also 3.50 trunk/Translations 3.50.1 Goals 3.50.2 Description 3.50.2.1 Translation Entries 3.50.2.2 Translation Markers 3.50.2.3 Translation Files 3.50.2.4 Template Translation Files 3.50.2.5 Common Translation Files 3.50.2.6 Specific Translation Files 3.50.2.7 Translation Rendering 3.50.2.8 Translation (Pre-)Rendering Configuration Scripts 3.50.2.9 Translation Rendering Default Functionality 3.50.3 Usage 3.50.4 See also 3.51 trunk/Translations/Identity 3.51.1 Goals 3.51.2 Description 3.51.3 Usage 3.51.4 See also 3.52 trunk/Translations/Identity/Brands 3.52.1 Goals 3.52.2 Description 3.52.2.1 Conventional file names 3.52.2.2 Numeric file names 3.52.2.3 Translation markers 3.52.3 Usage 3.52.4 See also 3.53 trunk/Translations/Identity/Brands/Tpl 3.53.1 Goals 3.53.2 Description 3.53.3 Usage 3.53.4 See also 3.54 trunk/Translations/Identity/Fonts 3.54.1 Goals 3.54.2 Description 3.54.2.1 Translation Markers 3.54.3 Usage 3.54.4 See also 3.55 trunk/Translations/Identity/Models 3.55.1 Goals 3.55.2 Description 3.55.3 Usage 3.55.4 See also 3.56 trunk/Translations/Identity/Release 3.56.1 Goals 3.56.2 Description 3.56.3 Usage 3.56.4 See also 3.57 trunk/Translations/Identity/Themes 3.57.1 Goals 3.57.2 Description 3.57.3 Usage 3.57.4 See also 3.58 trunk/Translations/Identity/Themes/Backgrounds 3.58.1 Goals 3.58.2 Description 3.58.3 Usage 3.58.4 See also 3.59 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress 3.59.1 Goals 3.59.2 Description 3.59.3 Usage 3.59.4 See also 3.60 trunk/Translations/Identity/Widgets 3.60.1 Goals 3.60.2 Description 3.60.3 Usage 3.60.4 See also Index List of Figures CentOS Artwork Repository ************************* This manual describes the CentOS Artwork Repository. The CentOS Artwork Repository exists to organize and automate The CentOS Project corporate visual identity (*note trunk Identity::, to start on). Copyright (C) 2009, 2010 Alain Reguera Delgado. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no 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. 1 branches ********** 2 tags ****** 3 trunk ******* 3.1 trunk/Identity ================== 3.1.1 Goals ----------- The `trunk/Identity' directory exists to organize CentOS corporate identity artworks. 3.1.2 Description ----------------- The CentOS Project corporate identity is the "persona" of the organization known as The CentOS Project. The CentOS Project corporate identity plays a significant role in the way the CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, the CentOS Project corporate visual identity expresses the values and ambitions of the CentOS Project organization, its business, and its characteristics. The CentOS Project corporate identity provides visibility, recognizability, reputation, structure and identification to the CentOS Project organization by means of corporate design, corporate communication, and corporate behaviour. The CentOS Project settles down its corporate visual identity on a "monolithic corporate visual identity structure". In this structure The CentOS Project uses one unique name (The CentOS Brand) and one unique visual style (The CentOS Default Theme) in all its manifestations. *The CentOS Brands* The CentOS brand is the name or trademark that conncects the producer with their products. In this case, the producer is The CentOS Project and the products are the CentOS distributions, the CentOS web sites, the CentOS promotion stuff, etc. *Note trunk Identity Brands::, for more information. *The CentOS Themes* The CentOS themes are a set of image files connected by one unique visual style. The CentOS themes implements CentOS project corporate visual identity in each visual manifestation of CentOS project (e.g., distributions, websites, promotion stuff, etc.). *Note trunk Identity Themes::, for more information. Inside a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting websites, using the distribution, or acting on social events, the one unique name and one unique visual style conect them all to say: Hey! we are all parts of the CentOS project. And, probably, some vister will say: Can I join the party? Yes you can, it is free. :) 3.1.3 Usage ----------- To produce identity artworks, use the following commands: `centos-art render 'path/to/dir'' When `path/to/dir' refers to one renderable directory under `trunk/Identity', this command renders identity artworks using both related design models and related translation files. `centos-art render 'path/to/dir' --filter='pattern'' When `path/to/dir' refers to one renderable directory under `trunk/Identity', this command renders identity artworks using both related design models and related translation files that match the regular expression passed in `--filter='pattern'' argument. To control the number of files produced by `centos-art' command, you need to look into the translation path and provide a regular expression pattern that matches the translation path, or paths, related to the file, or files, you want to produce. The regular expression pattern you provide to `centos-art' command is applied to the translation path from its very beginning. It is not the same to say `5/en/01-welcome' that `01-welcome', the frist expression matches but the last one does not. When using `--filter='pattern'' you don't need to specify the file extension. It is removed from translation path before applying the pattern, so it doesn't count here. 3.1.4 Renderable directories ---------------------------- Inside `trunk/Identity', renderable directories should have one of the following directory layouts: 3.1.4.1 Layout 1: Simple image rendering ........................................ This directory layout contains one `Img/' directory (to store final images), one `Tpl/' directory to store design templates, and the translation entry is empty (there isn't translation files in this configuration). In this configuration, one design template produces one untranslated PNG image, just as it is in the template. trunk/Identity/path/to/dir |-- Img | |-- anaconda_header_fig1.png | |-- anaconda_header_fig2.png | `-- anaconda_header_summary.png `-- Tpl |-- anaconda_header_fig1.svg |-- anaconda_header_fig2.svg `-- anaconda_header_summary.svg 3.1.4.2 Layout 2: Simple image rendering (extended) ................................................... This directory layout contains one `Img/' directory (to store final images), one `Tpl/' directory to store design templates, and the translation entry is empty (there isn't translation files in this configuration). When images are rendered, the `Img/' directory structure is created automatically using the `Tpl/' directory structure as reference. In this configuration, one design template produces one untranslated PNG image, just as it is in the template. trunk/Identity/path/to/dir |-- Img | |-- Corporate | | `-- monolithic.png | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.png | |-- fig2.png | `-- summary.png `-- Tpl |-- Corporate | `-- monolithic.svg `-- Distro `-- Anaconda `-- Header |-- fig1.svg |-- fig2.svg `-- summary.svg 3.1.4.3 Layout 3: Language specific image rendering ................................................... This directory layout extends previous one in order to produce language-specific images. This directory layout contains one `Img/' directory (to store final images), one `Tpl/' directory to store design templates, and the translation entry contains translation files inside (organized by language codes). trunk/Translations/Identity/path/to/dir |-- en | |-- Corporate | | `-- monolithic.sed | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.sed | |-- fig2.sed | `-- summary.sed `-- es |-- Corporate | `-- monolithic.sed `-- Distro `-- Anaconda `-- Header |-- fig1.sed |-- fig2.sed `-- summary.sed When images are rendered, the `Img/' directory structure is created automatically using the translation entry structure as reference (see above). trunk/Identity/path/to/dir |-- Img | |-- en | | |-- Corporate | | | `-- monolithic.png | | `-- Distro | | `-- Anaconda | | `-- Header | | |-- fig1.png | | |-- fig2.png | | `-- summary.png | `-- es | |-- Corporate | | `-- monolithic.png | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.png | |-- fig2.png | `-- summary.png `-- Tpl |-- Corporate | `-- monolithic.svg `-- Distro `-- Anaconda `-- Header |-- fig1.svg |-- fig2.svg `-- summary.svg In this configuration, one language-specific file is applied to one design tempalate to produce one translated PNG image. The relation between language-specific translation file and design template is done removing the language-specific directory from translation path, and the one design template path that matches it is used. If no design template is found for one translation file, the final PNG image for that translation file is not produced and the next translation file in the list is evaluated. For example, in this configuration the following translation files: trunk/Translations/Identity/path/to/dir/en/Corporate/monolithic.sed trunk/Translations/Identity/path/to/dir/es/Corporate/monolithic.sed match the same design template file: trunk/Identity/path/to/dir/Tpl/Corporate/monolithic.svg in order to produce the following PNG image files: trunk/Identity/path/to/dir/Img/en/Corporate/monolithic.png trunk/Identity/path/to/dir/Img/es/Corporate/monolithic.png 3.1.4.4 Layout 4: Release and language specific image rendering ............................................................... This directory layout extends previous one in order to produce language-specific images for different major releases of CentOS distribution (as CentOS release schema describes). This directory layout contains one `Img/' directory (to store final images), one `Tpl/' directory to store design templates, and the translation entry contains translation files inside (organized by language codes and major release numbers). trunk/Translations/Identity/path/to/dir |-- 5 | |-- en | | |-- Corporate | | | `-- monolithic.sed | | `-- Distro | | `-- Anaconda | | `-- Header | | |-- fig1.sed | | |-- fig2.sed | | `-- summary.sed | `-- es | |-- Corporate | | `-- monolithic.sed | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.sed | |-- fig2.sed | `-- summary.sed `-- 6 |-- en | |-- Corporate | | `-- monolithic.sed | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.sed | |-- fig2.sed | `-- summary.sed `-- es |-- Corporate | `-- monolithic.sed `-- Distro `-- Anaconda `-- Header |-- fig1.sed |-- fig2.sed `-- summary.sed When images are rendered, the `Img/' directory structure is created automatically using the translation entry structure as reference (see above). trunk/Identity/path/to/dir |-- Img | |-- 5 | | |-- en | | | |-- Corporate | | | | `-- monolithic.png | | | `-- Distro | | | `-- Anaconda | | | `-- Header | | | |-- fig1.png | | | |-- fig2.png | | | `-- summary.png | | `-- es | | |-- Corporate | | | `-- monolithic.png | | `-- Distro | | `-- Anaconda | | `-- Header | | |-- fig1.png | | |-- fig2.png | | `-- summary.png | `-- 6 | |-- en | | |-- Corporate | | | `-- monolithic.png | | `-- Distro | | `-- Anaconda | | `-- Header | | |-- fig1.png | | |-- fig2.png | | `-- summary.png | `-- es | |-- Corporate | | `-- monolithic.png | `-- Distro | `-- Anaconda | `-- Header | |-- fig1.png | |-- fig2.png | `-- summary.png `-- Tpl |-- Corporate | `-- monolithic.svg `-- Distro `-- Anaconda `-- Header |-- fig1.svg |-- fig2.svg `-- summary.svg In this configuration, one language-specific file, is applied to one design tempalate to produce one translated PNG image for each major release specified in the translation entry. The relation among release-specific and language-specific translation files, and design template is done removing the release-specific and language-specific directories from translation path, and looking for the one design template path that matches. If no design template matches the translation file, the final PNG image for that translation file is not produced and the next translation file in the list is evaluated. For example, in this configuration, the following translation files: trunk/Translations/Identity/path/to/dir/5/en/Corporate/monolithic.sed trunk/Translations/Identity/path/to/dir/5/es/Corporate/monolithic.sed trunk/Translations/Identity/path/to/dir/6/en/Corporate/monolithic.sed trunk/Translations/Identity/path/to/dir/6/es/Corporate/monolithic.sed match the same design template file: trunk/Identity/path/to/dir/Tpl/Corporate/monolithic.svg in order to produce the following PNG image files: trunk/Identity/path/to/dir/Img/5/en/Corporate/monolithic.png trunk/Identity/path/to/dir/Img/5/es/Corporate/monolithic.png trunk/Identity/path/to/dir/Img/6/en/Corporate/monolithic.png trunk/Identity/path/to/dir/Img/6/es/Corporate/monolithic.png 3.1.4.5 Layout 5: Brands specific image rendering ................................................. *Note trunk Identity Brands::, for more information about themes specific image rendering and directory layout. 3.1.4.6 Layout 6: Themes specific image rendering ................................................. *Note trunk Identity Themes::, for more information about themes specific image rendering and directory layout. 3.1.5 File name convenctions ---------------------------- As file name convenction, inside CentOS Artwork Repository, both text-based and image-based file name produced by `centos-art.sh' script has the same name of their translation files without the `.sed' extension. The file extension is set as follow: 3.1.5.1 When text-based files are rendered .......................................... Text-based files end up having the same extension of their design template file. 3.1.5.2 When image-based files are rendered ........................................... Image-based files always end up having the `.png' extension. *Tip* Once `.png' images are created, other image formats may be created using the `renderFormats' post-rendering action, inside the image-based related pre-rendering configuration script. *Note trunk Scripts Bash::, for more information. 3.1.6 See also -------------- 3.1.7 References ---------------- * `http://en.wikipedia.org/Corporate_identity' (and related links). 3.2 trunk/Identity/Brands ========================= 3.2.1 Goals ----------- * ... 3.2.2 Description ----------------- 3.2.3 Usage ----------- 3.2.4 See also -------------- 3.3 trunk/Identity/Fonts ======================== 3.3.1 Goals ----------- This section exists to organize digital typographies used by the CentOS project. 3.3.2 Description ----------------- 3.3.3 Usage ----------- The CentOS corporate identity is attached to `DejaVu LGC' font-family. Whatever artwork you design for CentOS project, that requires typography usage, must be done using `DejaVu LGC' font-family. *Recommendation-1:* For screen desings (e.g., anything that final destination will never be printed on paper or any medium outside computer screens) use `DejaVu LGC Sans' font-family. *Recommendation-2:* For non-screen designs (e.g., anything that final desition will be printed on paper or any other medium outside computer screens) use `DejaVu LGC Serif' font-family. As convenction files described in this rule are stored under `Stationery' directories. The only execption for the two recommendations above is the typography used inside CentOS logo. The CentOS logo is the main visual representation of the CentOS project so the typography used in it must be the same always, no matter where it be shown. It also has to be clear enough to dismiss any confussion between similar typefaces (e.g., the number one (1) sometimes is confuesed with the letter `el' (l) or letter `ai' (i)). As CentOS logo typography convenction, the word `CentOS' uses `Denmark' typography as base, both for the word `CentOS' and the phrase `Community Enterprise Operating System'. The size of CentOS logo's phrase is half the size in poits the word `CentOS' has and it below `CentOS' word and aligned with it on the left. The distance between `CentOS' word and phrase `Community Enterprise Operating System' have the size in points the phrase has. When the CentOS release brand is built, use `Denmark' typography for the release number. The release number size is two times larger (in height) than default `CentOS' word. The separation between release number and `CentOS' word is twice the size in points of separation between `CentOS' word and phrase `Community Enterprise Operating System'. Another component inside CentOS logo is the trademark symbol (TM). This symbol specifies that the CentOS logo must be consider a product brand, even it is not a registered one. The trademark symbol uses DejaVu LGC Sans Regular typography. The trademark symbol is aligned right-top on the outter side of `CentOS' word. The trademark symbol must not exceed haf the distance, in points, between `CentOS' word and the release number on its right. It would be very convenient for the CentOS Project and its community to to make a registered trademark (®) of CentOS logo. To make a register trademark of CentOS Logo prevents legal complications in the market place of brands. It grants the consistency, through time, of CentOS project corporate visual identity. *Note* The information about trademarks and corporate identity is my personal interpretation of `http://en.wikipedia.org/Corporate_identity' and `http://en.wikipedia.org/Trademark' description. If you have practical experiences with these affairs, please serve yourself to improve this section with your reasons. 3.3.4 See also -------------- 3.4 trunk/Identity/Icons ======================== 3.4.1 Goals ----------- * ... 3.4.2 Description ----------------- 3.4.3 Usage ----------- 3.4.4 See also -------------- 3.5 trunk/Identity/Isolinux =========================== 3.5.1 Goals ----------- * ... 3.5.2 Description ----------------- 3.5.3 Usage ----------- 3.5.4 See also -------------- 3.6 trunk/Identity/Models ========================= 3.6.1 Goals ----------- This section exists to organize design models. 3.6.2 Description ----------------- Design models are representative designs useful to understand how to build artworks. 3.6.3 Usage ----------- 3.6.4 See also -------------- 3.7 trunk/Identity/Models/Css ============================= 3.7.1 Goals ----------- This directory exists to provide common style sheets (CSS) definitions to HTML design models. 3.7.2 Description ----------------- * ... 3.7.3 Usage ----------- * ... 3.7.4 See also -------------- 3.8 trunk/Identity/Models/Html ============================== 3.8.1 Goals ----------- * ... 3.8.2 Description ----------------- * ... 3.8.3 Usage ----------- * ... 3.8.4 See also -------------- 3.9 trunk/Identity/Models/Img/Promo/Web ======================================= 3.9.1 Goals ----------- * Provide images related to CentOS web interface. 3.9.2 Description ----------------- * ... 3.9.3 Usage ----------- * ... 3.9.4 See also -------------- 3.10 trunk/Identity/Models/Tpl ============================== 3.10.1 Goals ------------ * ... 3.10.2 Description ------------------ * ... 3.10.3 Usage ------------ * ... 3.10.4 See also --------------- 3.11 trunk/Identity/Models/Tpl/Promo/Web ======================================== 3.11.1 Goals ------------ Organize scalable vector graphics (svg) to help describe the CentOS web environment. 3.11.2 The CentOS web environment --------------------------------- Inside CentOS corporate identity, the CentOS web environment is considered a promotion component. The CentOS web environment is formed by a central web application --to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)-- and many different free web applications --to cover specific needs (e.g., wiki, mailing lists, etc.)--. The CentOS web environment is addressed to solve the following issues: * One unique name and one unique visual style to all web applications used inside the web environment. * One-step navigation to web applications inside the environment. * High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions). The CentOS project is attached to a monolithic corporate visual identity (*note trunk Identity::), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case. Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (`http://wiki.centos.org/') is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't support(1) a customization system that separates presentation from logic, similar to MoinMoin's one. This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic). To solve the "one unique visual style" issue, installation and actualization of web applications --used inside CentOS web environment-- need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes. At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. 3.11.2.1 Design model (without ads) ................................... 3.11.2.2 Design model (with ads) ................................ 3.11.2.3 HTML definitions ......................... 3.11.2.4 Controlling visual style ................................. Inside CentOS web environment, the visual style is controlled by the following compenents: *Webenv header background* trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png *CSS definitions* trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css 3.11.2.5 Producing visual style ............................... The visual style of CentOS web environment is defined in the following files: trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg As graphic designer you use `1024x250.xcf' file to produce `1024x250-bg.png' file. Later, inside `1024x250.svg' file, you use the `1024x250-bg.png' file as background layer to draw your vectorial design. When you consider you artwork ready, use the `centos-art.sh' script, as described below, to produce the visual style controller images of CentOS web environment. centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250' Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. 3.11.2.6 Navigation ................... Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. 3.11.2.7 Development and release cycle ...................................... The CentOS web environment development and relase cycle is described below: *Download* The first action is download the source code of web applications we want to use inside CentOS web environment. *Important* The source location from which web application are downloaded is very important. Use SRPMs from CentOS *[base]* and *[updates]* repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource. *Prepare* Once web application source code has been downloaded, our duty is organize its files inside `webenv' version controlled repository. When preparing the structure keep in mind that different web applications have different visual styles, and also different ways to implement it. A convenient way to organize the file system structure would be create one development line for each web application we use inside CentOS web environment. For example, consider the following file system structure: https://projects.centos.org/svn/webenv/trunk/ |-- WebApp1/ | |-- Sources/ | | `-- webapp1-0.0.1/ | |-- Rpms/ | | `-- webapp1-0.0.1.rpm | |-- Srpms/ | | `-- webapp1-0.0.1.srpm | `-- Specs/ | `-- webapp1-0.0.1.spec |-- WebApp2/ `-- WebAppN/ *Customize* Once web applications have been organized inside the version controlled repository file system, use subversion to create the CentOS customization development line of web applications source code. For example, using the above file system structure, you can create the customization development line of `webapp1-0.0.1/' with the following command: svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv The command above creates the following structure: https://projects.centos.org/svn/webenv/trunk/ |-- WebApp1/ | |-- Sources/ | | |-- webapp1-0.0.1/ | | `-- webapp1-0.0.1-webenv/ | |-- Rpms/ | | `-- webapp1-0.0.1.rpm | |-- Srpms/ | | `-- webapp1-0.0.1.srpm | `-- Specs/ | `-- webapp1-0.0.1.spec |-- WebApp2/ `-- WebAppN/ In the above structure, the `webapp1-0.0.1-webenv/' directory is the place where you customize the visual style of `webapp1-0.0.1/' web application. *Tip* Use Subversion's `diff' between CentOS customization and upstream development lines to know what you are changing exactly. *Build packages* When web application has been customized, build the web application RPM and SRPM using the source location with `-webenv' prefix. https://projects.centos.org/svn/webenv/trunk/ |-- WebApp1/ | |-- Sources/ | | |-- webapp1-0.0.1/ | | `-- webapp1-0.0.1-webenv/ | |-- Rpms/ | | |-- webapp1-0.0.1.rpm | | `-- webapp1-0.0.1-webenv.rpm | |-- Srpms/ | | |-- webapp1-0.0.1.srpm | | `-- webapp1-0.0.1-webenv.srpm | `-- Specs/ | |-- webapp1-0.0.1.spec | `-- webapp1-0.0.1-webenv.spec |-- WebApp2/ `-- WebAppN/ *Release for testing* When the customized web application has been packaged, make packages available for testing and quality assurance. This can be achives using a [webenv-test] yum repository. *Note* The [webenv-test] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv-test] repository you need to configure it first. If some problem is found to install/update/use the customized version of web application, the problem is notified somewhere (a bugtracker maybe) and the customization face is repated in order to fix the problem. To release the new package add a number after `-webenv' prefix. For example, if some problem is found in `webapp1-0.0.1-webenv.rpm', when it be fixed the new package will be named `webapp1-0.0.1-webenv-1.rpm'. If a problem is found in `webapp1-0.0.1-webenv-1.rpm', when it be fixed the new package will be named `webapp1-0.0.1-webenv-2.rpm', and so on. The "customization -- release for testing" process is repeated until CentOS quality assurance team considers the package is ready for production. *Release for production* When customized web application packages are considered ready for production they are moved from [webenv-test] to [webenv] repository. This action is commited by CentOS quality assurance team. *Note* The [webenv] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv] repository you need to configure it first. 3.11.2.8 The [webenv-test] repository ..................................... /etc/yum.repos.d/CentOS-Webenv-test.repo [webenv-test] name=CentOS-$releasever - Webenv-test mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test #baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever enabled=1 priority=10 3.11.2.9 The [webenv] repository ................................ /etc/yum.repos.d/CentOS-Webenv.repo [webenv] name=CentOS-$releasever - Webenv mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv #baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever enabled=1 priority=10 3.11.2.10 Priority configuration ................................ Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories. 3.11.3 Usage ------------ * ... 3.11.4 See also --------------- ---------- Footnotes ---------- (1) Mailman's theme support may be introduced in mailman-3.x.x release. 3.12 trunk/Identity/Models/Xcf ============================== 3.12.1 Goals ------------ * ... 3.12.2 Description ------------------ * ... 3.12.3 Usage ------------ * ... 3.12.4 See also --------------- 3.13 trunk/Identity/Release =========================== 3.13.1 Goals ------------ * ... 3.13.2 Description ------------------ 3.13.3 Usage ------------ 3.13.4 See also --------------- 3.14 trunk/Identity/Themes ========================== 3.14.1 Goals ------------ The `trunk/Identity/Themes/' directory exists to: * Organize CentOS Themes. 3.14.2 Description ------------------ 3.14.3 Usage ------------ In this location themes are organized in "Models" --to store common information-- and "Motifs"--to store unique information. At rendering time, both motifs and models are combined to produce the final CentOS themes. CentOS themes can be tagged as "Default" or "Alternative". CentOS themes are maintained by CentOS community. 3.14.4 See also --------------- 3.15 trunk/Identity/Themes/Models ================================= 3.15.1 Goals ------------ * Organize theme models. 3.15.2 Description ------------------ Theme models let you modeling characteristics (e.g., dimensions, translation markers, position of each element on the display area, etc.) common to all themes. Theme models let you reduce the time needed when propagating artistic motifs to different visual manifestations. Theme models serves as a central pool of design templates for themes to use. This way you can produce themes with different artistic motifs but same characteristics. 3.15.3 Usage ------------ Inside the framework location above, you find theme models organized by name. You can add your own theme models to the structure by adding a directory to the list. By default you have the `*Note Default: trunk Identity Themes Models Default,' and `*Note Alternative: trunk Identity Themes Models Alternative,' ready-to-use theme models. 3.15.4 See also --------------- 3.16 trunk/Identity/Themes/Models/Alternative ============================================= 3.16.1 Goals ------------ * ... 3.16.2 Description ------------------ CentOS alternative theme models exist for people how want to use a different visual style on their installations of CentOS distribution. As the visual style is needed for a system already installed components like Anaconda are not required inside alternative themes. Inside alternative themes you find post-installation visual style only (i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative themes are maintained by CentOS Community. 3.16.3 Usage ------------ * ... 3.16.4 See also --------------- 3.17 trunk/Identity/Themes/Models/Default ========================================= 3.17.1 Goals ------------ This location stores CentOS default theme model. The CentOS default theme model is used in all visual manifestations of CentOS Project's corporate visual identity (e.g., distributions, web sites, promotion, etc.). 3.17.2 Description ------------------ 3.17.3 Usage ------------ Changing CentOS default theme is not very convenient because that affects the "recognition" of CentOS Project. Nevertheless, we are interested on seeing your art work propositions. Specially if your art work is an improvement to the base idea behind CentOS default theme (*Modern*, squares and circles flowing up.). If you are not happy with CentOS default theme, you can look inside CentOS alternative themes and download the one you are interested in. If you are not happy with any of the CentOS alternative themes available, then go and design your own CentOS alternative theme as described in *Note Theme Motifs: trunk Identity Themes Motifs. 3.17.4 See also --------------- 3.18 trunk/Identity/Themes/Models/Default/Distro ================================================ 3.18.1 Goals ------------ * ... 3.18.2 Description ------------------ It applies to all major releases of CentOS distribution. 3.18.2.1 One theme for all major releases ......................................... Sometimes, specific visual manifestations are formed by common components which have internal differences. That is the case of CentOS distribution visual manifestation. Since a visual style point of view, the CentOS distributions share common artwork components like Anaconda --to cover the CentOS distribution installation--, BootUp --to cover the CentOS distribution start up--, and Backgrounds --to cover the CentOS distribution desktop--. Now, since a technical point of view, those common artwork components are made of software improved constantly. So, we need to find a way to keep one unique name and one unique visual style in artwork components that have internal difference and also remark internal difference as well. *Important* Remarking the CentOS release schema inside each major release of CentOS distribution --or similar visual manifestation-- takes _high attention_ inside The CentOS Project corporate visual identity. It should be very clear for people which major release of CentOS distribution they are using. In order to remark the CentOS release schema, the CentOS Artwork SIG uses a release-specific brand design named "The CentOS Release Brand". The CentOS release brand is compossed by the CentOS logotype _and_ the CentOS major release number (as specified in CentOS release schema definition). In this solution, the CentOS release brand is set inside all release-specific artworks (e.g., distribution, installation media, etc.) in remarkable way. The CentOS release brand is the design component that lets us remark the CentOS release schema inside the monolithic corporate visual identity structure we propose to use. 3.18.2.2 One theme for each major release ......................................... Other way we've been using to remark CentOS release schema is applying one unique theme for _each_ major release of CentOS distribution. That is, if we have 4 major releases of CentOS distribution, we need to provide 4 different themes to cover each CentOS distribution available. Inside CentOS Artwork Repository, you can create many themes and that is very convenient. But using one unique theme for _each_ major release of CentOS distribution would bring visual isolation among distributions, websites and promotion visual manifestations. If the CentOS project would maintain just one CentOS distribution (and many experienced graphic designers ready to create beautiful artworks) this model would be nice. Indeed, this model looks quite similar to that one used by Fedora project, doesn't it. But no, the CentOS project maintains near to 4 major releases of CentOS distribution in parallel, and that fact makes a huge difference since the corporate visual identity point of view. If we use one unique theme for _each_ major release of CentOS distribution, which one of those themes, does we use to cover other CentOS visual manifestations, like websites and promotion stuff? In whatever case you choose some release-specific distribution user will be visually isolated from other CentOS visual manifestations like websites and promotion stuff, even if the CentOS brand is present in all visual manifestations. In such a case, probably, users will end up asking themselves, why my CentOS distribution has this design and the CentOS website another one? Isn't them on the same project? With luck the CentOS brand will exonerate user form visual isolation. 3.18.3 Usage ------------ 3.18.4 See also --------------- 3.19 trunk/Identity/Themes/Models/Default/Distro/Anaconda ========================================================= 3.19.1 Goals ------------ * ... 3.19.2 Description ------------------ 3.19.3 Usage ------------ 3.19.4 See also --------------- 3.20 trunk/Identity/Themes/Models/Default/Promo =============================================== 3.20.1 Goals ------------ * ... 3.20.2 Description ------------------ It applies to all tangible and non tangible items CentOS uses to promote its existence. Clothes, posters, installation media, stationery, release countdown images, banners, stickers, are all examples of promotion designs. * ... 3.20.3 Usage ------------ * ... 3.20.4 See also --------------- 3.21 trunk/Identity/Themes/Models/Default/Web ============================================= 3.21.1 Goals ------------ * ... 3.21.2 Description ------------------ It applies to all web applications CentOS uses to handle its needs (Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving HTML standards should be consider here. * ... 3.21.3 Usage ------------ * ... 3.21.4 See also --------------- 3.22 trunk/Identity/Themes/Motifs ================================= 3.22.1 Goals ------------ The `trunk/Identity/Themes/Motifs' directory exists to: * Organize CentOS themes' artistic motifs. 3.22.2 Description ------------------ The artistic motif of theme is a graphic design component that provides theme's visual style, it is used as pattern to connect all visual manifestations inside one unique theme. Artistic motifs are based on conceptual ideas. Conceptual ideas bring the motivation, they are fuel for the engines of human imagination. Good conceptual ideas may produce good motivation to produce almost anything, and art works don't escape from it. `TreeFlower' CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence. `Modern' Modern, squares and circles flowing up. If you have new conceptual ideas for CentOS, then you can say that you want to create a new artistic motif for CentOS. To create a new artistic motif you need to create a directory under `Identity/Themes/Motifs/' using a name coherent with your conceptual idea. That name will be your artistic motif's name. If possible, when creating new conceptual ideas for CentOS, think about what CentOS means for you, what does it makes you feel, take your time, think deep, and share; you can improve the idea as time goes on. Once you have defined a name for your theme, you need to create the motif structure of your theme. The motif structure is the basic direcotry structure you'll use to work your ideas. Here is where you organize your graphic design projects. To add a new motif structure to CentOS Artwork Repository, you need to use the `centos-art' command line in the `Identity/Themes/Motifs/' directory as described below: centos-art add --motif=ThemeName The previous command will create the motif's basic structure for you. The basic structure produced by `centos-art' command is illustrated in the following figure: trunk/Identity/Themes/Motifs/$ThemeName/ |-- Backgrounds | |-- Img | `-- Tpl |-- Info | |-- Img | `-- Tpl |-- Palettes `-- Screenshots 3.22.3 Usage ------------ When designing artistic motifs for CentOS, consider the following recommendations: * Give a unique (case-sensitive) name to your Motif. This name is used as value wherever theme variable ($THEME) or translation marker (=THEME=) is. Optionally, you can add a description about inspiration and concepts behind your work. * Use the location `trunk/Identity/Themes/Motifs/$THEME/' to store your work. If it doesn't exist create it. Note that this require you to have previous commit access in CentOS Artwork Repository. * The CentOS Project is using the blue color (#204c8d) as base for its corporate visual identity. Use the CentOS Project's base corporate color as much as possible in your artistic motif designs. * Try to make your design fit one of the theme models. * Feel free to make your art enterprise-level and beautiful. * Add the following information on your art work (both in a visible design area, and inside Inkscape's document metadata section wherever it be possible): * The name (or logo) of your artistic motif. * The copyright sentence: Copyright (C) YEAR YOURNAME * The license under which the work is released. All CentOS Art works are released under Creative Common Share-Alike License 3.0 (http://creativecommons.org/licenses/by-sa/3.0/) (`http://creativecommons.org/licenses/by-sa/3.0/'). 3.22.4 See also --------------- 3.23 trunk/Identity/Themes/Motifs/Flame ======================================= The _Flame_ artistic motif was completly built using Gimp 2.2 in CentOS 5.5. In this section we describe the steps we followed through its construction. This information may be useful for anyone interested in reproducing the _Flame_ artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity (*note trunk Identity::). 3.23.1 Step 1: Set image size ----------------------------- Create an empty image and fill the Background layer with black (`000000') color. Image dimensions depends on the final destination you plan to use the image for. For the sake of our construction example we used an image of 640x480 pixels and 300 pixels per inch (ppi). 3.23.2 Step 2: Add patterns --------------------------- Create a new layer named `Paper', place it over `Background' layer and fill it with `Paper (100x100)' pattern. Add a mask to `Paper' layer using radial gradient and blur it. You may need to repeat this step more than once in order to achieve a confortable black radial degradation on the right side of your design. In our image dimension, the central point of radial degradation is at 430x296 approximately. Once you've done with black radial degradation, reduce the `Paper' layer opacity to 20%. Duplicate `Paper' layer and rename it `Stripes' --duplicating the layer helps us to be sure the layer masks will be equal in both `Paper' and `Stripes' layers--. Remove paper pattern from `Stripes' layer. Fill `Stripes' layer with `Stripes (48x48)' pattern and reduce the `Stripes' layer opacity to 15%: 3.23.3 Step 3: Add flame motif ------------------------------ Create a new layer named `Flame'. Set the foreground to white color (`ffffff'). Use the Gimp's flame filter (`Filters > Render > Nature > Flame...') to build the flame motif on `Flame' layer. The flame filter can produce stunning, randomly generated fractal patterns. This feature of Gimp give us a great oportunity to grant the production of new artistic motifs very quickly because of its "randomly generated" nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the `centos-art.sh' script (*note trunk Scripts Bash::) inside the CentOS Artwork Repository. To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we could produce a new visual style, every two years, based on a new "randomly generated" flame pattern, and publish the whole corporate visual identity (i.e., distribution stuff, promotion stuff, websites stuff, etc.) with the new major release of CentOS distribution all together at once. Producing a new visual style is not one day's task. Once we have the artistic motif defined, we need to propagate it through all visual manifestations of The CentOS Project corporate visual identity. When we say that we could produce one new visual style every two years we really mean: to work two years long in order to propagate a new visual style to all visual manifestations of The CentOS Project corporate visual identity. Obviously, in order to propagate one visual style to all different visual manifestations of The CentOS Project corporate visual identity, we need first to know which the visual manifestations are. To define which visual manifestations are inside The CentOS Project corporate visual identity, is one of the goals the CentOS Artwork Repository and this documentation manual are both aimed to satisfy. Once we define which the visual manifestation are, it is possible to define how to produce them, and this way, organize the automation process. Such automation process is one of the goals of `centos-art.sh' script. With the combination of both CentOS Artwork Repository and `centos-art.sh' scripts we define work lines where translators, programmers, and graphic designers work together to distribute and reduce the amount of time employed to produce The CentOS Project monolithic corporate identity. From a monolithic corporate visual identity point of view, notice that we are producing a new visual style for the same theme (i.e., _Flame_). It would be another flame design but still a flame design. This idea is very important to be aware of, because we are somehow "refreshing" the theme, not changing it at all. This way, as we are "refreshing" the theme, we still keep oursleves inside the monolithic conception we are trying to be attached to (i.e., one unique name, and one unique visual style for all visual manifestations). Producing artistic motifs is a creative process that may consume long time, specially for people without experienced knowlegde on graphic design land. Using "randomly generated" conception to produce artistic motifs could be, practically, a way for anyone to follow in order to produce maintainable artistic motifs in few steps. Due to the "randomly generated" nature of Flame filter, you may find that the same pattern is not always used each time you use the Flame filter interface. Using the same pattern design for each visual manifestation is essential in order to maintain the visual connection among all visual manifestations inside the same theme. Occasionally, we may introduce pattern variations in opacity, size, or even position but never change the pattern design itself, nor the color information used by images considered part of the same theme. *Important* When we design background images, which are considered part of the same theme, it is essential to use the same design pattern always. This is what makes theme images to be visually connected among themeselves, and so, the reason we use to define the word "theme" as: a set of images visually connected among themeselves. In order to recreate the same flame pattern every time we may need to, the Flame filter interface provides the `Save' and `Open' options. The `Save' option brings up a file save dialog that allows you to save the current Flame settings for the plug-in, so that you can recreate them later. The `Open' option brings up a file selector that allows you to open a previously saved Flame settings file. The Flame settings we used in our example are saved in the file: trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def Ok. Now that we have created the flame motif, and also divagated a bit about it, lets continue with the construction steps. Duplicate `Flame' layer and rename it `Flame Blur'. Place `Flame Blur' below `Flame' layer. Add gussian blur filter (`Filters > Blur > Gussian Blur...'). Horizontal:10.0 Vertical:10.0 Duplicate `Flame' layer and rename it `Flame Softglow'. Place `Flame Softglow' above `Flame' layer. Add Softglow filter (`Filters > Artisitc > Softglow...'). Glow radius: 10.00 Brightness: 0.75 Sharpness: 0.85 Reduce flame layers opacity using the same value. The value used to reduce flame layers opacity may vary from one image to another, specifically, on the place the image will be finally placed on. For example, images used as desktop background have the flame layers opacity reduced to 50% in order to reduce brightness. Otherwise, the background image used in anaconda progress slides has flame layers opacity reduced to 20% in order to reduce brightness even more so text could look clean and readable over it. 3.23.4 Step 4: Add foreground color ----------------------------------- Create a new layer named `Color', place it on top of all visible layers and fill it with plain color (`4c005a'). Reduce `Color' layer opacity to 10%. You can use the `Color' layer to control the final color information you want to produce the image for. When setting color information, remember that the same artistic motif needs to be reproduced in 14 and 16 colors for Grub and Syslinux visual manifestations respectively. Using many different colors in the artistic motif may reduce the possibility of your design to fix in all different situations. Likewise, using more colors in one design, and less colors in another design will reduce the connectivity among your designs, since color information is relevant to visual identity. It is up to you to find out justice and compromise among all possible variables you may face, when you propagate your artistic motif visual style to different visual manifestations of CentOS Project corporate visual identity. 3.23.5 See also --------------- 3.24 trunk/Identity/Themes/Motifs/Modern ======================================== 3.24.1 Presentation ------------------- 3.24.2 Construction ------------------- 3.24.3 Usage ------------ * ... 3.24.4 See also --------------- 3.25 trunk/Identity/Themes/Motifs/Modern/Backgrounds ==================================================== 3.25.1 Goals ------------ * Organize background images for Modern theme. 3.25.2 Description ------------------ Inside motif's `Backgrounds/' directory you can create vectorial designs using Inkscape and background images using Gimp. Later, you can export background images as `.png' and load them in your vectorial design project using Inkscape's import feautre. You may need to repeat this technic for different screen resoluions. In that case you need to create one file for each screen resolution and do the appropriate linking inside .svg to .png files. For example if you need to produce background images in 800x600 you need to create the following file: xcf/800x600.xcf to produce the background image: img/800x600-bg.png which is loaded in: svg/800x600.svg to produce the final background image: img/800x600.png The `img/800x600.png' background image is produced automatically by means of rendering scripts. In other cases, like Anaconda's, it is possible that you need to make some variations to one background image that don't want to appear on regular background images of the same resolution. In this case you need to create a new and specific background image for that art component. For example, if you need to produce the background image used by Anconda (800x600) art works you create the file: xcf/800x600-anaconda.xcf to produce the background image: img/800x600-anaconda-bg.png which is loaded in: svg/800x600-anaconda.svg to produce the file: img/800x600-anaconda.png The 800x600-anaconda.png file is used by all Anaconda art works sharing a common 800x600 screen resolution (e.g., Header, Progress, Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors and 640x480 pixels so you need to create a 640x480 background image for it, and take the color limitation into account when designing it. Background images without artistic motif are generally used as based to build the Background images that do contain the theme's artistic motif. Background images are linked (using Inkscape's import feature) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas. In this structure you design background images for different screen resolutions based on theme's artistic motif. You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea. Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.). Inside each motif directories represent just one unique artistic motif. The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes. Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif. Inside CentOS Artwork Repository, theme visual styles (Motifs) and theme visual structures (Models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the `centos-art' command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under the motif's name directory using the model directory structure as reference. The artistic motif base structure is used by `centos-art' to produce images automatically. This section describes each directory of CentOS artistic motif base structure. 3.25.3 Usage ------------ The motif's `Backgrounds/' directory is probably the motif's core component. Inside motif's `Backgrounds/' directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The motif's `Backgrounds/' directory can contain subdirectories to help you organize the design process. 3.25.4 See also --------------- 3.26 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img ======================================================== 3.26.1 Goals ------------ * ... 3.26.2 Description ------------------ 3.26.3 Usage ------------ In this directory is where you store all background images (e.g., .png, .jpg, .xpm, etc.). This directory is required by `centos-art' command line interface. 3.26.4 See also --------------- 3.27 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl ======================================================== 3.27.1 Goals ------------ * ... 3.27.2 Description ------------------ 3.27.3 Usage ------------ In this directory is where you store all the scalable vector graphics (e.g., .svg) files. This directory is required by `centos-art' command line interface. 3.27.4 See also --------------- 3.28 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf ======================================================== 3.28.1 Goals ------------ * ... 3.28.2 Description ------------------ * ... 3.28.3 Usage ------------ In this directory is where you store Gimp's project files (e.g, .xcf). This directory is not required by `centos-art' command line interface. If you can create a beautiful background images using scalable vector graphics only, then there is no need to use the `Xcf/' directory to store Gimp's background projects. Of course, you can merge Gimp's power with Inkscape's power to produce images based on them. In this last case you need the `Xcf/' directory. 3.28.4 See also --------------- 3.29 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress ================================================================= 3.29.1 Goals ------------ * ... 3.29.2 Description ------------------ 3.29.3 Usage ------------ To render Anaconda progress slide images using the Modern's artistic motif design, the Default theme model, and available translation files (*note trunk Translations Identity Themes Distro Anaconda Progress::); use the following commands: cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/ centos-art render --identity The above command will create the following structure: trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress |-- 3 | |-- en | | |-- 01-welcome.png | | |-- 02-donate.png | | `-- 03-yum.png | `-- es | |-- 01-welcome.png | |-- 02-donate.png | `-- 03-yum.png |-- 4 | |-- en | | |-- 01-welcome.png | | |-- 02-donate.png | | `-- 03-yum.png | `-- es | |-- 01-welcome.png | |-- 02-donate.png | `-- 03-yum.png `-- 5 |-- en | |-- 01-welcome.png | |-- 02-donate.png | `-- 03-yum.png `-- es |-- 01-welcome.png |-- 02-donate.png `-- 03-yum.png 3.29.4 See also --------------- 3.30 trunk/Identity/Themes/Motifs/Modern/Palettes ================================================= 3.30.1 Goals ------------ * Organize palette files for Modern theme. 3.30.2 Description ------------------ 3.30.3 Usage ------------ Here is where graphic designers define theme palettes for color-limited art works. Theme palettes contain the color information that rendering functions need, in order to produce images with color limitations. Theme palettes contain theme's unique color information. 3.30.4 See also --------------- 3.31 trunk/Identity/Themes/Motifs/TreeFlower ============================================ 3.31.1 Goals ------------ * ... 3.31.2 Description ------------------ 3.31.3 Usage ------------ 3.31.4 See also --------------- 3.32 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds ======================================================== 3.32.1 Goals ------------ This section exists to orgnize TreeFlower's backgrounds. 3.32.2 Description ------------------ 3.32.2.1 Desktop background ........................... Once you have defined the vectorial artistic motif design, use the `centos-art.sh' script (as described in usage section below) to produce the png version of it. With the png version of your vectorial design do the following: Open the png version with GIMP. Save the png version as gimp's project inside `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf' directory, using the same name of your vectorial design but with the `.xcf' extension. Now use GIMP to improve your design. Here you may add one layer for pattern, another for colors, and so on until you find yourself confortable with your artwork. For example, the following layer distribution (from bottom to top) was used to build revision 285 of file `1360x768.xcf' using TreeFlower's artistic motif at revision 241. *Layer 1: Background* The first thing we did with GIMP was to create a layer named `Background' to store the artistic motif (File > Open as layer). This layer is the lowest layer in the image. Later, we started to create layers one upon another to change the artistic motif visual style. *Layer 2: Shadow#1* This layer is above `Background' and contains a linear gradient from left (000000) to right (transparent) covering the whole image. This layer masks the artistic motif to avoid the effect of linear gradient. This layer is 100% of opacity. *Layer 3: Shadow#2* This layer is above `Shadow#1' and contains a linear gradient from left (000000) to right (transparent) covering just the 70% of the whole image aproximatly. This layer doesn't mask the artistic motif which make the left part of it fall into the dark of linear gradient. This layer is 100% of opacity. *Layer 4: Pattern (Paper)* This layer is above `Shadow#2' an contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif so the pattern is applied over the whole image. This layer is set to 15% of opacity. *Layer 5: Pattern (Stripes)* This layer is above `Pattern (Paper)' and contains the stripes used over the artistic motif. This layer do masks the artistic motif so the stripes are only applied to it. This layer is set to 10% of opacity. *Layer 6: Shadow#3* This layer is above `Pattern (Stripes)' and contains a linear gradient from right (6600ff) to left (transparent). This layer masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 15% of opacity. *Layer 7: Shadow#4* This layer is above `Shadow#3' and contains a linear gradient from left (000000) to right (transparent). This layer do masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 10% of opacity. *Layer 8: Color#1* This layer is above `Shadow#4' and is filled with orange (ffae00) color over the whole image. This layer is set to 10% of opacity. *Layer 9: Color#2* This layer is above `Color#1' and is filled with blue (010a88) color over the whole image. This layer is set to 10% of opacity. *Note* There is no definite combination. To get the appropriate visual design is a matter of constant testing and personal taste. Finally, use the GIMP's `Save as copy ...' option to export the final design. To export the final design use the same name of your vectorial design plus `-final.png' extension. You can repeat these steps to create images for other screen resolutions. 3.32.2.2 Anaconda Prompt (syslinux) background .............................................. When building syslinux backgrounds it is needed to take into account that the final image is reduced to 16 colors. In desktop background there is no color limitation but syslinux does have. The goal of this section is achieving a final syslinux background as close as possible to desktop backgrounds using 16 colors only. Another point to consider is the forground and background definition used by syslinux. The syslinux documentation says that the color set in position 0 is the background and color set in position 7 is the forground. The final palette of color used by our background will match that specification. For great contrast we'll use black as background and white as forground. At this poing we have black (000000) and white (ffffff) colors in our syslinux palette, which left us with 14 colors to play with. Let's begin with `Xcf/640x300.xcf' layer distribution from bottom to top: *Layer 1: Background* This layer is the lowest layer in the image composition and contains the artistic motif image rendered for the same resolution (i.e., `Img/Png/640x300.png'). This layer is set to 100% of opacity. *Layer 2: Pattern (Paper)* This layer is placed above `Background' layer and contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif. This layer is set to 30% of opacity. *Layer 3: Pattern (Stripes)* This layer is placed above `Pattern (Paper)' layer and contains the stripes pattern shipped with GIMP 2.2. This layer does mask the artistic motif in order to apply the stripes over it only. The background is not affected by the stripes pattern just the artistic motif. This layer is set to 20% of opacity. *Layer 4: Shadow#1* This layer is placed above `Pattern (Stripes)' layer and fills the entire layer area with violet (6600ff) color. This layer do mask the artistic motif in order to applied the violet color to the background area outside the artistic motif only. This layer is set to 15% of opacity. *Layer 5: Color#1* This layer is above `Shadow#1' and is filled with orange (ffae00) color to cover the whole image. This layer is set to 10% of opacity. *Layer 6: Color#2* This layer is above `Color#1' and is filled with blue (010a88) color to cover the whole image. This layer is set to 10% of opacity. *Layer 7: Shadow#2* This layer is above `Color#1' and contains a linear gradient from left (000000) to right (transparent) covering 70% of the image approximately. At this point we have the composition and should look like the desktop backgrounds. Compared with desktop backgrounds there are some differences in opacity. This is because in our testings the final color information found with this composition produces an acceptable 16 color image. Of course this is something we haven't seen yet. To define the color information of our current coposition, save the syslinux GIMP's background composition we've done using GIMP's `File > Save as Copy ...' option in the following location: trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png Now, create the final png version of syslinux backgrounds using the following command: centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt This command will create syslinux-splash final images for all major releases of CentOS distribution the repository has been configured to. The important files here are `syslinux-splash.png', other files may contain the wrong information because we haven't defined yet the correct color information to use. Open one `syslinux-splash.png' file with GIMP and use the `Image > Mode > Indexed' to reduce image colors up to 16 colors, using GIMP's `Generate optimum palette' feature. If the image looks aceptable after reducing colors, use GIMP's `Palettes' menu (Ctrl+P) to import a new palette from file and name it `CentOS-TreeFlower-Syslinux'. Once you've saved the palette, the color information is stored at: ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl You need to edit `CentOS-TreeFlower-Syslinux.gpl' file in order to set the appropriate order of colors. Remember black (000000) in position 0, and white (ffffff) in position 7. Other positions are irrelevant. When editing this file you may find that color reduction did not set black and white colors to their respective values exactly. Change that manually. For example, consider the following palette: GIMP Palette Name: CentOS-TreeFlower-Syslinux Columns: 16 # 0 0 0 Background (black) 23 20 35 Untitled 34 25 48 Untitled 37 35 60 Untitled 47 36 68 Untitled 37 54 86 Untitled 60 48 90 Untitled 255 255 255 Foreground (white) 66 54 99 Untitled 74 61 98 Untitled 49 78 126 Untitled 43 87 151 Untitled 92 89 95 Untitled 54 104 183 Untitled 158 153 156 Untitled 201 196 195 Untitled Update the `Palettes' menu to get the new color positions from the file you just edited and open the palette with double click. Update the `syslinux.gpl' file copying the following file: ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl to trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl With the `CentOS-TreeFlower-Syslinux' palette opened in the `Palette Editor', open (Ctrl+O) the following file: trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm and replace its color information with that one in `CentOS-TreeFlower-Syslinux' palette. When you are replacing color information inside `syslilnux.ppm', remember to keep the order of colors just as they are in the `CentOS-TreeFlower-Palette' palette. The `syslinux.ppm' file is 16 pixels width and 1 pixel height, so you probably need to zoom it a bit to set the color information in their place when using the pen tool with the brush `Circle (01) (1 x 1)'. Once you've updated the `syslinux.ppm' file, it is time to update the following file: trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex The `syslinux.hex' file contains the color information in hexadecimal notation. The color information in hexadecimal notation is required by `ppmtolss16' command. The `ppmtolss16' command produces the final LSS16 image format that is used by syslinux program inside CentOS distribution. The color information inside `syslinux.hex' must match the one in `syslinux.ppm' and `syslinux.gpl'. For example, based on `CentOS-TreeFlower-Syslinux' palette of colors above, consider the following `syslinux.hex' file: #000000=0 #171423=1 #221930=2 #25233c=3 #2f2444=4 #253656=5 #3c305a=6 #ffffff=7 #423663=8 #4a3d62=9 #314e7e=10 #2b5797=11 #5c595f=12 #3668b7=13 #9e999c=14 #c9c4c3=15 3.32.2.3 Grub background ........................ 3.32.3 Usage ------------ * ... 3.32.4 See also --------------- 3.33 trunk/Identity/Widgets =========================== 3.33.1 Goals ------------ * ... 3.33.2 Description ------------------ 3.33.3 Usage ------------ 3.33.4 See also --------------- 3.34 trunk/Manuals ================== 3.34.1 Goals ------------ * ... 3.34.2 Description ------------------ * ... 3.34.3 Usage ------------ `centos-art help --read='path/to/dir'' Use this command to read directory documentation specified in `path/to/dir'. `centos-art help --read='path/to/dir' --filter='filename'' Use this command to read file documentation as specified by `path/to/dir/filename' combination. `centos-art help --edit='path/to/dir'' Use this command to edit directory documentation as specified in `path/to/dir'. `centos-art help --edit='path/to/dir' --filter='filename'' Use this command to edit file documentation as specified in `path/to/dir/filename' combination. `centos-art help --update='path/to/dir'' Use this command to update documentation output files. `centos-art help --remove='path/to/dir'' Use this command to remove directory documentation as specified in `path/to/dir'. *Caution* When directory documentation is removed all documentation under it is also removed. *Tip* To recover from directory documentation lost, try the following command (before commit local changes up to central repository): svn revert path/to/dir --recursive `centos-art help --remove='path/to/dir' --filter='filename'' Use this command to remove file documentation as specified in `path/to/dir/filename' combination. 3.34.4 See also --------------- 3.35 trunk/Scripts ================== 3.35.1 Goals ------------ The `trunk/Scripts' directory exists to: * Organize the "trunk" development line of automation scripts by programming language. 3.35.2 Description ------------------ * ... 3.35.3 Usage ------------ * ... 3.35.4 See also --------------- 3.36 trunk/Scripts/Bash ======================= 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. The `centos-art.sh' script is splited in several configuration and function files which are loaded when the `centos-art.sh' script is executed. This section describes the order in which `centos-art.sh' loads its configuration and function files. 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's location. If your system was prepared to use CentOS Artwork Repository correctly (*note 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/initFunctions.sh' script to initialize global variables (e.g., `gettext''s 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 (*note 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' represents the action you want to do (e.g., `verify', `render', `locale', `help', etc.). The remaining arguments are modifiers to `arg1'. The `--arg2' definition is required. The `--arg3' is optional. For example, if you want to render all anaconda progress slides, for all major releases of CentOS distribution, for all languages availabe using TreeFlower motif as background, you use the following command: centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Progress Now, if you only want to render anaconda progress `01-welcome.png' slide, for CentOS distribution major release 5, in English language, you need to add the third argument as follows: centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Progress --filter=5/en/01-welcome Once command-line arguments have been retrived, the `centos-art.sh' script loads specific functions using the `cli_getActions.sh' function script. For example, if you run the command `centos-art render --entry', the `centos-art.sh' script will look for `trunk/Scripts/Bash/Functions/Render' directory and will load the `render' function from `render.sh' function script; this, in order to achive the rendering task as it defines. +------------------------------------------------------------------+ | [centos@host]$ centos-art action 'path/to/dir' --option='value' | +------------------------------------------------------------------+ | ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh | +---v-----------------------------------------v--------------------+ | centos-art.sh | +---v---------------------------------v---+ . | initFunctions.sh | . . +---------------------------------+ . . | cli $@ | . . +---v-------------------------v---+ . . . | cli_getActions $@ | . . . . +---v-----------------v---+ . . . . . | function call 1 | . . . . . . | function call 2 | . . . . . . | function call n | . . . . . . +-----------------+ . . . . . ........................... . . . ................................... . ........................................... Figure 3.1: The `centos-art.sh' initialization environment. 3.36.3 Usage ------------ The `centos-art.sh' script usage information is described inside each specific function documentation (*note trunk Scripts Bash Functions::). 3.36.4 See also --------------- 3.37 trunk/Scripts/Bash/Functions ================================= 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 (*note Toolbox introduction: (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. *Tip* Join CentOS developers mailing list 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--, subversion's `$Id$' keyword which 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 `greet' functionality command-line interface 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. 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''s 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''s 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 (*note 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 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 (*note trunk Scripts Bash Functions Locale::) of `centos-art.sh' script, just as the following command illustrates: centos-art locale --edit *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. 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 a message simply, but more interesting things can be achieved inside action specific function definitions. For example, if you pass a directory path as second argument option value, 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: 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 repository entry over which its associated action will be performed in. Repository entries can be directories, files, or URLs refering the repository structure. When action value is not specified as repository entry, the `centos-art.sh' script evaluates the current directory it was executed from. If such directory is under the repository structure (i.e., `/home/centos/artwork/'), the `centos-art.sh' script uses that directory as value to ACTIONVAL variable. Otherwise, if outside the repository structure, the `centos-art.sh' script prints the message `The path provided can't be processed.' and, after it, immediatly ends script execution. Default action value is 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 ACTIONVAL passed to `centos-art.sh' script is `path/to/dir'. -- 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 stores them in the ARGUMENT 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 ......................... Functions defined under `trunk/Scripts/Bash/Functions/' directory are considered global. Global function can be used inside action specific functionalities and 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. `cli_checkActionArguments' is called from `cli_getActionArguments' function. Probably, there is not other use for `cli_checkActionArguments' but to be called from `cli_getActionArguments' function. -- 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. 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.2: 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 Redefines 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 you use `cli_doParseArgumentsReDef' inside some function, the positional parameters variable ($@) is automatically reset to that function positional parameters, not the command-line positional parameters. If you need to redefine specific 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 on. In order to use positional paramenters passed as command-line, we use the ARGUMENTS global variable which is defined at `cli' function, and occasionally, farther redefined (by `cli_doParseArgumentsReDef') as far as it may be convenient. -- Function: cli_getActionArguments [$@] Initialize function name (FUNCNAM), action name (ACTIONNAM), and action value (ACTIONVAL) global variables, using positional parameters passed in $@ variable. The `cli_getActionsArguments' function is called from `cli.sh' function script. The `cli_getActionsArguments' function is call 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, `cli-getActionsArguments' uses regular expression to retrive action variables from first and second argument. The first argument defines the value use as function name (FUNCNAM), and the second argument defines the value 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 rener 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 after the equal sign (`='), and before the first space character, are considered as the action value (ACTIONVAL). In order to provide action values with space characters you need to enclose it with quotes like in `--option='This is long value''. 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_getActionsArguments' shifts the positional arguments to remove the first two arguments passed (i.e., those one used to retrive action related variables) and redefine the arguments (ARGUMENTS) global variable with the new positional parameters information. -- Function: cli_getActions 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. Functionalities supported by `centos-art.sh' script are initialized and executed using the `centos-art.sh' script functionality name convenction as reference. In order to 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 independent files 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... } In order to keep visual consistency among function scripts, use the following function script design model as template to create 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... } Once `centos-art.sh' script determines which functionality directory to use, function scripts are executed and function definitinos exported. This way, function definitions are made available inside `centos-art.sh' script execution evironment 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 informative message. -- 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 -- 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* `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, each time we change name convenctions in the repository (*note trunk Scripts Bash Functions Path::, for more information). -- Function: cli_getRepoStatus -- Function: cli_getTemporalFile NAME Output absolute path to temporal file NAME. `cli_getTemporalFile' 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 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 `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 `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. *Note 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. *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.37.4 See also --------------- 3.38 trunk/Scripts/Bash/Functions/Html ====================================== 3.38.1 Goals ------------ * ... 3.38.2 Description ------------------ * ... 3.38.3 Usage ------------ * ... 3.38.4 See also --------------- 3.39 trunk/Scripts/Bash/Functions/Locale ======================================== 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 finish PO file's edition and quit text editor, the `centos-art' command creates the related machine object in the location `$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo'. At this point, all translations you made in the PO file should be available to your language when runing `centos-art.sh' script. In order to make the `centos-art.sh' internationalization, the `centos-art.sh' script was modified as described in the `gettext' info documentation (`info gettext'). You can find such modifications in the following files: * `trunk/Scripts/Bash/initFunctions.sh' * `trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh' * `trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh' * ... 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 --------------- 3.40 trunk/Scripts/Bash/Functions/Manual ======================================== 3.40.1 Goals ------------ * ... 3.40.2 Description ------------------ * ... 3.40.3 Usage ------------ * ... 3.40.4 See also --------------- 3.41 trunk/Scripts/Bash/Functions/Path ====================================== 3.41.1 Goals ------------ This section exists to organize files related to `path' functiontionality of `centos-art.sh' script. The `path' functionality of `centos-art.sh' script 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/'. Figure 3.3: The CentOS Artwork Repository layout. The `trunk/' directory (*note 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 develop CentOS corporate visual identity. The `branches/' directory (*note 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 on CentOS corporate visual identity. The `tags/' directory (*note 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 you need to remember concentrating them in just one single place you can 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 design background images and propagate them to different visual manifestations using one theme's model as reference. Later, when the theme is considered "ready" for implementation (i.e. all visual manifestations have been already set), 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. Figure 3.4: Name convention for tags and branches creation. As proposition, it would be convenient not to freeze trunk development lines using tags or anything else. 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 provides a less changable area where only small fixes/corrections 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 you can 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 who build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. 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 where parallel directory removes the uncommon path information is when we use the `help' functionality. This time, `centos-art.sh' script uses parallel directory information (without uncommon directory levels) to build the documentation entry required by Texinfo to store documentation entries inside the repository. Figure 3.5: Parallel directories removing uncommon information. 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. Figure 3.6: Parallel directories adding uncommon information. When one parent directory changes, all their related parallel directories need to be changed too. This is required in order for parallel directories to match the new parent directory structure. In the other hand, parallel directories should never be modified by no reason but to satisfy their parent directory structure. Liberal change of parallel directories may suppress the conceptual idea they were initially created for. Figure 3.7: Wrong construction of parallel directories. 3.41.2.5 Syncronizing path information ...................................... Creating parallel directories is very useful to keep repository organized. But, what would happen to functionalities like `help' (*WARNING:* _The `trunk Scripts Bash Functions Help' documentation entry no longer exists._) 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? Well, at this point, functionalities like `help' may confuse themselves if path information is not updated. 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 `help' 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 remove what must be removed to match the new parent directory structure. There is no way for `help', 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 movement actions, like thoses achived by `rm' or `mv' commands, take 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. Syncronizing parallel directories with their respecitive parent directory implies moving files inside the repository, i.e. we need to, firstly, rebuild the path information for each parallel directory inside the repository, using the current path of its parent directory as reference, and later, use the new path information to move each old parallel directory from its old location to its new location based on an updated path information. 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 related files into version control system, and later, use commands from the version control system to move those files already versioned. 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 file corrections have been already made, the syncronization action takes care of updating path references inside related files. Updating path references inside related files is specially important for documentation files where documentation nodes are built using repository path information as reference. 3.41.2.6 What is the right location 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 location to store it? The CentOS Community (`http://wiki.centos.org/GettingHelp') is 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 looking the correct place to store new files, to bear in mind the corporate visual identity structure used inside the CentOS Artwork Repository (*note trunk Identity::) would be probaly the best advice we could offer to you, the rest is just matter of choosing appropriate names. To illustrate this desition process let's consider the `trunk/Identity/Themes/Motifs/TreeFlower/Distro/' directory as example. It is the main development line of CentOS distribution visual manifestation, using TreeFlower's artistic motif, inside themes 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 happens most of time, when you 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/Distro/' 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/Distro/' location are described in the following commands, respectively: centos-art help --read=turnk/ centos-art help --read=turnk/Identity/ centos-art help --read=turnk/Identity/Themes/ centos-art help --read=turnk/Identity/Themes/Motifs/ centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/ centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/Distro/ 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' Use this command to duplicate `SRC' in working copy, remembering history. In this command, `SRC' and `DST' can each be either a working copy (WC) path or URL: `WC -> WC' Copy and schedule for addition (with history). `WC -> URL' Immediately commit a copy of WC to URL. `URL -> WC' Check out URL into WC, schedule for addition. `URL -> URL' Complete server-side copy; used to branch and tag. This command is an interface for Subversion's `copy' command. Options related to Subversion's `copy' command can be passed from third argument on. For example to specify a log message use the `--message' option as follow: centos-art path --copy=URL/SRC --to=URL/DST --message 'Copy url/src to url/dst' For more information on Subversion's `copy' functionality, run the command: `svn help copy | less'. `centos-art path --move=SRC --to=DST' Move and/or rename something in working copy or repository. In this command, SRC and DST can both be working copy (WC) paths or URLs: `WC -> WC' Move and schedule for addition (with history). `URL -> URL' Complete server-side rename. This command is an interface for Subversion's `move' command. Options related to Subversion's `move' command can be passed from third argument on. For example to specify a log message use the `--message' option as follow: centos-art path --move=URL/SRC --to=URL/DST --message 'Move url/src to url/dst' For more information on Subversion's `move' functionality, run the command: `svn help move | less'. `centos-art path --delete='SRC'' Use this command to remove files and directories from version control. In this command, `SRC' can be a working copy (WC) path or URL. `WC' Each item specified by a PATH is scheduled for deletion upon the next commit. Files, and directories that have not been committed, are immediately removed from the working copy. PATHs that are, or contain, unversioned or modified items will not be removed unless the `--force' option is given. `URL' Each item specified by a URL is deleted from the repository via an immediate commit. This command is an interface for Subversion's `delete' command. Options related to Subversion's `delete' can be passed from third argument on. For example to specify a log message use the `--message' as follow: centos-art path --delete='URL' --message 'Delete url.' For more information on Subversion's `delete' functionality, run the command: `svn help delete | less'. `centos-art path --sync='SRC'' Use this command to syncronize path information inside working copy. This command is automatically used after moving or renaming parent directories. In this command, `SRC' is a working copy path inside `trunk/Identity/' location, considered the parent directory you want to syncronize path information for. 3.41.4 See also --------------- 3.42 trunk/Scripts/Bash/Functions/Render ======================================== 3.42.1 Goals ------------ * ... 3.42.2 Description ------------------ * ... 3.42.3 Usage ------------ * ... 3.42.4 See also --------------- 3.43 trunk/Scripts/Bash/Functions/Render/Config =============================================== 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 ............................................... 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. *Note* *Note 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.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. `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.44 trunk/Scripts/Bash/Functions/Shell ======================================= 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| } 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* 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 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| } 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* 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.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* 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.45 trunk/Scripts/Bash/Functions/Svg ===================================== 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 `' 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 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 (http://creativecommons.org/licenses/by-sa/3.0/). 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 ........................... As SVG files grow they may end up with unused definitions inside. For example, if you stop using a pattern or gradient, tags used to define them are considered unused definitions then. Inkscape 0.46 brings the `Vaccum Defs' feature to remove those unused definitions from SVG files. The `Vaccum Defs' feature is available both at graphical interface and command line interface. If you have one or two couple of files, removing unused SVG definitions using graphical interface may be enough to you. In contrast, if you have houndred of files to maintain it is not a fun task to use the gui interface to remove unused SVG definitions editing those files one by one. To remove unused SVG definitions from several SVG files, the `centos-art.sh' script uses Inkscape's 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* 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.46 trunk/Scripts/Bash/Functions/Verify ======================================== 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. 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. *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''s 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 .............................. 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. `TZ' Default time zone representation. Time representation inside repository server is set to Coordinated Universal Time (UTC). Time represetation inside repository working copies is set as their administrators personally define. When repository working copies time representation be defined, it would be a very good convention to follow if working copies administrators would set their systems clock to use UTC. Otherwise it would be difficult for working copies users to find out when changes were committed up to repository server exactly in time. *Tip* Coordinated Univeral Time (UTC) representation can be configured when you install CentOS distribution; or later, runing the `system-config-date' command at a shell prompt from your graphical interface. *Note* If you set your system clock to use UTC representation, you also need to set the `TZ' environment variable inside `~/.bash_profile' as follows: export TZ=UTC This is required in order for your terminal to display the correct time information of your zone, taking UTC representation as reference. `TEXTDOMAIN' Default domain used to retrieve translated messages. This value is set in `initFunctions.sh' and shouldn't be changed. `TEXTDOMAINDIR' Default directory used to retrieve translated messages. This value is set in `initFunctions.sh' and shouldn't be changed. `LANG' Default locale information. This value is set when you start your session and can be changed using the `locale' functionality of `centos-art.sh' script (*note trunk Scripts Bash Functions Locale::, for more information). 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.47 trunk/Scripts/Bash/Locale ============================== 3.47.1 Goals ------------ This section exists to organize translation messages and templates used by `centos-art.sh' script. 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 (*note trunk Scripts Bash Functions Locale::). 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. *Note trunk Scripts Bash Functions Locale::, for more information on how to use `centos-art.sh' "locale" functionality. 3.47.4 See also --------------- 3.48 trunk/Scripts/Perl ======================= 3.48.1 Goals ------------ * ... 3.48.2 Description ------------------ 3.48.3 Usage ------------ 3.48.4 See also --------------- 3.49 trunk/Scripts/Python ========================= 3.49.1 Goals ------------ * ... 3.49.2 Description ------------------ * ... 3.49.3 Usage ------------ * ... 3.49.4 See also --------------- 3.50 trunk/Translations ======================= 3.50.1 Goals ------------ The `trunk/Translations' directory exists to: * Organize translation files. * Organize translation templates used to produce translation files. 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 they need 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.(1) * There are near to four major releases of CentOS distribution to rebrand in parallel development.(2) * Each CentOS distribution in parallel development supports more than two hundreds locales.(3) In order to aliviate maintainance of artwork production for such environment, we divided artwork production in three production lines: 1. *Note trunk Identity Themes Models::, to define artworks characteristics (e.g., dimensions, position on the screen, etc.). 2. *Note 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's 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's 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's entry path remain in translation's entry path, and how variable values like theme names (e.g., Modern) are stript out from translation's 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. *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''s 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. *Note* The monolithic visual identity is implemented using theme models (*note trunk Identity Themes Models::) and artistic motifs (*note 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''s 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 *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. *Tip* More information about how to use `sed''s replacement commands and flags is available in `sed''s documentation manual. To read sed's 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's 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's implementation, the translation pre-rendering scripts are store in the `trunk/Scripts/Bash/Config' location; if you are using `centos-art' Python's implementation, then translation pre-rendering scripts are stored in the `trunk/Scripts/Python/Config' location, and so on for other implementations. Bash's 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's 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. *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's, `py' for Python's, `pl' for Perl's, 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 to 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. *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 (*note Translation Markers: trunk:Translations:TranslationMarkers.). 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. 3.50.4 See also --------------- ---------- Footnotes ---------- (1) This number is an approximate value and may change. It is mainly based on CentOS 5 rebranding experience. (2) This value was taken from CentOS release schema. (3) This value was taken from the `locale -a' command's output. 3.51 trunk/Translations/Identity ================================ 3.51.1 Goals ------------ * ... 3.51.2 Description ------------------ * ... 3.51.3 Usage ------------ * ... 3.51.4 See also --------------- 3.52 trunk/Translations/Identity/Brands ======================================= 3.52.1 Goals ------------ * Organize brands' translation files. 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: /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 design's 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: `#000000' Specify which color to use when rendering brand images. *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.52.3 Usage ------------ To render brands' translation files, use the following command: centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands 3.52.4 See also --------------- 3.53 trunk/Translations/Identity/Brands/Tpl =========================================== 3.53.1 Goals ------------ 3.53.2 Description ------------------ 3.53.3 Usage ------------ 3.53.4 See also --------------- 3.54 trunk/Translations/Identity/Fonts ====================================== 3.54.1 Goals ------------ This section exists to organize fonts translation files. 3.54.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* Do not create translation files for font-families not used somewhere inside CentOS visual identity. The font's identity entry (*note trunk Identity Fonts::) is used as reference when someone needs to know which font-families are allowed to use inside CentOS visual identity. 3.54.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.54.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.54.4 See also --------------- 3.55 trunk/Translations/Identity/Models ======================================= 3.55.1 Goals ------------ 3.55.2 Description ------------------ 3.55.3 Usage ------------ 3.55.4 See also --------------- 3.56 trunk/Translations/Identity/Release ======================================== 3.56.1 Goals ------------ 3.56.2 Description ------------------ 3.56.3 Usage ------------ 3.56.4 See also --------------- 3.57 trunk/Translations/Identity/Themes ======================================= 3.57.1 Goals ------------ 3.57.2 Description ------------------ 3.57.3 Usage ------------ 3.57.4 See also --------------- 3.58 trunk/Translations/Identity/Themes/Backgrounds =================================================== 3.58.1 Goals ------------ * ... 3.58.2 Description ------------------ * ... 3.58.3 Usage ------------ * ... 3.58.4 See also --------------- 3.59 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress ================================================================ 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. * *Note trunk Identity Themes Motifs Modern Distro Anaconda Progress::. 3.59.3 Usage ------------ Translation rendering is described in `trunk/Translations' documentation entry (*note trunk Translations::). 3.59.4 See also --------------- 3.60 trunk/Translations/Identity/Widgets ======================================== 3.60.1 Goals ------------ * ... 3.60.2 Description ------------------ * ... 3.60.3 Usage ------------ * ... 3.60.4 See also --------------- Index ***** branches: See 1. (line 390) Common translation files: See 3.50.2.5. (line 5557) How to render brands' translation files: See 3.52.3. (line 5861) How to render fonts' translation files: See 3.54.3. (line 5934) How to render translation files: See 3.50.3. (line 5727) Metadata maintainance: See 3.45.2. (line 4701) Specific translation files: See 3.50.2.6. (line 5582) tags: See 2. (line 393) Template translation files: See 3.50.2.4. (line 5387) Translation brands file names: See 3.52.2.1. (line 5818) Translation configuration scripts: See 3.50.2.8. (line 5616) Translation entries: See 3.50.2.1. (line 5203) Translation files: See 3.50.2.3. (line 5319) Translation markers: See 3.50.2.2. (line 5284) Translation paths: See 3.50.2.1. (line 5203) Translation pre-rendering configuration scripts:See 3.50.2.8. (line 5616) Translation rendering: See 3.50.2.7. (line 5605) Translation rendering default functionality: See 3.50.2.9. (line 5702) trunk: See 3. (line 396) trunk Identity: See 3.1. (line 399) trunk Identity Brands: See 3.2. (line 819) trunk Identity Fonts: See 3.3. (line 836) trunk Identity Icons: See 3.4. (line 913) trunk Identity Isolinux: See 3.5. (line 930) trunk Identity Models: See 3.6. (line 947) trunk Identity Models Css: See 3.7. (line 967) trunk Identity Models Html: See 3.8. (line 989) trunk Identity Models Img Promo Web: See 3.9. (line 1010) trunk Identity Models Tpl: See 3.10. (line 1031) trunk Identity Models Tpl Promo Web: See 3.11. (line 1052) trunk Identity Models Xcf: See 3.12. (line 1366) trunk Identity Release: See 3.13. (line 1387) trunk Identity Themes: See 3.14. (line 1404) trunk Identity Themes Models: See 3.15. (line 1429) trunk Identity Themes Models Alternative: See 3.16. (line 1462) trunk Identity Themes Models Default: See 3.17. (line 1489) trunk Identity Themes Models Default Distro: See 3.18. (line 1521) trunk Identity Themes Models Default Distro Anaconda:See 3.19. (line 1605) trunk Identity Themes Models Default Promo: See 3.20. (line 1622) trunk Identity Themes Models Default Web: See 3.21. (line 1648) trunk Identity Themes Motifs: See 3.22. (line 1673) trunk Identity Themes Motifs Flame: See 3.23. (line 1777) trunk Identity Themes Motifs Modern: See 3.24. (line 1963) trunk Identity Themes Motifs Modern Backgrounds:See 3.25. (line 1980) trunk Identity Themes Motifs Modern Backgrounds Img:See 3.26. (line 2102) trunk Identity Themes Motifs Modern Backgrounds Tpl:See 3.27. (line 2123) trunk Identity Themes Motifs Modern Backgrounds Xcf:See 3.28. (line 2144) trunk Identity Themes Motifs Modern Distro Anaconda Progress:See 3.29. (line 2171) trunk Identity Themes Motifs Modern Palettes: See 3.30. (line 2227) trunk Identity Themes Motifs TreeFlower: See 3.31. (line 2249) trunk Identity Themes Motifs TreeFlower Backgrounds:See 3.32. (line 2266) trunk Identity Widgets: See 3.33. (line 2562) trunk Manuals: See 3.34. (line 2579) trunk Scripts: See 3.35. (line 2633) trunk Scripts Bash: See 3.36. (line 2657) trunk Scripts Bash Functions: See 3.37. (line 2769) trunk Scripts Bash Functions Html: See 3.38. (line 3792) trunk Scripts Bash Functions Locale: See 3.39. (line 3813) trunk Scripts Bash Functions Manual: See 3.40. (line 3893) trunk Scripts Bash Functions Path: See 3.41. (line 3914) trunk Scripts Bash Functions Render: See 3.42. (line 4316) trunk Scripts Bash Functions Render Config: See 3.43. (line 4337) trunk Scripts Bash Functions Shell: See 3.44. (line 4515) trunk Scripts Bash Functions Svg: See 3.45. (line 4683) trunk Scripts Bash Functions Verify: See 3.46. (line 4871) trunk Scripts Bash Locale: See 3.47. (line 5087) trunk Scripts Perl: See 3.48. (line 5116) trunk Scripts Python: See 3.49. (line 5133) trunk Translations: See 3.50. (line 5154) trunk Translations Identity: See 3.51. (line 5756) trunk Translations Identity Brands: See 3.52. (line 5777) trunk Translations Identity Brands Tpl: See 3.53. (line 5872) trunk Translations Identity Fonts: See 3.54. (line 5887) trunk Translations Identity Models: See 3.55. (line 5950) trunk Translations Identity Release: See 3.56. (line 5965) trunk Translations Identity Themes: See 3.57. (line 5980) trunk Translations Identity Themes Backgrounds:See 3.58. (line 5995) trunk Translations Identity Themes Distro Anaconda Progress:See 3.59. (line 6016) trunk Translations Identity Widgets: See 3.60. (line 6109) Unused definitions: See 3.45.2.1. (line 4808) List of Figures ***************