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/Modern/Backgrounds
3.23.1 Goals
3.23.2 Description
3.23.3 Usage
3.23.4 See also
3.24 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
3.24.1 Goals
3.24.2 Description
3.24.3 Usage
3.24.4 See also
3.25 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
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/Xcf
3.26.1 Goals
3.26.2 Description
3.26.3 Usage
3.26.4 See also
3.27 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
3.27.1 Goals
3.27.2 Description
3.27.3 Usage
3.27.4 See also
3.28 trunk/Identity/Themes/Motifs/Modern/Palettes
3.28.1 Goals
3.28.2 Description
3.28.3 Usage
3.28.4 See also
3.29 trunk/Identity/Themes/Motifs/TreeFlower
3.29.1 Goals
3.29.2 Description
3.29.3 Usage
3.29.4 See also
3.30 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
3.30.1 Goals
3.30.2 Description
3.30.2.1 Desktop background
3.30.2.2 Anaconda Prompt (syslinux) background
3.30.2.3 Grub background
3.30.3 Usage
3.30.4 See also
3.31 trunk/Identity/Widgets
3.31.1 Goals
3.31.2 Description
3.31.3 Usage
3.31.4 See also
3.32 trunk/Manuals
3.32.1 Goals
3.32.2 Description
3.32.3 Usage
3.32.4 See also
3.33 trunk/Scripts
3.33.1 Goals
3.33.2 Description
3.33.3 Usage
3.33.4 See also
3.34 trunk/Scripts/Bash
3.34.1 Goals
3.34.2 Description
3.34.3 Usage
3.34.4 See also
3.35 trunk/Scripts/Bash/Functions
3.35.1 Goals
3.35.2 Description
3.35.3 Usage
3.35.3.1 Global variables
3.35.3.2 Global functions
3.35.3.3 Specific functions
3.35.4 See also
3.36 trunk/Scripts/Bash/Functions/Help
3.36.1 Goals
3.36.2 Description
3.36.3 Usage
3.36.4 See also
3.37 trunk/Scripts/Bash/Functions/Html
3.37.1 Goals
3.37.2 Description
3.37.3 Usage
3.37.4 See also
3.38 trunk/Scripts/Bash/Functions/Locale
3.38.1 Goals
3.38.2 Description
3.38.3 Usage
3.38.4 See also
3.39 trunk/Scripts/Bash/Functions/Path
3.39.1 Goals
3.39.2 Description
3.39.3 Usage
3.39.4 See also
3.40 trunk/Scripts/Bash/Functions/Render
3.40.1 Goals
3.40.2 Description
3.40.3 Usage
3.40.4 See also
3.41 trunk/Scripts/Bash/Functions/Render/Config
3.41.1 Goals
3.41.2 Description
3.41.2.1 The `render.conf.sh' identity model
3.41.2.2 The `render.conf.sh' translation model
3.41.2.3 The `render.conf.sh' rendering actions
3.41.3 Usage
3.41.4 See also
3.42 trunk/Scripts/Bash/Functions/Shell
3.42.1 Goals
3.42.2 Description
3.42.3 Usage
3.42.4 See also
3.43 trunk/Scripts/Bash/Functions/Svg
3.43.1 Goals
3.43.2 Description
3.43.3 Usage
3.43.4 See also
3.44 trunk/Scripts/Bash/Functions/Verify
3.44.1 Goals
3.44.2 Description
3.44.2.1 Packages
3.44.2.2 Links
3.44.2.3 Environment variables
3.44.3 Usage
3.44.4 See also
3.45 trunk/Scripts/Bash/Locale
3.45.1 Goals
3.45.2 Description
3.45.3 Usage
3.45.4 See also
3.46 trunk/Scripts/Perl
3.46.1 Goals
3.46.2 Description
3.46.3 Usage
3.46.4 See also
3.47 trunk/Scripts/Python
3.47.1 Goals
3.47.2 Description
3.47.3 Usage
3.47.4 See also
3.48 trunk/Translations
3.48.1 Goals
3.48.2 Description
3.48.2.1 Translation Entries
3.48.2.2 Translation Markers
3.48.2.3 Translation Files
3.48.2.4 Template Translation Files
3.48.2.5 Common Translation Files
3.48.2.6 Specific Translation Files
3.48.2.7 Translation Rendering
3.48.2.8 Translation (Pre-)Rendering Configuration Scripts
3.48.2.9 Translation Rendering Default Functionality
3.48.3 Usage
3.48.4 See also
3.49 trunk/Translations/Identity
3.49.1 Goals
3.49.2 Description
3.49.3 Usage
3.49.4 See also
3.50 trunk/Translations/Identity/Brands
3.50.1 Goals
3.50.2 Description
3.50.2.1 Conventional file names
3.50.2.2 Numeric file names
3.50.2.3 Translation markers
3.50.3 Usage
3.50.4 See also
3.51 trunk/Translations/Identity/Brands/Tpl
3.51.1 Goals
3.51.2 Description
3.51.3 Usage
3.51.4 See also
3.52 trunk/Translations/Identity/Fonts
3.52.1 Goals
3.52.2 Description
3.52.2.1 Translation Markers
3.52.3 Usage
3.52.4 See also
3.53 trunk/Translations/Identity/Models
3.53.1 Goals
3.53.2 Description
3.53.3 Usage
3.53.4 See also
3.54 trunk/Translations/Identity/Release
3.54.1 Goals
3.54.2 Description
3.54.3 Usage
3.54.4 See also
3.55 trunk/Translations/Identity/Themes
3.55.1 Goals
3.55.2 Description
3.55.3 Usage
3.55.4 See also
3.56 trunk/Translations/Identity/Themes/Backgrounds
3.56.1 Goals
3.56.2 Description
3.56.3 Usage
3.56.4 See also
3.57 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
3.57.1 Goals
3.57.2 Description
3.57.3 Usage
3.57.4 See also
3.58 trunk/Translations/Identity/Widgets
3.58.1 Goals
3.58.2 Description
3.58.3 Usage
3.58.4 See also
Index
List of Figures
CentOS Artwork Repository
*************************
This manual describes what the CentOS Artwork Repository is and what
can you do inside it.
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 store 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.
*RULE-1:*
For screen desings (e.g., anything that final destination will
never be printed on paper or any medium outside computre screens)
use DejaVu LGC Sans font-family.
*RULE-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 rules 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 "URW Bookman L" Normal
(not in bold, not in italic, not in anything else) 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/Modern/Backgrounds
====================================================
3.23.1 Goals
------------
* Organize background images for Modern theme.
3.23.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.23.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.23.4 See also
---------------
3.24 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img
========================================================
3.24.1 Goals
------------
* ...
3.24.2 Description
------------------
3.24.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.24.4 See also
---------------
3.25 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl
========================================================
3.25.1 Goals
------------
* ...
3.25.2 Description
------------------
3.25.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.25.4 See also
---------------
3.26 trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf
========================================================
3.26.1 Goals
------------
* ...
3.26.2 Description
------------------
* ...
3.26.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.26.4 See also
---------------
3.27 trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress
=================================================================
3.27.1 Goals
------------
* ...
3.27.2 Description
------------------
3.27.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.27.4 See also
---------------
3.28 trunk/Identity/Themes/Motifs/Modern/Palettes
=================================================
3.28.1 Goals
------------
* Organize palette files for Modern theme.
3.28.2 Description
------------------
3.28.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.28.4 See also
---------------
3.29 trunk/Identity/Themes/Motifs/TreeFlower
============================================
3.29.1 Goals
------------
* ...
3.29.2 Description
------------------
3.29.3 Usage
------------
3.29.4 See also
---------------
3.30 trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds
========================================================
3.30.1 Goals
------------
This section exists to orgnize TreeFlower's backgrounds.
3.30.2 Description
------------------
3.30.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.30.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.30.2.3 Grub background
........................
3.30.3 Usage
------------
* ...
3.30.4 See also
---------------
3.31 trunk/Identity/Widgets
===========================
3.31.1 Goals
------------
* ...
3.31.2 Description
------------------
3.31.3 Usage
------------
3.31.4 See also
---------------
3.32 trunk/Manuals
==================
3.32.1 Goals
------------
* ...
3.32.2 Description
------------------
* ...
3.32.3 Usage
------------
`centos-art help 'path/to/dir''
Use this command to read directory documentation specified in
`path/to/dir'.
`centos-art help 'path/to/dir' --read='filename''
Use this command to read file documentation as specified by
`path/to/dir/filename' combination.
`centos-art help 'path/to/dir' --edit'
Use this command to edit directory documentation as specified in
`path/to/dir'.
`centos-art help 'path/to/dir' --edit='filename''
Use this command to edit file documentation as specified in
`path/to/dir/filename' combination.
`centos-art help 'path/to/dir' --update'
Use this command to update documentation output files.
`centos-art help 'path/to/dir' --remove'
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 'path/to/dir' --remove='filename''
Use this command to remove file documentation as specified in
`path/to/dir/filename' combination.
3.32.4 See also
---------------
3.33 trunk/Scripts
==================
3.33.1 Goals
------------
The `trunk/Scripts' directory exists to:
* Organize the "trunk" development line of automation scripts by
programming language.
3.33.2 Description
------------------
* ...
3.33.3 Usage
------------
* ...
3.33.4 See also
---------------
3.34 trunk/Scripts/Bash
=======================
3.34.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.34.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.34.3 Usage
------------
The `centos-art.sh' script usage information is described inside each
specific function documentation (*note trunk Scripts Bash Functions::).
3.34.4 See also
---------------
3.35 trunk/Scripts/Bash/Functions
=================================
3.35.1 Goals
------------
The `trunk/Scripts/Bash/Functions' directory exists to organize
`centos-art.sh' specific functionalities.
3.35.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 <centos-art@centos.org>
to share your ideas.
It is also worth to know what global functions do we have available
inside `centos-art.sh' script, so advantage can be taken from them.
Global functions 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 describe
function definition in the following five components: 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 "$OPTIONNAM" in
--hello )
greet_doHello
;;
--bye )
greet_doBye
;;
* )
cli_printMessage "`gettext "The option provided is not valid."`"
cli_printMessage "$(caller)" 'AsToKnowMoreLine'
esac
}
The OPTIONNAM 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
OPTIONNAM variable would be `--hello'. Using this configuration let us
deside which action to perform based on the option 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 further lines 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"` $OPTIONVAL"
}
The `greet_doHello' function definition is stored in
`greet_doHello.sh' function script.
function greet_doBye {
cli_printMessage "`gettext "Goodbye"` $OPTIONVAL"
}
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 OPTIONVAL 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
OPTIONVAL 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 `help' functionality (*note trunk Scripts
Bash Functions Help::) of `centos-art.sh' script, just as the following
command illustrates:
centos-art help --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.35.3 Usage
------------
3.35.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: ACTION
Default action 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'.
-- Variable: OPTIONNAM
Default option name 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 OPTIONNAM passed
to `centos-art.sh' script is `--entry'.
-- Variable: OPTIONVAL
Default option value 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 OPTIONVAL passed
to `centos-art.sh' script is `path/to/dir'.
-- Variable: REGEX
Default option value passed as third argument in `centos-art.sh'
command-line interface. For example, in the command `centos-art
render --entry=path/to/dir --filter=regex', the REGEX passed to
`centos-art.sh' is `regex'.
The third argument option name is not variable as second argument
option name is. The third argument option name is stocked to
`--filter' for whatever value it passed at the right side of its
equal sign.
Generally, third argument option value is used to pass regular
expression patterns that modify the list of files to process, but
this is not the only feature REGEX may serve to.
-- Variable: ANSWER
Default answer to confirmation questions.
As most questions request confirmation to perform some action,
default answer to ANSWER variable is negative (i.e., `No').
Default answer value takes place when no value is entered as
response to confirmation questions before pressing <RET> key.
-- Variable: TMPFILE
Default location to store temporal files.
The TMPFILE uses `/tmp' directory as source location to store
temporal files, the `centos-art.sh' script name, and the process
id of `centos-art.sh' script execution 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:
${TMPFILE}-${FILE}
If FILE name is `instance.svg' and process id is `3761', the final
temporal file built from previous temporal file definition would
be:
/tmp/centos-art.sh-3761-instance.svg
When you use TMPFILE global variable 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=${TMPFILE}-${FILE}
# Do something ...
# Remove temporal instance of file.
if [[ -f $INSTANCE ]];then
rm $INSTANCE
fi
done
-- 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.35.3.2 Global functions
.........................
The following global functions of `centos-art.sh' script, are available
for you to use inside specific functions:
-- Function: cli_commitRepoChanges
Commit recent changes up to central repository.
The `cli_commitRepoChanges' function uses the list of files stored
in the FILES variable and verifies changes inside your repository
working copy, using subversion commands. If
`cli_commitRepoChanges' finds changes inside your working copy, it
asks you for confirmation to commit them up to central repository.
Call `cli_commitRepoChanges' function after functions that modify
files inside your repository working copy.
-- Function: cli_checkFiles FILE [TYPE]
Verify files.
`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 or a
symbolic link.
As default behaviour, if FILE passes all verifications,
`centos-art.sh' script continues with its normal flow.
-- Function: cli_getCountryCodes [FILTER]
Output country codes.
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]
Output country names.
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.
The `cli_getCountryName' function outputs country name supported
by `centos-art.sh' script.
-- 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 no common language
specification is used for English language (i.e., `en'). 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.
The `cli_getCurrentLocale' function outputs current locale used by
`centos-art.sh' script.
-- Function: cli_getLangCodes [FILTER]
Output language codes.
`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.
The `cli_getLangCodes' function outputs language codes supported
by `centos-art.sh' script.
-- Function: cli_getLangName [FILTER]
Output language names.
`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.
The `cli_getLangName' function outputs language names supported by
`centos-art.sh' script.
-- 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.
*Warning* `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 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 changing file name convenctions inside `cli_getRepoName' what
you are really changing is the way functions interpret repository
file system organization. In order to a complete file name
convenction change, you also need to change file names and
directory names inside repository file system organization, just
as you did in `cli_getRepoName' function.
*Note* *Note trunk Scripts Bash Functions Path::, for more
information on how to rename files and directories massively
inside repository file system organization.
-- Function: cli_getThemeName
Output theme name.
In order for `cli_getThemeName' function to extract theme name
correctly, the OPTIONVAL 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]
Give format to output messages.
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 using two-columns format.
Updating $MESSAGE
`AsRemovingLine'
To print `Removing' messages using two-columns format.
Removing $MESSAGE
`AsCheckingLine'
To print `Checking' messages using two-columns format.
Checking $MESSAGE
`AsCreatingLine'
To print `Creating' messages using two-columns format.
Creating $MESSAGE
`AsSavedAsLine'
To print `Saved as' messages using two-columns format.
Saved as $MESSAGE
`AsLinkToLine'
To print `Linked to' messages using two-columns format.
Linked to $MESSAGE
`AsMovedToLine'
To print `Moved to' messages using two-columns format.
Moved to $MESSAGE
`AsTranslationLine'
To print `Translation' messages using two-columns format.
Translation $MESSAGE
`AsConfigurationLine'
To print `Configuration' messages using two-columns format.
Configuration $MESSAGE
`AsResponseLine'
To print response messages using one-column format.
--> $MESSAGE
`AsRequestLine'
To print request messages using one-column format. Request
messages supress the trailing newline character from final
output.
$MESSAGE
`AsYesOrNoRequestLine'
To print `yes or no' request messages using 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 you are using `centos-art.sh' script in a locale
different from `en_US.UTF-8', confirmation answer may be
different from `y'. For example, if you are using
`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 help --read='path/to/dir'
----------------------------------------------------------------------
Use `AsToKnowMoreLine' option after errors and for intentional
script termination.
`AsRegularLine'
To standardize regular messages using one-column format.
When MESSAGE contains a colon inside (e.g., `description:
message'), the `cli_printMessage' function outputs MESSAGE
using two-columns format.
*Tip* To improve two-columns format, change the following
file:
trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
Use `cli_printMessage' function whenever you need to output
information from `centos-art.sh' script.
3.35.3.3 Specific functions
...........................
The following specific functions of `centos-art.sh' script, are
available for you to use:
3.35.4 See also
---------------
3.36 trunk/Scripts/Bash/Functions/Help
======================================
3.36.1 Goals
------------
* ...
3.36.2 Description
------------------
* ...
3.36.3 Usage
------------
* ...
3.36.4 See also
---------------
3.37 trunk/Scripts/Bash/Functions/Html
======================================
3.37.1 Goals
------------
* ...
3.37.2 Description
------------------
* ...
3.37.3 Usage
------------
* ...
3.37.4 See also
---------------
3.38 trunk/Scripts/Bash/Functions/Locale
========================================
3.38.1 Goals
------------
* ...
3.38.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.38.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.38.4 See also
---------------
3.39 trunk/Scripts/Bash/Functions/Path
======================================
3.39.1 Goals
------------
This section exists to organize files related to centos-art.sh path
functiontionality. The centos-art.sh path functionality standardizes
file movements inside CentOS Artwork Repository. This helps to keep
repository file system syncronized with documentation file system.
3.39.2 Description
------------------
* ...
3.39.3 Usage
------------
This feature is not supported yet.
`centos-art path --rename='old new' --filter='d''
Rename all occurences of `old' directory names with `new'
directory name, recursively under the current location.
`centos-art path --rename='old new' --filter='f''
Rename all occurences of `old' file names with `new' file name,
recursively under the current location.
3.39.4 See also
---------------
3.40 trunk/Scripts/Bash/Functions/Render
========================================
3.40.1 Goals
------------
* ...
3.40.2 Description
------------------
* ...
3.40.3 Usage
------------
* ...
3.40.4 See also
---------------
3.41 trunk/Scripts/Bash/Functions/Render/Config
===============================================
3.41.1 Goals
------------
The `trunk/Scripts/Bash/Config' directory exists to oraganize
pre-rendering configuration scripts.
3.41.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.41.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.41.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.41.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.41.3 Usage
------------
Use the following commands to administer both identity and translation
pre-rendering configuration scripts:
`centos-art config 'path/to/dir/' --create'
Use this command to create `path/to/dir' related pre-rendering
configuration script.
`centos-art config 'path/to/dir/' --edit'
Use this command to edit `path/to/dir' related pre-rendering
configuration script.
`centos-art config 'path/to/dir/' --read'
Use this command to read `path/to/dir' related pre-rendering
configuration script.
`centos-art config 'path/to/dir/' --remove'
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.41.4 See also
---------------
3.42 trunk/Scripts/Bash/Functions/Shell
=======================================
3.42.1 Goals
------------
* ...
3.42.2 Description
------------------
* ...
3.42.3 Usage
------------
* ...
3.42.4 See also
---------------
3.43 trunk/Scripts/Bash/Functions/Svg
=====================================
3.43.1 Goals
------------
This section exists to organize the "svg" functionality of
centos-art.sh script.
3.43.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 a set of (let's say 30) SVG files, and you want
to set common metadata to all of them. Doing so file by file is a
tedious task, so the centos-art.sh script provides the "svg"
functionality to aid you maintain such actions.
Most "svg" actions take one opening tag (e.g., `<metadata'), and one
closing tag (e.g., `</metadata') and replace everything in-between with
the information you define. The information you need to define is
inside template files as sed's replacement commands. Template files
are stored under `trunk/Scripts/Bash/Functions/Svg/Tpl/' directory and
can contain translation markers.
Translation markers have the form `=SOMETEXT='. Translation markers
are used by "svg" functionalities to introduce dynamic information
(e.g., dates, keywords based on path, etc.)
3.43.3 Usage
------------
`centos-art svg --update-metadata='path/to/dir''
Use this command to update metadata information to all `.svg'
files under `path/to/dir' as defined in the metadata template file.
`centos-art svg --update-metadata='path/to/dir' --filter='filename''
Use this command to update metadata information to
`path/to/dir/filename', as defined in the metadata template file.
3.43.4 See also
---------------
3.44 trunk/Scripts/Bash/Functions/Verify
========================================
3.44.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.44.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.44.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.44.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.44.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.44.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.44.4 See also
---------------
3.45 trunk/Scripts/Bash/Locale
==============================
3.45.1 Goals
------------
This section exists to organize translation messages and templates used
by `centos-art.sh' script.
3.45.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.45.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.45.4 See also
---------------
3.46 trunk/Scripts/Perl
=======================
3.46.1 Goals
------------
* ...
3.46.2 Description
------------------
3.46.3 Usage
------------
3.46.4 See also
---------------
3.47 trunk/Scripts/Python
=========================
3.47.1 Goals
------------
* ...
3.47.2 Description
------------------
* ...
3.47.3 Usage
------------
* ...
3.47.4 See also
---------------
3.48 trunk/Translations
=======================
3.48.1 Goals
------------
The `trunk/Translations' directory exists to:
* Organize translation files.
* Organize translation templates used to produce translation files.
3.48.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.48.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.48.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.48.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.48.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.48.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.48.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.48.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.48.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: splash-small.sed 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.48.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.48.3 Usage
------------
`centos-art render '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 '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.48.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.49 trunk/Translations/Identity
================================
3.49.1 Goals
------------
* ...
3.49.2 Description
------------------
* ...
3.49.3 Usage
------------
* ...
3.49.4 See also
---------------
3.50 trunk/Translations/Identity/Brands
=======================================
3.50.1 Goals
------------
* Organize brands' translation files.
3.50.2 Description
------------------
Translation files, inside `trunk/Translations/Identity/Brands'
translation entry, don't use default rendering translation
functionality, they use the following translation pre-rendering
configuration file instead:
/home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh
Inside `trunk/Translations/Identity/Brands' translation entry,
translation files are symbolic links pointing to the common template
translation structure, inside the translation template (`Tpl/')
directory.
Inside `trunk/Translations/Identity/Brands' translation entry,
translation files are created using identity design templates as
reference. The translation pre-rendering script creates a translation
structure where the translation template (`Tpl/') directory structure
applies to each single design template available.
For example, if the brands' translation template (`Tpl/') directory
has 30 translation files, and there are 20 design templates; the
brands' translation pre-rendering script creates a translation
structure of symbolic links where the 30 translation files apply the 20
design templates one by one, producing 600 translation symbolic links
as result. At this point, when rendering identity, the `centos-art'
script considers translation symbolic links as translation files.
Translation file names, inside brands' translation template (`Tpl')
directory have special meaning:
3.50.2.1 Conventional file names
................................
Convenctional file names look like `blue.sed', `2c-a.sed', etc.
Replacement commands inside translation file are applied to design
templates and translation file names are used as final image name. The
image dimensions use the same dimensions that design template has.
3.50.2.2 Numeric file names
...........................
Numeric file names look like `300.sed', `200.sed', etc. Replacements
commands inside translation files are applied to design templates, and
translation file names are used as final image name. The final image
is saved using an specific `width' defined by the number part of the
translation file name. The image `height' is automatically scaled based
on the previous `width' definition to maintain the 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.50.2.3 Translation markers
............................
Inside `trunk/Translations/Identity/Brands/', translation files combine
the following translation markers:
`#000000'
Specify which color to use when rendering brand images.
*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.50.3 Usage
------------
To render brands' translation files, use the following command:
centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands
3.50.4 See also
---------------
3.51 trunk/Translations/Identity/Brands/Tpl
===========================================
3.51.1 Goals
------------
3.51.2 Description
------------------
3.51.3 Usage
------------
3.51.4 See also
---------------
3.52 trunk/Translations/Identity/Fonts
======================================
3.52.1 Goals
------------
* Organize fonts' translation files.
3.52.2 Description
------------------
Translation files, inside `trunk/Translations/Fonts', have the
following structure:
# ----------------------------------------------------------------------
# $Id: Fonts.texi 29 2010-09-12 05:32:26Z al $
# ----------------------------------------------------------------------
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.52.2.1 Translation Markers
............................
Inside `trunk/Translations/Identity/Fonts', translation files combine
the following translation markers:
`font-family:Denmark'
Specify which font family to use when rendering font preview
images.
`font-weight:normal'
Specify which font weight to use when rendering font preview
images.
`font-style:normal'
Specify which font style to use when rendering font preview images.
3.52.3 Usage
------------
Inside `trunk/Translations/Fonts' you use your favorite text editor to
create translation files. Inside `trunk/Translations/Fonts' there is
not translation template directory (`Tpl/'), nor translation rendering
using `centos-art' script. For example, to create the
`dejavu_lgc_sans-boldoblique.sed' translation file using `vim' editor,
type the following command:
vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed
3.52.4 See also
---------------
3.53 trunk/Translations/Identity/Models
=======================================
3.53.1 Goals
------------
3.53.2 Description
------------------
3.53.3 Usage
------------
3.53.4 See also
---------------
3.54 trunk/Translations/Identity/Release
========================================
3.54.1 Goals
------------
3.54.2 Description
------------------
3.54.3 Usage
------------
3.54.4 See also
---------------
3.55 trunk/Translations/Identity/Themes
=======================================
3.55.1 Goals
------------
3.55.2 Description
------------------
3.55.3 Usage
------------
3.55.4 See also
---------------
3.56 trunk/Translations/Identity/Themes/Backgrounds
===================================================
3.56.1 Goals
------------
* ...
3.56.2 Description
------------------
* ...
3.56.3 Usage
------------
* ...
3.56.4 See also
---------------
3.57 trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
================================================================
3.57.1 Goals
------------
* Organize Anaconda progress translation templates.
* Organize Anaconda progress translation files in several languages
and major releases of CentOS distribution.
3.57.2 Description
------------------
Use the following command to produce translation files based:
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
`-- Tpl
|-- en
| |-- 01-welcome.sed
| |-- 02-donate.sed
| `-- 03-yum.sed
`-- es
|-- 01-welcome.sed
|-- 02-donate.sed
`-- 03-yum.sed
In order to produce the slide images in PNG format we need to have
the translation files first. So we use the following commands to create
translation files for CentOS 3, 4, and 5 major releases:
centos-art render --translation --filter='3,4,5'
The above commands will produce the following translation structure:
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress
|-- 3
| |-- en
| | |-- 01-welcome.sed
| | |-- 02-donate.sed
| | `-- 03-yum.sed
| `-- es
| |-- 01-welcome.sed
| |-- 02-donate.sed
| `-- 03-yum.sed
|-- 4
| |-- en
| | |-- 01-welcome.sed
| | |-- 02-donate.sed
| | `-- 03-yum.sed
| `-- es
| |-- 01-welcome.sed
| |-- 02-donate.sed
| `-- 03-yum.sed
|-- 5
| |-- en
| | |-- 01-welcome.sed
| | |-- 02-donate.sed
| | `-- 03-yum.sed
| `-- es
| |-- 01-welcome.sed
| |-- 02-donate.sed
| `-- 03-yum.sed
`-- Tpl
|-- en
| |-- 01-welcome.sed
| |-- 02-donate.sed
| `-- 03-yum.sed
`-- es
|-- 01-welcome.sed
|-- 02-donate.sed
`-- 03-yum.sed
At this point we have all the translation files we need to produce
Anaconda progress welcome, donate and yum slides images; in English and
Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is, a sum
of 18 images around.
Now, with translation files in place, let's move to `trunk/Identity'
structure and render them.
* *Note trunk Identity Themes Motifs Modern Distro Anaconda
Progress::.
3.57.3 Usage
------------
Translation rendering is described in `trunk/Translations'
documentation entry (*note trunk Translations::).
3.57.4 See also
---------------
3.58 trunk/Translations/Identity/Widgets
========================================
3.58.1 Goals
------------
* ...
3.58.2 Description
------------------
* ...
3.58.3 Usage
------------
* ...
3.58.4 See also
---------------
Index
*****
branches: See 1. (line 368)
Common translation files: See 3.48.2.5. (line 4366)
How to render brands' translation files: See 3.50.3. (line 4671)
How to render fonts' translation files: See 3.52.3. (line 4748)
How to render translation files: See 3.48.3. (line 4536)
Specific translation files: See 3.48.2.6. (line 4391)
tags: See 2. (line 371)
Template translation files: See 3.48.2.4. (line 4196)
Translation brands file names: See 3.50.2.1. (line 4628)
Translation configuration scripts: See 3.48.2.8. (line 4425)
Translation entries: See 3.48.2.1. (line 4012)
Translation files: See 3.48.2.3. (line 4128)
Translation markers: See 3.48.2.2. (line 4093)
Translation paths: See 3.48.2.1. (line 4012)
Translation pre-rendering configuration scripts:See 3.48.2.8.
(line 4425)
Translation rendering: See 3.48.2.7. (line 4414)
Translation rendering default functionality: See 3.48.2.9. (line 4511)
trunk: See 3. (line 374)
trunk Identity: See 3.1. (line 377)
trunk Identity Brands: See 3.2. (line 797)
trunk Identity Fonts: See 3.3. (line 814)
trunk Identity Icons: See 3.4. (line 890)
trunk Identity Isolinux: See 3.5. (line 907)
trunk Identity Models: See 3.6. (line 924)
trunk Identity Models Css: See 3.7. (line 944)
trunk Identity Models Html: See 3.8. (line 966)
trunk Identity Models Img Promo Web: See 3.9. (line 987)
trunk Identity Models Tpl: See 3.10. (line 1008)
trunk Identity Models Tpl Promo Web: See 3.11. (line 1029)
trunk Identity Models Xcf: See 3.12. (line 1343)
trunk Identity Release: See 3.13. (line 1364)
trunk Identity Themes: See 3.14. (line 1381)
trunk Identity Themes Models: See 3.15. (line 1406)
trunk Identity Themes Models Alternative: See 3.16. (line 1439)
trunk Identity Themes Models Default: See 3.17. (line 1466)
trunk Identity Themes Models Default Distro: See 3.18. (line 1498)
trunk Identity Themes Models Default Distro Anaconda:See 3.19.
(line 1582)
trunk Identity Themes Models Default Promo: See 3.20. (line 1599)
trunk Identity Themes Models Default Web: See 3.21. (line 1625)
trunk Identity Themes Motifs: See 3.22. (line 1650)
trunk Identity Themes Motifs Modern Backgrounds:See 3.23. (line 1754)
trunk Identity Themes Motifs Modern Backgrounds Img:See 3.24.
(line 1876)
trunk Identity Themes Motifs Modern Backgrounds Tpl:See 3.25.
(line 1897)
trunk Identity Themes Motifs Modern Backgrounds Xcf:See 3.26.
(line 1918)
trunk Identity Themes Motifs Modern Distro Anaconda Progress:See 3.27.
(line 1945)
trunk Identity Themes Motifs Modern Palettes: See 3.28. (line 2001)
trunk Identity Themes Motifs TreeFlower: See 3.29. (line 2023)
trunk Identity Themes Motifs TreeFlower Backgrounds:See 3.30.
(line 2040)
trunk Identity Widgets: See 3.31. (line 2336)
trunk Manuals: See 3.32. (line 2353)
trunk Scripts: See 3.33. (line 2407)
trunk Scripts Bash: See 3.34. (line 2431)
trunk Scripts Bash Functions: See 3.35. (line 2543)
trunk Scripts Bash Functions Help: See 3.36. (line 3262)
trunk Scripts Bash Functions Html: See 3.37. (line 3283)
trunk Scripts Bash Functions Locale: See 3.38. (line 3304)
trunk Scripts Bash Functions Path: See 3.39. (line 3384)
trunk Scripts Bash Functions Render: See 3.40. (line 3416)
trunk Scripts Bash Functions Render Config: See 3.41. (line 3437)
trunk Scripts Bash Functions Shell: See 3.42. (line 3615)
trunk Scripts Bash Functions Svg: See 3.43. (line 3636)
trunk Scripts Bash Functions Verify: See 3.44. (line 3680)
trunk Scripts Bash Locale: See 3.45. (line 3896)
trunk Scripts Perl: See 3.46. (line 3925)
trunk Scripts Python: See 3.47. (line 3942)
trunk Translations: See 3.48. (line 3963)
trunk Translations Identity: See 3.49. (line 4566)
trunk Translations Identity Brands: See 3.50. (line 4587)
trunk Translations Identity Brands Tpl: See 3.51. (line 4682)
trunk Translations Identity Fonts: See 3.52. (line 4697)
trunk Translations Identity Models: See 3.53. (line 4764)
trunk Translations Identity Release: See 3.54. (line 4779)
trunk Translations Identity Themes: See 3.55. (line 4794)
trunk Translations Identity Themes Backgrounds:See 3.56. (line 4809)
trunk Translations Identity Themes Distro Anaconda Progress:See 3.57.
(line 4830)
trunk Translations Identity Widgets: See 3.58. (line 4923)
List of Figures
***************