-
-
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_42.html b/Manuals/en/Html/Repository/repository_42.html
index 8ee857f..d399be4 100644
--- a/Manuals/en/Html/Repository/repository_42.html
+++ b/Manuals/en/Html/Repository/repository_42.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
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:
-
Use this command to translate command-line interface output messages
-in the current system locale you are using (as specified in LANG
-environment variable).
-
Use this command to see the command-line interface locale report. -
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_43.html b/Manuals/en/Html/Repository/repository_43.html
index 97c449c..60a9b42 100644
--- a/Manuals/en/Html/Repository/repository_43.html
+++ b/Manuals/en/Html/Repository/repository_43.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
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:
+
Use this command to translate command-line interface output messages
+in the current system locale you are using (as specified in LANG
+environment variable).
+
Use this command to see the command-line interface locale report. +
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_44.html b/Manuals/en/Html/Repository/repository_44.html
index 80b7fc9..70c4da1 100644
--- a/Manuals/en/Html/Repository/repository_44.html
+++ b/Manuals/en/Html/Repository/repository_44.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
This section exists to organize files related to path
-functiontionality of `centos-art.sh' script. The path
-functionality of `centos-art.sh' script standardizes movement,
-syncronization, branching, tagging, and general file maintainance
-inside the repository.
-
"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." -
- - -The repository layout describes organization of files and directories -inside the repository. The repository layout provides the standard -backend required for automation scripts to work correctly. If such -layout changes unexpectedly, automation scripts may confuse themselves -and stop doing what we expect from them to do. -
-As convenction, inside CentOS Artwork Repository, we organize files -and directories, related to CentOS corporate visual identity, under -three top level directories named `trunk/', `branches/', and -`tags/'. -
-Figure 3.10: The CentOS Artwork Repository layout. - -
-The `trunk/' directory (see section trunk) organizes the main -development line of CentOS corporate visual identity. Inside -`trunk/' directory structure, the CentOS corporate visual -identity concepts are implemented using directories. There is one -directory level for each relevant concept inside the repository. The -`trunk/' directory structure is mainly used to develop CentOS -corporate visual identity. -
-The `branches/' directory (see section branches) oranizes parallel -development lines to `trunk/' directory. The `branches/' -directory is used to set points in time where develpment lines are -devided one from another taking separte and idependent lives that -share a common past from the point they were devided on. The -`branches/' directory is mainly used to perform quality assurance -on CentOS corporate visual identity. -
-The `tags/' directory (see section tags) organizes parallel frozen -lines to `branches/' directory. The parallel frozen lines are -immutable, nothing change inside them once they has been created. The -`tags/' directory is mainly used to publish final releases of -CentOS corporate visual identity. -
-The CentOS Artwork Repository layout is firmly grounded on a -Subversion base. Subversion (http://subversion.tigris.org) is a -version control system, which allows you to keep old versions of files -and directories (usually source code), keep a log of who, when, and -why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a -single copy of the master sources. This copy is called the source -"repository"; it contains all the information to permit extracting -previous versions of those files at any time. -
- - -Repository name convenctions help us to maintain consistency of names -inside the repository. -
-Repository name convenctions are applied to files and directories -inside the repository layout. As convenction, inside the repository -layout, file names are all written in lowercase -(`01-welcome.png', `splash.png', `anaconda_header.png', -etc.) and directory names are all written capitalized (e.g., -`Identity', `Themes', `Motifs', `TreeFlower', -etc.). -
-Repository name convenctions are implemented inside the
-cli_getRepoName function of `centos-art.sh' script. With
-cli_getRepoName function we reduce the amount of commands and
-convenctions you need to remember concentrating them in just one
-single place you can look for fixes and improvements.
-
Repository work flow describes the steps and time intervals used to -produce CentOS corporate visual identity inside CentOS Artwork -Repository. -
-To illustrate repository work flow let's consider themes' development -cycle. -
-Initially, we start working themes on their trunk development line -(e.g., `trunk/Identity/Themes/Motifs/TreeFlower/'), here we -design background images and propagate them to different visual -manifestations using one theme's model as reference. -
-Later, when the theme is considered "ready" for implementation (i.e. -all visual manifestations have been already set), we create a branch -for it (e.g., `branches/Identity/Themes/Motifs/TreeFlower/1/'). -Once the branch has been created, we forget that branch and continue -working the trunk development line while others (e.g., an artwork -quality assurance team) test the new branch for tunning it up. -
-Once the branch has been tunned up, and considered "ready" for -release, it is freezed under `tags/' directory (e.g., -`tags/Identity/Themes/Motifs/TreeFower/1.0/') for packagers, -webmasters, promoters, and anyone who needs images from that CentOS -theme the tag was created for. -
-Both branches and tags, inside CentOS Artwork Repository, use -numerical values to identify themselves under the same location. -Branches start at one (i.e., `1') and increment one unit for each -branch created from the same trunk development line. Tags start at -zero (i.e., `0') and increment one unit for each tag created from -the same branch development line. -
-Figure 3.11: Name convention for tags and branches creation. - -
-As proposition, it would be convenient not to freeze trunk development -lines using tags or anything else. If you think you need to freeze a -trunk development line, create a branch for it and then freeze that -branch instead. -
-The trunk development line may introduce problems we cannot see -immediatly. Certainly, the high changable nature of trunk development -line complicates finding and fixing such problems. On the other hand, -the branched development lines provides a less changable area where -only small fixes/corrections are commited up to repository. -
-If others find and fix bugs inside the branched development line, we -could merge such changes/experiences back to trunk development line -(not visversa) in order for future branches, created from trunk, to -benefit. -
-Time intervals used to create branches and tags may vary, just as -different needs may arrive. For example, consider the release schema -of CentOS distribution: one major release every 2 years, security -updates every 6 months, support for 7 years long. Each time a CentOS -distribution is released, specially if it is a major release, there is -a theme need in order to cover CentOS distribution artwork -requirements. At this point, is where CentOS Artwork Repository comes -up to scene. -
-Before releasing a new major release of CentOS distribution you can -create a branch for one of several theme development lines available -inside the CentOS Artwork Repository, perform quality assurance on it, -and later, freeze that branch using tags. Once a the theme branch has -been frozen (under `tags/' directory), CentOS Packagers (the -persons who build CentOS distribution) can use that frozen branch as -source location to fulfill CentOS distribution artwork needs. -
- - -Inside CentOS Artwork Repository, parallel directories are simple -directory entries built from a common parent directory and placed in a -location different to that, the common parent directory is placed on. -Parallel directories are useful to create branches, tags, -translations, documentation, pre-rendering configuration script, and -similar directory structures. -
-Parallel directories take their structure from one unique parent -directory. Inside CentOS Artwork Repository, this unique parent -directory is under `trunk/Identity' location. The -`trunk/Identity' location must be considered the reference for -whatever information you plan to create inside the repository. -
-In some circumstances, parallel directories may be created removing
-uncommon information from their paths. Uncommon path information
-refers to those directory levels in the path which are not common for
-other parallel directories. For example, when rendering
-`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory
-structure, the `centos-art.sh' script removes the
-`Motifs/TreeFlower/' directory levels from path, in order to
-build the parallel directory used to retrived translations, and
-pre-rendering configuration scripts required by render
-functionality.
-
Another example where parallel directory removes the uncommon path
-information is when we use the help functionality. This time,
-`centos-art.sh' script uses parallel directory information
-(without uncommon directory levels) to build the documentation entry
-required by Texinfo to store documentation entries inside the
-repository.
-
Figure 3.12: Parallel directories removing uncommon information. - -
-Othertimes, parallel directories may add uncommon information to their -paths. This is the case we use to create branches and tags. When we -create branches and tags, a numerical identifier is added to parallel -directory structure path. The place where the numerical identifier is -set on is relevant to corporate visual identity structure and should -be carefully considered where it will be. -
-Figure 3.13: Parallel directories adding uncommon information. - -
-When one parent directory changes, all their related parallel -directories need to be changed too. This is required in order for -parallel directories to match the new parent directory structure. In -the other hand, parallel directories should never be modified by no -reason but to satisfy their parent directory structure. Liberal change -of parallel directories may suppress the conceptual idea they were -initially created for. -
-Figure 3.14: Wrong construction of parallel directories. - -
- - -Creating parallel directories is very useful to keep repository
-organized. But, what would happen to functionalities like help
-(WARNING: The `trunk Scripts Bash Functions Help' documentation entry no longer exists.) that rely on parent
-directory structures to create documentation entries (using parallel
-directory structures) if one of those parent directory structures
-suddenly changes after the documentation entry has been already
-created for it?
-
Well, at this point, functionalities like help may confuse
-themselves if path information is not updated. Such functionalities
-work with parent directory structure as reference; if a parent
-directory changes, the functionalities dont't even note it because
-they work with the last parent directory structure available in the
-repository, no matter what it is.
-
In the specific case of documentation (the help functionality),
-the problem mentioned above provokes that older parent directories,
-already documented, remain inside documentation directory structures
-as long as you get your hands into the documentation directory
-structure (`trunk/Manuals') and remove what must be removed to
-match the new parent directory structure.
-
There is no way for help, and similar functionalities that use
-parent directories as reference, to know when and how directory
-movements take place inside the repository. Such information is
-available only when movement actions, like thoses achived by
-rm or mv commands, take place inside the
-repository. So, is there, at the moment of moving files, when we need
-to syncronize parallel directories with their unique parent directory
-structure.
-
Syncronizing parallel directories with their respecitive parent -directory implies moving files inside the repository, i.e. we need to, -firstly, rebuild the path information for each parallel directory -inside the repository, using the current path of its parent directory -as reference, and later, use the new path information to move each old -parallel directory from its old location to its new location based on -an updated path information. -
-As CentOS Artwork Repository is built over a version control system, -file movements inside the repository are considered repository -changes. In order for these repository changes to be versioned, we -need to, firstly, add changes related files into version control -system, and later, use commands from the version control system to -move those files already versioned. This configuration makes possible -for everyone to know about changes details inside the repository; and -if needed, revert or update them back to a previous revision. -
-Finally, once all file corrections have been already made, the -syncronization action takes care of updating path references inside -related files. Updating path references inside related files is -specially important for documentation files where documentation nodes -are built using repository path information as reference. -
- - -Occasionly, you may find that new corporate visual identity components -need to be added to the repository. If that is your case, the first -question you need to ask yourself, before start to create directories -blindly all over, is: What is the right location to store it? -
-The CentOS Community (http://wiki.centos.org/GettingHelp) is the -best place to find answers to your question, but going there with -hands empty is not good idea. It may give the impression you don't -really care about. Instead, consider the following suggestions to find -your own comprehension and so, make your propositions based on it. -
-When looking the correct place to store new files, to bear in mind the -corporate visual identity structure used inside the CentOS Artwork -Repository (see section trunk/Identity) would be probaly the best advice -we could offer to you, the rest is just matter of choosing appropriate -names. To illustrate this desition process let's consider the -`trunk/Identity/Themes/Motifs/TreeFlower/Distro/' directory as -example. It is the main development line of CentOS distribution visual -manifestation, using TreeFlower's artistic motif, inside themes of -CentOS corporate visual identity. -
-When building parent directory structures, you may find that reaching -an acceptable location may take some time, and as it happens most of -time, when you find it, that may be not a definite solution. There are -many concepts that you need to play with, in order to find a result -that match the conceptual idea you try to implement in the new -directory location. To know which these concepts are, split the -location in words and read its documentation entry from less specific -to more specific. -
-For example, the -`trunk/Identity/Themes/Motifs/TreeFlower/Distro/' location -evolved through several months of contant work and there is no certain -it won't change in the future, even it fixes quite well the concept we -are trying to implement. The concepts used in -`trunk/Identity/Themes/Distro/Motifs/TreeFlower/Distro/' location -are described in the following commands, respectively: -
-centos-art help --read=turnk/ -centos-art help --read=turnk/Identity/ -centos-art help --read=turnk/Identity/Themes/ -centos-art help --read=turnk/Identity/Themes/Motifs/ -centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/ -centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/Distro/ --
Other location concepts can be found similary as we did above, just -change the location we used above by the one you are trying to know -concepts for. -
- - +
-
-
-
-
-
-
-centos-art path --copy=SRC --to=DSTUse this command to duplicate `SRC' in working copy, -remembering history. In this command, `SRC' and -`DST' can each be either a working copy (WC) path or -URL: -
-Copy and schedule for addition (with history). -
-Immediately commit a copy of WC to URL. -
-Check out URL into WC, schedule for addition. -
-Complete server-side copy; used to branch and tag. -
This command is an interface for Subversion's copy command.
-Options related to Subversion's copy command can be passed
-from third argument on. For example to specify a log message use the
-`--message' option as follow:
-
centos-art path --copy=URL/SRC --to=URL/DST --message 'Copy url/src to url/dst' --
For more information on Subversion's copy functionality,
-run the command: svn help copy | less.
-
centos-art path --move=SRC --to=DSTMove and/or rename something in working copy or repository. In this -command, SRC and DST can both be working copy (WC) paths or URLs: -
-Move and schedule for addition (with history). -
Complete server-side rename. -
This command is an interface for Subversion's move command.
-Options related to Subversion's move command can be passed
-from third argument on. For example to specify a log message use the
-`--message' option as follow:
-
centos-art path --move=URL/SRC --to=URL/DST --message 'Move url/src to url/dst' --
For more information on Subversion's move functionality,
-run the command: svn help move | less.
-
centos-art path --delete='SRC'Use this command to remove files and directories from version control. -In this command, `SRC' can be a working copy (WC) path or URL. -
-Each item specified by a PATH is scheduled for deletion upon the next -commit. Files, and directories that have not been committed, are -immediately removed from the working copy. PATHs that are, or -contain, unversioned or modified items will not be removed unless the -`--force' option is given. -
-Each item specified by a URL is deleted from the repository via an -immediate commit. -
This command is an interface for Subversion's delete
-command. Options related to Subversion's delete can be
-passed from third argument on. For example to specify a log message
-use the `--message' as follow:
-
centos-art path --delete='URL' --message 'Delete url.' --
For more information on Subversion's delete functionality,
-run the command: svn help delete | less.
-
centos-art path --sync='SRC'Use this command to syncronize path information inside working copy. -This command is automatically used after moving or renaming parent -directories. In this command, `SRC' is a working copy path -inside `trunk/Identity/' location, considered the parent -directory you want to syncronize path information for. -
| 3.36 trunk/Scripts/Bash | - | |
| 3.37 trunk/Scripts/Bash/Functions | - |
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_45.html b/Manuals/en/Html/Repository/repository_45.html
index 611801c..b8ba04f 100644
--- a/Manuals/en/Html/Repository/repository_45.html
+++ b/Manuals/en/Html/Repository/repository_45.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
This section exists to organize files related to path
+functiontionality of `centos-art.sh' script. The path
+functionality of `centos-art.sh' script standardizes movement,
+syncronization, branching, tagging, and general file maintainance
+inside the repository.
+
"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." +
+ + +The repository layout describes organization of files and directories +inside the repository. The repository layout provides the standard +backend required for automation scripts to work correctly. If such +layout changes unexpectedly, automation scripts may confuse themselves +and stop doing what we expect from them to do. +
+As convenction, inside CentOS Artwork Repository, we organize files +and directories, related to CentOS corporate visual identity, under +three top level directories named `trunk/', `branches/', and +`tags/'. +
+Figure 3.10: The CentOS Artwork Repository layout. + +
+The `trunk/' directory (see section trunk) organizes the main +development line of CentOS corporate visual identity. Inside +`trunk/' directory structure, the CentOS corporate visual +identity concepts are implemented using directories. There is one +directory level for each relevant concept inside the repository. The +`trunk/' directory structure is mainly used to develop CentOS +corporate visual identity. +
+The `branches/' directory (see section branches) oranizes parallel +development lines to `trunk/' directory. The `branches/' +directory is used to set points in time where develpment lines are +devided one from another taking separte and idependent lives that +share a common past from the point they were devided on. The +`branches/' directory is mainly used to perform quality assurance +on CentOS corporate visual identity. +
+The `tags/' directory (see section tags) organizes parallel frozen +lines to `branches/' directory. The parallel frozen lines are +immutable, nothing change inside them once they has been created. The +`tags/' directory is mainly used to publish final releases of +CentOS corporate visual identity. +
+The CentOS Artwork Repository layout is firmly grounded on a +Subversion base. Subversion (http://subversion.tigris.org) is a +version control system, which allows you to keep old versions of files +and directories (usually source code), keep a log of who, when, and +why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a +single copy of the master sources. This copy is called the source +"repository"; it contains all the information to permit extracting +previous versions of those files at any time. +
+ + +Repository name convenctions help us to maintain consistency of names +inside the repository. +
+Repository name convenctions are applied to files and directories +inside the repository layout. As convenction, inside the repository +layout, file names are all written in lowercase +(`01-welcome.png', `splash.png', `anaconda_header.png', +etc.) and directory names are all written capitalized (e.g., +`Identity', `Themes', `Motifs', `TreeFlower', +etc.). +
+Repository name convenctions are implemented inside the
+cli_getRepoName function of `centos-art.sh' script. With
+cli_getRepoName function we reduce the amount of commands and
+convenctions you need to remember concentrating them in just one
+single place you can look for fixes and improvements.
+
Repository work flow describes the steps and time intervals used to +produce CentOS corporate visual identity inside CentOS Artwork +Repository. +
+To illustrate repository work flow let's consider themes' development +cycle. +
+Initially, we start working themes on their trunk development line +(e.g., `trunk/Identity/Themes/Motifs/TreeFlower/'), here we +design background images and propagate them to different visual +manifestations using one theme's model as reference. +
+Later, when the theme is considered "ready" for implementation (i.e. +all visual manifestations have been already set), we create a branch +for it (e.g., `branches/Identity/Themes/Motifs/TreeFlower/1/'). +Once the branch has been created, we forget that branch and continue +working the trunk development line while others (e.g., an artwork +quality assurance team) test the new branch for tunning it up. +
+Once the branch has been tunned up, and considered "ready" for +release, it is freezed under `tags/' directory (e.g., +`tags/Identity/Themes/Motifs/TreeFower/1.0/') for packagers, +webmasters, promoters, and anyone who needs images from that CentOS +theme the tag was created for. +
+Both branches and tags, inside CentOS Artwork Repository, use +numerical values to identify themselves under the same location. +Branches start at one (i.e., `1') and increment one unit for each +branch created from the same trunk development line. Tags start at +zero (i.e., `0') and increment one unit for each tag created from +the same branch development line. +
+Figure 3.11: Name convention for tags and branches creation. + +
+As proposition, it would be convenient not to freeze trunk development +lines using tags or anything else. If you think you need to freeze a +trunk development line, create a branch for it and then freeze that +branch instead. +
+The trunk development line may introduce problems we cannot see +immediatly. Certainly, the high changable nature of trunk development +line complicates finding and fixing such problems. On the other hand, +the branched development lines provides a less changable area where +only small fixes/corrections are commited up to repository. +
+If others find and fix bugs inside the branched development line, we +could merge such changes/experiences back to trunk development line +(not visversa) in order for future branches, created from trunk, to +benefit. +
+Time intervals used to create branches and tags may vary, just as +different needs may arrive. For example, consider the release schema +of CentOS distribution: one major release every 2 years, security +updates every 6 months, support for 7 years long. Each time a CentOS +distribution is released, specially if it is a major release, there is +a theme need in order to cover CentOS distribution artwork +requirements. At this point, is where CentOS Artwork Repository comes +up to scene. +
+Before releasing a new major release of CentOS distribution you can +create a branch for one of several theme development lines available +inside the CentOS Artwork Repository, perform quality assurance on it, +and later, freeze that branch using tags. Once a the theme branch has +been frozen (under `tags/' directory), CentOS Packagers (the +persons who build CentOS distribution) can use that frozen branch as +source location to fulfill CentOS distribution artwork needs. +
+ + +Inside CentOS Artwork Repository, parallel directories are simple +directory entries built from a common parent directory and placed in a +location different to that, the common parent directory is placed on. +Parallel directories are useful to create branches, tags, +translations, documentation, pre-rendering configuration script, and +similar directory structures. +
+Parallel directories take their structure from one unique parent +directory. Inside CentOS Artwork Repository, this unique parent +directory is under `trunk/Identity' location. The +`trunk/Identity' location must be considered the reference for +whatever information you plan to create inside the repository. +
+In some circumstances, parallel directories may be created removing
+uncommon information from their paths. Uncommon path information
+refers to those directory levels in the path which are not common for
+other parallel directories. For example, when rendering
+`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory
+structure, the `centos-art.sh' script removes the
+`Motifs/TreeFlower/' directory levels from path, in order to
+build the parallel directory used to retrived translations, and
+pre-rendering configuration scripts required by render
+functionality.
+
Another example where parallel directory removes the uncommon path
+information is when we use the help functionality. This time,
+`centos-art.sh' script uses parallel directory information
+(without uncommon directory levels) to build the documentation entry
+required by Texinfo to store documentation entries inside the
+repository.
+
Figure 3.12: Parallel directories removing uncommon information. + +
+Othertimes, parallel directories may add uncommon information to their +paths. This is the case we use to create branches and tags. When we +create branches and tags, a numerical identifier is added to parallel +directory structure path. The place where the numerical identifier is +set on is relevant to corporate visual identity structure and should +be carefully considered where it will be. +
+Figure 3.13: Parallel directories adding uncommon information. + +
+When one parent directory changes, all their related parallel +directories need to be changed too. This is required in order for +parallel directories to match the new parent directory structure. In +the other hand, parallel directories should never be modified by no +reason but to satisfy their parent directory structure. Liberal change +of parallel directories may suppress the conceptual idea they were +initially created for. +
+Figure 3.14: Wrong construction of parallel directories. + +
+ + +Creating parallel directories is very useful to keep repository
+organized. But, what would happen to functionalities like help
+(WARNING: The `trunk Scripts Bash Functions Help' documentation entry no longer exists.) that rely on parent
+directory structures to create documentation entries (using parallel
+directory structures) if one of those parent directory structures
+suddenly changes after the documentation entry has been already
+created for it?
+
Well, at this point, functionalities like help may confuse
+themselves if path information is not updated. Such functionalities
+work with parent directory structure as reference; if a parent
+directory changes, the functionalities dont't even note it because
+they work with the last parent directory structure available in the
+repository, no matter what it is.
+
In the specific case of documentation (the help functionality),
+the problem mentioned above provokes that older parent directories,
+already documented, remain inside documentation directory structures
+as long as you get your hands into the documentation directory
+structure (`trunk/Manuals') and remove what must be removed to
+match the new parent directory structure.
+
There is no way for help, and similar functionalities that use
+parent directories as reference, to know when and how directory
+movements take place inside the repository. Such information is
+available only when movement actions, like thoses achived by
+rm or mv commands, take place inside the
+repository. So, is there, at the moment of moving files, when we need
+to syncronize parallel directories with their unique parent directory
+structure.
+
Syncronizing parallel directories with their respecitive parent +directory implies moving files inside the repository, i.e. we need to, +firstly, rebuild the path information for each parallel directory +inside the repository, using the current path of its parent directory +as reference, and later, use the new path information to move each old +parallel directory from its old location to its new location based on +an updated path information. +
+As CentOS Artwork Repository is built over a version control system, +file movements inside the repository are considered repository +changes. In order for these repository changes to be versioned, we +need to, firstly, add changes related files into version control +system, and later, use commands from the version control system to +move those files already versioned. This configuration makes possible +for everyone to know about changes details inside the repository; and +if needed, revert or update them back to a previous revision. +
+Finally, once all file corrections have been already made, the +syncronization action takes care of updating path references inside +related files. Updating path references inside related files is +specially important for documentation files where documentation nodes +are built using repository path information as reference. +
+ +Occasionly, you may find that new corporate visual identity components +need to be added to the repository. If that is your case, the first +question you need to ask yourself, before start to create directories +blindly all over, is: What is the right location to store it? +
+The CentOS Community (http://wiki.centos.org/GettingHelp) is the +best place to find answers to your question, but going there with +hands empty is not good idea. It may give the impression you don't +really care about. Instead, consider the following suggestions to find +your own comprehension and so, make your propositions based on it. +
+When looking the correct place to store new files, to bear in mind the +corporate visual identity structure used inside the CentOS Artwork +Repository (see section trunk/Identity) would be probaly the best advice +we could offer to you, the rest is just matter of choosing appropriate +names. To illustrate this desition process let's consider the +`trunk/Identity/Themes/Motifs/TreeFlower/Distro/' directory as +example. It is the main development line of CentOS distribution visual +manifestation, using TreeFlower's artistic motif, inside themes of +CentOS corporate visual identity. +
+When building parent directory structures, you may find that reaching +an acceptable location may take some time, and as it happens most of +time, when you find it, that may be not a definite solution. There are +many concepts that you need to play with, in order to find a result +that match the conceptual idea you try to implement in the new +directory location. To know which these concepts are, split the +location in words and read its documentation entry from less specific +to more specific. +
+For example, the +`trunk/Identity/Themes/Motifs/TreeFlower/Distro/' location +evolved through several months of contant work and there is no certain +it won't change in the future, even it fixes quite well the concept we +are trying to implement. The concepts used in +`trunk/Identity/Themes/Distro/Motifs/TreeFlower/Distro/' location +are described in the following commands, respectively: +
+centos-art help --read=turnk/ +centos-art help --read=turnk/Identity/ +centos-art help --read=turnk/Identity/Themes/ +centos-art help --read=turnk/Identity/Themes/Motifs/ +centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/ +centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/Distro/ ++
Other location concepts can be found similary as we did above, just +change the location we used above by the one you are trying to know +concepts for. +
centos-art path --copy=SRC --to=DSTUse this command to duplicate `SRC' in working copy, +remembering history. In this command, `SRC' and +`DST' can each be either a working copy (WC) path or +URL: +
+Copy and schedule for addition (with history). +
+Immediately commit a copy of WC to URL. +
+Check out URL into WC, schedule for addition. +
+Complete server-side copy; used to branch and tag. +
This command is an interface for Subversion's copy command.
+Options related to Subversion's copy command can be passed
+from third argument on. For example to specify a log message use the
+`--message' option as follow:
+
centos-art path --copy=URL/SRC --to=URL/DST --message 'Copy url/src to url/dst' ++
For more information on Subversion's copy functionality,
+run the command: svn help copy | less.
+
centos-art path --move=SRC --to=DSTMove and/or rename something in working copy or repository. In this +command, SRC and DST can both be working copy (WC) paths or URLs: +
+Move and schedule for addition (with history). +
Complete server-side rename. +
This command is an interface for Subversion's move command.
+Options related to Subversion's move command can be passed
+from third argument on. For example to specify a log message use the
+`--message' option as follow:
+
centos-art path --move=URL/SRC --to=URL/DST --message 'Move url/src to url/dst' ++
For more information on Subversion's move functionality,
+run the command: svn help move | less.
+
centos-art path --delete='SRC'Use this command to remove files and directories from version control. +In this command, `SRC' can be a working copy (WC) path or URL. +
+Each item specified by a PATH is scheduled for deletion upon the next +commit. Files, and directories that have not been committed, are +immediately removed from the working copy. PATHs that are, or +contain, unversioned or modified items will not be removed unless the +`--force' option is given. +
+Each item specified by a URL is deleted from the repository via an +immediate commit. +
This command is an interface for Subversion's delete
+command. Options related to Subversion's delete can be
+passed from third argument on. For example to specify a log message
+use the `--message' as follow:
+
centos-art path --delete='URL' --message 'Delete url.' ++
For more information on Subversion's delete functionality,
+run the command: svn help delete | less.
+
centos-art path --sync='SRC'Use this command to syncronize path information inside working copy. +This command is automatically used after moving or renaming parent +directories. In this command, `SRC' is a working copy path +inside `trunk/Identity/' location, considered the parent +directory you want to syncronize path information for. +
| 3.43 trunk/Scripts/Bash/Functions/Render/Config | + | |
| 3.36 trunk/Scripts/Bash | + | |
| 3.37 trunk/Scripts/Bash/Functions |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_46.html b/Manuals/en/Html/Repository/repository_46.html
index 9f748fe..702944a 100644
--- a/Manuals/en/Html/Repository/repository_46.html
+++ b/Manuals/en/Html/Repository/repository_46.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
The `trunk/Scripts/Bash/Config' directory exists to oraganize -pre-rendering configuration scripts. -
+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. -
- - -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. -
- - -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. -
- - -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
See section trunk/Scripts/Bash/Functions/Render, to know more -about possible values for `BASE', `POST' and `LAST' -action definitions. -
To specify the `LAST' action, you need to set the `LAST:' -string followed by the function name of the action you want to -perform. For example, consider the following example if you want to -render all files first and organize them later: -
-ACTIONS[0]='BASE:renderImage' -ACTIONS[1]='POST:renderFormats: xpm jpg tif' -ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' -- +
Use the following commands to administer both identity and translation -pre-rendering configuration scripts: -
-Use this command to create `path/to/dir' related pre-rendering -configuration script. -
-Use this command to edit `path/to/dir' related pre-rendering -configuration script. -
-Use this command to read `path/to/dir' related pre-rendering -configuration script. -
-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.36 trunk/Scripts/Bash | - | |
| 3.37 trunk/Scripts/Bash/Functions | - | |
| 3.42 trunk/Scripts/Bash/Functions/Render | + | |
| 3.44 trunk/Scripts/Bash/Functions/Render/Config |
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_47.html b/Manuals/en/Html/Repository/repository_47.html
index b3e8e34..80c9853 100644
--- a/Manuals/en/Html/Repository/repository_47.html
+++ b/Manuals/en/Html/Repository/repository_47.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
This section exists to organize files related to shell
-functionality of `centos-art.sh' script.
+
The `trunk/Scripts/Bash/Config' directory exists to oraganize +pre-rendering configuration scripts.
- +The shell functionality of `centos-art.sh' script helps
-you to maintain bash scripts inside repository. For example, suppose
-you've created many functionalities for `centos-art.sh' script,
-and you want to use a common copyright and license note for
-consistency in all your script files. If you have a bunch of files,
-doing this one by one wouldn't be a big deal. In contrast, if the
-amount of files grows, updating the copyright and license note for all
-of them would be a task rather tedious. The shell functionality
-exists to solve maintainance tasks just as the one previously
-mentioned.
+
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. +
+ + +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.
-When you use shell functionality to update copyright inside
-script files, it is required that your script files contain (at least)
-the following top commentary structure:
+
Inside identity pre-rendering configuration scripts, image-based +pre-rendering configuration scripts look like the following:
- 1| #!/bin/bash
- 2| #
- 3| # doSomething.sh -- The function description goes here.
- 4| #
- 5| # Copyright
- 6| #
- 7| # ...
- 8| #
- 9| # ----------------------------------------------------------------------
-10| # $Id$
-11| # ----------------------------------------------------------------------
-12|
-13| function doSomething {
-14|
-15| }
+#!/bin/bash
+
+function render_loadConfig {
+
+ # Define rendering actions.
+ ACTIONS[0]='BASE:renderImage'
+ ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
+
+}
-Relevant lines in the above structure are lines from 5 to 9.
-Everything else in the file is left immutable.
+
Inside identity pre-rendering configuration scripts, text-based
+pre-rendering configuration scripts look like the following:
-When you are updating copyright through shell
-functionality, the `centos-art.sh' script replaces everything
-in-between line 5 --the first one matching `^# Copyright .+$'
-string-- and line 9--the first long dash separator matching `^#
--+$'-- with the content of copyright template instance.
+
#!/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.
-
Caution
Be sure to add the long dash separator that matches
-`^# -+$' regular expression before the function
-definition. Otherwise, if the `Copyright' line is present but no
-long dash separator exists, `centos-art.sh' will remove anything
-in-between the `Copyright' line and the end of file. This way you
-may lost your function definitions entirely.
-
-The copyright template instance is created from one copyright template
-stored in the `Config/tpl_forCopyright.sed' file. The template
-instance is created once, and later removed when no longer needed. At
-this moment, when template instance is created, the
-`centos-art.sh' script takes advantage of automation in order to
-set copyright full name and date dynamically.
+
+
3.44.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.
-When you use shell functionality to update copyright, the first
-thing `shell' functionality does is requesting copyright
-information to user, and later, if values were left empty (i.e., no
-value was typed before pressing RET key), the `shell'
-functionality uses its own default values.
+
+
+
3.44.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.
-When shell functionality uses its own default values, the final
-copyright note looks like the following:
+
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:
- 1| #!/bin/bash
- 2| #
- 3| # doSomthing.sh -- The function description goes here.
- 4| #
- 5| # Copyright (C) 2003, 2010 The CentOS Project
- 6| #
- 7| # This program is free software; you can redistribute it and/or modify
- 8| # it under the terms of the GNU General Public License as published by
- 9| # the Free Software Foundation; either version 2 of the License, or
-10| # (at your option) any later version.
-11| #
-12| # This program is distributed in the hope that it will be useful, but
-13| # WITHOUT ANY WARRANTY; without even the implied warranty of
-14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-15| # General Public License for more details.
-16| #
-17| # You should have received a copy of the GNU General Public License
-18| # along with this program; if not, write to the Free Software
-19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-20| # USA.
-21| #
-22| # ----------------------------------------------------------------------
-23| # $Id$
-24| # ----------------------------------------------------------------------
-25|
-26| function doSomething {
-27|
-28| }
+ACTIONS[0]='BASE:renderImage'
-Relevant lines in the above structure are lines from 5 to 22. Pay
-attention how the copyright line was built, and how the license was
-added into the top comment where previously was just three dots.
-Everything else in the file was left immutable.
+
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.
-To change copyright information (i.e., full name or year information),
-run the shell functionality over the root directory containing
-the script files you want to update copyright in and enter the
-appropriate information when it be requested. You can run the
-shell functionality as many times as you need to.
+
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 change copyright license (i.e., the text in-between lines 7 and
-20), you need to edit the `Config/tpl_forCopyright.sed' file, set
-the appropriate information, and run the shell functionality
-once again for changes to take effect over the files you specify.
+
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:
-
Important
The `centos-art.sh' script is released as:
+
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:
-GNU GENERAL PUBLIC LICENSE
-Version 2, June 1991
-
-Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-Do not change the license information under which `centos-art.sh'
-script is released. Instead, if you think a different license must be
-used, please share your reasons at CentOS Developers mailing list.
+
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
See section trunk/Scripts/Bash/Functions/Render, to know more
+about possible values for `BASE', `POST' and `LAST'
+action definitions.
+To specify the `LAST' action, you need to set the `LAST:'
+string followed by the function name of the action you want to
+perform. For example, consider the following example if you want to
+render all files first and organize them later:
+
+ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
+
3.44.3 Usage
+Use the following commands to administer both identity and translation
+pre-rendering configuration scripts:
+
--
centos-art sh --update-copyright='path/to/dir'
--
centos-art sh --update-copyright='path/to/dir' --filter='regex'
-Use these commands to update copyright information in `.sh' files
-under `path/to/dir' directory.
-
-
-When you provide `--filter='regex'' argument, the list of files
-to process is reduced as specified in `regex' regular expression.
-Inside `centos-art.sh' script, the `regex' regular
-expression is used in combination with find command to look
-for files matching the regular expression path pattern.
+
`centos-art config --create='path/to/dir/''
+
+Use this command to create `path/to/dir' related pre-rendering
+configuration script.
-
Warning
In order for `regex' regular expression to match
-a file, the `regex' regular expresion must match the whole file
-path not just the file name.
-
-
-For example, if you want to match all `render.conf.sh' files
-inside `path/to/dir', use the .+/render.conf regular
-expression. Later, `centos-art.sh' script uses this value inside
-^$REGEX\.sh$ expression in order to build the final regular
-expression (i.e., ^.+/render.conf\.sh$) that is evaluated
-against available file paths inside the list of files to process.
+
+ `centos-art config --edit='path/to/dir/''
+
+Use this command to edit `path/to/dir' related pre-rendering
+configuration script.
+
+
+ `centos-art config --read='path/to/dir/''
+
+Use this command to read `path/to/dir' related pre-rendering
+configuration script.
-Exceptionally, when you provide `--filter='regex'' in the way
-that `regex', appended to `path/to/dir/' (i.e.
-`path/to/dir/regex'), matches a regular file; the
-`centos-art.sh' script uses the file matching as only file in the
-list of files to process.
+
+ `centos-art config --remove='path/to/dir/''
+
+Use this command to remove `path/to/dir' related pre-rendering
+configuration script.
+
+
+
+
+In the commands above, `path/to/dir' refers to one renderable
+directory path under `trunk/Identity' or
+`trunk/Translations' structures only.
@@ -256,6 +274,8 @@ list of files to process.
3.37 trunk/Scripts/Bash/Functions
3.43 trunk/Scripts/Bash/Functions/Render
+ [ > ]
[ << ]
-[ Up ]
-[ >> ]
+[ Up ]
+[ >> ]
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_48.html b/Manuals/en/Html/Repository/repository_48.html
index 7983358..64c52b1 100644
--- a/Manuals/en/Html/Repository/repository_48.html
+++ b/Manuals/en/Html/Repository/repository_48.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
-CentOS Artwork Repository: 3.45 trunk/Scripts/Bash/Functions/Svg
+CentOS Artwork Repository: 3.45 trunk/Scripts/Bash/Functions/Shell
-
-
+
+
@@ -64,201 +64,162 @@ ul.toc {list-style: none}
[ << ]
[ Up ]
-[ >> ]
+[ >> ]
[Top]
[Contents]
-[Index]
+[Index]
[ ? ]
-
+
- 3.45 trunk/Scripts/Bash/Functions/Svg
+ 3.45 trunk/Scripts/Bash/Functions/Shell
3.45.1 Goals
-This section exists to organize files related to svg
+
This section exists to organize files related to shell
functionality of `centos-art.sh' script.
3.45.2 Description
-The svg functionality of `centos-art.sh' script helps you
-to maintain scalable vector graphics (SVG) inside repository. For
-example, suppose you've been working in CentOS default design models
-under `trunk/Identity/Themes/Models/', and you want to set common
-metadata to all of them, and later remove all unused SVG defintions
-from `*.svg' files. Doing so file by file may be a tedious task,
-so the `centos-art.sh' script provides the svg
-functionality to aid you maintain such actions.
+
The shell functionality of `centos-art.sh' script helps
+you to maintain bash scripts inside repository. For example, suppose
+you've created many functionalities for `centos-art.sh' script,
+and you want to use a common copyright and license note for
+consistency in all your script files. If you have a bunch of files,
+doing this one by one wouldn't be a big deal. In contrast, if the
+amount of files grows, updating the copyright and license note for all
+of them would be a task rather tedious. The shell functionality
+exists to solve maintainance tasks just as the one previously
+mentioned.
-
-
-
- 3.45.2.1 Metadata maintainance
-
-The metadata used is defined by Inkscape 0.46 using the SVG standard
-markup. The `centos-art.sh' script replaces everything
-in-between <metadata and </metadata> tags with a
-predefined metadata template we've set for this purpose.
-
-The metadata template was created using the metadata information of a
-file which, using Inkscape 0.46, all metadata fields were set. This
-created a complete markup representation of how SVG metadata would
-look like. Later, we replaced every single static value with a
-translation marker in the form `=SOMETEXT=', where
-SOMETEXT is the name of its main opening tag. Later, we
-transform the metadata template into a sed replacement set of commads
-escaping new lines at the end of each line.
+
When you use shell functionality to update copyright inside
+script files, it is required that your script files contain (at least)
+the following top commentary structure:
-With metadata template in place, the `centos-art.sh' script uses
-it to create a metadata template instance for the file being processed
-currently. The metadata template instance contains the metadata
-portion of sed replacement commands with translation markers already
-traduced. In this action, instance creation, is where we take
-advantage of automation and generate metadata values like title, date,
-keywords, source, identifier, and relation dynamically, based on the
-file path `centos-art.sh' script is currently creating metadata
-information for.
+
1| #!/bin/bash
+ 2| #
+ 3| # doSomething.sh -- The function description goes here.
+ 4| #
+ 5| # Copyright
+ 6| #
+ 7| # ...
+ 8| #
+ 9| # ----------------------------------------------------------------------
+10| # $Id$
+11| # ----------------------------------------------------------------------
+12|
+13| function doSomething {
+14|
+15| }
+
+Relevant lines in the above structure are lines from 5 to 9.
+Everything else in the file is left immutable.
-With metadata template instance in place, the `centos-art.sh'
-script uses it to replace real values inside all `.svg' files
-under the current location you're running the `centos-art.sh'
-script on. Default behaviour is to ask user to enter each metadatum
-required, one by one. If user leaves metadatum empty, by pressing
-RET key, `centos-art.sh' uses its default value.
-
-The `centos-art.sh' script modifies the following metadata:
-
-
-- `Title'
-Name by which this document is formally known. If no value is set
-here, `centos-art.sh' script uses the file name as title.
+
When you are updating copyright through shell
+functionality, the `centos-art.sh' script replaces everything
+in-between line 5 --the first one matching `^# Copyright .+$'
+string-- and line 9--the first long dash separator matching `^#
+-+$'-- with the content of copyright template instance.
-- `Date'
-Date associated with the creation of this document (YYYY-MM-DD). If no
-value is set here, `centos-art.sh' script uses the current date
-information as in date +%Y-%m-%d.
-
-- `Creator'
-Name of entity primarily responsible for making the content of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
-
-- `Rights'
-Name of entity with rights to the intellectual Property of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
-
-- `Publisher'
-Name of entity responsible for making this document available. If no
-value is set here, `centos-art.sh' script uses the string
-`The CentOS Project'.
-
-- `Identifier'
-Unique URI to reference this document. If no value is set here,
-`centos-art.sh' script uses the current file path to build the
-related url that points to current file location inside repository
-central server.
-
-- `Source'
-Unique URI to reference the source of this document. If no value is
-set here, `centos-art.sh' script uses current file path to build
-the related url that points to current file location inside repository
-central server.
+
Caution
Be sure to add the long dash separator that matches
+`^# -+$' regular expression before the function
+definition. Otherwise, if the `Copyright' line is present but no
+long dash separator exists, `centos-art.sh' will remove anything
+in-between the `Copyright' line and the end of file. This way you
+may lost your function definitions entirely.
+
+
+The copyright template instance is created from one copyright template
+stored in the `Config/tpl_forCopyright.sed' file. The template
+instance is created once, and later removed when no longer needed. At
+this moment, when template instance is created, the
+`centos-art.sh' script takes advantage of automation in order to
+set copyright full name and date dynamically.
-- `Relation'
-Unique URI to a related document. If no value is set here,
-`centos-art.sh' script uses current file path to build the
-related url that points to current file location inside repository
-central server.
+
When you use shell functionality to update copyright, the first
+thing `shell' functionality does is requesting copyright
+information to user, and later, if values were left empty (i.e., no
+value was typed before pressing RET key), the `shell'
+functionality uses its own default values.
-- `Language'
-Two-letter language tag with optional subtags for the language of this
-document. (e.g. `en-GB'). If no value is set here,
-`centos-art.sh' script uses the current locale information as in
-cli_getCurrentLocale function.
+
When shell functionality uses its own default values, the final
+copyright note looks like the following:
-- `Keywords'
-The topic of this document as comma-separated key words, prhases, or
-classifications. If no value is set here, `centos-art.sh' script
-uses file path to build
+
1| #!/bin/bash
+ 2| #
+ 3| # doSomthing.sh -- The function description goes here.
+ 4| #
+ 5| # Copyright (C) 2003, 2010 The CentOS Project
+ 6| #
+ 7| # This program is free software; you can redistribute it and/or modify
+ 8| # it under the terms of the GNU General Public License as published by
+ 9| # the Free Software Foundation; either version 2 of the License, or
+10| # (at your option) any later version.
+11| #
+12| # This program is distributed in the hope that it will be useful, but
+13| # WITHOUT ANY WARRANTY; without even the implied warranty of
+14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+15| # General Public License for more details.
+16| #
+17| # You should have received a copy of the GNU General Public License
+18| # along with this program; if not, write to the Free Software
+19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+20| # USA.
+21| #
+22| # ----------------------------------------------------------------------
+23| # $Id$
+24| # ----------------------------------------------------------------------
+25|
+26| function doSomething {
+27|
+28| }
+
+Relevant lines in the above structure are lines from 5 to 22. Pay
+attention how the copyright line was built, and how the license was
+added into the top comment where previously was just three dots.
+Everything else in the file was left immutable.
-- `Coverage'
-Extent or scope of this document. If no value is set here,
-`centos-art.sh' script uses the string `The CentOS Project'.
+
To change copyright information (i.e., full name or year information),
+run the shell functionality over the root directory containing
+the script files you want to update copyright in and enter the
+appropriate information when it be requested. You can run the
+shell functionality as many times as you need to.
-- `Description'
-Description about the document. If no value is set here,
-`centos-art.sh' script uses uses empty value as default.
+
To change copyright license (i.e., the text in-between lines 7 and
+20), you need to edit the `Config/tpl_forCopyright.sed' file, set
+the appropriate information, and run the shell functionality
+once again for changes to take effect over the files you specify.
-- `Contributors'
-People that contributes in the creation/maintainance of the document.
-If no value is set here, `centos-art.sh' script uses uses empty
-value as default.
-
-
-The `License' metadatum is not set as a choise, by now. It is
-fixed Creative Common Attribution Share-Alike 3.0 License. This is done in order to
-grant license consistency among all SVG files we manage inside CentOS
-Artwork Repository.
+
Important
The `centos-art.sh' script is released as:
-
+GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991
-
- 3.45.2.2 Unused definitions
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+Do not change the license information under which `centos-art.sh'
+script is released. Instead, if you think a different license must be
+used, please share your reasons at CentOS Developers mailing list.
+
-As SVG files grow they may end up with unused definitions inside. For
-example, if you stop using a pattern or gradient, tags used to define
-them are considered unused definitions then. Inkscape 0.46 brings the
-`Vaccum Defs' feature to remove those unused definitions from SVG
-files. The `Vaccum Defs' feature is available both at graphical
-interface and command line interface.
-
-If you have one or two couple of files, removing unused SVG
-definitions using graphical interface may be enough to you. In
-contrast, if you have houndred of files to maintain it is not a fun
-task to use the gui interface to remove unused SVG definitions editing
-those files one by one.
-
-To remove unused SVG definitions from several SVG files, the
-`centos-art.sh' script uses Inkscape's command-line interface,
-specifically with the `--vaccum-defs' option.
-
-
+
3.45.3 Usage
--
centos-art svg --update-metadata='path/to/dir'
--
centos-art svg --update-metadata='path/to/dir' --filter='regex'
-Use these commands to update metadata information to `.svg' files
-under `path/to/dir' directory.
-
--
centos-art svg --vacuum-defs='path/to/dir'
--
centos-art svg --vacuum-defs='path/to/dir' --filter='regex'
-Use these commands to remove unused definitions inside `.svg'
-files under `path/to/dir' directory.
+
-
centos-art sh --update-copyright='path/to/dir'
+-
centos-art sh --update-copyright='path/to/dir' --filter='regex'
+Use these commands to update copyright information in `.sh' files
+under `path/to/dir' directory.
@@ -273,12 +234,12 @@ a file, the `regex' regular expresion must match the whole file
path not just the file name.
-For example, if you want to match all `summary.svg' files inside
-`path/to/dir', use the .+/summary regular expression.
-Later, `centos-art.sh' script uses this value inside
-^$REGEX\.svg$ expression in order to build the final regular
-expression (i.e., ^.+/summary\.svg$) that is evaluated against
-available file paths inside the list of files to process.
+
For example, if you want to match all `render.conf.sh' files
+inside `path/to/dir', use the .+/render.conf regular
+expression. Later, `centos-art.sh' script uses this value inside
+^$REGEX\.sh$ expression in order to build the final regular
+expression (i.e., ^.+/render.conf\.sh$) that is evaluated
+against available file paths inside the list of files to process.
Exceptionally, when you provide `--filter='regex'' in the way
that `regex', appended to `path/to/dir/' (i.e.
@@ -287,7 +248,7 @@ that `regex', appended to `path/to/dir/' (i.e.
list of files to process.
-
+
3.45.4 See also
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_49.html b/Manuals/en/Html/Repository/repository_49.html
index c1b7e10..beeec95 100644
--- a/Manuals/en/Html/Repository/repository_49.html
+++ b/Manuals/en/Html/Repository/repository_49.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
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. +
This section exists to organize files related to svg
+functionality of `centos-art.sh' script.
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.
+
The svg functionality of `centos-art.sh' script helps you
+to maintain scalable vector graphics (SVG) inside repository. For
+example, suppose you've been working in CentOS default design models
+under `trunk/Identity/Themes/Models/', and you want to set common
+metadata to all of them, and later remove all unused SVG defintions
+from `*.svg' files. Doing so file by file may be a tedious task,
+so the `centos-art.sh' script provides the svg
+functionality to aid you maintain such actions.
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.
+
The metadata used is defined by Inkscape 0.46 using the SVG standard
+markup. The `centos-art.sh' script replaces everything
+in-between <metadata and </metadata> tags with a
+predefined metadata template we've set for this purpose.
- -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.
+
The metadata template was created using the metadata information of a
+file which, using Inkscape 0.46, all metadata fields were set. This
+created a complete markup representation of how SVG metadata would
+look like. Later, we replaced every single static value with a
+translation marker in the form `=SOMETEXT=', where
+SOMETEXT is the name of its main opening tag. Later, we
+transform the metadata template into a sed replacement set of commads
+escaping new lines at the end of each line.
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.
+
With metadata template in place, the `centos-art.sh' script uses +it to create a metadata template instance for the file being processed +currently. The metadata template instance contains the metadata +portion of sed replacement commands with translation markers already +traduced. In this action, instance creation, is where we take +advantage of automation and generate metadata values like title, date, +keywords, source, identifier, and relation dynamically, based on the +file path `centos-art.sh' script is currently creating metadata +information for.
- - -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. +
With metadata template instance in place, the `centos-art.sh' +script uses it to replace real values inside all `.svg' files +under the current location you're running the `centos-art.sh' +script on. Default behaviour is to ask user to enter each metadatum +required, one by one. If user leaves metadatum empty, by pressing +RET key, `centos-art.sh' uses its default value.
-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--. +
The `centos-art.sh' script modifies the following metadata:
-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.
+
Name by which this document is formally known. If no value is set +here, `centos-art.sh' script uses the file name as title.
- - -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. +
Date associated with the creation of this document (YYYY-MM-DD). If no
+value is set here, `centos-art.sh' script uses the current date
+information as in date +%Y-%m-%d.
The `verify' functionality of `centos-art.sh' script -evaluates the following environment variables: +
Name of entity primarily responsible for making the content of this +document. If no value is set here, `centos-art.sh' script uses +the string `The CentOS Project'.
-EDITORDefault text editor. +
Name of entity with rights to the intellectual Property of this +document. If no value is set here, `centos-art.sh' script uses +the string `The CentOS Project'.
-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.
+
Name of entity responsible for making this document available. If no +value is set here, `centos-art.sh' script uses the string +`The CentOS Project'.
-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:
+
Unique URI to reference this document. If no value is set here, +`centos-art.sh' script uses the current file path to build the +related url that points to current file location inside repository +central server.
-If no one of these values is set in EDITOR environment variable,
-`centos-art.sh' uses `/usr/bin/vim' text editor by default.
+
Unique URI to reference the source of this document. If no value is +set here, `centos-art.sh' script uses current file path to build +the related url that points to current file location inside repository +central server.
TZDefault time zone representation. +
Unique URI to a related document. If no value is set here, +`centos-art.sh' script uses current file path to build the +related url that points to current file location inside repository +central server.
-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. +
Two-letter language tag with optional subtags for the language of this
+document. (e.g. `en-GB'). If no value is set here,
+`centos-art.sh' script uses the current locale information as in
+cli_getCurrentLocale function.
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. +
The topic of this document as comma-separated key words, prhases, or +classifications. If no value is set here, `centos-art.sh' script +uses file path to build
-- -Tip
Coordinated Univeral Time (UTC) representation can be -configured when you install CentOS distribution; or later, runing the -
system-config-datecommand 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
TZenvironment 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. -
TEXTDOMAINDefault domain used to retrieve translated messages. This value is -set in `initFunctions.sh' and shouldn't be changed. +
Extent or scope of this document. If no value is set here, +`centos-art.sh' script uses the string `The CentOS Project'.
TEXTDOMAINDIRDefault directory used to retrieve translated messages. This value is -set in `initFunctions.sh' and shouldn't be changed. +
Description about the document. If no value is set here, +`centos-art.sh' script uses uses empty value as default.
LANGDefault locale information. This value is set when you start your -session and can be changed using the `locale' functionality of -`centos-art.sh' script (see section trunk/Scripts/Bash/Functions/Locale, for more information). +
People that contributes in the creation/maintainance of the document. +If no value is set here, `centos-art.sh' script uses uses empty +value as default.
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.
+
The `License' metadatum is not set as a choise, by now. It is +fixed Creative Common Attribution Share-Alike 3.0 License. This is done in order to +grant license consistency among all SVG files we manage inside CentOS +Artwork Repository.
-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. + + + +
As SVG files grow they may end up with unused definitions inside. For +example, if you stop using a pattern or gradient, tags used to define +them are considered unused definitions then. Inkscape 0.46 brings the +`Vaccum Defs' feature to remove those unused definitions from SVG +files. The `Vaccum Defs' feature is available both at graphical +interface and command line interface.
-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.
+
If you have one or two couple of files, removing unused SVG +definitions using graphical interface may be enough to you. In +contrast, if you have houndred of files to maintain it is not a fun +task to use the gui interface to remove unused SVG definitions editing +those files one by one.
-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. +
To remove unused SVG definitions from several SVG files, the +`centos-art.sh' script uses Inkscape's command-line interface, +specifically with the `--vaccum-defs' option.
-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 svg --update-metadata='path/to/dir'centos-art svg --update-metadata='path/to/dir' --filter='regex'Use these commands to update metadata information to `.svg' files +under `path/to/dir' directory.
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. +
centos-art svg --vacuum-defs='path/to/dir'centos-art svg --vacuum-defs='path/to/dir' --filter='regex'Use these commands to remove unused definitions inside `.svg' +files under `path/to/dir' directory.
When you provide `--filter='regex'' argument, the list of files
+to process is reduced as specified in `regex' regular expression.
+Inside `centos-art.sh' script, the `regex' regular
+expression is used in combination with find command to look
+for files matching the regular expression path pattern.
+
+ +Warning
In order for `regex' regular expression to match +a file, the `regex' regular expresion must match the whole file +path not just the file name. +
For example, if you want to match all `summary.svg' files inside
+`path/to/dir', use the .+/summary regular expression.
+Later, `centos-art.sh' script uses this value inside
+^$REGEX\.svg$ expression in order to build the final regular
+expression (i.e., ^.+/summary\.svg$) that is evaluated against
+available file paths inside the list of files to process.
+
Exceptionally, when you provide `--filter='regex'' in the way +that `regex', appended to `path/to/dir/' (i.e. +`path/to/dir/regex'), matches a regular file; the +`centos-art.sh' script uses the file matching as only file in the +list of files to process. +
- +| [ < ] | -[ > ] | +||||||
| [ < ] | +[ > ] | [ << ] | -[ Up ] | -[ >> ] | +[ Up ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_5.html b/Manuals/en/Html/Repository/repository_5.html
index 8a1ddd8..845f661 100644
--- a/Manuals/en/Html/Repository/repository_5.html
+++ b/Manuals/en/Html/Repository/repository_5.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
This section exists to organize files related to `centos-art.sh' +script `verify' functionality. The `verify' +functionality of `centos-art.sh' script helps you to verify the +workstation configuration you are planning to use as host for your +working copy of CentOS Artwork Repository. +
+ + +The 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.
+
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.
+
This section exists to organize translation messages and templates -used by `centos-art.sh' script. +
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.
Translated messages of `centos-art.sh' script are managed using
-GNU gettext utilities. Most translation actions have been
-automated through `centos-art.sh' script "locale" functionality
-(see section trunk/Scripts/Bash/Functions/Locale).
+
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: +
+EDITORDefault 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:
+
If no one of these values is set in EDITOR environment variable,
+`centos-art.sh' uses `/usr/bin/vim' text editor by default.
+
TZDefault 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-datecommand 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
TZenvironment 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. +
TEXTDOMAINDefault domain used to retrieve translated messages. This value is +set in `initFunctions.sh' and shouldn't be changed. +
+TEXTDOMAINDIRDefault directory used to retrieve translated messages. This value is +set in `initFunctions.sh' and shouldn't be changed. +
+LANGDefault locale information. This value is set when you start your +session and can be changed using the `locale' functionality of +`centos-art.sh' script (see section trunk/Scripts/Bash/Functions/Locale, for more information). +
The content of `trunk/Scripts/Bash/Locale' directory should not -be managed manually. Instead, use the "locale" functionality of -`centos-art.sh' script. See section trunk/Scripts/Bash/Functions/Locale, for more information on how to use `centos-art.sh' -"locale" functionality. +
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. +
+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. +
+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.37 trunk/Scripts/Bash/Functions | + | |
| 3.36 trunk/Scripts/Bash | ||
| 3.35 trunk/Scripts | + | |
| 3.37 trunk/Scripts/Bash/Functions |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_51.html b/Manuals/en/Html/Repository/repository_51.html
index e2c014c..1c58256 100644
--- a/Manuals/en/Html/Repository/repository_51.html
+++ b/Manuals/en/Html/Repository/repository_51.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
This section exists to organize translation messages and templates +used by `centos-art.sh' script. +
Translated messages of `centos-art.sh' script are managed using
+GNU gettext utilities. Most translation actions have been
+automated through `centos-art.sh' script "locale" functionality
+(see section trunk/Scripts/Bash/Functions/Locale).
+
The content of `trunk/Scripts/Bash/Locale' directory should not +be managed manually. Instead, use the "locale" functionality of +`centos-art.sh' script. See section trunk/Scripts/Bash/Functions/Locale, for more information on how to use `centos-art.sh' +"locale" functionality. +
| 3.37 trunk/Scripts/Bash/Functions | + | |
| 3.35 trunk/Scripts | + |
| [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_52.html b/Manuals/en/Html/Repository/repository_52.html
index 9392e0f..27b7285 100644
--- a/Manuals/en/Html/Repository/repository_52.html
+++ b/Manuals/en/Html/Repository/repository_52.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_53.html b/Manuals/en/Html/Repository/repository_53.html
index 1882f8a..26f81fe 100644
--- a/Manuals/en/Html/Repository/repository_53.html
+++ b/Manuals/en/Html/Repository/repository_53.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
The `trunk/Translations' directory exists to: -
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: -
In order to aliviate maintainance of artwork production for such -environment, we divided artwork production in three production lines: -
-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". -
-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). -
- - -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.
-
Figure 3.15: The image rendering flow. - -
-Translation markers can be whatever text you want, but as convenction -we use the following to represent releases of CentOS distribution: -
-Replace with minor release of CentOS distribution. In the schema M.N, the minor -release is represented by the N letter. -
Replace with major release of CentOS distribution. In the schema M.N, -the major release is represented by the M letter. -
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. -
- - -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 (see section trunk/Identity/Themes/Models) and artistic -motifs (see section trunk/Identity/Themes/Motifs). -
Assuming that both theme models and theme motifs are ready for using, -the initial translation entry to produce Firstboot artworks would look -like the following: -
-trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/ -|-- Tpl -| `-- splash-small.sed -`-- firstboot-left.sed --
With the translation entry above, centos-art command is able
-to produce the image `firstboot-left.png' only. To produce
-`splash-small.png' images for major releases (e.g., 3, 4, 5, and
-6) of CentOS distribution we need to produce the release-specific
-translation files using the centos-art script as following:
-
centos-art render --entry=/home/centos/artwork/trunk/Translations/Identity/Themes/BootUp/Firstboot --filter='3,4,5,6' --
The above command produces the following translation entiry: -
-trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/ -|-- 3 -| `-- splash-small.sed -|-- 4 -| `-- splash-small.sed -|-- 5 -| `-- splash-small.sed -|-- 6 -| `-- splash-small.sed -|-- Tpl -| `-- splash-small.sed -`-- firstboot-left.sed --
At this point centos-art is able to produce the Firstboot
-artwork images for major releases of CentOS distribution. To add new
-release-specific translation files, run the translation rendering
-command with the release number you want to produce translation files
-for in the `--filter='release-number'' argument.
-
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 insed'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. -
- - -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. -- - -
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 -- - -
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.
-
When the centos-art script finds a translation template
-directory inside translation entry, it looks for translations
-pre-rendering configuration scripts for that translation entry.
-Translation pre-rendering configuration scripts let you extend
-translation's default functionality (described below).
-
Translation pre-rendering configuration scripts are stored under
-`trunk/Scripts' directory, specifically under the appropriate
-language implementation. If you are using centos-art Bash's
-implementation, the translation pre-rendering scripts are store in the
-`trunk/Scripts/Bash/Config' location; if you are using
-centos-art Python's implementation, then translation
-pre-rendering scripts are stored in the
-`trunk/Scripts/Python/Config' location, and so on for other
-implementations.
-
Bash's translation pre-rendering configuration scripts look like the -following: -
-
-
-#!/bin/bash
-#
-# render_loadConfig.sh -- brief description here.
-#
-# Copyright (C) YEAR YOURNAME
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-# USA.
-#
-# ----------------------------------------------------------------------
-# $Id: render_loadConfig.sh 94 2010-09-18 10:59:42Z al $
-# ----------------------------------------------------------------------
-
-function render_loadConfig {
-...
-}
-
-Translation pre-rendering scripts are function scripts loaded and
-executed when rendering a translation entry. Translation pre-rendering
-scripts are loaded using the translation entry being rendered as
-reference. For example, suppose you are using the
-centos-art Bash's implementation, and you are rendering
-translations for CentOS brands, in this situation the translation
-entry would be:
-
trunk/Translations/Identity/Brands --
and the entry inside the translation pre-rendering configuration -structure would be: -
-trunk/Scripts/Bash/Config/Identity/Brands --
Once the centos-art script detects that translation
-pre-rendering configuration directory exists, the centos-art
-script looks for the translation pre-rendering configuration file. If
-the translation pre-rendering configuration file exists, it is loaded
-and executed. Once the translation pre-rendering configuration file
-has been executed the translation rendering process is over, and so
-the script execution.
-
- -Note
Translation pre-rendering configuration files have the -following form: -
render.conf.extension -where `extension' refers the programming language implementation -you are using. For example, `sh' for Bash's, `py' for -Python's, `pl' for Perl's, and so on for other implementations. -
As we are using Bash implementation to describe the translation
-pre-rendering configuration example, the translation pre-rendering
-configuration file that centos-art looks for, inside the
-above translation pre-rendering configuration directory, is
-`render.conf.sh'.
-
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-artscript using predifined release -translation markers. Release translation markers are described in the -translation marker section -(see Translation Markers). -
When `path/to/dir' refers one directory under -`trunk/Translations', this command orverwrites available -translation files using translation templates. -
-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. -
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_54.html b/Manuals/en/Html/Repository/repository_54.html
index 6138aad..5267cc7 100644
--- a/Manuals/en/Html/Repository/repository_54.html
+++ b/Manuals/en/Html/Repository/repository_54.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
The `trunk/Translations' directory exists to: +
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: +
In order to aliviate maintainance of artwork production for such +environment, we divided artwork production in three production lines: +
+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". +
+ + +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). +
+ + +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.
+
Figure 3.15: The image rendering flow. + +
+Translation markers can be whatever text you want, but as convenction +we use the following to represent releases of CentOS distribution: +
+Replace with minor release of CentOS distribution. In the schema M.N, the minor +release is represented by the N letter. +
Replace with major release of CentOS distribution. In the schema M.N, +the major release is represented by the M letter. +
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. +
+ + +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 (see section trunk/Identity/Themes/Models) and artistic +motifs (see section trunk/Identity/Themes/Motifs). +
Assuming that both theme models and theme motifs are ready for using, +the initial translation entry to produce Firstboot artworks would look +like the following: +
+trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/ +|-- Tpl +| `-- splash-small.sed +`-- firstboot-left.sed ++
With the translation entry above, centos-art command is able
+to produce the image `firstboot-left.png' only. To produce
+`splash-small.png' images for major releases (e.g., 3, 4, 5, and
+6) of CentOS distribution we need to produce the release-specific
+translation files using the centos-art script as following:
+
centos-art render --entry=/home/centos/artwork/trunk/Translations/Identity/Themes/BootUp/Firstboot --filter='3,4,5,6' ++
The above command produces the following translation entiry: +
+trunk/Translations/Identity/Themes/Distro/BootUp/Firstboot/ +|-- 3 +| `-- splash-small.sed +|-- 4 +| `-- splash-small.sed +|-- 5 +| `-- splash-small.sed +|-- 6 +| `-- splash-small.sed +|-- Tpl +| `-- splash-small.sed +`-- firstboot-left.sed ++
At this point centos-art is able to produce the Firstboot
+artwork images for major releases of CentOS distribution. To add new
+release-specific translation files, run the translation rendering
+command with the release number you want to produce translation files
+for in the `--filter='release-number'' argument.
+
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 insed'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. +
+ + +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. ++ + +
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 ++ + +
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.
+
When the centos-art script finds a translation template
+directory inside translation entry, it looks for translations
+pre-rendering configuration scripts for that translation entry.
+Translation pre-rendering configuration scripts let you extend
+translation's default functionality (described below).
+
Translation pre-rendering configuration scripts are stored under
+`trunk/Scripts' directory, specifically under the appropriate
+language implementation. If you are using centos-art Bash's
+implementation, the translation pre-rendering scripts are store in the
+`trunk/Scripts/Bash/Config' location; if you are using
+centos-art Python's implementation, then translation
+pre-rendering scripts are stored in the
+`trunk/Scripts/Python/Config' location, and so on for other
+implementations.
+
Bash's translation pre-rendering configuration scripts look like the +following: +
+#!/bin/bash
+#
+# render_loadConfig.sh -- brief description here.
+#
+# Copyright (C) YEAR YOURNAME
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+# USA.
+#
+# ----------------------------------------------------------------------
+# $Id: render_loadConfig.sh 94 2010-09-18 10:59:42Z al $
+# ----------------------------------------------------------------------
+
+function render_loadConfig {
+...
+}
+
+Translation pre-rendering scripts are function scripts loaded and
+executed when rendering a translation entry. Translation pre-rendering
+scripts are loaded using the translation entry being rendered as
+reference. For example, suppose you are using the
+centos-art Bash's implementation, and you are rendering
+translations for CentOS brands, in this situation the translation
+entry would be:
+
trunk/Translations/Identity/Brands ++
and the entry inside the translation pre-rendering configuration +structure would be: +
+trunk/Scripts/Bash/Config/Identity/Brands ++
Once the centos-art script detects that translation
+pre-rendering configuration directory exists, the centos-art
+script looks for the translation pre-rendering configuration file. If
+the translation pre-rendering configuration file exists, it is loaded
+and executed. Once the translation pre-rendering configuration file
+has been executed the translation rendering process is over, and so
+the script execution.
+
+ +Note
Translation pre-rendering configuration files have the +following form: +
render.conf.extension +where `extension' refers the programming language implementation +you are using. For example, `sh' for Bash's, `py' for +Python's, `pl' for Perl's, and so on for other implementations. +
As we are using Bash implementation to describe the translation
+pre-rendering configuration example, the translation pre-rendering
+configuration file that centos-art looks for, inside the
+above translation pre-rendering configuration directory, is
+`render.conf.sh'.
+
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-artscript using predifined release +translation markers. Release translation markers are described in the +translation marker section +(see Translation Markers). +
When `path/to/dir' refers one directory under +`trunk/Translations', this command orverwrites available +translation files using translation templates. +
+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. +
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_55.html b/Manuals/en/Html/Repository/repository_55.html
index bd5f58a..651ab5b 100644
--- a/Manuals/en/Html/Repository/repository_55.html
+++ b/Manuals/en/Html/Repository/repository_55.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
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: -
- - -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. -
- - -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. -
- - -Inside `trunk/Translations/Identity/Brands/', translation files -combine the following translation markers: -
-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. -
To render brands' translation files, use the following command: -
-centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands -+
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_56.html b/Manuals/en/Html/Repository/repository_56.html
index 9b7b698..4c1d148 100644
--- a/Manuals/en/Html/Repository/repository_56.html
+++ b/Manuals/en/Html/Repository/repository_56.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
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: +
+ + +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. +
+ + +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. +
+ + +Inside `trunk/Translations/Identity/Brands/', translation files +combine the following translation markers: +
+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. +
To render brands' translation files, use the following command: +
+centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands +
| 3.54 trunk/Translations/Identity/Brands/Tpl | + | |
| 3.2 trunk/Identity/Brands | + |
| [ > ] | [ << ] | -[ Up ] | -[ >> ] | +[ Up ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_57.html b/Manuals/en/Html/Repository/repository_57.html
index 2c1fdff..a25f1c2 100644
--- a/Manuals/en/Html/Repository/repository_57.html
+++ b/Manuals/en/Html/Repository/repository_57.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
This section exists to organize fonts translation files. -
+Translation files, inside `trunk/Translations/Fonts', have the -following structure: -
-s!font-family:Denmark!font-family:DejaVu LGC Sans! -s!font-weight:normal!font-weight:bold! -s!font-style:normal!font-style:italic! --
Inside `trunk/Translations/Fonts', there is one translation file -for each font preview image you want to produce. This way, we create -one translation file for each font-family we use somewhere inside -CentOS visual identity. -
-- -Important
Do not create translation files for font-families -not used somewhere inside CentOS visual identity. The font's identity -entry (see section trunk/Identity/Fonts) is used as reference when someone -needs to know which font-families are allowed to use inside CentOS -visual identity. -
Inside `trunk/Translations/Identity/Fonts', translation files -combine the following translation markers: -
-Specify which font family to use when rendering font preview images. -
Specify which font weight to use when rendering font preview images. -
Specify which font style to use when rendering font preview images. -
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.3 trunk/Identity/Fonts | - |
| [ < ] | -[ > ] | +|||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_58.html b/Manuals/en/Html/Repository/repository_58.html
index ce36bba..2110675 100644
--- a/Manuals/en/Html/Repository/repository_58.html
+++ b/Manuals/en/Html/Repository/repository_58.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +||||||||||||||
| [ < ] | +[ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
This section exists to organize fonts translation files. +
+ +Translation files, inside `trunk/Translations/Fonts', have the +following structure: +
+s!font-family:Denmark!font-family:DejaVu LGC Sans! +s!font-weight:normal!font-weight:bold! +s!font-style:normal!font-style:italic! ++
Inside `trunk/Translations/Fonts', there is one translation file +for each font preview image you want to produce. This way, we create +one translation file for each font-family we use somewhere inside +CentOS visual identity. +
++ -Important
Do not create translation files for font-families +not used somewhere inside CentOS visual identity. The font's identity +entry (see section trunk/Identity/Fonts) is used as reference when someone +needs to know which font-families are allowed to use inside CentOS +visual identity. +
Inside `trunk/Translations/Identity/Fonts', translation files +combine the following translation markers: +
+Specify which font family to use when rendering font preview images. +
Specify which font weight to use when rendering font preview images. +
Specify which font style to use when rendering font preview images. +
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.3 trunk/Identity/Fonts | + |
| [ > ] | [ << ] | -[ Up ] | -[ >> ] | +[ Up ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_59.html b/Manuals/en/Html/Repository/repository_59.html
index 2f96943..b081183 100644
--- a/Manuals/en/Html/Repository/repository_59.html
+++ b/Manuals/en/Html/Repository/repository_59.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_6.html b/Manuals/en/Html/Repository/repository_6.html
index cc96a46..09a99a8 100644
--- a/Manuals/en/Html/Repository/repository_6.html
+++ b/Manuals/en/Html/Repository/repository_6.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
-
+
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_61.html b/Manuals/en/Html/Repository/repository_61.html
index 296fc82..9727656 100644
--- a/Manuals/en/Html/Repository/repository_61.html
+++ b/Manuals/en/Html/Repository/repository_61.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_62.html b/Manuals/en/Html/Repository/repository_62.html
index e18bc2f..4a574ac 100644
--- a/Manuals/en/Html/Repository/repository_62.html
+++ b/Manuals/en/Html/Repository/repository_62.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
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. -
Translation rendering is described in `trunk/Translations' -documentation entry (see section trunk/Translations). -
+| [ < ] | [ > ] | [ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_63.html b/Manuals/en/Html/Repository/repository_63.html
index 1a46474..462c5cc 100644
--- a/Manuals/en/Html/Repository/repository_63.html
+++ b/Manuals/en/Html/Repository/repository_63.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
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. +
Translation rendering is described in `trunk/Translations' +documentation entry (see section trunk/Translations). +
| 3.60 trunk/Translations/Identity/Widgets | - |
| [ < ] | @@ -121,11 +182,11 @@ ul.toc {list-style: none}[ << ] | [ Up ] | -[ >> ] | +[ >> ] |
- This document was generated on December, 4 2010 using texi2html 1.76.
+ This document was generated on December, 5 2010 using texi2html 1.76.
diff --git a/Manuals/en/Html/Repository/repository_64.html b/Manuals/en/Html/Repository/repository_64.html
index 169c4bd..89132ec 100644
--- a/Manuals/en/Html/Repository/repository_64.html
+++ b/Manuals/en/Html/Repository/repository_64.html
@@ -16,7 +16,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled GNU Free
Documentation License.
-->
-
+
| [ < ] | -[ > ] | +[ > ] | [ << ] | -[ Up ] | -[ >> ] | +[ Up ] | +[ >> ] | [Top] | [Contents] | -[Index] | +[Index] | [ ? ] |
| Jump to: | B - -C - -H - -M - -S - -T - -U - - |
|---|