diff --git a/Manual/Directories/trunk/Identity.texi b/Manual/Directories/trunk/Identity.texi index 8712eaa..ad28eca 100644 --- a/Manual/Directories/trunk/Identity.texi +++ b/Manual/Directories/trunk/Identity.texi @@ -18,10 +18,7 @@ recognizability, reputation, structure and identification to The CentOS Project organization by means of @emph{Corporate Design}, @emph{Corporate Communication}, and @emph{Corporate Behaviour}. -@float Figure, The CentOS Project Corporate Identity @image{trunk/Identity/Images/Manual/Corporate/monolithic,450pt,,,jpg} -@caption{The CentOS Project Corporate Identity.} -@end float @subsubheading Corporate Mission diff --git a/Manual/Directories/trunk/Identity/Brushes.texi b/Manual/Directories/trunk/Identity/Brushes.texi index 2c8d28c..49210e7 100755 --- a/Manual/Directories/trunk/Identity/Brushes.texi +++ b/Manual/Directories/trunk/Identity/Brushes.texi @@ -14,7 +14,6 @@ format and later exported to any of the brush formats recognized by GIMP (e.g., @file{.gbr} or @file{.gih}) using the same name of its source file. -@float Figure, Brush file format and directory structure @verbatim 1. Common brushes 2. Theme-specific brushes ---------------------- ----------------------------------------------------------- @@ -27,8 +26,6 @@ trunk/Identity/Brushes trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brus |-- 2.gih |-- 2.gih `-- 3.gbr `-- 3.gbr @end verbatim -@caption{Brush file format and directory structure.} -@end float In order for both common brushes and theme-specific brushes to be loaded by GIMP, related @file{.gbr} and @file{.gih} brush files need @@ -66,25 +63,19 @@ both the brush file name and the suffix information, it is possible to build unique names for links under @file{~/.gimp-2.2/brushes} directory, scalably. -@float Figure, Common brushes path relation @verbatim trunk/Identity/Brushes |-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-1.gbr (link) |-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-2.gbr (link) `-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-3.gbr (link) @end verbatim -@caption{Common brushes path relation.} -@end float -@float Figure, Theme-specific brushes path relation @verbatim trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes |-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-1.gbr (link) |-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-2.gbr (link) `-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-3.gbr (link) @end verbatim -@caption{Theme-specific brushes path relation.} -@end float Brushes produced with GIMP has a description field associated that is shown in the Brushes panel of GIMP. This description is set when the diff --git a/Manual/Directories/trunk/Identity/Fonts.texi b/Manual/Directories/trunk/Identity/Fonts.texi index 99c7266..ea4b08b 100644 --- a/Manual/Directories/trunk/Identity/Fonts.texi +++ b/Manual/Directories/trunk/Identity/Fonts.texi @@ -9,15 +9,9 @@ repository and how to make them available for you to use in The CentOS Project Corporate Identity is attached to @samp{DejaVu LGC} font-family and @samp{Denmark} font-family. -@float Figure, DejaVu LGC font family @image{trunk/Identity/Images/Manual/Fonts/dejavu-lgc,430pt,,,jpg} -@caption{DejaVu-LGC font-family.} -@end float -@float Figure, Denmark font family @image{trunk/Identity/Images/Manual/Fonts/denmark,430pt,,,jpg} -@caption{Denmark font-family.} -@end float @quotation @strong{Caution} @@ -43,3 +37,8 @@ intruce a clearer copyright and license notice. @end itemize @subheading See also + +@itemize +@item @ref{Directories trunk Identity}. +@item @ref{Directories trunk}. +@end itemize diff --git a/Manual/Directories/trunk/Identity/Models/Brands.texi b/Manual/Directories/trunk/Identity/Models/Brands.texi index 4c33e99..ac95326 100644 --- a/Manual/Directories/trunk/Identity/Models/Brands.texi +++ b/Manual/Directories/trunk/Identity/Models/Brands.texi @@ -24,10 +24,7 @@ it below @samp{CentOS} word and aligned with it on the left. The distance between @samp{CentOS} word and phrase @samp{Community Enterprise Operating System} have the size in points the phrase has. -@float Figure, The CentOS logo construction @image{trunk/Identity/Images/Manual/Brands/Logos/a,,,,} -@caption{The CentOS logo construction} -@end float When the CentOS release brand is built, use @samp{Denmark} typography for the release number. The release number size is two times larger diff --git a/Manual/Directories/trunk/Scripts.texi b/Manual/Directories/trunk/Scripts.texi index 960aa4c..d786849 100644 --- a/Manual/Directories/trunk/Scripts.texi +++ b/Manual/Directories/trunk/Scripts.texi @@ -14,118 +14,151 @@ here. @subheading Description -The best way to understand @file{centos-art.sh} automation script is -studying its source code. However, as start point, you may prefer to -read an introductory resume before diving into the source code -details. - -The @file{centos-art.sh} script is written in Bash. Most tasks, inside -@file{centos-art.sh} script, have been organized in many specific -functionalities that you can invoke from the @command{centos-art} -command-line interface. - -When you type the @command{centos-art} command in your terminal, the -operating system trys to execute that command. In order to execute the -command, the operating system needs to know where it is, so the -operating system uses the @var{PATH} environment variable to look for -that command location. If your system was prepared to use CentOS -Artwork Repository correctly (@pxref{Directories trunk Scripts -Functions Prepare}) you should have a symbolic link inside -@file{~/bin} directory that points to the @file{centos-art.sh} script -file. As @file{~/bin} directory is, by default, inside @var{PATH} -environment variable, the execution of @command{centos-art} command -runs the @file{centos-art.sh} script. - -When @file{centos-art.sh} script is executed, the first it does is -initializing global variables (e.g., @command{gettext} variables) and -global function scripts. Global function scripts are located inside -@file{trunk/Scripts/Functions} directory and their file names begin -with @samp{cli}. Global function scripts provide common -functionalities that can be used anywhere inside @file{centos-art.sh} -script execution environment. - -Once global variables and function scripts have been loaded, -@file{centos-art.sh} script executes the @command{cli} global function -from @file{cli.sh} function script to retrive command-line arguments -and define some default values that may be used later by specific -function scripts (@pxref{Directories trunk Scripts Functions}). - -As convenction, the @file{centos-art.sh} command-line arguments have -the following format: +The best way to understand the @command{centos-art.sh} script is +studying and improving its source code. However, as start point, you +may prefer to read an introductory resume before diving into the +source code details. In this section we identify the different parts +the @command{centos-art.sh} script is made of and how these parts +interact one another. + +@subsubheading Execution environments + +The @command{centos-art.sh} script is basically made of four execution +environments which are named @emph{script}, @emph{global}, +@emph{specific} and @emph{action}. These execution environments are +nested one into another and provide different definition levels for +variables and functions. In this design, variables and functions +defined in higher execution environments are available on lower +execution environments, but variables and functions defined in lower +execution environments are not available for higher execution +enviroments. @verbatim -centos-art function path/to/dir --option='value' -@end verbatim - -In the above example, @samp{centos-art} is the command you use to -invoke @file{centos-art.sh} script. The @samp{arg1} is required and -represents the functionality you want to perform (e.g., -@option{verify}, @option{render}, @option{locale}, @option{manual}, -etc.). The remaining arguments are modifiers to @option{arg1}. The -@option{--arg2} definition is required and represets, specifically, -the action inside the functionality you want to perform. The -@option{--arg3} and on, are optional. - -Once command-line arguments have been retrived, the -@file{centos-art.sh} script loads specific functionalities using the -@file{cli_getFunctions.sh} function script. Only one specific -functionality can be loaded at one script execution I.e., you run -@command{centos-art.sh} script to run just one functionality. - -@float Figure, Functionalities initialization -@verbatim +----------------------------------------------------------------------+ | [centos@host]$ centos-art function path/to/dir --option='value' | +----------------------------------------------------------------------+ | ~/bin/centos-art --> ~/artwork/trunk/Scripts/centos-art.sh | +---v--------------------------------------------------------------v---+ | centos-art.sh | - +-v--------------------------------------------------------v---+ - . | cli $@ | . - . +-v--------------------------------------------------v---+ . - . . | cli_getFunctions | . . - . . +-v-----------v-----------v-----------v------------+ . . - . . . | function1 | function2 | functionN | . . . - . . . +-----------+-----------+-----------+ . . . - . . .................................................... . . - . .......................................................... . + +---v------------------------------------------------------v---+ + . | cli $@ | . + . +---v----------------------------------------------v---+ . + . . | cli_getFunctions | . . + . . +---v--------------------------------------v---+ . . + . . . | function | . . . + . . . +---v------------------------------v---+ . . . + . . . . | function_getArguments | . . . . + . . . . | function_doSomething | . . . . + . . . . +------------------------------+ . . . . + . . . . . . . . + . . . . Execution environment (action) . . . . + . . . ........................................ . . . + . . . . . . + . . . Execution environment (specific) . . . + . . ................................................ . . + . . . . + . . Execution environment (global) . . + . ........................................................ . + . . + . Execution environment (script) . ................................................................ @end verbatim -@caption{Functionalities initialization environment.} -@end float -Functionalities are implemented by means of actions. Once the -functionality has been initiazalized, actions initialization take -place for that functionality. Actions initialization model is very -similar to functions initialization model. But with the difference, -that actions are loaded inside function environment, and so, share -variables and functions defined inside function environment. +The script execution environment exists to provide script definitions +that can't be set anywhere else inside the script. Example of such +definitions include initialization of internationalization through +@command{gettext} program, script personal information and +initialization of global functionalities. + +The global execution environment exists to provide definitions that +can't be set anywhere else inside the script. Example of such +definitions include initialization of functionalities (e.g., +@code{cli_printMessage}, @code{cli_getCurrentLocale}, +@code{cli_checkFiles}, etc.) and variables (e.g., @var{FUNCNAM}, +@var{FUNCDIR}, @var{FUNCDIRNAM}, @var{ARGUMENTS}, etc.) that can be +both used on specific and action execution environments, only. + +The specific execution environment exists to provide definitions that +can't be set anywhere else inside the script. Example of such +definitions include initialization of specifc functionalities (e.g., +@code{render}, @code{help}, @code{locale}, etc.) and specific +variables (@var{ACTIONNAM}, @var{ACTIONVAL}, etc.) that can be used on +action execution environment only. + +The action execution environment exists to perform the script actions +themselves. It is here where we perform content rendition, content +documentation, content localization and whatever action you plan for +the @command{centos-art.sh} script to perform. For example, if you +passed the @code{render} value as first argument to +@command{centos-art.sh} command-line, the script performs the content +rendition action through the @code{render} function which is defined +in the @file{render.sh} file under +@file{trunk/Scripts/Functions/Render} directory. Is there, inside +@code{render} functionality were the action execution environment +takes place exactly. + +@subsubheading Command-line interface + +When the @command{centos-art} command is executed in a bash terminal, +the bash interpreter uses the @env{PATH} environment variable to find +where such command is. In order to run the @command{centos-art}, it +must exist either as a link to an executable file or an executable +file by its own, in any of the paths provided by @env{PATH} +environment variable. Otherwise, the bash interpreter will print an +error message and prompt you back to type a valid command. + +By default, after installing The CentOS Distribution, there is no +@command{centos-art} command available in the @env{PATH} environment +variable for you to execute. The @command{centos-art} command is made +available in your workstation as result of executing the +@code{prepare} functionality of @command{centos-art.sh} script +(@pxref{Directories trunk Scripts Functions Prepare}) which requires +you had previously downloaded a working copy of CentOS Artwork +Repository in your workstation. + +When the @command{centos-art} is executed, the first positional +parameter passed is required and represents the name of the function +you want to perform (e.g., @code{render} for content rendition, +@code{locale} for content localization, etc.). Beyond the first +positional parameter you can provide either option or non-option +parameters in no specific order. There are also, option parameters +with arguments and without arguments. Frequently, non-option paramters +are used to specify the path location inside the repository where the +function will be performed in (e.g., the directory structure do you +want to produce content for) and option parameters to specify how such +functionality is performed (e.g., do you want to go quietly? do you +want to do filtering? etc.). -@float Figure, Actions initialization @verbatim -+----------------------------------------------------------------------+ -| cli_getFunctions | -+---v----------------------------v----v----------------------------v---+ -. | function1 | | function2 | . -. +-v------------------------v-+ +-v------------------------v-+ . -. . | function1_getArguments | . . | function2_getArguments | . . -. . +-v--------------------v-+ . . +-v--------------------v-+ . . -. . . | action 1 | . . . . | action 1 | . . . -. . . | action 2 | . . . . | action 2 | . . . -. . . | action N | . . . . | action N | . . . -. . . +--------------------+ . . . . +--------------------+ . . . -. . .......................... . . .......................... . . -. .............................. .............................. . -........................................................................ + A B C D E +---------- ------- ----------- ---------------- ------- +centos-art funcnam path/to/dir --filter='regex' --quiet +---------- ------- ----------- ---------------- ------- + + A = The centos-art.sh script command-line. + B = The centos-art.sh function name. + C = Non-option parameter. + D = Option parameter (with argument). + E = Option parameter (without argument). @end verbatim -@caption{Actions initialization environment.} -@end float + +@subsubheading Parsing command-line options + +The action of parsing options is performed through @command{getopt} +and results particularly interesting. @command{getopt} breaks up +(parse) options in command lines and checks for legal options using +the GNU @code{getopt} routines to do this. One important consideration +on @command{centos-art.sh} script design is that positional parameters +are retrived in the @code{cli} function but parsed on each specific +function, individually. There isn't a big parsing definition to cover +all specific functions, but one parsing definitions for each specific +functions. @subheading Usage -The @file{centos-art.sh} script usage information is described inside -each specific function documentation (@pxref{Directories trunk Scripts -Functions}). +@itemize +@item @xref{Directories trunk Scripts Functions}. +@end itemize @subheading See also diff --git a/Manual/Directories/trunk/Scripts/Functions.texi b/Manual/Directories/trunk/Scripts/Functions.texi index 3275053..01e8633 100755 --- a/Manual/Directories/trunk/Scripts/Functions.texi +++ b/Manual/Directories/trunk/Scripts/Functions.texi @@ -324,11 +324,10 @@ The following specific functions of @file{centos-art.sh} script, are available for you to use: @itemize +@item @xref{Directories trunk Scripts Functions Help}. +@item @xref{Directories trunk Scripts Functions Locale}. @item @xref{Directories trunk Scripts Functions Prepare}. @item @xref{Directories trunk Scripts Functions Render}. -@item @xref{Directories trunk Scripts Functions Locale}. -@item @xref{Directories trunk Scripts Functions Help}. -@item --- @strong{Removed}(xref:Directories trunk Scripts Functions Path) ---. @item @xref{Directories trunk Scripts Functions Tuneup}. @end itemize diff --git a/Manual/Directories/trunk/Scripts/Functions/Prepare.texi b/Manual/Directories/trunk/Scripts/Functions/Prepare.texi index e71d550..47fe398 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Prepare.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Prepare.texi @@ -1,114 +1,83 @@ @subheading Goals -This section exists to organize files related to @file{centos-art.sh} -script @samp{prepare} functionality. The @samp{prepare} functionality -of @file{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. +This section describes the @code{prepare} functionality of +@command{centos-art.sh} script and the preliminar steps you need to +follow in order to get your workstation ready for using the CentOS +Artwork Repository. @subheading Description -The first time you download CentOS Artwork Repository you need to -configure your workstation in order to use @file{centos-art.sh} -script. These preliminar configurations are based mainly on auxiliar -RPM packages installation, symbolic links creations, and environment -variables definitions. The @samp{prepare} functionality of -@file{centos-art.sh} script guides you through this preliminar -configuration process. - -If this is the first time you run @file{centos-art.sh} script, the -appropriate way to use its @samp{prepare} functionality is not using -the @file{centos-art.sh} script directly, but the absolute path to -@command{centos-art.sh} script instead (i.e., -@file{~/artwork/trunk/Scripts/Bash/centos-art.sh}). This is necessary -because @file{centos-art} symbolic link, under @file{~/bin/} -directory, has not been created yet. - -@subsubheading 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 @command{centos-art.sh} script uses are shipped with -CentOS distribution, and can be installed from CentOS base repository. -The only exception is @samp{inkscape}, the package we use to -manipulate SVG files. The @samp{inkscape} package is not inside -CentOS distribution so it needs to be installed from third party -repositories. +The @code{prepare} functionality of @command{centos-art.sh} script +verifies all the information required by the working copy of CentOS +Artwork Repository (e.g., packages of software, symbolic links, etc.) +does exist in your workstation. + +The @code{prepare} functionality of @command{centos-art.sh} script is +part of the CentOS Artwork Repository. So, in order to execute the +@code{prepare} functionality of @command{centos-art.sh} script you +need to have access to a working copy of CentOS Artwork Repository, +first. Working copies of CentOS Artwork Repository are downloaded +from the source repository and made available to you by mean of +workstations. A workstation is a computer that you install and +configure (prepare) to do something. In this case, you pick a computer +and prepare it for working on the CentOS Artwork Repository. + +@subsubheading Installing the workstation + +Installing the workstation is the first step you need to perform for +using the CentOS Artwork Repository. In this step you make your +computer functional through an operating system. In this case, The +Community Enterprise Operating System; which is also know as The +CentOS Distribution or just CentOS, for short. + +To install The CentOS Distribution you need to have the installation +media somehow (e.g., CDs, DVDs, Pendrives, etc.). There are several +different ways to perform the installation process of CentOS +distribution, but generally, you put the installation media in your +media reader, boot the computer from it, and follow the installer +intructions. That simple. + +If you don't have the installation media of CentOS distribution, you +need to download the ISO files related to the media you plan to use +(e.g., CD or DVD) and then create the installation media by yourself. +The CentOS Distribution ISO files can be downloaded from +@url{http://mirrors.centos.org/} and, if you chosen CD or DVD as your +prefered installation medium, you can burn the ISO files using the +@command{K3B} application to create the installation media you'll use. +Of course, in order to download the ISO files and create the +installation media, you need to have an already installed CentOS +workstation where you can realized all the work. + +@subsubheading Configuring the workstation + +Once you've installed the workstation and it is up and running, login +as @samp{root} user, create a username (e.g., @samp{centos}) and set a +password for it. This is the username you must use for everyday work +inside your working copy of the CentOS Artwork Repository. @quotation -@strong{Note} Configuration of third party repositories inside CentOS -distribution is described in CentOS wiki, specifically in the -following URL: -@url{http://wiki.centos.org/AdditionalResources/Repositories} +@strong{Caution} Do not use ever the @samp{root} username for your +everyday work inside the working copy of CentOS Artwork Repository. +It is dangerous and might provoke unreversable damages on your +workstation. @end quotation -Before installing packages, the @file{centos-art.sh} script uses -@command{sudo} to request root privileges to execute @command{yum} -installation functionality. If your user isn't defined as a -privileged user---at least to run @command{yum} commands--- inside -@file{/etc/sudoers} configuration file, you will not be able to -perform package installation tasks as set in @file{centos-art.sh} -script @samp{prepare} functionality. - -Setting sudo privileges to users is an administrative task you have to -do by yourself. If you don't have experience with @command{sudo} -command, please read its man page running the command: @command{man -sudo}. This reading will be very useful, and with some practice, you -will be able to configure your users to have @command{sudo} -privileges. - -@subsubheading Links - -Creation of symbolic links helps us to alternate between different -implementations of @file{centos-art.sh} script-line (e.g., -@file{centos-art.sh}, for Bash implementation; @file{centos-art.py}, -for Python implementation; @file{centos-art.pl}, for Perl -implementation; and so on for other implementations). The -@file{centos-art.sh} script-line definition takes place inside your -personal binary (@file{~/bin/}) directory in order to make the script -implementation ---the one that @file{centos-art} links to--- available -to @var{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 @file{centos-art.sh} -script functionalities available outside @file{trunk/} repository -directory structure, but at its same level in repository tree. This is -useful if you need to use the ``render'' functionality of -@command{centos-art.sh} under @file{branches/} repository directory -structure as you usually do inside @file{trunk/} repository directory -structure. As consequence of this configuration, automation scripts -cannot be branched under @file{branches/Scripts} directory structure. - -@subsubheading 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 @file{~/.bash_profile} file. The -@samp{prepare} functionality of @file{centos-art.sh} script doesn't -modify your @file{~/.bash_profile} file. - -The @samp{prepare} functionality of @file{centos-art.sh} script -evaluates the following environment variables: - -@table @env -@item EDITOR -Default text editor. - -The @file{centos-art.sh} script uses default text @env{EDITOR} to edit -pre-commit subversion messages, translation files, configuration -files, script files, and similar text-based files. +Once you've created the username for everyday work, there are some +environment variables that you can customize to fit your personal +needs (e.g., the text editor you'll use, the language the automation +scripts will use to print and translate output messages, the time +correction for your location, etc.). To customize these variables you +need to edit your profile file (i.e., @file{~/.bash_profile}) and set +the redefinition there. Notice that you may need to logout and then +do login again in order for the new variable values to take effect. + +@table @strong +@item Default text editor: + +The default text editor information is contrlled by the @env{EDITOR} +environment variable. The @file{centos-art.sh} script uses the default +text editor to edit subversion pre-commit messages, translation files, +documentation files, script files, and similar text-based files. If @env{EDITOR} environment variable is not set, @file{centos-art.sh} script uses @file{/usr/bin/vim} as default text editor. Otherwise, the @@ -120,325 +89,188 @@ following values are recognized by @file{centos-art.sh} script: @item @file{/usr/bin/nano} @end itemize -If no one of these values is set in @env{EDITOR} environment variable, -@file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default. - -@item TEXTDOMAIN - -Default domain used to retrieve translated messages. This variable is -set in @file{initFunctions.sh} and shouldn't be changed. - -@item TEXTDOMAINDIR +If no one of these values is set in the @env{EDITOR} environment +variable, the @file{centos-art.sh} script uses @file{/usr/bin/vim} +text editor, the one installed by default in The CentOS Distribution. -Default directory used to retrieve translated messages. This variable -is set in @file{initFunctions.sh} and shouldn't be changed. +@item Default locale information: -@item LANG - -Default locale information. - -This variable is initially set in the configuration process of CentOS -distribution installer (i.e., Anaconda), specifically in the -@samp{Language} step; or once installed using the +The default locale information is controlled by the @env{LANG} +environment variable. This variable is initially set in the +configuration process of CentOS distribution installer, specifically +in the @samp{Language} step; or once installed using the @command{system-config-language} tool. -The @file{centos-art.sh} script uses the @var{LANG} environment -variable to know in which language the script messages are printed -out. - -@item TZ - -Default time zone representation. - -This variable is initially set in the configuration process of CentOS -distribution installer (i.e., Anaconda), specifically in the -@samp{Date and time} step; or once installed using the -@command{system-config-date} tool. - -The @file{centos-art.sh} script doesn't use the @var{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 @var{TZ} variable may be -necessary. - -@quotation -@strong{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. -@end quotation - -The format of @var{TZ} environment variable is described in -@file{tzset(3)} manual page. - +The @command{centos-art.sh} script uses the @env{LANG} environment +variable to determine what language to use for printing output +messages. Moreover, the @code{locale} functionality uses the +@env{LANG} to determine what translation messages to udpate or edit. + +@item Default time zone representation: + +The time zone representation is a time correction applied to the +system time (stored in the BIOS clock) based on your country location. +This correction is specially useful to distributed computers around +the world that work together and need to be syncronized in time to +know when things happened. + +The CentOS Artwork Repository is made of one server and several +workstations spread around the world. In order for all these +workstations to know when changes in the server took place, it is +required that all the workstations set their system clocks to use the +same time information (i.e., @acronym{UTC,Coordinated Universal Time}) +and set the time correction for their countries in the operating +system. Otherwise, it'd be hard to know when something exactly +happened. + +Generally, setting the time information is a straight-forward task and +configuration tools provided by The CentOS Distribution do cover time +correction for most of the countries around the world. However, if +you need a time precision not provided by any of the date and time +configuration tools provided by The CentOS Distribution then, you need +to use the @env{TZ} environment variable to correct the time +information by yourself. The format of @env{TZ} environment variable +is described in @file{tzset(3)} manual page. @end table -@subsubheading Shell Script Files +@subsubheading Downloading the working copy -The @code{shell} functionality of @file{centos-art.sh} script helps -you to maintain bash scripts inside repository. For example, suppose -you've created many functionalities for @file{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 @code{shell} functionality -exists to solve maintainance tasks just as the one previously -mentioned. +Once you've configured the workstation, it is time to download the +working copy of CentOS Artwork Repository. -When you use @code{shell} functionality to update copyright inside -script files, it is required that your script files contain (at least) -the following top commentary structure: +To download the working copy of CentOS Artwork Repository you need to +login as your everyday work username (e.g., @samp{centos}) and use the +Subversion client to bring all the files you need to work with down +from the source location of CentOS Artwork Repository +(@url{https://projects.centos.org/svn/artwork/}) to your workstation, +just as the following command describes: @verbatim - 1| #!/bin/bash - 2| # - 3| # doSomething.sh -- The function description goes here. - 4| # - 5| # Copyright - 6| # - 7| # ... - 8| # - 9| # ---------------------------------------------------------------------- -10| # $Id$ -11| # ---------------------------------------------------------------------- -12| -13| function doSomething { -14| -15| } +svn co https://projects.centos.org/svn/artwork ~/ @end verbatim -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 @code{shell} -functionality, the @file{centos-art.sh} script replaces everything -in-between line 5 ---the first one matching @samp{^# Copyright .+$} -string--- and line 9---the first long dash separator matching @samp{^# --+$}--- with the content of copyright template instance. +This command will create the working copy of CentOS Artwork Repository +in your workstation, specifically in the @file{/home/centos/artwork} +directory. Note that you only need to execute this command once. +After that, to keep your working copy up to date, you use the +Subversion @command{update} command instead. @quotation -@strong{Caution} Be sure to add the long dash separator that matches -@samp{^# -+$} regular expression @emph{before} the function -definition. Otherwise, if the @samp{Copyright} line is present but no -long dash separator exists, @file{centos-art.sh} will remove anything -in-between the @samp{Copyright} line and the end of file. This way you -may lost your function definitions entirely. +@strong{Tip} In the condition that you don't have Subversion client +installed in the workstation, then you can install it using the +command: + +@verbatim +sudo yum install subversion +@end verbatim @end quotation -The copyright template instance is created from one copyright template -stored in the @file{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 -@file{centos-art.sh} script takes advantage of automation in order to -set copyright full name and date dynamically. +@subsubheading Configuring the working copy -When you use @code{shell} functionality to update copyright, the first -thing @file{shell} functionality does is requesting copyright -information to user, and later, if values were left empty (i.e., no -value was typed before pressing @key{RET} key), the @file{shell} -functionality uses its own default values. +Once you have a working copy of CentOS Artwork Repository in your +workstation, you can go and run the @code{prepare} functionality of +@command{centos-art.sh} script to realize the remaining configuration +stuff. -When @code{shell} functionality uses its own default values, the final -copyright note looks like the following: +Assuming this is the very first time you run the +@command{centos-art.sh} script, you'll find that there is no +@command{centos-art} command-line interface for it in your +workstation. This is correct. In order to have the +@command{centos-art} command-line in your workstation, you need to run +the @command{centos-art.sh} script using its absolute path: @verbatim - 1| #!/bin/bash - 2| # - 3| # doSomthing.sh -- The function description goes here. - 4| # - 5| # Copyright (C) 2003, 2010 The CentOS Project - 6| # - 7| # This program is free software; you can redistribute it and/or modify - 8| # it under the terms of the GNU General Public License as published by - 9| # the Free Software Foundation; either version 2 of the License, or -10| # (at your option) any later version. -11| # -12| # This program is distributed in the hope that it will be useful, but -13| # WITHOUT ANY WARRANTY; without even the implied warranty of -14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -15| # General Public License for more details. -16| # -17| # You should have received a copy of the GNU General Public License -18| # along with this program; if not, write to the Free Software -19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 -20| # USA. -21| # -22| # ---------------------------------------------------------------------- -23| # $Id$ -24| # ---------------------------------------------------------------------- -25| -26| function doSomething { -27| -28| } +~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS] @end verbatim -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 @code{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 -@code{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 @file{Config/tpl_forCopyright.sed} file, set -the appropriate information, and run the @code{shell} functionality -once again for changes to take effect over the files you specify. - -@quotation -@strong{Important} The @file{centos-art.sh} script is released as: +Assuming you've already run the @code{prepare} functionality before, +there is no need for you to use the absolute path again. Instead, you +can use the @command{centos-art} command-line interface directly, as +the following example describes: @verbatim -GNU GENERAL PUBLIC LICENSE -Version 2, June 1991 - -Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 675 Mass Ave, Cambridge, MA 02139, USA +centos-art.sh prepare [OPTIONS] @end verbatim -Do not change the license information under which @file{centos-art.sh} -script is released. Instead, if you think a different license must be -used, please share your reasons at @email{centos-devel@@centos-art.sh} -mailing list. +Notice that you can execute the @code{prepare} functionality more than +once. This is specially useful to keep the link information +syncronized. For example, considering you've added new brushes to or +removed old brushes from your working copy of CentOS Artwork +Repository, the link information related to those files need to be +updated in the @file{~/.gimp-2.2/brushes} directory too, in a way that +reflect the addition/deletion change that took place in your working +copy. The same is true for fonts, patterns and palettes components. -See file -@url{file:///home/centos/artwork/trunk/Scripts/COPYING,trunk/Scripts/COPYING}, -for a complete license description. -@end quotation +@subheading Usage -@subsubheading SVG Files - -The @code{svg} functionality of @file{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 @file{trunk/Identity/Themes/Models/}, and you want to set common -metadata to all of them, and later remove all unused SVG defintions -from @samp{*.svg} files. Doing so file by file may be a tedious task, -so the @file{centos-art.sh} script provides the @code{svg} -functionality to aid you maintain such actions. - -The metadata used is defined by Inkscape 0.46 using the SVG standard -markup. The @file{centos-art.sh} script replaces everything -in-between @code{} 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 @samp{=SOMETEXT=}, where -@code{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 @file{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 @file{centos-art.sh} script is currently creating metadata -information for. - -With metadata template instance in place, the @file{centos-art.sh} -script uses it to replace real values inside all @samp{.svg} files -under the current location you're running the @file{centos-art.sh} -script on. Default behaviour is to ask user to enter each metadatum -required, one by one. If user leaves metadatum empty, by pressing -@key{RET} key, @file{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 @samp{Vacuum Defs} command -in @samp{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 @file{centos-art.sh} script uses Inkscape command-line -interface, specifically with the @option{--vaccum-defs} option. - -@subsubheading XHTML Files +@subsubheading Synopsis -@subheading Usage +@command{centos-art prepare [OPTIONS]} -@table @command +@subsubheading Options -@item centos-art prepare --packages +@table @option +@item --packages -Verify required packages your workstation needs in order to run the -@file{centos-art.sh} script correctly. If there are missing packages, -the @file{centos-art.sh} script asks you to confirm their -installation. When installing packages, the @file{centos-art.sh} -script uses the @command{yum} application in order to achieve the -task. +Verify existence of software packages and install them if they aren't +installed yet. -In case all packages required by @file{centos-art.sh} script are -already installed in your workstation, the message @samp{The required -packages are already installed.} is output for you to know. +This option provides the software required to manipulate files inside +the repository (e.g., image files, documentation files, translation +files, script files, etc.). Most of the software packages required by +the CentOS Artwork Repository are available on The CentOS Distribution +and can be installed using The CentOS Distribution installation media. +The only exception is the @file{inkscape}, the package you use to +manipulate @acronym{SVG,Scalable Vector Graphics} files. The +@file{inkscape} package isn't inside The CentOS Distribution or any of +The CentOS Project repositories neither, so you need to install it from +a third party repositories like @samp{RPMForge} or @samp{EPEL}. -@item centos-art prepare --links +@item --link -Verify required links your workstation needs in order to run the -centos-art command correctly. If any required link is missing, the -@command{centos-art.sh} script asks you to confirm their installation. -To install required links, the @command{centos-art.sh} script uses the -@command{ln} command. +Update connection between working copy and workstation through +symbolic links. -In case all links required by @file{centos-art.sh} script are already -created in your workstation, the message @samp{The required links are -already installed.} is output for you to know. +This option creates the @command{centos-art} command-line interface of +@command{centos-art.sh} script through a symbolic link. There is no +need for you to type the full path to @command{centos-art.sh} script +each time you need to execute it. Instead, you use the +@command{centos-art} command which is much shorter and faster to type. -In case a regular file exists with the same name of a required link, -the @file{centos-art.sh} script outputs the @samp{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 @file{centos-art.sh} -script will fall into a continue installation request for that missing -link. To end this continue request you can answer @samp{No}, or -remove the existent regular file to let @file{centos-art.sh} script -install the link on its place. +This option connects design compenents like fonts, brushes, patterns +and palettes inside your working copy of CentOS Artwork Repository +with programs like @acronym{GIMP, GNU Image Manipulation Program} and +Inkscape outside it. This way, all your modifications on these +components will take place inside the repository and will be shared to +all other working copies the next time you commit the changes up to +source repository. -@item centos-art prepare --environment -@itemx centos-art prepare --environment --filter='regex' +This option standardizes width, tabulation, indentation, and line +numbering for text editors in your workstation. The configuration +file where these definitions are set, is versioned inside your working +copy and linked from the appropriate place in the workstation to make +it valid to your default text editor. -Output a brief description of environment variables used by -@file{centos-art.sh} script. +@item --environment -If @samp{--filter} option is provided, output is reduced as defined in -the @samp{regex} regular expression value. If @samp{--filter} option -is specified but @samp{regex} value is not, the @file{centos-art.sh} -script outputs information as if @samp{--filter} option had not been -provided at all. +Print the name and value of some of the environment variables used by +@command{centos-art.sh} scripts. + +@item --quiet + +Supress all output messages except errors. This option assumes an +affirmative response to all questions so, take care when using it. @end table @subheading See also -@menu -* Directories trunk Scripts:: -* Directories trunk Scripts Functions:: -@end menu +@itemize +@item @ref{Directories trunk Scripts Functions} +@item @ref{Directories trunk Scripts} +@item @ref{Directories trunk} +@item +@url{http://wiki.centos.org/AdditionalResources/Repositories/,The +CentOS Repositories}, to know how to configure third party +repositories inside The CentOS Distribution. +@end itemize diff --git a/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi b/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi index d6bb628..889f183 100755 --- a/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi @@ -6,6 +6,205 @@ @subheading Description +@subsubheading Shell Script Files + +The @code{shell} functionality of @file{centos-art.sh} script helps +you to maintain bash scripts inside repository. For example, suppose +you've created many functionalities for @file{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 @code{shell} functionality +exists to solve maintainance tasks just as the one previously +mentioned. + +When you use @code{shell} functionality to update copyright inside +script files, it is required that your script files contain (at least) +the following top commentary structure: + +@verbatim + 1| #!/bin/bash + 2| # + 3| # doSomething.sh -- The function description goes here. + 4| # + 5| # Copyright + 6| # + 7| # ... + 8| # + 9| # ---------------------------------------------------------------------- +10| # $Id$ +11| # ---------------------------------------------------------------------- +12| +13| function doSomething { +14| +15| } +@end verbatim + +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 @code{shell} +functionality, the @file{centos-art.sh} script replaces everything +in-between line 5 ---the first one matching @samp{^# Copyright .+$} +string--- and line 9---the first long dash separator matching @samp{^# +-+$}--- with the content of copyright template instance. + +@quotation +@strong{Caution} Be sure to add the long dash separator that matches +@samp{^# -+$} regular expression @emph{before} the function +definition. Otherwise, if the @samp{Copyright} line is present but no +long dash separator exists, @file{centos-art.sh} will remove anything +in-between the @samp{Copyright} line and the end of file. This way you +may lost your function definitions entirely. +@end quotation + +The copyright template instance is created from one copyright template +stored in the @file{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 +@file{centos-art.sh} script takes advantage of automation in order to +set copyright full name and date dynamically. + +When you use @code{shell} functionality to update copyright, the first +thing @file{shell} functionality does is requesting copyright +information to user, and later, if values were left empty (i.e., no +value was typed before pressing @key{RET} key), the @file{shell} +functionality uses its own default values. + +When @code{shell} functionality uses its own default values, the final +copyright note looks like the following: + +@verbatim + 1| #!/bin/bash + 2| # + 3| # doSomthing.sh -- The function description goes here. + 4| # + 5| # Copyright (C) 2003, 2010 The CentOS Project + 6| # + 7| # This program is free software; you can redistribute it and/or modify + 8| # it under the terms of the GNU General Public License as published by + 9| # the Free Software Foundation; either version 2 of the License, or +10| # (at your option) any later version. +11| # +12| # This program is distributed in the hope that it will be useful, but +13| # WITHOUT ANY WARRANTY; without even the implied warranty of +14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +15| # General Public License for more details. +16| # +17| # You should have received a copy of the GNU General Public License +18| # along with this program; if not, write to the Free Software +19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 +20| # USA. +21| # +22| # ---------------------------------------------------------------------- +23| # $Id$ +24| # ---------------------------------------------------------------------- +25| +26| function doSomething { +27| +28| } +@end verbatim + +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 @code{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 +@code{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 @file{Config/tpl_forCopyright.sed} file, set +the appropriate information, and run the @code{shell} functionality +once again for changes to take effect over the files you specify. + +@quotation +@strong{Important} The @file{centos-art.sh} script is released as: + +@verbatim +GNU GENERAL PUBLIC LICENSE +Version 2, June 1991 + +Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 675 Mass Ave, Cambridge, MA 02139, USA +@end verbatim + +Do not change the license information under which @file{centos-art.sh} +script is released. Instead, if you think a different license must be +used, please share your reasons at @email{centos-devel@@centos-art.sh} +mailing list. + +See file +@url{file:///home/centos/artwork/trunk/Scripts/COPYING,trunk/Scripts/COPYING}, +for a complete license description. +@end quotation + +@subsubheading SVG Files + +The @code{svg} functionality of @file{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 @file{trunk/Identity/Themes/Models/}, and you want to set common +metadata to all of them, and later remove all unused SVG defintions +from @samp{*.svg} files. Doing so file by file may be a tedious task, +so the @file{centos-art.sh} script provides the @code{svg} +functionality to aid you maintain such actions. + +The metadata used is defined by Inkscape 0.46 using the SVG standard +markup. The @file{centos-art.sh} script replaces everything +in-between @code{} 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 @samp{=SOMETEXT=}, where +@code{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 @file{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 @file{centos-art.sh} script is currently creating metadata +information for. + +With metadata template instance in place, the @file{centos-art.sh} +script uses it to replace real values inside all @samp{.svg} files +under the current location you're running the @file{centos-art.sh} +script on. Default behaviour is to ask user to enter each metadatum +required, one by one. If user leaves metadatum empty, by pressing +@key{RET} key, @file{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 @samp{Vacuum Defs} command +in @samp{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 @file{centos-art.sh} script uses Inkscape command-line +interface, specifically with the @option{--vaccum-defs} option. + +@subsubheading XHTML Files + @itemize @item ... @end itemize diff --git a/Manual/Introduction/authors.texi b/Manual/Introduction/authors.texi index 4a7eba0..08da524 100755 --- a/Manual/Introduction/authors.texi +++ b/Manual/Introduction/authors.texi @@ -7,8 +7,8 @@ Work line: @ref{Directories trunk Identity} @itemize @item Guideon de Kok -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} -@item @email{marcus@@moeller.org,Marcus Moeller} +@item @email{al@@art.centos.org,Alain Reguera Delgado} +@item @email{mm@@art.centos.org,Marcus Moeller} @end itemize @subheading Documentation @@ -16,8 +16,8 @@ Work line: @ref{Directories trunk Identity} Work line: @ref{Directories trunk Manual} @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} -@item @email{ralph@@centos.org,Ralph Angenendt} +@item @email{al@@art.centos.org,Alain Reguera Delgado} +@item @email{ralph@@dev.centos.org,Ralph Angenendt} @end itemize @subheading Localization @@ -25,7 +25,7 @@ Work line: @ref{Directories trunk Manual} Work line: @ref{Directories trunk Locales} @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} (Spanish) +@item @email{al@@art.centos.org,Alain Reguera Delgado} (Spanish) @end itemize @subheading Automation @@ -33,17 +33,17 @@ Work line: @ref{Directories trunk Locales} Work line: @ref{Directories trunk Scripts} @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{al@@art.centos.org,Alain Reguera Delgado} @end itemize @subheading Infrastructure @itemize -@item @email{karan@@centos.org,Karanbirn Singh} -@item @email{ralph@@centos.org,Ralph Angenendt} +@item @email{karan@@dev.centos.org,Karanbirn Singh} +@item @email{ralph@@dev.centos.org,Ralph Angenendt} @end itemize @subheading Packaging @itemize -@item @email{karan@@centos.org,Karanbirn Singh} -@item @email{ralph@@centos.org,Ralph Angenendt} +@item @email{karan@@dev.centos.org,Karanbirn Singh} +@item @email{ralph@@dev.centos.org,Ralph Angenendt} @end itemize diff --git a/Manual/repository.info.bz2 b/Manual/repository.info.bz2 index 3f64a97..9e2cc0f 100644 Binary files a/Manual/repository.info.bz2 and b/Manual/repository.info.bz2 differ diff --git a/Manual/repository.pdf b/Manual/repository.pdf index 2795898..a6e0fbc 100644 Binary files a/Manual/repository.pdf and b/Manual/repository.pdf differ diff --git a/Manual/repository.txt.bz2 b/Manual/repository.txt.bz2 index f9defed..67e06a8 100644 Binary files a/Manual/repository.txt.bz2 and b/Manual/repository.txt.bz2 differ diff --git a/Manual/repository.xhtml.tar.bz2 b/Manual/repository.xhtml.tar.bz2 index fadda21..3bfff52 100644 Binary files a/Manual/repository.xhtml.tar.bz2 and b/Manual/repository.xhtml.tar.bz2 differ diff --git a/Manual/repository.xml b/Manual/repository.xml index 29ca55c..fe4854e 100644 --- a/Manual/repository.xml +++ b/Manual/repository.xml @@ -164,10 +164,10 @@ Guideon de Kok - alain.reguera@gmail.comAlain Reguera Delgado + al@art.centos.orgAlain Reguera Delgado - marcus@moeller.orgMarcus Moeller + mm@art.centos.orgMarcus Moeller Documentation @@ -175,10 +175,10 @@ • - alain.reguera@gmail.comAlain Reguera Delgado + al@art.centos.orgAlain Reguera Delgado - ralph@centos.orgRalph Angenendt + ralph@dev.centos.orgRalph Angenendt Localization @@ -186,7 +186,7 @@ • - alain.reguera@gmail.comAlain Reguera Delgado (Spanish) + al@art.centos.orgAlain Reguera Delgado (Spanish) Automation @@ -194,27 +194,27 @@ • - alain.reguera@gmail.comAlain Reguera Delgado + al@art.centos.orgAlain Reguera Delgado Infrastructure • - karan@centos.orgKaranbirn Singh + karan@dev.centos.orgKaranbirn Singh - ralph@centos.orgRalph Angenendt + ralph@dev.centos.orgRalph Angenendt Packaging • - karan@centos.orgKaranbirn Singh + karan@dev.centos.orgKaranbirn Singh - ralph@centos.orgRalph Angenendt + ralph@dev.centos.orgRalph Angenendt @@ -736,11 +736,6 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 - Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Path - - - Directories trunk Scripts Functions Prepare Directories trunk Scripts Functions Prepare @@ -751,11 +746,6 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 - Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Render Config - - - Directories trunk Scripts Functions Tuneup Directories trunk Scripts Functions Tuneup @@ -876,12 +866,7 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 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 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. - - Figure - - - The CentOS Project Corporate Identity. - + Corporate Mission The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively. Corporate Design @@ -1019,10 +1004,7 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 This section describes how brushes are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program. Description A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've organized brushes in common brushes and theme-specific brushes. In both cases, brushes are initially created in .xcf format and later exported to any of the brush formats recognized by GIMP (e.g., .gbr or .gih) using the same name of its source file. - - Figure - - - Brush file format and directory structure. - In order for both common brushes and theme-specific brushes to be loaded by GIMP, related .gbr and .gih brush files need to be stored under ~/.gimp-2.2/brushes directory. This location is out of CentOS Artwork Repository and provides no version control by itself. This way, brushes aren't exported to this location but into the repository directory structure which is versioned. Later, we create symbolic links in ~/.gimp-2.2/brushes to connect file brushes inside the repository and, this way, provide the configuration needed by GIMP to use the brush files produced inside the repository. Warning When brushes are added to or removed from the repository, you need to update your working copy and all information related to brushes inside your workstation (e.g., brush links in ~/.gimp-2.2/brushes and the Brushes panel in GIMP). Otherwise, you may end up with broken links or brushes in the repository that wouldn't be available for you to use in GIMP. Inside the repository, common brushes and theme-specific brushes are created individually in different locations, but they all are linked from one unique location (i.e., ~/.gimp-2.2/brushes). This configuration may provoke brush overlapping if a name convenction is not implemented correctly. In that sake, file names used for brushes inside the repository must be unique, no matter where they be. As file name convenction inside the repository, brushes are named using lowercase letters, numbers, minus characters and dot characters, only. Additionally, when links are built, we use one suffix for those brushes retrived from trunk/Identity/Brushes and another suffix for those brushes retrivided from theme-specific directories. Using both the brush file name and the suffix information, it is possible to build unique names for links under ~/.gimp-2.2/brushes directory, scalably. - - Figure - - - Common brushes path relation. - - - Figure - - - Theme-specific brushes path relation. - Brushes produced with GIMP has a description field associated that is shown in the Brushes panel of GIMP. This description is set when the brush is created as .xcf file and can be updated when it is exported either to .gbr or .gih format. It wouldn't be too useful to have two or more brushes using the same description so, we also make description of brush files unique, too. In that sake, we use the same name schema used to name brush links as description but without including the file extension (e.g., if we have the centos-flame-3.gbr brush, its description would be centos-flame-3). Usage The way you use brushes is up to your creativeness. However, the way brushes are made available needs to be standardized. That's the reason of organizing brushes in common brushes and theme-specific brushes. @@ -1095,18 +1065,8 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes This section describes how typographies are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program and Inkscape. Description The CentOS Project Corporate Identity is attached to DejaVu LGC font-family and Denmark font-family. - - Figure - - - DejaVu-LGC font-family. - - - Figure - - - Denmark font-family. - + + Caution The copyright and license of Denmark typography aren't very specific and that issue may represent a threat to The CentOS Project Corporate Identity. @@ -1119,6 +1079,15 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes See also + + • + + Directories trunk Identity. + + + Directories trunk. + + @@ -1207,12 +1176,7 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes 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. The CentOS Brand is the main visual representation of the CentOS project so the typography used in it must be the same always, no matter where it be shown. It also has to be clear enough to dismiss any confussion between similar typefaces (e.g., the number one (1) sometimes is confuesed with the letter el (l) or letter ai (i)). As convenction, the word CentOS uses Denmark typography as base, both for the word CentOS and the phrase Community Enterprise Operating System. The phrase size of CentOS logo is half the size in poits the word CentOS has and it below CentOS word and aligned with it on the left. The distance between CentOS word and phrase Community Enterprise Operating System have the size in points the phrase has. - - Figure - - - The CentOS logo construction - + When the CentOS release brand is built, use Denmark typography for the release number. The release number size is two times larger (in height) than default CentOS word. The separation between release number and CentOS word is twice the size in points of separation between CentOS word and phrase Community Enterprise Operating System. Another component inside CentOS logo is the trademark symbol (TM). This symbol specifies that the CentOS logo must be consider a product brand, even it is not a registered one. The trademark symbol uses DejaVu LGC Sans Regular typography. The trademark symbol is aligned right-top on the outter side of CentOS word. The trademark symbol must not exceed haf the distance, in points, between CentOS word and the release number on its right. It would be very convenient for the CentOS Project and its community to to make a registered trademark (®) of CentOS logo. To make a register trademark of CentOS Logo prevents legal complications in the market place of brands. It grants the consistency, through time, of CentOS project corporate visual identity. @@ -2465,64 +2429,68 @@ priority=10 This section provides the automation work line. The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. In this section you'll find how to organize and extend the 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. Description - The best way to understand centos-art.sh automation script is studying its source code. However, as start point, you may prefer to read an introductory resume before diving into the source code details. - The centos-art.sh script is written in Bash. Most tasks, inside centos-art.sh script, have been organized in many specific functionalities that you can invoke from the centos-art command-line interface. - When you type the centos-art command in your terminal, the operating system trys to execute that command. In order to execute the command, the operating system needs to know where it is, so the operating system uses the PATH environment variable to look for that command location. If your system was prepared to use CentOS Artwork Repository correctly (see Directories trunk Scripts Functions Prepare) you should have a symbolic link inside ~/bin directory that points to the centos-art.sh script file. As ~/bin directory is, by default, inside PATH environment variable, the execution of centos-art command runs the centos-art.sh script. - When centos-art.sh script is executed, the first it does is initializing global variables (e.g., gettext variables) and global function scripts. Global function scripts are located inside trunk/Scripts/Functions directory and their file names begin with cli. Global function scripts provide common functionalities that can be used anywhere inside centos-art.sh script execution environment. - Once global variables and function scripts have been loaded, centos-art.sh script executes the cli global function from cli.sh function script to retrive command-line arguments and define some default values that may be used later by specific function scripts (see Directories trunk Scripts Functions). - As convenction, the centos-art.sh command-line arguments have the following format: + The best way to understand the centos-art.sh script is studying and improving its source code. However, as start point, you may prefer to read an introductory resume before diving into the source code details. In this section we identify the different parts the centos-art.sh script is made of and how these parts interact one another. + Execution environments + The centos-art.sh script is basically made of four execution environments which are named script, global, specific and action. These execution environments are nested one into another and provide different definition levels for variables and functions. In this design, variables and functions defined in higher execution environments are available on lower execution environments, but variables and functions defined in lower execution environments are not available for higher execution enviroments. - In the above example, centos-art is the command you use to invoke centos-art.sh script. The arg1 is required and represents the functionality you want to perform (e.g., , , , , etc.). The remaining arguments are modifiers to . The definition is required and represets, specifically, the action inside the functionality you want to perform. The and on, are optional. - Once command-line arguments have been retrived, the centos-art.sh script loads specific functionalities using the cli_getFunctions.sh function script. Only one specific functionality can be loaded at one script execution I.e., you run centos-art.sh script to run just one functionality. - - Figure - - ~/artwork/trunk/Scripts/centos-art.sh | +---v--------------------------------------------------------------v---+ | centos-art.sh | - +-v--------------------------------------------------------v---+ - . | cli $@ | . - . +-v--------------------------------------------------v---+ . - . . | cli_getFunctions | . . - . . +-v-----------v-----------v-----------v------------+ . . - . . . | function1 | function2 | functionN | . . . - . . . +-----------+-----------+-----------+ . . . - . . .................................................... . . - . .......................................................... . + +---v------------------------------------------------------v---+ + . | cli $@ | . + . +---v----------------------------------------------v---+ . + . . | cli_getFunctions | . . + . . +---v--------------------------------------v---+ . . + . . . | function | . . . + . . . +---v------------------------------v---+ . . . + . . . . | function_getArguments | . . . . + . . . . | function_doSomething | . . . . + . . . . +------------------------------+ . . . . + . . . . . . . . + . . . . Execution environment (action) . . . . + . . . ........................................ . . . + . . . . . . + . . . Execution environment (specific) . . . + . . ................................................ . . + . . . . + . . Execution environment (global) . . + . ........................................................ . + . . + . Execution environment (script) . ................................................................ ]]> - Functionalities initialization environment. - - Functionalities are implemented by means of actions. Once the functionality has been initiazalized, actions initialization take place for that functionality. Actions initialization model is very similar to functions initialization model. But with the difference, that actions are loaded inside function environment, and so, share variables and functions defined inside function environment. - - Figure - - The script execution environment exists to provide script definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of internationalization through gettext program, script personal information and initialization of global functionalities. + The global execution environment exists to provide definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of functionalities (e.g., cli_printMessage, cli_getCurrentLocale, cli_checkFiles, etc.) and variables (e.g., FUNCNAM, FUNCDIR, FUNCDIRNAM, ARGUMENTS, etc.) that can be both used on specific and action execution environments, only. + The specific execution environment exists to provide definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of specifc functionalities (e.g., render, help, locale, etc.) and specific variables (ACTIONNAM, ACTIONVAL, etc.) that can be used on action execution environment only. + The action execution environment exists to perform the script actions themselves. It is here where we perform content rendition, content documentation, content localization and whatever action you plan for the centos-art.sh script to perform. For example, if you passed the render value as first argument to centos-art.sh command-line, the script performs the content rendition action through the render function which is defined in the render.sh file under trunk/Scripts/Functions/Render directory. Is there, inside render functionality were the action execution environment takes place exactly. + Command-line interface + When the centos-art command is executed in a bash terminal, the bash interpreter uses the PATH environment variable to find where such command is. In order to run the centos-art, it must exist either as a link to an executable file or an executable file by its own, in any of the paths provided by PATH environment variable. Otherwise, the bash interpreter will print an error message and prompt you back to type a valid command. + By default, after installing The CentOS Distribution, there is no centos-art command available in the PATH environment variable for you to execute. The centos-art command is made available in your workstation as result of executing the prepare functionality of centos-art.sh script (see Directories trunk Scripts Functions Prepare) which requires you had previously downloaded a working copy of CentOS Artwork Repository in your workstation. + When the centos-art is executed, the first positional parameter passed is required and represents the name of the function you want to perform (e.g., render for content rendition, locale for content localization, etc.). Beyond the first positional parameter you can provide either option or non-option parameters in no specific order. There are also, option parameters with arguments and without arguments. Frequently, non-option paramters are used to specify the path location inside the repository where the function will be performed in (e.g., the directory structure do you want to produce content for) and option parameters to specify how such functionality is performed (e.g., do you want to go quietly? do you want to do filtering? etc.). + - Actions initialization environment. - + Parsing command-line options + The action of parsing options is performed through getopt and results particularly interesting. getopt breaks up (parse) options in command lines and checks for legal options using the GNU getopt routines to do this. One important consideration on centos-art.sh script design is that positional parameters are retrived in the cli function but parsed on each specific function, individually. There isn't a big parsing definition to cover all specific functions, but one parsing definitions for each specific functions. Usage - The centos-art.sh script usage information is described inside each specific function documentation (see Directories trunk Scripts Functions). + + • + + See Directories trunk Scripts Functions. + + See also • @@ -2710,19 +2678,16 @@ centos-art locale --edit trunk/Scripts • - See Directories trunk Scripts Functions Prepare. - - - See Directories trunk Scripts Functions Render. + See Directories trunk Scripts Functions Help. See Directories trunk Scripts Functions Locale. - See Directories trunk Scripts Functions Help. + See Directories trunk Scripts Functions Prepare. - See Directories trunk Scripts Functions Path. + See Directories trunk Scripts Functions Render. See Directories trunk Scripts Functions Tuneup. @@ -2776,7 +2741,7 @@ centos-art locale --edit trunk/Scripts Directories trunk Scripts Functions Locale - Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Prepare Directories trunk Scripts Functions Help Directories
@@ -2838,136 +2803,33 @@ centos-art locale --edit trunk/Scripts
- Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Prepare - Directories trunk Scripts Functions Locale - Directories -
- The <file>trunk/Scripts/Functions/Path</file> Directory - Directories trunk Scripts Functions Path - Goals - This section exists to organize files related to path functiontionality. The path functionality standardizes movement, syncronization, branching, tagging, and general file maintainance inside the repository. - Description - ”CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence.” - Repository layout - The repository layout describes organization of files and directories inside the repository. The repository layout provides the standard backend required for automation scripts to work correctly. If such layout changes unexpectedly, automation scripts may confuse themselves and stop doing what we expect from them to do. - As convenction, inside CentOS Artwork Repository, we organize files and directories related to CentOS corporate visual identity under three top level directories named: trunk/, branches/, and tags/. - The trunk/ directory (see 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 () 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 name convenctions - Repository name convenctions help us to maintain consistency of names inside the repository. - Repository name convenctions are applied to files and directories inside the repository layout. As convenction, inside the repository layout, file names are all written in lowercase (01-welcome.png, splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity, Themes, Motifs, TreeFlower, etc.). - Repository name convenctions are implemented inside the cli_getRepoName function of centos-art.sh script. With cli_getRepoName function we reduce the amount of commands and convenctions to remember, concentrating them in just one single place to look for fixes and improvements. - Repository work flow - Repository work flow describes the steps and time intervals used to produce CentOS corporate visual identity inside CentOS Artwork Repository. - To illustrate repository work flow let's consider themes' development cycle. - Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). - Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. - Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. - Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. - - Convenction 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. - 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. - Usage - - - centos-art path --copy='SRC' --to='DST' - - Copy to and schedule for addition (with history). In this command, SRC and DST are both working copy (WC) entries. - - - - centos-art path --delete='SRC' - - Delete . In order for this command to work the file or directory you intend to delete should be under version control first. In this command, SRC is a working copy (WC) entry. - - -
- See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - - - -
- - Directories trunk Scripts Functions Prepare Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Locale Directories
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. + This section describes the prepare functionality of centos-art.sh script and the preliminar steps you need to follow in order to get your workstation ready for using the 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 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. - 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. + The prepare functionality of centos-art.sh script verifies all the information required by the working copy of CentOS Artwork Repository (e.g., packages of software, symbolic links, etc.) does exist in your workstation. + The prepare functionality of centos-art.sh script is part of the CentOS Artwork Repository. So, in order to execute the prepare functionality of centos-art.sh script you need to have access to a working copy of CentOS Artwork Repository, first. Working copies of CentOS Artwork Repository are downloaded from the source repository and made available to you by mean of workstations. A workstation is a computer that you install and configure (prepare) to do something. In this case, you pick a computer and prepare it for working on the CentOS Artwork Repository. + Installing the workstation + Installing the workstation is the first step you need to perform for using the CentOS Artwork Repository. In this step you make your computer functional through an operating system. In this case, The Community Enterprise Operating System; which is also know as The CentOS Distribution or just CentOS, for short. + To install The CentOS Distribution you need to have the installation media somehow (e.g., CDs, DVDs, Pendrives, etc.). There are several different ways to perform the installation process of CentOS distribution, but generally, you put the installation media in your media reader, boot the computer from it, and follow the installer intructions. That simple. + If you don't have the installation media of CentOS distribution, you need to download the ISO files related to the media you plan to use (e.g., CD or DVD) and then create the installation media by yourself. The CentOS Distribution ISO files can be downloaded from http://mirrors.centos.org/ and, if you chosen CD or DVD as your prefered installation medium, you can burn the ISO files using the K3B application to create the installation media you'll use. Of course, in order to download the ISO files and create the installation media, you need to have an already installed CentOS workstation where you can realized all the work. + Configuring the workstation + Once you've installed the workstation and it is up and running, login as root user, create a username (e.g., centos) and set a password for it. This is the username you must use for everyday work inside your working copy of the CentOS Artwork Repository. - 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 + Caution Do not use ever the root username for your everyday work inside the working copy of CentOS Artwork Repository. It is dangerous and might provoke unreversable damages on your workstation. - 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: + Once you've created the username for everyday work, there are some environment variables that you can customize to fit your personal needs (e.g., the text editor you'll use, the language the automation scripts will use to print and translate output messages, the time correction for your location, etc.). To customize these variables you need to edit your profile file (i.e., ~/.bash_profile) and set the redefinition there. Notice that you may need to logout and then do login again in order for the new variable values to take effect. - EDITOR + Default text 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. + The default text editor information is contrlled by the EDITOR environment variable. The centos-art.sh script uses the default text editor to edit subversion pre-commit messages, translation files, documentation 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: • @@ -2981,170 +2843,104 @@ centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ /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. + If no one of these values is set in the EDITOR environment variable, the centos-art.sh script uses /usr/bin/vim text editor, the one installed by default in The CentOS Distribution. - TEXTDOMAIN + Default locale information: - Default domain used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. + The default locale information is controlled by the LANG environment variable. This variable is initially set in the configuration process of CentOS distribution installer, 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 determine what language to use for printing output messages. Moreover, the locale functionality uses the LANG to determine what translation messages to udpate or edit. - TEXTDOMAINDIR + Default time zone representation: - 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. + The time zone representation is a time correction applied to the system time (stored in the BIOS clock) based on your country location. This correction is specially useful to distributed computers around the world that work together and need to be syncronized in time to know when things happened. + The CentOS Artwork Repository is made of one server and several workstations spread around the world. In order for all these workstations to know when changes in the server took place, it is required that all the workstations set their system clocks to use the same time information (i.e., UTCCoordinated Universal Time) and set the time correction for their countries in the operating system. Otherwise, it'd be hard to know when something exactly happened. + Generally, setting the time information is a straight-forward task and configuration tools provided by The CentOS Distribution do cover time correction for most of the countries around the world. However, if you need a time precision not provided by any of the date and time configuration tools provided by The CentOS Distribution then, you need to use the TZ environment variable to correct the time information by yourself. 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: + Downloading the working copy + Once you've configured the workstation, it is time to download the working copy of CentOS Artwork Repository. + To download the working copy of CentOS Artwork Repository you need to login as your everyday work username (e.g., centos) and use the Subversion client to bring all the files you need to work with down from the source location of CentOS Artwork Repository (https://projects.centos.org/svn/artwork/) to your workstation, just as the following command describes: - 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. + This command will create the working copy of CentOS Artwork Repository in your workstation, specifically in the /home/centos/artwork directory. Note that you only need to execute this command once. After that, to keep your working copy up to date, you use the Subversion update command instead. - 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. + Tip In the condition that you don't have Subversion client installed in the workstation, then you can install it using the command: + - 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: + Configuring the working copy + Once you have a working copy of CentOS Artwork Repository in your workstation, you can go and run the prepare functionality of centos-art.sh script to realize the remaining configuration stuff. + Assuming this is the very first time you run the centos-art.sh script, you'll find that there is no centos-art command-line interface for it in your workstation. This is correct. In order to have the centos-art command-line in your workstation, you need to run the centos-art.sh script using its absolute path: - 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: - Assuming you've already run the prepare functionality before, there is no need for you to use the absolute path again. Instead, you can use the centos-art command-line interface directly, as the following example describes: + - 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.sh 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 + Notice that you can execute the prepare functionality more than once. This is specially useful to keep the link information syncronized. For example, considering you've added new brushes to or removed old brushes from your working copy of CentOS Artwork Repository, the link information related to those files need to be updated in the ~/.gimp-2.2/brushes directory too, in a way that reflect the addition/deletion change that took place in your working copy. The same is true for fonts, patterns and palettes components. Usage + Synopsis + centos-art prepare [OPTIONS] + Options - 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. + Verify existence of software packages and install them if they aren't installed yet. + This option provides the software required to manipulate files inside the repository (e.g., image files, documentation files, translation files, script files, etc.). Most of the software packages required by the CentOS Artwork Repository are available on The CentOS Distribution and can be installed using The CentOS Distribution installation media. The only exception is the inkscape, the package you use to manipulate SVGScalable Vector Graphics files. The inkscape package isn't inside The CentOS Distribution or any of The CentOS Project repositories neither, so you need to install it from a third party repositories like RPMForge or EPEL. - 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. + Update connection between working copy and workstation through symbolic links. + This option creates the centos-art command-line interface of centos-art.sh script through a symbolic link. There is no need for you to type the full path to centos-art.sh script each time you need to execute it. Instead, you use the centos-art command which is much shorter and faster to type. + This option connects design compenents like fonts, brushes, patterns and palettes inside your working copy of CentOS Artwork Repository with programs like GIMPGNU Image Manipulation Program and Inkscape outside it. This way, all your modifications on these components will take place inside the repository and will be shared to all other working copies the next time you commit the changes up to source repository. + This option standardizes width, tabulation, indentation, and line numbering for text editors in your workstation. The configuration file where these definitions are set, is versioned inside your working copy and linked from the appropriate place in the workstation to make it valid to your default text editor. - 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. + Print the name and value of some of the environment variables used by centos-art.sh scripts. + + + + + + Supress all output messages except errors. This option assumes an affirmative response to all questions so, take care when using it.
See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - - - + + • + + Directories trunk Scripts Functions + + + Directories trunk Scripts + + + Directories trunk + + + http://wiki.centos.org/AdditionalResources/Repositories/The CentOS Repositories, to know how to configure third party repositories inside The CentOS Distribution. + +
Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Tuneup Directories trunk Scripts Functions Prepare Directories
@@ -3490,138 +3286,13 @@ function render_loadConfig { See also - - Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Render Config - - - -
- - - Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Tuneup - Directories trunk Scripts Functions Render - Directories -
- The <file>trunk/Scripts/Functions/Render/Config</file> Directory - Directories trunk Scripts Functions Render Config - Goals - The trunk/Scripts/Bash/Config directory exists to oraganize pre-rendering configuration scripts. - Description - Pre-rendering configuration scripts let you customize the way centos-art.sh script renders identity and translation repository entries. Pre-rendering configuration scripts are render.conf.sh files with render_loadConfig function definition inside. - There is one render.conf.sh file for each pre-rendering configuration entry. Pre-rendering configuration entries can be based both on identity and translation repository entires. Pre-rendering configuration entries are required for each identity entry, but not for translation entries. - The render.conf.sh identity model - Inside CentOS Artwork Repository, we consider identity entries to all directories under trunk/Identity directory. Identity entries can be image-based or text-based. When you render image-based identity entries you need to use image-based pre-rendering configuration scripts. Likewise, when you render text-based identity entries you need to use text-based pre-rendering configuration scripts. - Inside identity pre-rendering configuration scripts, image-based pre-rendering configuration scripts look like the following: - - Inside identity pre-rendering configuration scripts, text-based pre-rendering configuration scripts look like the following: - - When using identity pre-rendering configuration scripts, you can extend both image-based and text-based pre-rendering configuration scripts using image-based and text-based post-rendering actions, respectively. - The render.conf.sh translation model - Translation pre-rendering configuration scripts take precedence before default translation rendering action. Translation pre-rendering actions are useful when default translation rendering action do not fit itself to translation entry rendering requirements. - The render.conf.sh rendering actions - Inside both image-based and text-based identity pre-rendering configuration scripts, we use the ACTIONS array variable to define the way centos-art.sh script performs identity rendering. Identity rendering is organized by one BASE action, and optional POST and LAST rendering actions. - The BASE action specifies what kind of rendering does the centos-art.sh script will perform with the files related to the pre-rendering configuration script. The BASE action is required. Possible values to BASE action are either renderImage or renderText only. - To specify the BASE action you need to set the BASE: string followed by one of the possible values. For example, if you want to render images, consider the following definition of BASE action: - - Only one BASE action must be specified. If more than one BASE action is specified, the last one is used. If no BASE action is specified at all, an error is triggered and the centos-art.sh script ends its execution. - The POST action specifies which action to apply for each file rendered (at the rendering time). This action is optional. You can set many different POST actions to apply many different actions over the same already rendered file. Possible values to POST action are renderFormats, renderSyslinux, renderGrub, etc. - To specify the POST action, you need to use set the POST: followed by the function name of the action you want to perform. The exact form depends on your needs. For example, consider the following example to produce xpm, jpg, and tif images, based on already rendered png image, and also organize the produced files in directories named as their own extensions: - - In the previous example, file organization takes place at the moment of rendering, just after producing the png base file and before going to the next file in the list of files to render. If you don't want to organized the produced files in directories named as their own extensions, just remove the POST:groupByFormat action line: - - The LAST action specifies which actions to apply once the last file in the list of files to process has been rendered. The LAST action is optional. Possible values for LAST actions may be groupByFormat, renderGdmTgz, etc. - - Note — Removed(xref:trunk Scripts Bash Functions Render) —, to know more about possible values for BASE, POST and LAST action definitions. - - To specify the LAST action, you need to set the LAST: string followed by the function name of the action you want to perform. For example, consider the following example if you want to render all files first and organize them later: - - Usage - Use the following commands to administer both identity and translation pre-rendering configuration scripts: - - - centos-art config --create='path/to/dir/' - - Use this command to create path/to/dir related pre-rendering configuration script. - - - - centos-art config --edit='path/to/dir/' - - Use this command to edit path/to/dir related pre-rendering configuration script. - - - - centos-art config --read='path/to/dir/' - - Use this command to read path/to/dir related pre-rendering configuration script. - - - - centos-art config --remove='path/to/dir/' - - Use this command to remove path/to/dir related pre-rendering configuration script. - - -
- In the commands above, path/to/dir refers to one renderable directory path under trunk/Identity or trunk/Translations structures only. - 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 - - +
Directories trunk Scripts Functions Tuneup - Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Render Directories
The <file>trunk/Scripts/Functions/Tuneup</file> Directory @@ -3634,6 +3305,89 @@ ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' Description + 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.sh 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 •