diff --git a/Identity/Manual/Directories/trunk/Identity/Themes.texi b/Identity/Manual/Directories/trunk/Identity/Themes.texi index 00bb0bf..2084221 100644 --- a/Identity/Manual/Directories/trunk/Identity/Themes.texi +++ b/Identity/Manual/Directories/trunk/Identity/Themes.texi @@ -5,6 +5,71 @@ production of CentOS themes. @subsection Description +@subsubsection Work Flow + +Initially, we start working themes on their trunk development line +(e.g., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we +organize information that cannot be produced automatically (i.e., +background images, concepts, color information, screenshots, etc.). + +Later, when theme trunk development line is considered ``ready'' for +implementation (e.g., all required backgrounds have been designed), +we create a branch for it (e.g., +@file{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 @file{tags/} directory (e.g., +@file{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., @samp{1}) and increment one unit for each +branch created from the same trunk development line. Tags start at +zero (i.e., @samp{0}) and increment one unit for each tag created from +the same branch development line. + +@quotation +@strong{Convenction} Do not freeze trunk development lines using tags +directly. If you think you need to freeze a trunk development line, +create a branch for it and then freeze that branch instead. +@end quotation + +The trunk development line may introduce problems we cannot see +immediatly. Certainly, the high changable nature of trunk development +line complicates finding and fixing such problems. On the other hand, +the branched development lines provide a more predictable area where +only fixes/corrections to current content are commited up to +repository. + +If others find and fix bugs inside the branched development line, we +could merge such changes/experiences back to trunk development line +(not visversa) in order for future branches, created from trunk, to +benefit. + +Time intervals used to create branches and tags may vary, just as +different needs may arrive. For example, consider the release schema +of CentOS distribution: one major release every 2 years, security +updates every 6 months, support for 7 years long. Each time a CentOS +distribution is released, specially if it is a major release, there is +a theme need in order to cover CentOS distribution artwork +requirements. At this point, is where CentOS Artwork Repository comes +up to scene. + +Before releasing a new major release of CentOS distribution we create +a branch for one of several theme development lines available inside +the CentOS Artwork Repository, perform quality assurance on it, and +later, freeze that branch using tags. Once a the theme branch has been +frozen (under @file{tags/} directory), CentOS Packagers (the persons +whom build CentOS distribution) can use that frozen branch as source +location to fulfill CentOS distribution artwork needs. The same +applies to CentOS Webmasters (the persons whom build CentOS websites), +and any other visual manifestation required by the project. + @subsection Usage In this location themes are organized in ``Models'' ---to store common diff --git a/Identity/Manual/Introduction/chapter-menu.texi b/Identity/Manual/Introduction/chapter-menu.texi index e60794c..8bff50a 100644 --- a/Identity/Manual/Introduction/chapter-menu.texi +++ b/Identity/Manual/Introduction/chapter-menu.texi @@ -3,5 +3,6 @@ * Authors:: * Copying Conditions:: * Convenctions:: +* Layout:: * Feedback:: @end menu diff --git a/Identity/Manual/Introduction/chapter-nodes.texi b/Identity/Manual/Introduction/chapter-nodes.texi index f143dcf..0938433 100644 --- a/Identity/Manual/Introduction/chapter-nodes.texi +++ b/Identity/Manual/Introduction/chapter-nodes.texi @@ -18,6 +18,11 @@ @cindex Document convenctions @include Introduction/convenctions.texi +@node Layout +@section Repository Layout +@cindex Repository layout +@include Introduction/layout.texi + @node Feedback @section Send in Your Feedback @cindex Feedback diff --git a/Identity/Manual/Introduction/copying.texi b/Identity/Manual/Introduction/copying.texi index 797ea2c..50057bb 100755 --- a/Identity/Manual/Introduction/copying.texi +++ b/Identity/Manual/Introduction/copying.texi @@ -19,7 +19,7 @@ specific organization of files is part of @command{centos-art.sh} script, a bash script that automates most of the frequent tasks inside the repository. -@subsection The @command{centos-art.sh} script +@subheading The @command{centos-art.sh} script The @command{centos-art.sh} script and the organization of files it needs to work are not in the public domain; they are copyrighted and diff --git a/Identity/Manual/Introduction/layout.texi b/Identity/Manual/Introduction/layout.texi new file mode 100644 index 0000000..8e22ade --- /dev/null +++ b/Identity/Manual/Introduction/layout.texi @@ -0,0 +1,329 @@ +@emph{''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.''} + +This section describes the organization of files and directories +inside the CentOS Artwork 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 you may expect from them to do. + +As convenction, inside CentOS Artwork Repository, files and +directories related to CentOS corporate visual identity are organized +under three top level directories named: @file{trunk/}, +@file{branches/}, and @file{tags/}. + +The @file{trunk/} directory (@pxref{Directories trunk}) organizes the main +development line of CentOS corporate visual identity. Inside +@file{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 +@file{trunk/} directory structure is mainly used to perform +development tasks related to CentOS corporate visual identity. + +The @file{branches/} directory (@pxref{Directories branches}) oranizes +parallel development lines to @file{trunk/} directory. The +@file{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 @file{branches/} directory is mainly used to perform +quality assurance tasks related to CentOS corporate visual identity. + +The @file{tags/} directory (@pxref{Directories tags}) organizes parallel frozen +lines to @file{branches/} directory. The parallel frozen lines are +immutable, nothing change inside them once they has been created. The +@file{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 (@url{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. + +@subsection Repository file names + +Repository name convenctions are applied to files and directories +inside the repository layout. As convenction, file names are all +written in lowercase (@samp{01-welcome.png}, @samp{splash.png}, +@samp{anaconda_header.png}, etc.) and directory names are all written +capitalized (e.g., @samp{Identity}, @samp{Themes}, @samp{Motifs}, +@samp{TreeFlower}, etc.). + +Repository name convenctions are implemented inside the +@code{cli_getRepoName} function of @file{centos-art.sh} script. With +@code{cli_getRepoName} function the amount of commands and +convenctions to remember are reduced and concentrated in just one +single place to look for fixes and improvements. + +@subsection Repository work flow + +As repository work flow we understand a serie of normalized steps used +to produce contents inside CentOS Artwork Repository. There are two +relevant components inside the repository that we need to normalize +work flow for, they are: @emph{content rendition}, @emph{content +localization} and @emph{programming}. + +@subsubsection Content rendition + +The CentOS Project Corporate Identity, in part, is made of several +visual manifestations. These visual manifestations implement the +Corporate Identity by means of images placed in key visible areas of +each manifestation visual space. As work flow to produce these images, +we decompose images in design models and artistic motifs. Design +models provide the image structure (i.e., dimension, translation +markers, common designs, etc.) and artistic motifs the visual style +(i.e., the background information provide the look and feel). + +Design models are created for each visual manifestation the CentOS +Project is made of. This way we describe the visual manifestation and +provide a template system for it where several artistic motifs can be +applied. Artistic motifs are created with design models in mind, not +the visual manifestation such design models are applied to. + +The combination of both design models and artistic motifs is what we +know as @emph{Theme}. Themes let us create several design models and +several background images apart one another that can be later combined +albitrarily one another to provide a flexible way of producing images +for different visual manifestations. + +In addition to themes, you can find another way of image production, a +more direct way of image production where there is no artistic motif +at all, but design models only. This configuration is useful to +produce content that don't need specific background information like +icons and illustrations used in documentation. + +@subsubsection Content localization + +Whatever content rendition you perform, sometimes you need to produce +the content in different languages. Production of content in different +languages is known as localization or l10n for short. Inside CentOS +Artwork Repository, content localization is performed using the +@command{gettext} standard internationalization process as base. + +Basically, the @command{gettext} standard internationalization process +consists on retriving translatable strings from source files and +create Portable Objects and Machine Objects. Portable Objects contain +the information translators used to do their work, it is file that can +be edited by any convenctional text editor like Vim, Emacs or Nano. On +the other hand, Machine Objects are produced to be machine-redable as +its name implies, and are produced from Portable Objects. + +Since @command{gettext} needs to extract translatable strings form +source files in order to let translators to localize them, the types +of source files we use inside the repository are limitted to the file +types supported by @command{gettext} program. Most of source files +supported by @command{gettext} are those from programming languages +like C, C++, Bash, Python and Perl just to mention a few from the long +list of supported formats. However, formats like SVG, XHTML and +Docbook don't figure as supported in the long list of +@command{gettext} supported source files. For these formats we use the +@command{xml2po} program that come in @file{gnome-doc-utils} package +instead. The @command{xml2po} program reads one XML based file and +extracts translatable strings from it and creates one Portable Object +that is use to create a translated XML based file with the same +definition of the source file translatable strings were taken from +(e.g., if we extract translatable strings from a SVG file, as result +we get the same SVG file but with translatable strings already +localized ---obviously, for this to happen translators need to +localize translatable strings inside the Portable Object first, +localization don't appear as art of magic---). When using +@command{xml2po}, the Machine Object file is used just temporally to +produce the final translated XML based file. + +@quotation +@strong{Tip} If you want to have your content localized inside CentOS +Artwork Repository be sure to use source files supported by +@command{gettext} and @command{xml2po} programs. +@end quotation + +@subsubsection Programming + +So far, we've seen a conceptual view of how image production inside +CentOS Artwork Repository is performed, but how all this is +implemented, what is the practical view? + +The practical view can be found through @command{centos-art.sh} +script, a bash script specially designed to automate most frequent +tasks inside CentOS Artwork Repository. The @command{centos-art.sh} +script is stored in @file{trunk/Scripts} directory structure and is +there where the main development for @command{centos-art.sh} script +takes place. Basically, the @command{centos-art.sh} script is divided +in several functionalities that perform specific tasks inside the +repository. Such functionalities relay on repository organization to +work as expected. + +Maiking the @command{centos-art.sh} script to automate tasks is the +only possible work flow that I can think about right now. If you are a +programmer, take a functionality from @command{centos-art.sh} script, +study it, look how to improve it and share your ideas at +@email{centos-devel@@centos.org} mailing list. + +@quotation +@strong{Note} As default configuration, everyone is denied from +committing changes up to CentOS Artwork Repository. In order to gain +commit rights, you need to prove your interest in contributing and +maintaining that contribution. Otherwise, if you only want to comment +your ideas, the @email{centos-devel@@centos.org} mailing list exists +for you to manifest yourself. This restrictions are necessary to +protect our work from spammers. +@end quotation + +@subsection Parallel directories + +Inside CentOS Artwork Repository, parallel directories are simple +directory entries built from a common parent directory and placed in a +location different to that, the common parent directory is placed on. +Parallel directories are useful to create branches, tags, +translations, documentation, pre-rendering configuration script, and +similar directory structures. + +Parallel directories take their structure from one unique parent +directory. Inside CentOS Artwork Repository, this unique parent +directory is under @file{trunk/Identity} location. The +@file{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 +@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory +structure, the @file{centos-art.sh} script removes the +@file{Motifs/TreeFlower/} directory levels from path, in order to +build the parallel directory used to retrived translations, and +pre-rendering configuration scripts required by @code{render} +functionality. + +Another example of parallel directory is the documentation structure +created by @code{manual} functionality. This time, +@file{centos-art.sh} script uses parallel directory information with +uncommon directory levels to build the documentation entry required by +Texinfo documentation system, inside the repository. + +Othertimes, parallel directories may add uncommon information to their +paths. This is the case we use to create branches and tags. When we +create branches and tags, a numerical identifier is added to parallel +directory structure path. The place where the numerical identifier is +set on is relevant to corporate visual identity structure and should +be carefully considered where it will be. + +When one parent directory changes, all their related parallel +directories need to be changed too. This is required in order for +parallel directories to retain their relation with the parent +directory structure. In the other hand, parallel directories should +never be modified under no reason but to satisfy the relation to their +parent directory structure. Liberal change of parallel directories +may suppresses the conceptual idea they were initially created for; +and certainly, things may stop working the way they should do. + +@subsection Syncronizing path information + +Parallel directories are very useful to keep repository organized but +introduce some complications. For instance, consider what would +happen to functionalities like @code{manual} (@samp{trunk Scripts Bash +Functions Manual}) that rely on parent directory structures to create +documentation entries (using parallel directory structures) if one of +those parent directory structures suddenly changes after the +documentation entry has been already created for it? + +In such cases, functionalities like @code{manual} may confuse +themselves if path information is not updated to reflect the relation +with its parent directory. Such functionalities work with parent +directory structure as reference; if a parent directory changes, the +functionalities dont't even note it because they work with the last +parent directory structure available in the repository, no matter what +it is. + +In the specific case of documentation (the @code{manual} +functionality), the problem mentioned above provokes that older parent +directories, already documented, remain inside documentation directory +structures as long as you get your hands into the documentation +directory structure (@file{trunk/Manuals}) and change what must be +changed to match the new parent directory structure. + +There is no immediate way for @code{manual}, and similar +functionalities that use parent directories as reference, to know when +and how directory movements take place inside the repository. Such +information is available only when the file movement itself takes +place inside the repository. So, is there, at the moment of moving +files, when we need to syncronize parallel directories with their +unique parent directory structure. + +@quotation +@strong{Warning} There is not support for URL reference inside +@file{centos-art.sh} script. The @file{centos-art.sh} script is +designed to work with local files inside the working copy only. +@end quotation + +As CentOS Artwork Repository is built over a version control system, +file movements inside the repository are considered repository +changes. In order for these repository changes to be versioned, we +need to, firstly, add changes into the version control system, commit +them, and later, perform movement actions using version control system +commands. This configuration makes possible for everyone to know about +changes details inside the repository; and if needed, revert or update +them back to a previous revision. + +Finally, once all path information has been corrected, it is time to +take care of information inside the files. For instance, considere +what would happen if you make a reference to a documentation node, and +later the documentation node you refere to is deleted. That would make +Texinfo to produce error messages at export time. So, the +@file{centos-art.sh} script needs to know when such changes happen, in +a way they could be noted and handled without producing errors. + +@subsection What is the right place to store it? + +Occasionly, you may find that new corporate visual identity components +need to be added to the repository. If that is your case, the first +question you need to ask yourself, before start to create directories +blindly all over, is: What is the right place to store it? + +The CentOS Community different free support vains (see: +@url{http://wiki.centos.org/GettingHelp}) are the best place to find +answers to your question, but going there with hands empty is not good +idea. It may give the impression you don't really care about. Instead, +consider the following suggestions to find your own comprehension and +so, make your propositions based on it. + +When we are looking for the correct place to store new files, to bear +in mind the corporate visual identity structure used inside the CentOS +Artwork Repository (@pxref{Directories trunk Identity}) would be probaly the best +advice we could offer, the rest is just matter of choosing appropriate +names. To illustrate this desition process let's consider the +@file{trunk/Identity/Themes/Motifs/TreeFlower} directory as example. +It is the trunk development line of @emph{TreeFlower} artistic motif. +Artistic motifs are considered part of themes, which in turn are +considered part of CentOS corporate visual identity. + +When building parent directory structures, you may find that reaching +an acceptable location may take some time, and as it uses to happen +most of time; once you've find it, that may be not a definite +solution. There are many concepts that you need to play with, in +order to find a result that match the conceptual idea you try to +implement in the new directory location. To know which these concepts +are, split the location in words and read its documentation entry from +less specific to more specific. + +For example, the @file{trunk/Identity/Themes/Motifs/TreeFlower} +location evolved through several months of contant work and there is +no certain it won't change in the future, even it fixes quite well the +concept we are trying to implement. The concepts used in +@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} location are +described in the following commands, respectively: + +@verbatim +centos-art manual --read=turnk/ +centos-art manual --read=turnk/Identity/ +centos-art manual --read=turnk/Identity/Themes/ +centos-art manual --read=turnk/Identity/Themes/Motifs/ +centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ +@end verbatim + +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. diff --git a/Identity/Manual/repository.css b/Identity/Manual/repository.css index e0a60f3..3fa45d1 100755 --- a/Identity/Manual/repository.css +++ b/Identity/Manual/repository.css @@ -45,3 +45,9 @@ div#content table tr th { div#content pre.example { padding: 0.5em 1em; } + +div#content p img { + margin: 5px; + padding: 5px; + border: 1px solid #DADADA; + } diff --git a/Identity/Manual/repository.info.bz2 b/Identity/Manual/repository.info.bz2 index 6267462..d61d666 100644 Binary files a/Identity/Manual/repository.info.bz2 and b/Identity/Manual/repository.info.bz2 differ diff --git a/Identity/Manual/repository.pdf b/Identity/Manual/repository.pdf index 5afac2d..a0a7855 100644 Binary files a/Identity/Manual/repository.pdf and b/Identity/Manual/repository.pdf differ diff --git a/Identity/Manual/repository.txt.bz2 b/Identity/Manual/repository.txt.bz2 index 9a05f5f..c891d05 100644 Binary files a/Identity/Manual/repository.txt.bz2 and b/Identity/Manual/repository.txt.bz2 differ diff --git a/Identity/Manual/repository.xhtml.tar.bz2 b/Identity/Manual/repository.xhtml.tar.bz2 index 21aa9ab..e466134 100644 Binary files a/Identity/Manual/repository.xhtml.tar.bz2 and b/Identity/Manual/repository.xhtml.tar.bz2 differ diff --git a/Identity/Manual/repository.xml b/Identity/Manual/repository.xml index 5cdd775..b0218d0 100644 --- a/Identity/Manual/repository.xml +++ b/Identity/Manual/repository.xml @@ -98,6 +98,11 @@ + Layout + Layout + + + Feedback Feedback @@ -197,20 +202,17 @@ Copying conditionsInside the CentOS Artwork Repository you can find content branded by The CentOS Project and content not branded at all. Contents branded by The CentOS Project contain either The CentOS Trademark, The CentOS Logo or The CentOS Symbol. Content branded by The CentOS Project cannot be redistributed without previous conversation with The CentOS Project. However, you can study and modify both content branded by The CentOS Project and content not branded at all in the sake of proposing improvements to The CentOS Project corporate visual identity. If you are using the CentOS Artwork Repository for producing your own corporate visual identity, you should remove all The CentOS Trademarks from your contents and rename the repository to something other than CentOS Artwork Repository. The CentOS Artwork Repository organizes files in a very specific way to implement The CentOS Project corporate visual identity. This very specific organization of files is part of centos-art.sh script, a bash script that automates most of the frequent tasks inside the repository. - - - The <command>centos-art.sh</command> script - The centos-art.sh script and the organization of files it needs to work are not in the public domain; they are copyrighted and there are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of this program that they might get from you. - Specifically, we want to make sure that you have the right to give away copies of centos-art.sh script, that you receive source code or else can get it if you want it, that you can change this program or use pieces of it in new free programs, and that you know you can do these things. - To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of the centos-art.sh script, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. - Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the centos-art.sh script. If this program is modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. - The precise conditions of the license for the centos-art.sh script are found in the General Public Licenses that accompany it (see file file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING). This manual specifically is covered by the GNU Free Documentation License. - + The centos-art.sh script + The centos-art.sh script and the organization of files it needs to work are not in the public domain; they are copyrighted and there are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of this program that they might get from you. + Specifically, we want to make sure that you have the right to give away copies of centos-art.sh script, that you receive source code or else can get it if you want it, that you can change this program or use pieces of it in new free programs, and that you know you can do these things. + To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of the centos-art.sh script, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. + Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the centos-art.sh script. If this program is modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. + The precise conditions of the license for the centos-art.sh script are found in the General Public Licenses that accompany it (see file file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING). This manual specifically is covered by the GNU Free Documentation License. Convenctions - Feedback + Layout Copying Conditions Introduction
@@ -288,10 +290,105 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh
- Feedback + Layout + Feedback Convenctions Introduction
+ Repository Layout + Repository layout”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.” + This section describes the organization of files and directories inside the CentOS Artwork 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 you may expect from them to do. + As convenction, inside CentOS Artwork Repository, files and directories related to CentOS corporate visual identity are organized under three top level directories named: trunk/, branches/, and tags/. + The trunk/ directory (see Directories trunk) organizes the main development line of CentOS corporate visual identity. Inside trunk/ directory structure, the CentOS corporate visual identity concepts are implemented using directories. There is one directory level for each relevant concept inside the repository. The trunk/ directory structure is mainly used to perform development tasks related to CentOS corporate visual identity. + The branches/ directory (see Directories branches) oranizes parallel development lines to trunk/ directory. The branches/ directory is used to set points in time where develpment lines are devided one from another taking separte and idependent lives that share a common past from the point they were devided on. The branches/ directory is mainly used to perform quality assurance tasks related to CentOS corporate visual identity. + The tags/ directory (see Directories 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 file names + Repository name convenctions are applied to files and directories inside the repository layout. As convenction, 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 the amount of commands and convenctions to remember are reduced and concentrated in just one single place to look for fixes and improvements. + + + + Repository work flow + As repository work flow we understand a serie of normalized steps used to produce contents inside CentOS Artwork Repository. There are two relevant components inside the repository that we need to normalize work flow for, they are: content rendition, content localization and programming. + + + Content rendition + The CentOS Project Corporate Identity, in part, is made of several visual manifestations. These visual manifestations implement the Corporate Identity by means of images placed in key visible areas of each manifestation visual space. As work flow to produce these images, we decompose images in design models and artistic motifs. Design models provide the image structure (i.e., dimension, translation markers, common designs, etc.) and artistic motifs the visual style (i.e., the background information provide the look and feel). + Design models are created for each visual manifestation the CentOS Project is made of. This way we describe the visual manifestation and provide a template system for it where several artistic motifs can be applied. Artistic motifs are created with design models in mind, not the visual manifestation such design models are applied to. + The combination of both design models and artistic motifs is what we know as Theme. Themes let us create several design models and several background images apart one another that can be later combined albitrarily one another to provide a flexible way of producing images for different visual manifestations. + In addition to themes, you can find another way of image production, a more direct way of image production where there is no artistic motif at all, but design models only. This configuration is useful to produce content that don't need specific background information like icons and illustrations used in documentation. + + + + Content localization + Whatever content rendition you perform, sometimes you need to produce the content in different languages. Production of content in different languages is known as localization or l10n for short. Inside CentOS Artwork Repository, content localization is performed using the gettext standard internationalization process as base. + Basically, the gettext standard internationalization process consists on retriving translatable strings from source files and create Portable Objects and Machine Objects. Portable Objects contain the information translators used to do their work, it is file that can be edited by any convenctional text editor like Vim, Emacs or Nano. On the other hand, Machine Objects are produced to be machine-redable as its name implies, and are produced from Portable Objects. + Since gettext needs to extract translatable strings form source files in order to let translators to localize them, the types of source files we use inside the repository are limitted to the file types supported by gettext program. Most of source files supported by gettext are those from programming languages like C, C++, Bash, Python and Perl just to mention a few from the long list of supported formats. However, formats like SVG, XHTML and Docbook don't figure as supported in the long list of gettext supported source files. For these formats we use the xml2po program that come in gnome-doc-utils package instead. The xml2po program reads one XML based file and extracts translatable strings from it and creates one Portable Object that is use to create a translated XML based file with the same definition of the source file translatable strings were taken from (e.g., if we extract translatable strings from a SVG file, as result we get the same SVG file but with translatable strings already localized —obviously, for this to happen translators need to localize translatable strings inside the Portable Object first, localization don't appear as art of magic—). When using xml2po, the Machine Object file is used just temporally to produce the final translated XML based file. + + Tip If you want to have your content localized inside CentOS Artwork Repository be sure to use source files supported by gettext and xml2po programs. + + + + + Programming + So far, we've seen a conceptual view of how image production inside CentOS Artwork Repository is performed, but how all this is implemented, what is the practical view? + The practical view can be found through centos-art.sh script, a bash script specially designed to automate most frequent tasks inside CentOS Artwork Repository. The centos-art.sh script is stored in trunk/Scripts directory structure and is there where the main development for centos-art.sh script takes place. Basically, the centos-art.sh script is divided in several functionalities that perform specific tasks inside the repository. Such functionalities relay on repository organization to work as expected. + Maiking the centos-art.sh script to automate tasks is the only possible work flow that I can think about right now. If you are a programmer, take a functionality from centos-art.sh script, study it, look how to improve it and share your ideas at centos-devel@centos.org mailing list. + + Note As default configuration, everyone is denied from committing changes up to CentOS Artwork Repository. In order to gain commit rights, you need to prove your interest in contributing and maintaining that contribution. Otherwise, if you only want to comment your ideas, the centos-devel@centos.org mailing list exists for you to manifest yourself. This restrictions are necessary to protect our work from spammers. + + + + + + Parallel directories + Inside CentOS Artwork Repository, parallel directories are simple directory entries built from a common parent directory and placed in a location different to that, the common parent directory is placed on. Parallel directories are useful to create branches, tags, translations, documentation, pre-rendering configuration script, and similar directory structures. + Parallel directories take their structure from one unique parent directory. Inside CentOS Artwork Repository, this unique parent directory is under trunk/Identity location. The trunk/Identity location must be considered the reference for whatever information you plan to create inside the repository. + In some circumstances, parallel directories may be created removing uncommon information from their paths. Uncommon path information refers to those directory levels in the path which are not common for other parallel directories. For example, when rendering trunk/Identity/Themes/Motifs/TreeFlower/Distro directory structure, the centos-art.sh script removes the Motifs/TreeFlower/ directory levels from path, in order to build the parallel directory used to retrived translations, and pre-rendering configuration scripts required by render functionality. + Another example of parallel directory is the documentation structure created by manual functionality. This time, centos-art.sh script uses parallel directory information with uncommon directory levels to build the documentation entry required by Texinfo documentation system, inside the repository. + Othertimes, parallel directories may add uncommon information to their paths. This is the case we use to create branches and tags. When we create branches and tags, a numerical identifier is added to parallel directory structure path. The place where the numerical identifier is set on is relevant to corporate visual identity structure and should be carefully considered where it will be. + When one parent directory changes, all their related parallel directories need to be changed too. This is required in order for parallel directories to retain their relation with the parent directory structure. In the other hand, parallel directories should never be modified under no reason but to satisfy the relation to their parent directory structure. Liberal change of parallel directories may suppresses the conceptual idea they were initially created for; and certainly, things may stop working the way they should do. + + + + Syncronizing path information + Parallel directories are very useful to keep repository organized but introduce some complications. For instance, consider what would happen to functionalities like manual (trunk Scripts Bash Functions Manual) that rely on parent directory structures to create documentation entries (using parallel directory structures) if one of those parent directory structures suddenly changes after the documentation entry has been already created for it? + In such cases, functionalities like manual may confuse themselves if path information is not updated to reflect the relation with its parent directory. Such functionalities work with parent directory structure as reference; if a parent directory changes, the functionalities dont't even note it because they work with the last parent directory structure available in the repository, no matter what it is. + In the specific case of documentation (the manual functionality), the problem mentioned above provokes that older parent directories, already documented, remain inside documentation directory structures as long as you get your hands into the documentation directory structure (trunk/Manuals) and change what must be changed to match the new parent directory structure. + There is no immediate way for manual, and similar functionalities that use parent directories as reference, to know when and how directory movements take place inside the repository. Such information is available only when the file movement itself takes place inside the repository. So, is there, at the moment of moving files, when we need to syncronize parallel directories with their unique parent directory structure. + + Warning There is not support for URL reference inside centos-art.sh script. The centos-art.sh script is designed to work with local files inside the working copy only. + + As CentOS Artwork Repository is built over a version control system, file movements inside the repository are considered repository changes. In order for these repository changes to be versioned, we need to, firstly, add changes into the version control system, commit them, and later, perform movement actions using version control system commands. This configuration makes possible for everyone to know about changes details inside the repository; and if needed, revert or update them back to a previous revision. + Finally, once all path information has been corrected, it is time to take care of information inside the files. For instance, considere what would happen if you make a reference to a documentation node, and later the documentation node you refere to is deleted. That would make Texinfo to produce error messages at export time. So, the centos-art.sh script needs to know when such changes happen, in a way they could be noted and handled without producing errors. + + + + What is the right place to store it? + Occasionly, you may find that new corporate visual identity components need to be added to the repository. If that is your case, the first question you need to ask yourself, before start to create directories blindly all over, is: What is the right place to store it? + The CentOS Community different free support vains (see: http://wiki.centos.org/GettingHelp) are the best place to find answers to your question, but going there with hands empty is not good idea. It may give the impression you don't really care about. Instead, consider the following suggestions to find your own comprehension and so, make your propositions based on it. + When we are looking for the correct place to store new files, to bear in mind the corporate visual identity structure used inside the CentOS Artwork Repository (see Directories trunk Identity) would be probaly the best advice we could offer, the rest is just matter of choosing appropriate names. To illustrate this desition process let's consider the trunk/Identity/Themes/Motifs/TreeFlower directory as example. It is the trunk development line of TreeFlower artistic motif. Artistic motifs are considered part of themes, which in turn are considered part of CentOS corporate visual identity. + When building parent directory structures, you may find that reaching an acceptable location may take some time, and as it uses to happen most of time; once you've find it, that may be not a definite solution. There are many concepts that you need to play with, in order to find a result that match the conceptual idea you try to implement in the new directory location. To know which these concepts are, split the location in words and read its documentation entry from less specific to more specific. + For example, the trunk/Identity/Themes/Motifs/TreeFlower location evolved through several months of contant work and there is no certain it won't change in the future, even it fixes quite well the concept we are trying to implement. The concepts used in trunk/Identity/Themes/Distro/Motifs/TreeFlower location are described in the following commands, respectively: + + 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. + +
+ + + Feedback + Layout + Introduction +
Send in Your Feedback FeedbackIf you find an error in the CentOS Artwork Repository Manual, or if you have thought of a way to make this manual better, we would like to hear from you! Create a new ticket in The CentOS Artwork SIG web site (https://projects.centos.org/trac/artwork/). If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily. @@ -343,6 +440,11 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh + Directories trunk Identity Manual + Directories trunk Identity Manual + + + Directories trunk Identity Palettes Directories trunk Identity Palettes @@ -418,13 +520,8 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh - Directories trunk Identity Themes Models Default Promo - Directories trunk Identity Themes Models Default Promo - - - - Directories trunk Identity Themes Models Default Web - Directories trunk Identity Themes Models Default Web + Directories trunk Identity Themes Models Default Posters + Directories trunk Identity Themes Models Default Posters @@ -443,33 +540,8 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh - Directories trunk Identity Themes Motifs Modern Backgrounds - Directories trunk Identity Themes Motifs Modern Backgrounds - - - - Directories trunk Identity Themes Motifs Modern Backgrounds Img - Directories trunk Identity Themes Motifs Modern Backgrounds Img - - - - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - - - - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - - - - Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress - Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress - - - - Directories trunk Identity Themes Motifs Modern Palettes - Directories trunk Identity Themes Motifs Modern Palettes + Directories trunk Identity Themes Motifs Pipes + Directories trunk Identity Themes Motifs Pipes @@ -478,11 +550,6 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - - - Directories trunk Identity Webenv Directories trunk Identity Webenv @@ -503,28 +570,18 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh - Directories trunk Scripts Functions Html - Directories trunk Scripts Functions Html - - - - Directories trunk Scripts Functions Identity - Directories trunk Scripts Functions Identity - - - Directories trunk Scripts Functions Locale Directories trunk Scripts Functions Locale - Directories trunk Scripts Functions Manual - Directories trunk Scripts Functions Manual + Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Prepare + Directories trunk Scripts Functions Prepare @@ -537,21 +594,6 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Directories trunk Scripts Functions Render Config - - Directories trunk Scripts Functions Shell - Directories trunk Scripts Functions Shell - - - - Directories trunk Scripts Functions Svg - Directories trunk Scripts Functions Svg - - - - Directories trunk Scripts Functions Verify - Directories trunk Scripts Functions Verify - - @@ -654,31 +696,17 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Identity - This section organizes image production in different formats and some non-image formats like XHTML and text files, as well. This is the perfect place to consolidate The CentOS Artwork SIG. If you are interested in producing art works for The CentOS Project, this place is for you. + This section describes the implementation of The CentOS Project Corporate Identity. This place is perfect to consolidate The CentOS Artwork SIG. If you are interested in producing art works for The CentOS Project, this place is for you. See Directories trunk Identity, for more information. - Manual - - This section organizes the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested on improving The CentOS Artwork Repository Manual, in this place you'll find the Texinfo documentation structure you need to work with. - — Removed(xref:Directories trunk Manual) —, for more information. - - - Scripts - This section organizes production of automation scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. + This section describes the implementation of centos-art.sh script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. See Directories trunk Scripts, for more information. - - Locales - - This section organizes production of translation messages for Identity, Documentation and Scripts. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. - See Directories trunk Identity Locales, for more information. - - @@ -714,56 +742,73 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Directories trunk Identity Goals - The trunk/Identity directory structure implements The CentOS Project Corporate Identity. + This section descirbes the implementation of The CentOS Project Corporate Identity. Description - The CentOS Project corporate identity is the “persona” of the organization known as The CentOS Project. The CentOS Project corporate identity plays a significant role in the way the CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, the CentOS Project corporate visual identity expresses the values and ambitions of the CentOS Project organization, its business, and its characteristics. - The CentOS Project corporate identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of Corporate Design, Corporate Communication, and Corporate Behaviour. + The CentOS Project Corporate Identity is the “persona” of the organization known as The CentOS Project. The CentOS Project Corporate Identity plays a significant role in the way the CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, the CentOS Project Corporate Identity expresses the values and ambitions of the CentOS Project organization, its business, and its characteristics. + The CentOS Project Corporate Identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of Corporate Design, Corporate Communication, and Corporate Behaviour. Corporate Design - The CentOS Project corporate design is applied to every single visual manifestations The CentOS Project as organization wants to express its existence. Examples of the most relevant visual manifestations inside The CentOS Project are The CentOS Distribution, The CentOS Web and The CentOS Stationery. - The CentOS Project corporate design is organized in the following work-lines: + The CentOS Project Corporate Design is applied to every single visual manifestations The CentOS Project as organization wants to express its existence. Examples of the most relevant visual manifestations inside The CentOS Project are The CentOS Distribution, The CentOS Web and The CentOS Stationery. + The CentOS Project Corporate Design is organized in the following work-lines: - The CentOS Brand + Brands - The CentOS Brand is the name or trademark that connects the producer with their products. In this case, the producer is The CentOS Project and the products are The CentOS Project visual manifestations. + The CentOS Brand provides the one unique name or trademark that connects the producer with their products. In this case, the producer is The CentOS Project and the products are The CentOS Project visual manifestations. See Directories trunk Identity Brands, for more information. - The CentOS Colors + Palettes - The CentOS Fonts provides the color information used along The CentOS Project visual manifestations. + The CentOS Palettes provide the Corporate Color information used along The CentOS Project visual manifestations. See Directories trunk Identity Palettes, for more information. - The CentOS Fonts + Fonts - The CentOS Fonts provides the typography information used along The CentOS Project visual manifestations. + The CentOS Fonts provide the Corporate Typography information used along The CentOS Project visual manifestations. See Directories trunk Identity Fonts, for more information. - The CentOS Themes + Themes - The CentOS Themes provides structural information and visual style information, as well, used along The CentOS Project visual manifestations. + The CentOS Themes provide the Corporate Structure and the Corporate Visual Style used along The CentOS Project visual manifestations. See Directories trunk Identity Themes, for more information. + + Manual + + This section organizes the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested on improving The CentOS Artwork Repository Manual, in this place you'll find the Texinfo documentation structure you need to work with. + See Directories trunk Identity Manual, for more information. + + + + Locales + + This section organizes production of translation messages for Identity, Documentation and Scripts. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. + See Directories trunk Identity Locales, for more information. + +
Corporate Communication - The CentOS Project corporate communication is based on community communication. In that sake, the following media are available for corporate communication: + The CentOS Project Corporate Communication is based on Community Communication. In that sake, the following media are available: • + The CentOS Chat (#centos, #centos-social, #centos-devel on irc.freenode.net) + + The CentOS Mailing Lists (http://lists.centos.org/). @@ -774,42 +819,54 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Corporate Behaviour - The CentOS Project corporate behaviour is based on community behaviour. + The CentOS Project Corporate Behaviour is based on Community Behaviour. Corporate Structure - The CentOS Project corporate structure is based on a monolithic corporate visual identity structure. In this structure, we use one unique name (The CentOS Brand) and one unique visual style (The CentOS Theme) in all The CentOS Project visual manifestations. - Inside a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting web sites, using the distribution, or acting on social events, the one unique name and one unique visual style connects them all to say: Hey! we are all part of The CentOS Project. - Other corporate structures have been considered as well, but they introduce visual contradictions we need to be aware of. In that sake, lets describe the idea of: Producing one different visual style for each major release of The CentOS Distribution. - The CentOS Project maintains near to four different major releases of The CentOS Distribution parallely in time and that fact makes one part of The CentOS Project structural design, but just one part, not the complete structural design. In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. - If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of. Would we end up with four different visual styles, one for each distribution? In that case, why The CentOS Distribution we use shows one visual style, The CentOS Web sites another and The CentOS Stationery even another completly different one? Isn't them all part of the same project? - Probably you be thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain? - Harder to maintain, more work to do, it is probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and that, certainly, didn't come through swinging magical wangs or something but hardly working out to automate tasks and so providing maintainance through time. Said that, we consider that The CentOS Project visual structure should be consequent with such stability and consistency tradition. It is true The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. - Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem does is in not propagating the brand new visual style created for the new release of CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. + The CentOS Project Corporate Structure is based on a Monolithic Corporate Visual Identity Structure. In this structure, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project. + In a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting web sites, using the distribution, or acting on social events, the one unique name and one unique visual style connects them all to say: Hey! we are all part of The CentOS Project. + Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major releasae of CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project and which are the visual manifestations it is made of. + The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Stationery. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. Inside Web and Stationery visual manifestations content is visually produced to fit non-release-specifc content but treat it as a visual manifestation properly. For example, consider that there is no a complete web site for each major release of CentOS distribution, but one web site to cover the information related to all release-specific visual manifestations like CentOS distribution. + In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., web sites and stationery)? + Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain? + Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and that, certainly, didn't come through swinging magical wangs or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Visual Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. + Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new release of CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. Usage - The trunk/ directory structure is organized in renderable and non-renderable directories. Generally, renderable directories contain two non-renderable directories inside, one to store design templates (the Tpl/ directory), and other to store the content produced (the Img/ directory). - In order to produce content inside rendereble directories, you can use the following command: - The trunk/Identity/ directory structure is organized in renderable and non-renderable directories. Generally, renderable directories are stored under trunk/Identity/Images and trunk/Identity/Themes/Motifs directories. These directories contain the image files used to implemente The CentOS Project Corporate Identity. + + + Rendition + In order to produce content inside rendereble directories, you can use the following command: + - - Warning If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared it for using The CentOS Artwork Repository yet. See Directories trunk Scripts Functions Verify, for more information. - - This command takes one design template from the template directory and creates an instance of it in order to apply translation messages on it, if any. Later, using the design template instance, the command renders the final content based on whether the design template instance is a SVG file or a Docbook file. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a Docbook file, the final content produced is a XHTML file. Final content is stored in the image directory using the design template directory paths as referece. The rendition flow described so far is known as the base-rendition flow. - Besides the base-rendition flow, the centos-art provides the post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art we need to wait for all the three images the Preview.png image is made of to be rendered, so we can combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. - Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to automatically process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order to reach its final construction. Directory-specific rendition is a way to programmatically describe how specific art works are built in and organized inside The CentOS Artwork Repository. Such descriptions have been added to centos-art command-line to let you produce them all with just one single command, as fast as your machine can be able to handle it. - See Directories trunk Scripts Functions Identity, for more information about the identity functionality of centos-art command-line interface. + + Warning If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared your workstation for using The CentOS Artwork Repository yet. See Directories trunk Scripts Functions Prepare, for more information. + + This command takes one design template (a.k.a., design model) from the template directory and creates an instance of it in order to apply translation messages, if any. Later, using the translated design template instance, the command renders the final content based on whether the design template instance is a SVG file or XHTML. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a XHTML file, the final content produced is a XHTML file. The rendition flow described so far is known as the centos-art.sh script base-rendition flow. + Besides the base-rendition flow, the centos-art provides post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs formats (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow, on the other hand, is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art.sh we need to wait for all the three images the Preview.png image is made of to be rendered in order to combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. + Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to automatically process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order to reach the final content construction. Directory-specific rendition is a way to programmatically describe how specific art works are built in and organized inside The CentOS Artwork Repository. Such descriptions have been added to centos-art.sh command-line to let you produce them all with just one single command, as fast as your machine can be able to handle it. + See Directories trunk Scripts Functions Render, for more information about the render functionality of centos-art.sh script. + + + + Documentation + + + + Localization + See also - See http://en.wikipedia.org/Corporate_identity (and related links), for general information on corporate identity. - Specially useful has been, and still be, the book Corporate Identity by Wally Olins (1989). This book provides many conceptual ideas we've used as base to build The CentOS Artwork Repository. + See http://en.wikipedia.org/Corporate_identity (and related links), for general information on Corporate Identity. + Specially useful has been, and still is, the book Corporate Identity by Wally Olins (1989). This book provides many conceptual ideas we've used as base to build The CentOS Artwork Repository.
@@ -899,7 +956,7 @@ centos-art render trunk/Identity/Path/To/Dir Directories trunk Identity Locales - Directories trunk Identity Palettes + Directories trunk Identity Manual Directories trunk Identity Fonts Directories
@@ -922,9 +979,54 @@ centos-art render trunk/Identity/Path/To/Dir
+ Directories trunk Identity Manual + Directories trunk Identity Palettes + Directories trunk Identity Locales + Directories +
+ The <file>trunk/Identity/Manual</file> Directory + Directories trunk Identity Manual + + Goals + + • + + ... + + + + + + Description + + • + + ... + + + + + + Usage + + • + + ... + + + + + + See also + + + +
+ + Directories trunk Identity Palettes Directories trunk Identity Themes - Directories trunk Identity Locales + Directories trunk Identity Manual Directories
The <file>trunk/Identity/Palettes</file> Directory @@ -981,6 +1083,20 @@ centos-art render trunk/Identity/Path/To/Dir Description + + Work Flow + Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). + Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. + Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. + Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. + + Convenction Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead. + + The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository. + If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit. + Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene. + Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under tags/ directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. + @@ -1093,7 +1209,7 @@ centos-art render trunk/Identity/Path/To/Dir Promotion - Design models for CentOS Promotion stuff (e.g., installation media, posters, etc.). See Directories trunk Identity Themes Models Default Promo, for more information. + Design models for CentOS Promotion stuff (e.g., installation media, posters, etc.). — Removed(xref:Directories trunk Identity Themes Models Default Promo) —, for more information. @@ -1641,7 +1757,7 @@ centos-art render trunk/Identity/Path/To/Dir Directories trunk Identity Themes Models Default Distro Syslinux - Directories trunk Identity Themes Models Default Promo + Directories trunk Identity Themes Models Default Posters Directories trunk Identity Themes Models Default Distro Rhgb Directories
@@ -1685,59 +1801,13 @@ centos-art render trunk/Identity/Path/To/Dir
- Directories trunk Identity Themes Models Default Promo - Directories trunk Identity Themes Models Default Web - Directories trunk Identity Themes Models Default Distro Syslinux - Directories -
- The <file>trunk/Identity/Themes/Models/Default/Promo</file> Directory - Directories trunk Identity Themes Models Default Promo - - Goals - - • - - ... - - - - - - Description - It applies to all tangible and non tangible items CentOS uses to promote its existence. Clothes, posters, installation media, stationery, release countdown images, banners, stickers, are all examples of promotion designs. - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - -
- - - Directories trunk Identity Themes Models Default Web + Directories trunk Identity Themes Models Default Posters Directories trunk Identity Themes Motifs - Directories trunk Identity Themes Models Default Promo + Directories trunk Identity Themes Models Default Distro Syslinux Directories
- The <file>trunk/Identity/Themes/Models/Default/Web</file> Directory - Directories trunk Identity Themes Models Default Web + The <file>trunk/Identity/Themes/Models/Default/Posters</file> Directory + Directories trunk Identity Themes Models Default Posters Goals @@ -1750,7 +1820,6 @@ centos-art render trunk/Identity/Path/To/Dir Description - It applies to all web applications CentOS uses to handle its needs (Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving HTML standards should be consider here. • @@ -1779,7 +1848,7 @@ centos-art render trunk/Identity/Path/To/Dir Directories trunk Identity Themes Motifs Directories trunk Identity Themes Motifs Flame - Directories trunk Identity Themes Models Default Web + Directories trunk Identity Themes Models Default Posters Directories
The <file>trunk/Identity/Themes/Motifs</file> Directory @@ -1886,6 +1955,17 @@ centos-art render trunk/Identity/Path/To/Dir + The Backgrounds/ directory is used to organize artistic motif background images and the projects used to build those images. + Background images are linked (using the import feature of Inkscape) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas. + In this configuration you design background images for different screen resolutions based on the theme artistic motif. + You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea. + Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.). + Each artistic motif directory represents just one unique artistic motif. + The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes. + Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif. + Inside CentOS Artwork Repository, theme visual styles (a.k.a., artistic motifs) and theme visual structures (a.k.a., design models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the centos-art command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under Motifs/ directory using the model name, and the model directory structure as reference. + The artistic motif base structure is used by centos-art to produce images automatically. This section describes each directory of CentOS artistic motif base structure. + The Backgrounds/ directory is probably the core component, inside Motifs/ directory structure. Inside Backgrounds/ directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The Backgrounds/ directory can contain subdirectories to help you organize the design process.
@@ -1899,7 +1979,7 @@ centos-art render trunk/Identity/Path/To/Dir Directories trunk Identity Themes Motifs Flame Goals - This section describes the steps we followed to construct the Flame artistic motif. This section may be useful for anyone interested in reproducing the Flame artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity (see Directories trunk Identity). + This section describes the Flame artistic motif. This section may be useful for anyone interested in reproducing the Flame artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity. @@ -1920,89 +2000,43 @@ centos-art render trunk/Identity/Path/To/Dir Important When we design background images, which are considered part of the same theme, it is essential to use the same design pattern always. This is what makes theme images to be visually connected among themeselves, and so, the reason we use to define the word “theme” as: a set of images visually connected among themeselves. In order for us to reproduce the same flame pattern always, Flame filter interface provides the Save and Open options. The Save option brings up a file save dialog that allows you to save the current Flame settings for the plug-in, so that you can recreate them later. The Open option brings up a file selector that allows you to open a previously saved Flame settings file. - The Flame settings we used in our example are saved in the file: - - - - - Construction - - Step 1: Set image size - Create an empty image and fill the Background layer with black (000000) color. Image dimensions depend on the final destination you plan to use the image for. For the sake of our construction example we used an image of 640x480 pixels and 300 pixels per inch (ppi). - - - - Step 2: Add base color and pattern information - Create a new layer named Base, place it over Background layer and fill it with the base color (7800ff) you want to have your background image set in. Add a mask to Base layer using radial gradient and blur it. You may need to repeat this step more than once in order to achieve a confortable black radial degradation on the right side of your design. - Duplicate Base layer and name it Paper. Place Paper layer over Base layer. Remove content of Paper layer and fill it with Paper (100x100) pattern. Once you've done with black radial degradation, reduce the Paper layer opacity to 20%. - Notice that when we duplicate one layer, the mask information related to layer is preserved from previous to next layer. This saves us some of the time required to produce different layers with the same mask information on them. - Duplicate Paper layer and rename it Stripes. Remove paper pattern from Stripes layer. Fill Stripes layer with Stripes (48x48) pattern and reduce the Stripes layer opacity to 15%. - - - - Step 3: Add flame motif - Create a new layer named Flame. Set the foreground (003cff) and background (0084ff) colors to the gradient you want to build the flame motif. - To build flame motif, use the flame filter (Filters > Render > Nature > Flame...) on Flame layer. We used a layer mask, with a radial gradient on it to control the boundaries of flame motif on Flame layer. - Duplicate Flame layer and rename it `Flame Blur'. Place `Flame Blur' below Flame layer. Apply Gussian blur filter (Filters > Blur > Gussian Blur...) until reaching the desiered effect. - The opacity value, in Flame layers, may vary from one image to another based on the place the image will be finally placed on. For example, images used as desktop background have the Flame layer opacity set at 100% but Flame Blur is set to 70%. However, you may find that background images used in anaconda progress slides have opacity reduced differently, in order to reduce brightness in a way that texts could look clean and readable over it. - - - - Step 4: Add foreground color - Create a new layer named Color, place it on top of all visible layers and fill it with plain color (4c005a). Reduce Color layer opacity to 20%. You can use the Color layer to control the right side color information you want to produce the image for. - Duplicate Flame layer and create a new layer named Color#1. Place Color#1 layer on top of layer named Color. Remove the mask information from Color#1 layer and recreate a new one using an inverted alpha channel as reference. Remove Color#1 layer content and fill it back with plain black (000000) color. Reduce Color#1 opacity to 20%. In this step we created a mask to protect the flame artistic motif from black color, so when we decrement or increment the opacity of layer, the flame artistic motif wouldn't be affected, just the environment suround it. - When you set color information, remember that the same artistic motif needs to be indexed to 14 and 16 colors, in order to produce Grub and Syslinux visual manifestations respectively. Using many different colors in the artistic motif may reduce the possibility of your design to fix all different situations in. Likewise, using more colors in one design, and less colors in another design will reduce the connectivity among your designs, since color information is relevant to visual identity. - When you propagate your artistic motif visual style to different visual manifestations of CentOS Project corporate visual identity, it is up to you to find out justice and compromise among all possible variables you may face. - + The Flame settings we used in our example are saved in the file named 800x600.xcf-flame.def, inside the Backgrounds/Xcf directory structure. See also - - - Directories trunk Identity Themes Motifs - Directories trunk Identity Themes Motifs - - - - Directories trunk Identity Themes - Directories trunk Identity Themes - - - - Directories trunk Identity - Directories trunk Identity - - - - Directories trunk - Directories trunk - - - + + • + + See Directories trunk Identity Themes Motifs. + + + See Directories trunk Identity Themes. + + + See Directories trunk Identity. + + + See Directories trunk. + +
Directories trunk Identity Themes Motifs Modern - Directories trunk Identity Themes Motifs Modern Backgrounds + Directories trunk Identity Themes Motifs Pipes Directories trunk Identity Themes Motifs Flame Directories
The <file>trunk/Identity/Themes/Motifs/Modern</file> Directory Directories trunk Identity Themes Motifs Modern - Presentation - - - - Construction + Goals - Usage + Description • @@ -2012,101 +2046,7 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def - See also - - - -
- - - Directories trunk Identity Themes Motifs Modern Backgrounds - Directories trunk Identity Themes Motifs Modern Backgrounds Img - Directories trunk Identity Themes Motifs Modern - Directories -
- The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds</file> Directory - Directories trunk Identity Themes Motifs Modern Backgrounds - - Goals - - • - - Organize background images for Modern theme. - - - - - - Description - Inside Motifs directory, the Backgrounds/ directory is used to create vectorial designs using Inkscape and background images using Gimp. Later, you can export background images as .png and load them in your vectorial design project using the import feautre of Inkscape. - You may need to repeat this technic for different screen resoluions. In that case you need to create one file for each screen resolution and do the appropriate linking inside .svg to .png files. For example if you need to produce background images in 800x600 you need to create the following file: - xcf/800x600.xcf - to produce the background image: - img/800x600-bg.png - which is loaded in: - svg/800x600.svg - to produce the final background image: - img/800x600.png - The img/800x600.png background image is produced automatically by means of rendering scripts. - In other cases (e.g. Anaconda), it is possible that you need to make some variations to one background image that don't want to appear on regular background images of the same resolution. In this case you need to create a new and specific background image for that art component. For example, if you need to produce the background image used by Anconda (800x600) art works you create the file: - xcf/800x600-anaconda.xcf - to produce the background image: - img/800x600-anaconda-bg.png - which is loaded in: - svg/800x600-anaconda.svg - to produce the file: - img/800x600-anaconda.png - The 800x600-anaconda.png file is used by all Anaconda art works sharing a common 800x600 screen resolution (e.g., Header, Progress, Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors and 640x480 pixels so you need to create a 640x480 background image for it, and take the color limitation into account when designing it. - Background images without artistic motif are generally used as based to build the Background images that do contain the theme artistic motif. - Background images are linked (using the import feature of Inkscape) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas. - In this structure you design background images for different screen resolutions based on the theme artistic motif. - You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea. - Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.). - Each artistic motif directory represents just one unique artistic motif. - The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes. - Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif. - Inside CentOS Artwork Repository, theme visual styles (Motifs) and theme visual structures (Models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the centos-art command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under Motifs/ directory using the model name, and the model directory structure as reference. - The artistic motif base structure is used by centos-art to produce images automatically. This section describes each directory of CentOS artistic motif base structure. - - - Usage - The Backgrounds/ directory is probably the core component, inside Motifs/ directory structure. Inside Backgrounds/ directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The Backgrounds/ directory can contain subdirectories to help you organize the design process. - - - - See also - - - Directories trunk Identity Themes Motifs Modern Backgrounds Img - Directories trunk Identity Themes Motifs Modern Backgrounds Img - - - - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - - - - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - - - - - -
- - - Directories trunk Identity Themes Motifs Modern Backgrounds Img - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - Directories trunk Identity Themes Motifs Modern Backgrounds - Directories -
- The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img</file> Directory - Directories trunk Identity Themes Motifs Modern Backgrounds Img - - Goals • @@ -2116,15 +2056,6 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def - Description - - - - Usage - In this directory is where you store all background images (e.g., .png, .jpg, .xpm, etc.). This directory is required by centos-art command line interface. - - - See also @@ -2132,13 +2063,13 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
- Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - Directories trunk Identity Themes Motifs Modern Backgrounds Img + Directories trunk Identity Themes Motifs Pipes + Directories trunk Identity Themes Motifs TreeFlower + Directories trunk Identity Themes Motifs Modern Directories
- The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl</file> Directory - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl + The <file>trunk/Identity/Themes/Motifs/Pipes</file> Directory + Directories trunk Identity Themes Motifs Pipes Goals @@ -2151,30 +2082,6 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def Description - - - - Usage - In this directory is where you store all the scalable vector graphics (e.g., .svg) files. This directory is required by centos-art command line interface. - - - - See also - - - -
- - - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress - Directories trunk Identity Themes Motifs Modern Backgrounds Tpl - Directories -
- The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf</file> Directory - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf - - Goals • @@ -2184,7 +2091,7 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def - Description + Usage • @@ -2194,11 +2101,6 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def - Usage - In this directory is where you store the project files (e.g, .xcf) of Gimp. This directory is not required by centos-art command line interface. If you can create a beautiful background images using scalable vector graphics only, then there is no need to use the Xcf/ directory to store background projects. Of course, you can merge both Gimp and Inkscape power to produce images based on them. In this last case you need the Xcf/ directory. - - - See also @@ -2206,21 +2108,15 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def
- Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress - Directories trunk Identity Themes Motifs Modern Palettes - Directories trunk Identity Themes Motifs Modern Backgrounds Xcf + Directories trunk Identity Themes Motifs TreeFlower + Directories trunk Identity Webenv + Directories trunk Identity Themes Motifs Pipes Directories
- The <file>trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress</file> Directory - Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress + The <file>trunk/Identity/Themes/Motifs/TreeFlower</file> Directory + Directories trunk Identity Themes Motifs TreeFlower Goals - - • - - ... - - @@ -2229,38 +2125,6 @@ trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def Usage - To render Anaconda progress slide images using the Modern artistic motif design, the Default theme model, and available translation files (— Removed(pxref:trunk Translations Identity Themes Distro Anaconda Progress) —); use the following commands: - cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/ -centos-art render --identity - The above command will create the following structure: - trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress -|-- 3 -| |-- en -| | |-- 01-welcome.png -| | |-- 02-donate.png -| | `-- 03-yum.png -| `-- es -| |-- 01-welcome.png -| |-- 02-donate.png -| `-- 03-yum.png -|-- 4 -| |-- en -| | |-- 01-welcome.png -| | |-- 02-donate.png -| | `-- 03-yum.png -| `-- es -| |-- 01-welcome.png -| |-- 02-donate.png -| `-- 03-yum.png -`-- 5 - |-- en - | |-- 01-welcome.png - | |-- 02-donate.png - | `-- 03-yum.png - `-- es - |-- 01-welcome.png - |-- 02-donate.png - `-- 03-yum.png @@ -2271,416 +2135,116 @@ centos-art render --identity
- Directories trunk Identity Themes Motifs Modern Palettes - Directories trunk Identity Themes Motifs TreeFlower - Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress + Directories trunk Identity Webenv + Directories trunk Scripts + Directories trunk Identity Themes Motifs TreeFlower Directories
- The <file>trunk/Identity/Themes/Motifs/Modern/Palettes</file> Directory - Directories trunk Identity Themes Motifs Modern Palettes + The <file>trunk/Identity/Webenv</file> Directory + Directories trunk Identity Webenv Goals • - Organize palette files for Modern theme. + ... Description - - - - Usage - Here is where graphic designers define theme palettes for color-limited art works. Theme palettes contain the color information that rendering functions need, in order to produce images with color limitations. Theme palettes contain the unique color information required by theme. - - - - See also - - - -
- - - Directories trunk Identity Themes Motifs TreeFlower - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - Directories trunk Identity Themes Motifs Modern Palettes - Directories -
- The <file>trunk/Identity/Themes/Motifs/TreeFlower</file> Directory - Directories trunk Identity Themes Motifs TreeFlower - - Goals + The CentOS web environment is formed by a central web application —to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)— and many different free web applications —to cover specific needs (e.g., wiki, mailing lists, etc.)—. + The CentOS web environment is addressed to solve the following issues: • - ... + One unique name and one unique visual style to all web applications used inside the web environment. + + + One-step navigation to web applications inside the environment. + + + High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions). - + The CentOS project is attached to a monolithic corporate visual identity (see Directories trunk Identity), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case. + Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (http://wiki.centos.org/) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't supportThe theme support of Mailman may be introduced in mailman-3.x.x release. a customization system that separates presentation from logic, similar to that used by MoinMoin. + This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic). + To solve the “one unique visual style” issue, installation and actualization of web applications —used inside CentOS web environment— need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes. + At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. - - Description - + + Design model (without ads) + - - Usage - + + Design model (with ads) + - - See also - - - -
- - - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - Directories trunk Identity Webenv - Directories trunk Identity Themes Motifs TreeFlower - Directories -
- The <file>trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds</file> Directory - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - - Goals - This section exists to orgnize backgrounds of TreeFlower artistic motif. - + + HTML definitions + - - Description - Desktop background - Once you have defined the vectorial artistic motif design, use the centos-art.sh script (as described in usage section below) to produce the png version of it. With the png version of your vectorial design do the following: - Open the png version with GIMP. - Save the png version as a project of GIMP inside trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf directory, using the same name of your vectorial design but with the .xcf extension. - Now use GIMP to improve your design. Here you may add one layer for pattern, another for colors, and so on until you find yourself confortable with your artwork. For example, the following layer distribution (from bottom to top) was used to build revision 285 of file 1360x768.xcf using TreeFlower artistic motif at revision 241. + Controlling visual style + Inside CentOS web environment, the visual style is controlled by the following compenents: - Layer 1: Background + Webenv header background - The first thing we did with GIMP was to create a layer named Background to store the artistic motif (File > Open as layer). This layer is the lowest layer in the image. Later, we started to create layers one upon another to change the artistic motif visual style. + - Layer 2: Shadow#1 + CSS definitions - This layer is above Background and contains a linear gradient from left (000000) to right (transparent) covering the whole image. This layer masks the artistic motif to avoid the effect of linear gradient. This layer is 100% of opacity. + +
+ + + + Producing visual style + The visual style of CentOS web environment is defined in the following files: + + As graphic designer you use 1024x250.xcf file to produce 1024x250-bg.png file. Later, inside 1024x250.svg file, you use the 1024x250-bg.png file as background layer to draw your vectorial design. When you consider you artwork ready, use the centos-art.sh script, as described below, to produce the visual style controller images of CentOS web environment. + + Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. + + + + Navigation + Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. + + + + Development and release cycle + The CentOS web environment development and relase cycle is described below: + - Layer 3: Shadow#2 + Download - This layer is above Shadow#1 and contains a linear gradient from left (000000) to right (transparent) covering just the 70% of the whole image aproximatly. This layer doesn't mask the artistic motif which make the left part of it fall into the dark of linear gradient. This layer is 100% of opacity. + The first action is download the source code of web applications we want to use inside CentOS web environment. + + Important The source location from which web application are downloaded is very important. Use SRPMs from CentOS [base] and [updates] repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource. + - Layer 4: Pattern (Paper) - - This layer is above Shadow#2 an contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif so the pattern is applied over the whole image. This layer is set to 15% of opacity. - - - - Layer 5: Pattern (Stripes) - - This layer is above Pattern (Paper) and contains the stripes used over the artistic motif. This layer do masks the artistic motif so the stripes are only applied to it. This layer is set to 10% of opacity. - - - - Layer 6: Shadow#3 - - This layer is above Pattern (Stripes) and contains a linear gradient from right (6600ff) to left (transparent). This layer masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 15% of opacity. - - - - Layer 7: Shadow#4 - - This layer is above Shadow#3 and contains a linear gradient from left (000000) to right (transparent). This layer do masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 10% of opacity. - - - - Layer 8: Color#1 - - This layer is above Shadow#4 and is filled with orange (ffae00) color over the whole image. This layer is set to 10% of opacity. - - - - Layer 9: Color#2 - - This layer is above Color#1 and is filled with blue (010a88) color over the whole image. This layer is set to 10% of opacity. - - -
- - Note There is no definite combination. To get the appropriate visual design is a matter of constant testing and personal taste. - - Finally, use Save as copy ... option to export the final design. To export the final design use the same name of your vectorial design plus -final.png extension. - You can repeat these steps to create images for other screen resolutions. - - - - Anaconda Prompt (syslinux) background - When building syslinux backgrounds it is needed to take into account that the final image is reduced to 16 colors. In desktop background there is no color limitation but syslinux does have. The goal of this section is achieving a final syslinux background as close as possible to desktop backgrounds using 16 colors only. - Another point to consider is the forground and background definition used by syslinux. The syslinux documentation says that the color set in position 0 is the background and color set in position 7 is the forground. The final palette of color used by our background will match that specification. For great contrast we'll use black as background and white as forground. At this poing we have black (000000) and white (ffffff) colors in our syslinux palette, which left us with 14 colors to play with. - Let's begin with Xcf/640x300.xcf layer distribution from bottom to top: - - - Layer 1: Background - - This layer is the lowest layer in the image composition and contains the artistic motif image rendered for the same resolution (i.e., Img/Png/640x300.png). This layer is set to 100% of opacity. - - - - Layer 2: Pattern (Paper) - - This layer is placed above Background layer and contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif. This layer is set to 30% of opacity. - - - - Layer 3: Pattern (Stripes) - - This layer is placed above Pattern (Paper) layer and contains the stripes pattern shipped with GIMP 2.2. This layer does mask the artistic motif in order to apply the stripes over it only. The background is not affected by the stripes pattern just the artistic motif. This layer is set to 20% of opacity. - - - - Layer 4: Shadow#1 - - This layer is placed above Pattern (Stripes) layer and fills the entire layer area with violet (6600ff) color. This layer do mask the artistic motif in order to applied the violet color to the background area outside the artistic motif only. This layer is set to 15% of opacity. - - - - Layer 5: Color#1 - - This layer is above Shadow#1 and is filled with orange (ffae00) color to cover the whole image. This layer is set to 10% of opacity. - - - - Layer 6: Color#2 - - This layer is above Color#1 and is filled with blue (010a88) color to cover the whole image. This layer is set to 10% of opacity. - - - - Layer 7: Shadow#2 - - This layer is above Color#1 and contains a linear gradient from left (000000) to right (transparent) covering 70% of the image approximately. - - -
- At this point we have the composition and should look like the desktop backgrounds. Compared with desktop backgrounds there are some differences in opacity. This is because in our testings the final color information found with this composition produces an acceptable 16 color image. Of course this is something we haven't seen yet. - To define the color information of our current coposition, save the syslinux background composition we've done using File > Save as Copy ... option in the following location: - - Now, create the final png version of syslinux backgrounds using the following command: - - This command will create syslinux-splash final images for all major releases of CentOS distribution the repository has been configured to. The important files here are syslinux-splash.png, other files may contain the wrong information because we haven't defined yet the correct color information to use. - Open one syslinux-splash.png file with GIMP and use the Image > Mode > Indexed to reduce image colors up to 16 colors, using the Generate optimum palette feature of GIMP. If the image looks aceptable after reducing colors, use the Palettes menu (Ctrl+P) of GIMP to import a new palette from file and name it CentOS-TreeFlower-Syslinux. Once you've saved the palette, the color information is stored at: - - You need to edit CentOS-TreeFlower-Syslinux.gpl file in order to set the appropriate order of colors. Remember black (000000) in position 0, and white (ffffff) in position 7. Other positions are irrelevant. When editing this file you may find that color reduction did not set black and white colors to their respective values exactly. Change that manually. For example, consider the following palette: - - Update the Palettes menu to get the new color positions from the file you just edited and open the palette with double click. - Update the syslinux.gpl file copying the following file: - - to - - With the CentOS-TreeFlower-Syslinux palette opened in the Palette Editor, open (Ctrl+O) the following file: - - and replace its color information with that one in CentOS-TreeFlower-Syslinux palette. When you are replacing color information inside syslilnux.ppm, remember to keep the order of colors just as they are in the CentOS-TreeFlower-Palette palette. - The syslinux.ppm file is 16 pixels width and 1 pixel height, so you probably need to zoom it a bit to set the color information in their place when using the pen tool with the brush Circle (01) (1 x 1). - Once you've updated the syslinux.ppm file, it is time to update the following file: - - The syslinux.hex file contains the color information in hexadecimal notation. The color information in hexadecimal notation is required by ppmtolss16 command. The ppmtolss16 command produces the final LSS16 image format that is used by syslinux program inside CentOS distribution. - The color information inside syslinux.hex must match the one in syslinux.ppm and syslinux.gpl. For example, based on CentOS-TreeFlower-Syslinux palette of colors above, consider the following syslinux.hex file: - - - - - Grub background - - - - - Usage - - • - - ... - - - - - - See also - - - -
- - - Directories trunk Identity Webenv - Directories trunk Scripts - Directories trunk Identity Themes Motifs TreeFlower Backgrounds - Directories -
- The <file>trunk/Identity/Webenv</file> Directory - Directories trunk Identity Webenv - - Goals - - • - - ... - - - - - - Description - The CentOS web environment is formed by a central web application —to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)— and many different free web applications —to cover specific needs (e.g., wiki, mailing lists, etc.)—. - The CentOS web environment is addressed to solve the following issues: - - • - - One unique name and one unique visual style to all web applications used inside the web environment. - - - One-step navigation to web applications inside the environment. - - - High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions). - - - The CentOS project is attached to a monolithic corporate visual identity (see Directories trunk Identity), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case. - Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (http://wiki.centos.org/) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't supportThe theme support of Mailman may be introduced in mailman-3.x.x release. a customization system that separates presentation from logic, similar to that used by MoinMoin. - This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic). - To solve the “one unique visual style” issue, installation and actualization of web applications —used inside CentOS web environment— need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes. - At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. - - - Design model (without ads) - - - - Design model (with ads) - - - - HTML definitions - - - - Controlling visual style - Inside CentOS web environment, the visual style is controlled by the following compenents: - - - Webenv header background - - - - - - CSS definitions - - - - -
- - - - Producing visual style - The visual style of CentOS web environment is defined in the following files: - - As graphic designer you use 1024x250.xcf file to produce 1024x250-bg.png file. Later, inside 1024x250.svg file, you use the 1024x250-bg.png file as background layer to draw your vectorial design. When you consider you artwork ready, use the centos-art.sh script, as described below, to produce the visual style controller images of CentOS web environment. - - Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. - - - - Navigation - Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. - - - - Development and release cycle - The CentOS web environment development and relase cycle is described below: - - - Download - - The first action is download the source code of web applications we want to use inside CentOS web environment. - - Important The source location from which web application are downloaded is very important. Use SRPMs from CentOS [base] and [updates] repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource. - - - - - Prepare + Prepare Once web application source code has been downloaded, our duty is organize its files inside webenv version controlled repository. When preparing the structure keep in mind that different web applications have different visual styles, and also different ways to implement it. A convenient way to organize the file system structure would be create one development line for each web application we use inside CentOS web environment. For example, consider the following file system structure: @@ -3910,7 +3474,11 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk - + + Directories trunk Scripts Functions Prepare + Directories trunk Scripts Functions Prepare + + @@ -3930,7 +3498,7 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk Directories trunk Scripts Functions Help - Directories trunk Scripts Functions Html + Directories trunk Scripts Functions Locale Directories trunk Scripts Functions Directories
@@ -3974,13 +3542,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
- Directories trunk Scripts Functions Html - Directories trunk Scripts Functions Identity + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Path Directories trunk Scripts Functions Help Directories
- The <file>trunk/Scripts/Functions/Html</file> Directory - Directories trunk Scripts Functions Html + The <file>trunk/Scripts/Functions/Locale</file> Directory + Directories trunk Scripts Functions Locale Goals @@ -3993,180 +3561,27 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk Description + This command looks for .sh files inside Bash directory and extracts translatable strings from files, using xgettext command, in order to create a portable object template (centos-art.sh.pot) file for them. + With the centos-art.sh.pot file up to date, the centos-art command removes the temporal list of files sotred inside /tmp directory and checks the current language of your user's session to create a portable object file for it, in the location $CLI_LANG/$CLI_LANG.po. + The CLI_LANG variable discribes the locale language used to output messages inside centos-art command. The locale language used inside centos-art command is taken from the LANG environment variable. The CLI_LANG variable has the LL_CC format, where LL is a language code from the ISO-639 standard, and CC a country code from the ISO-3166 standard. + The LANG environment variable is set when you do log in to your system. If you are using a graphical session, change language to your native language and do login. That would set and exoprt the LANG environment variable to the correct value. On the other side, if you are using a text session edit your ~/.bash_profile file to set and export the LANG environment variable to your native locale as defines the locale -a command output; do logout, and do login again. + At this point, the LANG environment variable has the appropriate value you need, in order to translate centos-art.sh messages to your native language (the one set in LANG environment variable). + With the $CLI_LANG/$CLI_LANG.po file up to date, the centos-art opens it for you to update translation strings. The centos-art command uses the value of EDITOR environment variable to determine your favorite text editor. If no value is defined on EDITOR, the /usr/bin/vim text editor is used as default. + When you finishd PO file edition and quit text editor, the centos-art command creates the related machine object in the location $CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo. + At this point, all translations you made in the PO file should be available to your language when runing centos-art.sh script. + In order to make the centos-art.sh internationalization, the centos-art.sh script was modified as described in the gettext info documentation (info gettext). You can find such modifications in the following files: • - ... + trunk/Scripts/Bash/initFunctions.sh + + + trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh + + + trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh - - - - Usage - - • - - ... - - - - - - See also - - - -
- - - Directories trunk Scripts Functions Identity - Directories trunk Scripts Functions Locale - Directories trunk Scripts Functions Html - Directories -
- The <file>trunk/Scripts/Functions/Identity</file> Directory - Directories trunk Scripts Functions Identity - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - -
- - - Directories trunk Scripts Functions Locale - Directories trunk Scripts Functions Manual - Directories trunk Scripts Functions Identity - Directories -
- The <file>trunk/Scripts/Functions/Locale</file> Directory - Directories trunk Scripts Functions Locale - - Goals - - • - - ... - - - - - - Description - This command looks for .sh files inside Bash directory and extracts translatable strings from files, using xgettext command, in order to create a portable object template (centos-art.sh.pot) file for them. - With the centos-art.sh.pot file up to date, the centos-art command removes the temporal list of files sotred inside /tmp directory and checks the current language of your user's session to create a portable object file for it, in the location $CLI_LANG/$CLI_LANG.po. - The CLI_LANG variable discribes the locale language used to output messages inside centos-art command. The locale language used inside centos-art command is taken from the LANG environment variable. The CLI_LANG variable has the LL_CC format, where LL is a language code from the ISO-639 standard, and CC a country code from the ISO-3166 standard. - The LANG environment variable is set when you do log in to your system. If you are using a graphical session, change language to your native language and do login. That would set and exoprt the LANG environment variable to the correct value. On the other side, if you are using a text session edit your ~/.bash_profile file to set and export the LANG environment variable to your native locale as defines the locale -a command output; do logout, and do login again. - At this point, the LANG environment variable has the appropriate value you need, in order to translate centos-art.sh messages to your native language (the one set in LANG environment variable). - With the $CLI_LANG/$CLI_LANG.po file up to date, the centos-art opens it for you to update translation strings. The centos-art command uses the value of EDITOR environment variable to determine your favorite text editor. If no value is defined on EDITOR, the /usr/bin/vim text editor is used as default. - When you finishd PO file edition and quit text editor, the centos-art command creates the related machine object in the location $CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo. - At this point, all translations you made in the PO file should be available to your language when runing centos-art.sh script. - In order to make the centos-art.sh internationalization, the centos-art.sh script was modified as described in the gettext info documentation (info gettext). You can find such modifications in the following files: - - • - - trunk/Scripts/Bash/initFunctions.sh - - - trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh - - - trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh - - - - • - - ... - - - - - - Usage -
- - centos-art locale --edit - - Use this command to translate command-line interface output messages in the current system locale you are using (as specified in LANG environment variable). - - - - centos-art locale --list - - Use this command to see the command-line interface locale report. - - -
- - - - See also - - - -
- - - Directories trunk Scripts Functions Manual - Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Locale - Directories -
- The <file>trunk/Scripts/Functions/Manual</file> Directory - Directories trunk Scripts Functions Manual - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage • @@ -4176,6 +3591,24 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk + Usage + + + centos-art locale --edit + + Use this command to translate command-line interface output messages in the current system locale you are using (as specified in LANG environment variable). + + + + centos-art locale --list + + Use this command to see the command-line interface locale report. + + +
+ + + See also @@ -4184,8 +3617,8 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Manual + Directories trunk Scripts Functions Prepare + Directories trunk Scripts Functions Locale Directories
The <file>trunk/Scripts/Functions/Path</file> Directory @@ -4306,83 +3739,319 @@ centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
- Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Prepare + Directories trunk Scripts Functions Render Directories trunk Scripts Functions Path Directories
- The <file>trunk/Scripts/Functions/Render</file> Directory - Directories trunk Scripts Functions RenderThe render functionality exists to produce both identity and translation files on different levels of information (i.e., different languages, release numbers, architectures, etc.). - The render functionality relies on “renderable directory structures” to produce files. Renderable directory structures can be either “identity directory structures” or “translation directory structures” with special directories inside. + The <file>trunk/Scripts/Functions/Prepare</file> Directory + Directories trunk Scripts Functions Prepare + + Goals + This section exists to organize files related to centos-art.sh script prepare functionality. The prepare functionality of centos-art.sh script helps you to prepare the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository. + - Renderable identity directory structures - Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS corporate visual identity, we need to point centos-art.sh to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it. - Inside the working copy, one renderable identity directory structures represents one visual manifestation of CentOS corporate visual identity, or said differently, each visual manifestation of CentOS corporate visual identity should have one renderable identity directory structure. - Inside renderable identity directory structures, centos-art.sh can render both image-based and text-based files. Specification of whether a renderable identity directory structure produces image-based or text-based content is a configuration action that takes place in the pre-rendition configuration script of that renderable identity directory structure. - Inside renderable identity directory structures, content production is organized in different configurations. A content production configuration is a unique combination of the components that make an identity directory structure renderable. One content production configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). + Description + The first time you download CentOS Artwork Repository you need to configure your workstation in order to use centos-art.sh script. These preliminar configurations are based mainly on auxiliar RPM packages installation, symbolic links creations, and environment variables definitions. The prepare 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 prepare 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. - Design template without translation - The design template without translation configuration is based on a renderable identity directory structure with an empty translation directory structure. In this configuration, one design template produces one untranslated file. Both design templates and final untranslated files share the same file name, but they differ one another in file-type and file-extension. - For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration: + Packages + Installation of auxiliar RPM packages provides the software required to manipulate files inside the repository (e.g., image files, documentation files, translation files, script files, etc.). Most of RPM packages centos-art.sh script uses are shipped with CentOS distribution, and can be installed from CentOS base repository. The only exception is inkscape, the package we use to manipulate SVG files. The inkscape package is not inside CentOS distribution so it needs to be installed from third party repositories. + + Note Configuration of third party repositories inside CentOS distribution is described in CentOS wiki, specifically in the following URL: http://wiki.centos.org/AdditionalResources/Repositories + + Before installing packages, the centos-art.sh script uses sudo to request root privileges to execute yum 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 prepare 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. + + + + Links + Creation of symbolic links helps us to alternate between different implementations of centos-art.sh script-line (e.g., centos-art.sh, for Bash implementation; centos-art.py, for Python implementation; centos-art.pl, for Perl implementation; and so on for other implementations). The centos-art.sh script-line definition takes place inside your personal binary (~/bin/) directory in order to make the script implementation —the one that centos-art links to— available to PATH environment variable. + Creation of symbolic links helps us to reuse components from repository working copy. For example, color information files maintained inside your working copy must never be duplicated inside program-specific configuration directories that uses them in your workstation (e.g., Gimp, Inkscape, etc.). Instead, a symbolic link must be created for each one of them, from program-specific configuration directories to files in the working copy. In this configuration, when someone commits changes to color information files up to central repository, they—the changes committed— will be immediatly available to your programs the next time you update your working copy —the place inside your workstation those color information files are stored—. + Creation of symbolic links helps us to make centos-art.sh script functionalities available outside trunk/ repository directory structure, but at its same level in repository tree. This is useful if you need to use the “render” functionality of centos-art.sh under branches/ repository directory structure as you usually do inside trunk/ repository directory structure. As consequence of this configuration, automation scripts cannot be branched under branches/Scripts directory structure. + + + + Environment variables + Definition of environemnt variables helps us to set default values to our user session life. The user session environment variable defintion takes place in the user's ~/.bash_profile file. The prepare functionality of centos-art.sh script doesn't modify your ~/.bash_profile file. + The prepare functionality of centos-art.sh script evaluates the following environment variables: - One renderable identity directory structure: + EDITOR - In this example we used Identity/Path/To/Dir as the identity component we want to produce untranslated images for. Identity components can be either under trunk/ or branches/ directory structure. - The identity component (i.e., Identity/Path/To/Dir, in this case) is also the bond component we use to connect the identity directory structures with their respective auxiliar directories (i.e., translation directory structres and pre-rendition configuration structures). The bond component is the path convenction that centos-art.sh uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have. - | -trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. -|-- Tpl <-- Design template directory. -| `-- file.svg <-- Design template file. -`-- Img <-- Directory used to store final files. - `-- file.png <-- Final image-based file produced from - design template file. -]]> - Inside design template directory, design template files are based on SVGScalable Vector Graphics and use the extension .svg. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required. - In order for SVGScalable Vector Graphics files to be considered “design template” files, they should be placed under the design template directory and to have set a CENTOSARTWORK object id inside. - The CENTOSARTWORK word itself is a convenction name we use to define which object/design area, inside a design template, the centos-art.sh script will use to export as PNGPortable Network Graphic image at rendition time. Whithout such object id specification, the centos-art.sh script cannot know what object/design area you (as designer) want to export as PNGPortable Network Graphic image file. - - Note At rendition time, the content of Img/ directory structure is produced by centos-art.sh automatically. - - When a renderable identity directory structure is configured to produce image-based content, centos-art.sh produces PNGPortable Network Graphics files with the .png extension. Once the base image format has been produced, it is possible for centos-art.sh to use it in order to automatically create other image formats that may be needed (— Removed(pxref:trunk Scripts Bash Functions Render Config) —). - Inside the working copy, you can find an example of “design template without translation” configuration at trunk/Identity/Models/. - See Directories trunk Identity, for more information. + Default text editor. + The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. + If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: + + • + + /usr/bin/vim + + + /usr/bin/emacs + + + /usr/bin/nano + + + If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. - One translation directory structure: + TEXTDOMAIN - In order for an identity entry to be considered an identity renderable directory structure, it should have a translation entry. The content of the translation entry is relevant to determine how to process the identity renderable directory entry. - If the translation entry is empty (i.e., there is no file inside it), centos-art.sh interprets the identity renderable directory structure as a “design templates without translation” configuration. - | -trunk/Translations/Identity/Path/To/Dir -`-- (empty) -]]> - If the translation entry is not empty, centos-art.sh can interpret the identity renderable directory structure as one of the following configurations: “design template with translation (one-to-one)” or “design template with translation (optimized)”. Which one of these configurations is used depends on the value assigned to the matching list (MATCHINGLIST) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for. - If the matching list variable is empty (as it is by default), then “design template with translation (one-to-one)” configuration is used. In this configuration it is required that both design templates and translation files have the same file names. This way, one translation files is applied to one design template, to produce one translated image. - If the matching list variable is not empty (because you redefine it in the pre-rendition configuration script), then “design template with translation (optimized)” configuration is used instead. In this configuration, design templates and translation files don't need to have the same names since such name relationship between them is specified in the matching list properly. - — Removed(xref:trunk Translations) —, for more information. + Default domain used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. - One pre-rendition configuration script: + TEXTDOMAINDIR - In order to make an identity directory structure renderable, a pre-rendition configuration script should exist for it. The pre-rendition configuration script specifies what type of rendition does centos-art.sh will perform over the identity directory structure and how does it do that. - | -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -]]> - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - Default directory used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. + + + + LANG + + Default locale information. + This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Language step; or once installed using the system-config-language tool. + The centos-art.sh script uses the LANG environment variable to know in which language the script messages are printed out. + + + + TZ + + Default time zone representation. + This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Date and time step; or once installed using the system-config-date tool. + The centos-art.sh script doesn't use the TZ environment variable information at all. Instead, this variable is used by the system shell to show the time information according to your phisical location on planet Earth. + Inside your computer, the time information is firstly set in the BIOS clock (which may need correction), and later in the configuration process of CentOS distribution installer (or later, by any of the related configuration tools inside CentOS distribution). Generally, setting time information is a straight-forward task and configuration tools available do cover most relevant location. However, if you need a time precision not provided by the configuration tools available inside CentOS distribution then, using TZ variable may be necessary. + + Convenction In order to keep changes syncronized between central repository and its working copies: configure both repository server and workstations (i.e., the place where each working copy is set on) to use Coordinated Universal Time (UTC) as base time representation. Later, correct the time information for your specific location using time zone correction. + + The format of TZ environment variable is described in tzset(3) manual page. + + +
+ + + + Shell Script Files + The shell functionality of centos-art.sh script helps you to maintain bash scripts inside repository. For example, suppose you've created many functionalities for centos-art.sh script, and you want to use a common copyright and license note for consistency in all your script files. If you have a bunch of files, doing this one by one wouldn't be a big deal. In contrast, if the amount of files grows, updating the copyright and license note for all of them would be a task rather tedious. The shell functionality exists to solve maintainance tasks just as the one previously mentioned. + When you use shell functionality to update copyright inside script files, it is required that your script files contain (at least) the following top commentary structure: + + Relevant lines in the above structure are lines from 5 to 9. Everything else in the file is left immutable. + When you are updating copyright through shell functionality, the centos-art.sh script replaces everything in-between line 5 —the first one matching ^# Copyright .+$ string— and line 9—the first long dash separator matching ^# -+$— with the content of copyright template instance. + + Caution Be sure to add the long dash separator that matches ^# -+$ regular expression before the function definition. Otherwise, if the Copyright line is present but no long dash separator exists, centos-art.sh will remove anything in-between the Copyright line and the end of file. This way you may lost your function definitions entirely. + + The copyright template instance is created from one copyright template stored in the Config/tpl_forCopyright.sed file. The template instance is created once, and later removed when no longer needed. At this moment, when template instance is created, the centos-art.sh script takes advantage of automation in order to set copyright full name and date dynamically. + When you use shell functionality to update copyright, the first thing shell functionality does is requesting copyright information to user, and later, if values were left empty (i.e., no value was typed before pressing RET key), the shell functionality uses its own default values. + When shell functionality uses its own default values, the final copyright note looks like the following: + + Relevant lines in the above structure are lines from 5 to 22. Pay attention how the copyright line was built, and how the license was added into the top comment where previously was just three dots. Everything else in the file was left immutable. + To change copyright information (i.e., full name or year information), run the shell functionality over the root directory containing the script files you want to update copyright in and enter the appropriate information when it be requested. You can run the shell functionality as many times as you need to. + To change copyright license (i.e., the text in-between lines 7 and 20), you need to edit the Config/tpl_forCopyright.sed file, set the appropriate information, and run the shell functionality once again for changes to take effect over the files you specify. + + Important The centos-art.sh script is released as: + + 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-devel@centos-art.shCentOS Developers mailing list. + See file file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING, for a complete license description. + + + + + SVG Files + 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 metadata used is defined by Inkscape 0.46 using the SVG standard markup. The centos-art.sh script replaces everything in-between <metadata and </metadata> tags with a predefined metadata template we've set for this purpose. + The metadata template was created using the metadata information of a file which, using Inkscape 0.46, all metadata fields were set. This created a complete markup representation of how SVG metadata would look like. Later, we replaced every single static value with a translation marker in the form =SOMETEXT=, where SOMETEXT is the name of its main opening tag. Later, we transform the metadata template into a sed replacement set of commads escaping new lines at the end of each line. + With metadata template in place, the centos-art.sh script uses it to create a metadata template instance for the file being processed currently. The metadata template instance contains the metadata portion of sed replacement commands with translation markers already traduced. In this action, instance creation, is where we take advantage of automation and generate metadata values like title, date, keywords, source, identifier, and relation dynamically, based on the file path centos-art.sh script is currently creating metadata information for. + With metadata template instance in place, the centos-art.sh script uses it to replace real values inside all .svg files under the current location you're running the centos-art.sh script on. Default behaviour is to ask user to enter each metadatum required, one by one. If user leaves metadatum empty, by pressing RET key, centos-art.sh uses its default value. + Many of the no-longer-used gradients, patterns, and markers (more precisely, those which you edited manually) remain in the corresponding palettes and can be reused for new objects. However if you want to optimize your document, use the Vacuum Defs command in File menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller. + If you have one or two couple of files, removing unused definitions using the graphical interface may be enough to you. In contrast, if you have dozens or even houndreds of scalable vector graphics files to maintain it is not a fun task to use the graphical interface to remove unused definitions editing those files one by one. + To remove unused definitions from several scalable vector graphics files, the centos-art.sh script uses Inkscape command-line interface, specifically with the option. + + + + XHTML Files + + + + + Usage + + + centos-art prepare --packages + + Verify required packages your workstation needs in order to run the centos-art.sh script correctly. If there are missing packages, the centos-art.sh script asks you to confirm their installation. When installing packages, the centos-art.sh script uses the yum application in order to achieve the task. + In case all packages required by centos-art.sh script are already installed in your workstation, the message The required packages are already installed. is output for you to know. + + + + centos-art prepare --links + + Verify required links your workstation needs in order to run the centos-art command correctly. If any required link is missing, the centos-art.sh script asks you to confirm their installation. To install required links, the centos-art.sh script uses the ln command. + In case all links required by centos-art.sh script are already created in your workstation, the message The required links are already installed. is output for you to know. + In case a regular file exists with the same name of a required link, the centos-art.sh script outputs the Already exists as regular file. message when listing required links that will be installed. Of course, as there is already a regular file where must be a link, no link is created. In such cases the centos-art.sh script will fall into a continue installation request for that missing link. To end this continue request you can answer No, or remove the existent regular file to let centos-art.sh script install the link on its place. + + + + centos-art prepare --environment + centos-art prepare --environment --filter='regex' + + Output a brief description of environment variables used by centos-art.sh script. + If --filter option is provided, output is reduced as defined in the regex regular expression value. If --filter option is specified but regex value is not, the centos-art.sh script outputs information as if --filter option had not been provided at all. + + +
+ + + + See also + + + Directories trunk Scripts + Directories trunk Scripts + + + + Directories trunk Scripts Functions + Directories trunk Scripts Functions + + + + +
+ + + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Prepare + Directories +
+ The <file>trunk/Scripts/Functions/Render</file> Directory + Directories trunk Scripts Functions RenderThe render functionality exists to produce both identity and translation files on different levels of information (i.e., different languages, release numbers, architectures, etc.). + The render functionality relies on “renderable directory structures” to produce files. Renderable directory structures can be either “identity directory structures” or “translation directory structures” with special directories inside. + + + Renderable identity directory structures + Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS corporate visual identity, we need to point centos-art.sh to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it. + Inside the working copy, one renderable identity directory structures represents one visual manifestation of CentOS corporate visual identity, or said differently, each visual manifestation of CentOS corporate visual identity should have one renderable identity directory structure. + Inside renderable identity directory structures, centos-art.sh can render both image-based and text-based files. Specification of whether a renderable identity directory structure produces image-based or text-based content is a configuration action that takes place in the pre-rendition configuration script of that renderable identity directory structure. + Inside renderable identity directory structures, content production is organized in different configurations. A content production configuration is a unique combination of the components that make an identity directory structure renderable. One content production configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). + + + Design template without translation + The design template without translation configuration is based on a renderable identity directory structure with an empty translation directory structure. In this configuration, one design template produces one untranslated file. Both design templates and final untranslated files share the same file name, but they differ one another in file-type and file-extension. + For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration: + + + One renderable identity directory structure: + + In this example we used Identity/Path/To/Dir as the identity component we want to produce untranslated images for. Identity components can be either under trunk/ or branches/ directory structure. + The identity component (i.e., Identity/Path/To/Dir, in this case) is also the bond component we use to connect the identity directory structures with their respective auxiliar directories (i.e., translation directory structres and pre-rendition configuration structures). The bond component is the path convenction that centos-art.sh uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have. + | +trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. +|-- Tpl <-- Design template directory. +| `-- file.svg <-- Design template file. +`-- Img <-- Directory used to store final files. + `-- file.png <-- Final image-based file produced from + design template file. +]]> + Inside design template directory, design template files are based on SVGScalable Vector Graphics and use the extension .svg. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required. + In order for SVGScalable Vector Graphics files to be considered “design template” files, they should be placed under the design template directory and to have set a CENTOSARTWORK object id inside. + The CENTOSARTWORK word itself is a convenction name we use to define which object/design area, inside a design template, the centos-art.sh script will use to export as PNGPortable Network Graphic image at rendition time. Whithout such object id specification, the centos-art.sh script cannot know what object/design area you (as designer) want to export as PNGPortable Network Graphic image file. + + Note At rendition time, the content of Img/ directory structure is produced by centos-art.sh automatically. + + When a renderable identity directory structure is configured to produce image-based content, centos-art.sh produces PNGPortable Network Graphics files with the .png extension. Once the base image format has been produced, it is possible for centos-art.sh to use it in order to automatically create other image formats that may be needed (— Removed(pxref:trunk Scripts Bash Functions Render Config) —). + Inside the working copy, you can find an example of “design template without translation” configuration at trunk/Identity/Models/. + See Directories trunk Identity, for more information. + + + + One translation directory structure: + + In order for an identity entry to be considered an identity renderable directory structure, it should have a translation entry. The content of the translation entry is relevant to determine how to process the identity renderable directory entry. + If the translation entry is empty (i.e., there is no file inside it), centos-art.sh interprets the identity renderable directory structure as a “design templates without translation” configuration. + | +trunk/Translations/Identity/Path/To/Dir +`-- (empty) +]]> + If the translation entry is not empty, centos-art.sh can interpret the identity renderable directory structure as one of the following configurations: “design template with translation (one-to-one)” or “design template with translation (optimized)”. Which one of these configurations is used depends on the value assigned to the matching list (MATCHINGLIST) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for. + If the matching list variable is empty (as it is by default), then “design template with translation (one-to-one)” configuration is used. In this configuration it is required that both design templates and translation files have the same file names. This way, one translation files is applied to one design template, to produce one translated image. + If the matching list variable is not empty (because you redefine it in the pre-rendition configuration script), then “design template with translation (optimized)” configuration is used instead. In this configuration, design templates and translation files don't need to have the same names since such name relationship between them is specified in the matching list properly. + — Removed(xref:trunk Translations) —, for more information. + + + + One pre-rendition configuration script: + + In order to make an identity directory structure renderable, a pre-rendition configuration script should exist for it. The pre-rendition configuration script specifies what type of rendition does centos-art.sh will perform over the identity directory structure and how does it do that. + | +trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir +`-- render.conf.sh +]]> + In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: + Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Shell Directories trunk Scripts Functions Render Directories
@@ -4812,430 +4480,6 @@ ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' - -
- - - Directories trunk Scripts Functions Shell - Directories trunk Scripts Functions Svg - Directories trunk Scripts Functions Render Config - Directories -
- The <file>trunk/Scripts/Functions/Shell</file> Directory - Directories trunk Scripts Functions Shell - - Goals - This section exists to organize files related to shell functionality of centos-art.sh script. - - - - Description - The shell functionality of centos-art.sh script helps you to maintain bash scripts inside repository. For example, suppose you've created many functionalities for centos-art.sh script, and you want to use a common copyright and license note for consistency in all your script files. If you have a bunch of files, doing this one by one wouldn't be a big deal. In contrast, if the amount of files grows, updating the copyright and license note for all of them would be a task rather tedious. The shell functionality exists to solve maintainance tasks just as the one previously mentioned. - When you use shell functionality to update copyright inside script files, it is required that your script files contain (at least) the following top commentary structure: - - Figure - - -
- - Relevant lines in the above structure are lines from 5 to 9. Everything else in the file is left immutable. - When you are updating copyright through shell functionality, the centos-art.sh script replaces everything in-between line 5 —the first one matching ^# Copyright .+$ string— and line 9—the first long dash separator matching ^# -+$— with the content of copyright template instance. - - Caution Be sure to add the long dash separator that matches ^# -+$ regular expression before the function definition. Otherwise, if the Copyright line is present but no long dash separator exists, centos-art.sh will remove anything in-between the Copyright line and the end of file. This way you may lost your function definitions entirely. - - The copyright template instance is created from one copyright template stored in the Config/tpl_forCopyright.sed file. The template instance is created once, and later removed when no longer needed. At this moment, when template instance is created, the centos-art.sh script takes advantage of automation in order to set copyright full name and date dynamically. - When you use shell functionality to update copyright, the first thing shell functionality does is requesting copyright information to user, and later, if values were left empty (i.e., no value was typed before pressing RET key), the shell functionality uses its own default values. - When shell functionality uses its own default values, the final copyright note looks like the following: - - Figure - - - - - Relevant lines in the above structure are lines from 5 to 22. Pay attention how the copyright line was built, and how the license was added into the top comment where previously was just three dots. Everything else in the file was left immutable. - To change copyright information (i.e., full name or year information), run the shell functionality over the root directory containing the script files you want to update copyright in and enter the appropriate information when it be requested. You can run the shell functionality as many times as you need to. - To change copyright license (i.e., the text in-between lines 7 and 20), you need to edit the Config/tpl_forCopyright.sed file, set the appropriate information, and run the shell functionality once again for changes to take effect over the files you specify. - - Important The centos-art.sh script is released as: - - 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-devel@centos-art.shCentOS Developers mailing list. - - - - - Usage -
The functions script base comment structureThe function script comment example
- - 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 argument, the list of files to process is reduced as specified in regex regular expression. Inside centos-art.sh script, the regex regular expression is used in combination with find command to look for files matching the regular expression path pattern. - - Warning In order for regex regular expression to match a file, the regex regular expresion must match the whole file path not just the file name. - - For example, if you want to match all render.conf.sh files inside path/to/dir, use the .+/render.conf regular expression. Later, centos-art.sh script uses this value inside ^$REGEX\.sh$ expression in order to build the final regular expression (i.e., ^.+/render.conf\.sh$) that is evaluated against available file paths inside the list of files to process. - Exceptionally, when you provide 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. - - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - - -
- - - Directories trunk Scripts Functions Svg - Directories trunk Scripts Functions Verify - Directories trunk Scripts Functions Shell - Directories -
- The <file>trunk/Scripts/Functions/Svg</file> Directory - Directories trunk Scripts Functions Svg - - Goals - This section exists to organize files related to svg functionality of centos-art.sh script. - - - - 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. - Metadata maintainance - - Metadata maintainance - The metadata used is defined by Inkscape 0.46 using the SVG standard markup. The centos-art.sh script replaces everything in-between <metadata and </metadata> tags with a predefined metadata template we've set for this purpose. - The metadata template was created using the metadata information of a file which, using Inkscape 0.46, all metadata fields were set. This created a complete markup representation of how SVG metadata would look like. Later, we replaced every single static value with a translation marker in the form =SOMETEXT=, where SOMETEXT is the name of its main opening tag. Later, we transform the metadata template into a sed replacement set of commads escaping new lines at the end of each line. - With metadata template in place, the centos-art.sh script uses it to create a metadata template instance for the file being processed currently. The metadata template instance contains the metadata portion of sed replacement commands with translation markers already traduced. In this action, instance creation, is where we take advantage of automation and generate metadata values like title, date, keywords, source, identifier, and relation dynamically, based on the file path centos-art.sh script is currently creating metadata information for. - With metadata template instance in place, the centos-art.sh script uses it to replace real values inside all .svg files under the current location you're running the centos-art.sh script on. Default behaviour is to ask user to enter each metadatum required, one by one. If user leaves metadatum empty, by pressing RET key, centos-art.sh uses its default value. - The centos-art.sh script modifies the following metadata: - - - Title - - Name by which this document is formally known. If no value is set here, centos-art.sh script uses the file name as title. - - - - Date - - Date associated with the creation of this document (YYYY-MM-DD). If no value is set here, centos-art.sh script uses the current date information as in date +%Y-%m-%d. - - - - Creator - - Name of entity primarily responsible for making the content of this document. If no value is set here, centos-art.sh script uses the string The CentOS Project. - - - - Rights - - Name of entity with rights to the intellectual Property of this document. If no value is set here, centos-art.sh script uses the string The CentOS Project. - - - - Publisher - - Name of entity responsible for making this document available. If no value is set here, centos-art.sh script uses the string The CentOS Project. - - - - Identifier - - Unique URI to reference this document. If no value is set here, centos-art.sh script uses the current file path to build the related url that points to current file location inside repository central server. - - - - Source - - Unique URI to reference the source of this document. If no value is set here, centos-art.sh script uses current file path to build the related url that points to current file location inside repository central server. - - - - Relation - - Unique URI to a related document. If no value is set here, centos-art.sh script uses current file path to build the related url that points to current file location inside repository central server. - - - - Language - - Two-letter language tag with optional subtags for the language of this document. (e.g. en-GB). If no value is set here, centos-art.sh script uses the current locale information as in cli_getCurrentLocale function. - - - - Keywords - - The topic of this document as comma-separated key words, prhases, or classifications. If no value is set here, centos-art.sh script uses file path to build - - - - Coverage - - Extent or scope of this document. If no value is set here, centos-art.sh script uses the string The CentOS Project. - - - - Description - - Description about the document. If no value is set here, centos-art.sh script uses uses empty value as default. - - - - Contributors - - People that contributes in the creation/maintainance of the document. If no value is set here, centos-art.sh script uses uses empty value as default. - - -
- The License metadatum is not set as a choise, by now. It is fixed http://creativecommons.org/licenses/by-sa/3.0/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. - Unused definitions - - - - Unused definitions - Many of the no-longer-used gradients, patterns, and markers (more precisely, those which you edited manually) remain in the corresponding palettes and can be reused for new objects. However if you want to optimize your document, use the Vacuum Defs command in File menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller. - If you have one or two couple of files, removing unused definitions using the graphical interface may be enough to you. In contrast, if you have dozens or even houndreds of scalable vector graphics files to maintain it is not a fun task to use the graphical interface to remove unused definitions editing those files one by one. - To remove unused definitions from several scalable vector graphics files, the centos-art.sh script uses Inkscape command-line interface, specifically with the option. - - - - - Usage - - - centos-art svg --update-metadata='path/to/dir' - centos-art svg --update-metadata='path/to/dir' --filter='regex' - - Use these commands to update metadata information to .svg files under path/to/dir directory. - - - - centos-art svg --vacuum-defs='path/to/dir' - centos-art svg --vacuum-defs='path/to/dir' --filter='regex' - - Use these commands to remove unused definitions inside .svg files under path/to/dir directory. - - -
- When you provide 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 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. - - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - - -
- - - Directories trunk Scripts Functions Verify - Directories trunk Scripts Functions Svg - Directories -
- The <file>trunk/Scripts/Functions/Verify</file> Directory - Directories trunk Scripts Functions Verify - - Goals - This section exists to organize files related to centos-art.sh script verify functionality. The verify functionality of centos-art.sh script helps you to verify the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository. - - - - Description - The first time you download CentOS Artwork Repository you need to configure your workstation in order to use centos-art.sh script. These preliminar configurations are based mainly on auxiliar RPM packages installation, symbolic links creations, and environment variables definitions. The verify functionality of centos-art.sh script guides you through this preliminar configuration process. - If this is the first time you run centos-art.sh script, the appropriate way to use its verify functionality is not using the centos-art.sh script directly, but the absolute path to centos-art.sh script instead (i.e., ~/artwork/trunk/Scripts/Bash/centos-art.sh). This is necessary because centos-art symbolic link, under ~/bin/ directory, has not been created yet. - - - Packages - Installation of auxiliar RPM packages provides the software required to manipulate files inside the repository (e.g., image files, documentation files, translation files, script files, etc.). Most of RPM packages centos-art.sh script uses are shipped with CentOS distribution, and can be installed from CentOS base repository. The only exception is inkscape, the package we use to manipulate SVG files. The inkscape package is not inside CentOS distribution so it needs to be installed from third party repositories. - - Note Configuration of third party repositories inside CentOS distribution is described in CentOS wiki, specifically in the following URL: http://wiki.centos.org/AdditionalResources/Repositories - - Before installing packages, the centos-art.sh script uses sudo to request root privileges to execute yum 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. - - - - Links - Creation of symbolic links helps us to alternate between different implementations of centos-art.sh script-line (e.g., centos-art.sh, for Bash implementation; centos-art.py, for Python implementation; centos-art.pl, for Perl implementation; and so on for other implementations). The centos-art.sh script-line definition takes place inside your personal binary (~/bin/) directory in order to make the script implementation —the one that centos-art links to— available to PATH environment variable. - Creation of symbolic links helps us to reuse components from repository working copy. For example, color information files maintained inside your working copy must never be duplicated inside program-specific configuration directories that uses them in your workstation (e.g., Gimp, Inkscape, etc.). Instead, a symbolic link must be created for each one of them, from program-specific configuration directories to files in the working copy. In this configuration, when someone commits changes to color information files up to central repository, they—the changes committed— will be immediatly available to your programs the next time you update your working copy —the place inside your workstation those color information files are stored—. - Creation of symbolic links helps us to make centos-art.sh script functionalities available outside trunk/ repository directory structure, but at its same level in repository tree. This is useful if you need to use the “render” functionality of centos-art.sh under branches/ repository directory structure as you usually do inside trunk/ repository directory structure. As consequence of this configuration, automation scripts cannot be branched under branches/Scripts directory structure. - - - - Environment variables - Definition of environemnt variables helps us to set default values to our user session life. The user session environment variable defintion takes place in the user's ~/.bash_profile file. The verify functionality of centos-art.sh script doesn't modify your ~/.bash_profile file. - The verify functionality of centos-art.sh script evaluates the following environment variables: - - - EDITOR - - Default text editor. - The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. - If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: - - • - - /usr/bin/vim - - - /usr/bin/emacs - - - /usr/bin/nano - - - If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. - - - - TEXTDOMAIN - - Default domain used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. - - - - TEXTDOMAINDIR - - Default directory used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. - - - - LANG - - Default locale information. - This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Language step; or once installed using the system-config-language tool. - The centos-art.sh script uses the LANG environment variable to know in which language the script messages are printed out. - - - - TZ - - Default time zone representation. - This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Date and time step; or once installed using the system-config-date tool. - The centos-art.sh script doesn't use the TZ environment variable information at all. Instead, this variable is used by the system shell to show the time information according to your phisical location on planet Earth. - Inside your computer, the time information is firstly set in the BIOS clock (which may need correction), and later in the configuration process of CentOS distribution installer (or later, by any of the related configuration tools inside CentOS distribution). Generally, setting time information is a straight-forward task and configuration tools available do cover most relevant location. However, if you need a time precision not provided by the configuration tools available inside CentOS distribution then, using TZ variable may be necessary. - - Convenction In order to keep changes syncronized between central repository and its working copies: configure both repository server and workstations (i.e., the place where each working copy is set on) to use Coordinated Universal Time (UTC) as base time representation. Later, correct the time information for your specific location using time zone correction. - - The format of TZ environment variable is described in tzset(3) manual page. - - -
- - - - - Usage - - - centos-art verify --packages - - Verify required packages your workstation needs in order to run the centos-art.sh script correctly. If there are missing packages, the centos-art.sh script asks you to confirm their installation. When installing packages, the centos-art.sh script uses the yum application in order to achieve the task. - In case all packages required by centos-art.sh script are already installed in your workstation, the message The required packages are already installed. is output for you to know. - - - - centos-art verify --links - - Verify required links your workstation needs in order to run the centos-art command correctly. If any required link is missing, the centos-art.sh script asks you to confirm their installation. To install required links, the centos-art.sh script uses the ln command. - In case all links required by centos-art.sh script are already created in your workstation, the message The required links are already installed. is output for you to know. - In case a regular file exists with the same name of a required link, the centos-art.sh script outputs the Already exists as regular file. message when listing required links that will be installed. Of course, as there is already a regular file where must be a link, no link is created. In such cases the centos-art.sh script will fall into a continue installation request for that missing link. To end this continue request you can answer No, or remove the existent regular file to let centos-art.sh script install the link on its place. - - - - centos-art verify --environment - centos-art verify --environment --filter='regex' - - Output a brief description of environment variables used by centos-art.sh script. - If --filter option is provided, output is reduced as defined in the regex regular expression value. If --filter option is specified but regex value is not, the centos-art.sh script outputs information as if --filter option had not been provided at all. - - -
- - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - -