From c9dfde839c2114a9ec1a8bb3861e254651743bc0 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Mar 01 2011 17:47:35 +0000 Subject: Update filesystem chapter inside repository documentation manual. --- diff --git a/Manuals/Repository/Filesystem/Identity.texi b/Manuals/Repository/Filesystem/Identity.texi new file mode 100644 index 0000000..65f22ca --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity.texi @@ -0,0 +1,126 @@ +@subsection Goals + +The @file{trunk/Identity} directory exists to organize CentOS +corporate identity artworks. + +@subsection Description + +The CentOS Project corporate identity is the ``persona'' of the +organization known as The CentOS Project. The CentOS Project +corporate identity plays a significant role in the way the CentOS +Project, as organization, presents itself to both internal and +external stakeholders. In general terms, the CentOS Project corporate +visual identity expresses the values and ambitions of the CentOS +Project organization, its business, and its characteristics. + +The CentOS Project corporate identity provides visibility, +recognizability, reputation, structure and identification to the +CentOS Project organization by means of corporate design, corporate +communication, and corporate behaviour. + +The CentOS Project settles down its corporate visual identity on a +``monolithic corporate visual identity structure''. In this structure +The CentOS Project uses one unique name (The CentOS Brand) and one +unique visual style (The CentOS Default Theme) in all its +manifestations. + +@table @strong + +@item The CentOS Brands +The CentOS brand is the name or trademark that conncects the producer +with their products. In this case, the producer is The CentOS Project +and the products are the CentOS distributions, the CentOS web sites, +the CentOS promotion stuff, etc. + +@xref{trunk Identity Brands}, for more information. + +@item The CentOS Themes + +The CentOS themes are a set of image files connected all together by +one unique visual style. Each theme is organized in different visual +manifestations, in order to cover each visual manifestation of The +CentOS Project (i.e., distributions, websites, promotion stuff, etc.). +@xref{trunk Identity Themes}, for more information. +@end table + +Inside a monolithic corporate visual identity structure, internal and +external stakeholders use to feel a strong sensation of uniformity, +orientation, and identification with the organization. No matter if +you are visiting websites, using the distribution, or acting on social +events, the one unique name and one unique visual style conect them +all to say: Hey! we are all parts of the CentOS project. And, +probably, some vister will say: Can I join the party? Yes you can, it +is free. :) + +@subsection Usage + +To produce identity artworks, use the following commands: + +@table @samp +@item centos-art render 'path/to/dir' + +When @samp{path/to/dir} refers to one renderable directory under +@file{trunk/Identity}, this command renders identity artworks using +both related design models and related translation files. + +@item centos-art render 'path/to/dir' --filter='pattern' + +When @samp{path/to/dir} refers to one renderable directory under +@file{trunk/Identity}, this command renders identity artworks using +both related design models and related translation files that match +the regular expression passed in @samp{--filter='pattern'} argument. + +To control the number of files produced by @command{centos-art} +command, you need to look into the translation path and provide a +regular expression pattern that matches the translation path, or +paths, related to the file, or files, you want to produce. + +The regular expression pattern you provide to @command{centos-art} +command is applied to the translation path from its very beginning. +It is not the same to say @samp{5/en/01-welcome} that +@samp{01-welcome}, the frist expression matches but the last one does +not. + +When using @samp{--filter='pattern'} you don't need to specify the +file extension. It is removed from translation path before applying +the pattern, so it doesn't count here. +@end table + +@subsection File name convenctions + +As file name convenction, inside CentOS Artwork Repository, both +text-based and image-based file name produced by @command{centos-art.sh} +script has the same name of their translation files without +the @samp{.sed} extension. The file extension is set as follow: + +@subsubsection When text-based files are rendered + +Text-based files end up having the same extension of their design +template file. + +@subsubsection When image-based files are rendered + +Image-based files always end up having the @file{.png} extension. + +@quotation +@strong{Tip} Once @file{.png} images are created, other image formats +may be created using the @command{renderFormats} post-rendering +action, inside the image-based related pre-rendering configuration +script. + +@xref{trunk Scripts Bash}, for more information. +@end quotation + +@subsection See also + +@menu +@comment --- Removed(* trunk Translations::) --- +@end menu + +@subsection References + +@itemize +@item @url{http://en.wikipedia.org/Corporate_identity} (and related +links). +@end itemize + diff --git a/Manuals/Repository/Filesystem/Identity/Brands.texi b/Manuals/Repository/Filesystem/Identity/Brands.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Brands.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Fonts.texi b/Manuals/Repository/Filesystem/Identity/Fonts.texi new file mode 100644 index 0000000..ef6730a --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Fonts.texi @@ -0,0 +1,79 @@ +@subsection Goals + +This section exists to organize digital typographies used by the +CentOS project. + +@subsection Description + +@subsection Usage + +The CentOS corporate identity is attached to @samp{DejaVu LGC} +font-family. Whatever artwork you design for CentOS project, that +requires typography usage, must be done using @samp{DejaVu LGC} +font-family. + +@table @strong +@item Recommendation-1: + +For screen desings (e.g., anything that final destination will never +be printed on paper or any medium outside computer screens) use +@samp{DejaVu LGC Sans} font-family. + +@item Recommendation-2: + +For non-screen designs (e.g., anything that final desition will be +printed on paper or any other medium outside computer screens) use +@samp{DejaVu LGC Serif} font-family. As convenction files described in +this rule are stored under @samp{Stationery} directories. +@end table + +The only execption for the two recommendations above is the typography +used inside CentOS logo. The CentOS logo is the main visual +representation of the CentOS project so the typography used in it must +be the same always, no matter where it be shown. It also has to be +clear enough to dismiss any confussion between similar typefaces +(e.g., the number one (1) sometimes is confuesed with the letter +@samp{el} (l) or letter @samp{ai} (i)). + +As CentOS logo typography convenction, the word @samp{CentOS} uses +@samp{Denmark} typography as base, both for the word @samp{CentOS} and +the phrase @samp{Community Enterprise Operating System}. The phrase +size of CentOS logo is half the size in poits the word @samp{CentOS} +has and 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. + +When the CentOS release brand is built, use @samp{Denmark} typography +for the release number. The release number size is two times larger +(in height) than default @samp{CentOS} word. The separation between +release number and @samp{CentOS} word is twice the size in points of +separation between @samp{CentOS} word and phrase @samp{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 @samp{CentOS} word. The trademark +symbol must not exceed haf the distance, in points, between +@samp{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. + +@quotation +@strong{Note} The information about trademarks and corporate identity +is my personal interpretation of +@url{http://en.wikipedia.org/Corporate_identity} and +@url{http://en.wikipedia.org/Trademark} description. If you have +practical experiences with these affairs, please serve yourself to +improve this section with your reasons. +@end quotation + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Icons.texi b/Manuals/Repository/Filesystem/Identity/Icons.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Icons.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Isolinux.texi b/Manuals/Repository/Filesystem/Identity/Isolinux.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Isolinux.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models.texi b/Manuals/Repository/Filesystem/Identity/Models.texi new file mode 100644 index 0000000..3973252 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models.texi @@ -0,0 +1,19 @@ +@subsection Goals + +This section exists to organize design models. + +@subsection Description + +Design models are representative designs useful to understand how +to build artworks. + +@subsection Usage + +@subsection See also + +@menu +* trunk Identity Models Html:: +* trunk Identity Models Css:: +* trunk Identity Models Tpl:: +* trunk Identity Models Xcf:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Css.texi b/Manuals/Repository/Filesystem/Identity/Models/Css.texi new file mode 100644 index 0000000..5639459 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Css.texi @@ -0,0 +1,21 @@ +@subsection Goals + +This directory exists to provide common style sheets (CSS) definitions +to HTML design models. + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Html.texi b/Manuals/Repository/Filesystem/Identity/Models/Html.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Html.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Img/Promo/Web.texi b/Manuals/Repository/Filesystem/Identity/Models/Img/Promo/Web.texi new file mode 100644 index 0000000..ec9b88b --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Img/Promo/Web.texi @@ -0,0 +1,23 @@ +@subsection Goals + +@itemize +@item Provide images related to CentOS web interface. +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +* trunk Identity Models Tpl Promo Web:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Tpl.texi b/Manuals/Repository/Filesystem/Identity/Models/Tpl.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Tpl.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Tpl/Promo/Web.texi b/Manuals/Repository/Filesystem/Identity/Models/Tpl/Promo/Web.texi new file mode 100644 index 0000000..56b7f37 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Tpl/Promo/Web.texi @@ -0,0 +1,329 @@ +@subsection Goals + +Organize scalable vector graphics (svg) to help describe the CentOS +web environment. + +@subsection The CentOS web environment + +Inside CentOS corporate identity, the CentOS web environment is +considered a promotion component. The CentOS web environment is formed +by a central web application ---to cover base needs (e.g., per-major +release information like release notes, lifetime, downloads, +documentation, support, security advisories, bugs, etc.)--- and many +different free web applications ---to cover specific needs (e.g., +wiki, mailing lists, etc.)---. + +The CentOS web environment is addressed to solve the following issues: + +@itemize +@item One unique name and one unique visual style to all web +applications used inside the web environment. + +@item One-step navigation to web applications inside the environment. + +@item High degree of customization to change the visual style of all +web applications with few changes (e.g, updating just two or three +images plus common style sheet [CSS] definitions). +@end itemize + +The CentOS project is attached to a monolithic corporate visual +identity (@pxref{trunk Identity}), where all visual manifestations +have one unique name and one unique visual style. This way, the CentOS +web environment has one unique name (the CentOS brand) and one unique +visual style (the CentOS default theme) for all its visual +manifestations, the web applications in this case. + +Since a maintainance point of view, achiving the one unique visual +style inside CentOS web environment is not a simple task. The CentOS +web environment is built upon many different web applications which +have different visual styles and different internal ways to customize +their own visual styles. For example: MoinMoin, the web application +used to support the CentOS wiki (@url{http://wiki.centos.org/}) is +highly customizable but Mailman (in its 2.x.x serie), the web +application used to support the CentOS mailing list, doesn't +support@footnote{The theme support of Mailman may be introduced in +mailman-3.x.x release.} a customization system that separates +presentation from logic, similar to that used by MoinMoin. + +This visual style diversity complicates our goal of one unique visual +style for all web applications. So, if we want one unique visual style +for all web applications used, it is innevitable to modify the web +applications in order to implement the CentOS one unique visual style +customization in them. Direct modification of upstream applications is +not convenient because upstream applications come with their one +visual style and administrators take the risk of loosing all +customization changes the next time the application be updated (since +not all upstream web applications, used in CentOS web environment, +separate presentation from logic). + +To solve the ``one unique visual style'' issue, installation and +actualization of web applications ---used inside CentOS web +environment--- need to be independent from upstream web applications +development line; in a way that CentOS web environment administrators +can install and update web applications freely without risk of loosing +the one unique visual style customization changes. + +At the surface of this issue we can see the need of one specific yum +repository to store CentOS web environment customized web applications. + +@subsubsection Design model (without ads) + +@subsubsection Design model (with ads) + +@subsubsection HTML definitions + +@subsubsection Controlling visual style + +Inside CentOS web environment, the visual style is controlled by the +following compenents: + +@table @strong +@item Webenv header background +@verbatim +trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png +@end verbatim + +@item CSS definitions +@verbatim +trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css +@end verbatim +@end table + +@subsubsection Producing visual style + +The visual style of CentOS web environment is defined in the following +files: + +@verbatim +trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf +trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png +trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png +trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg +@end verbatim + +As graphic designer you use @file{1024x250.xcf} file to produce +@file{1024x250-bg.png} file. Later, inside @file{1024x250.svg} file, +you use the @file{1024x250-bg.png} file as background layer to draw +your vectorial design. When you consider you artwork ready, use the +@command{centos-art.sh} script, as described below, to produce the +visual style controller images of CentOS web environment. + +@verbatim +centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250' +@end verbatim + +Once you have rendered required image files, changing the visual style +of CentOS web environment is a matter of replacing old image files +with new ones, inside webenv repository file system structure. The +visual style changes will take effect the next time customization line +of CentOS web applications be packaged, uploded, and installed from +[webenv] or [webenv-test] repositories. + +@subsubsection Navigation + +Inside CentOS web environment, the one-step navegation between web +applications is addressed using the web environment navigation bar. +The web environment navigation bar contains links to main applications +and is always visible no matter where you are inside the web +environment. + +@subsubsection Development and release cycle + +The CentOS web environment development and relase cycle is described +below: + +@table @strong + +@item Download + +The first action is download the source code of web applications we +want to use inside CentOS web environment. + +@quotation +@strong{Important} The source location from which web application are +downloaded is very important. Use SRPMs from CentOS @strong{[base]} +and @strong{[updates]} repositories as first choise, and third party +repositories (e.g. RPMForge, EPEL, etc.) as last resource. +@end quotation + +@item Prepare + +Once web application source code has been downloaded, our duty is +organize its files inside @samp{webenv} version controlled repository. + +When preparing the structure keep in mind that different web +applications have different visual styles, and also different ways to +implement it. A convenient way to organize the file system structure +would be create one development line for each web application we use +inside CentOS web environment. For example, consider the following +file system structure: + +@verbatim +https://projects.centos.org/svn/webenv/trunk/ +|-- WebApp1/ +| |-- Sources/ +| | `-- webapp1-0.0.1/ +| |-- Rpms/ +| | `-- webapp1-0.0.1.rpm +| |-- Srpms/ +| | `-- webapp1-0.0.1.srpm +| `-- Specs/ +| `-- webapp1-0.0.1.spec +|-- WebApp2/ +`-- WebAppN/ +@end verbatim + +@item Customize + +Once web applications have been organized inside the version +controlled repository file system, use subversion to create the CentOS +customization development line of web applications source code. For +example, using the above file system structure, you can create the +customization development line of @file{webapp1-0.0.1/} with the +following command: + +@verbatim +svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv +@end verbatim + +The command above creates the following structure: + +@verbatim +https://projects.centos.org/svn/webenv/trunk/ +|-- WebApp1/ +| |-- Sources/ +| | |-- webapp1-0.0.1/ +| | `-- webapp1-0.0.1-webenv/ +| |-- Rpms/ +| | `-- webapp1-0.0.1.rpm +| |-- Srpms/ +| | `-- webapp1-0.0.1.srpm +| `-- Specs/ +| `-- webapp1-0.0.1.spec +|-- WebApp2/ +`-- WebAppN/ +@end verbatim + +In the above structure, the @file{webapp1-0.0.1-webenv/} directory is +the place where you customize the visual style of +@file{webapp1-0.0.1/} web application. + +@quotation +@strong{Tip} Use the @command{diff} command of Subversion between +CentOS customization and upstream development lines to know what you +are changing exactly. +@end quotation + +@item Build packages + +When web application has been customized, build the web application +RPM and SRPM using the source location with @samp{-webenv} prefix. + +@verbatim +https://projects.centos.org/svn/webenv/trunk/ +|-- WebApp1/ +| |-- Sources/ +| | |-- webapp1-0.0.1/ +| | `-- webapp1-0.0.1-webenv/ +| |-- Rpms/ +| | |-- webapp1-0.0.1.rpm +| | `-- webapp1-0.0.1-webenv.rpm +| |-- Srpms/ +| | |-- webapp1-0.0.1.srpm +| | `-- webapp1-0.0.1-webenv.srpm +| `-- Specs/ +| |-- webapp1-0.0.1.spec +| `-- webapp1-0.0.1-webenv.spec +|-- WebApp2/ +`-- WebAppN/ +@end verbatim + +@item Release for testing + +When the customized web application has been packaged, make packages +available for testing and quality assurance. This can be achives using +a [webenv-test] yum repository. + +@quotation +@strong{Note} The [webenv-test] repository is not shipped inside +CentOS distribution default yum configuraiton. In order to use +[webenv-test] repository you need to configure it first. +@end quotation + +If some problem is found to install/update/use the customized version +of web application, the problem is notified somewhere (a bugtracker +maybe) and the customization face is repated in order to fix the +problem. To release the new package add a number after @samp{-webenv} +prefix. For example, if some problem is found in +@file{webapp1-0.0.1-webenv.rpm}, when it be fixed the new package will +be named @file{webapp1-0.0.1-webenv-1.rpm}. If a problem is found in +@file{webapp1-0.0.1-webenv-1.rpm}, when it be fixed the new package +will be named @file{webapp1-0.0.1-webenv-2.rpm}, and so on. + +The ``customization --- release for testing'' process is repeated +until CentOS quality assurance team considers the package is ready for +production. + +@item Release for production + +When customized web application packages are considered ready for +production they are moved from [webenv-test] to [webenv] repository. +This action is commited by CentOS quality assurance team. + +@quotation +@strong{Note} The [webenv] repository is not shipped inside CentOS +distribution default yum configuraiton. In order to use [webenv] +repository you need to configure it first. +@end quotation +@end table + +@subsubsection The [webenv-test] repository + +@verbatim +/etc/yum.repos.d/CentOS-Webenv-test.repo +@end verbatim + +@verbatim +[webenv-test] +name=CentOS-$releasever - Webenv-test +mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test +#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/ +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever +enabled=1 +priority=10 +@end verbatim + +@subsubsection The [webenv] repository + +@verbatim +/etc/yum.repos.d/CentOS-Webenv.repo +@end verbatim + +@verbatim +[webenv] +name=CentOS-$releasever - Webenv +mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv +#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/ +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever +enabled=1 +priority=10 +@end verbatim + +@subsubsection Priority configuration + +Both [webenv] and [webenv-test] repositories update packages inside +CentOS [base] and CentOS [updates] repositories. + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +* trunk Identity Models Img Promo Web:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Models/Xcf.texi b/Manuals/Repository/Filesystem/Identity/Models/Xcf.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Models/Xcf.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Release.texi b/Manuals/Repository/Filesystem/Identity/Release.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Release.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes.texi b/Manuals/Repository/Filesystem/Identity/Themes.texi new file mode 100644 index 0000000..01a20c1 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes.texi @@ -0,0 +1,26 @@ +@subsection Goals + +The @file{trunk/Identity/Themes/} directory exists to organize +production of CentOS themes. + +@subsection Description + +@subsection Usage + +In this location themes are organized in ``Models'' ---to store common +information--- and ``Motifs''---to store unique information. At +rendering time, both motifs and models are combined to produce the +final CentOS themes. CentOS themes can be tagged as ``Default'' or +``Alternative''. CentOS themes are maintained by CentOS community. + +@menu +* trunk Identity Themes Models:: +* trunk Identity Themes Motifs:: +@end menu + +@subsection See also + +@menu +* trunk Identity:: +* trunk:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models.texi new file mode 100644 index 0000000..b91973a --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models.texi @@ -0,0 +1,30 @@ +@subsection Goals + +@itemize +@item Organize theme models. +@end itemize + +@subsection Description + +Theme models let you modeling characteristics (e.g., dimensions, +translation markers, position of each element on the display area, +etc.) common to all themes. Theme models let you reduce the time +needed when propagating artistic motifs to different visual +manifestations. + +Theme models serves as a central pool of design templates for themes +to use. This way you can produce themes with different artistic motifs +but same characteristics. + +@subsection Usage + +Inside the framework location above, you find theme models organized +by name. You can add your own theme models to the structure by adding +a directory to the list. By default you have the `@xref{trunk Identity +Themes Models Default, Default},' and `@xref{trunk Identity Themes +Models Alternative, Alternative},' ready-to-use theme models. + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Alternative.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Alternative.texi new file mode 100644 index 0000000..483226a --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Alternative.texi @@ -0,0 +1,26 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +CentOS alternative theme models exist for people how want to use a +different visual style on their installations of CentOS distribution. +As the visual style is needed for a system already installed +components like Anaconda are not required inside alternative themes. +Inside alternative themes you find post-installation visual style only +(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative +themes are maintained by CentOS Community. + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Default.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default.texi new file mode 100644 index 0000000..6ce9103 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default.texi @@ -0,0 +1,27 @@ +@subsection Goals + +This location stores CentOS default theme model. The default theme +model of CentOS is used in all visual manifestations of CentOS Project +corporate visual identity (e.g., distributions, web sites, promotion, +etc.). + +@subsection Description + +@subsection Usage + +Changing CentOS default theme is not very convenient because that +affects the ``recognition'' of CentOS Project. Nevertheless, we are +interested on seeing your art work propositions. Specially if your +art work is an improvement to the base idea behind CentOS default +theme (@strong{Modern}, squares and circles flowing up.). + +If you are not happy with CentOS default theme, you can look inside +CentOS alternative themes and download the one you are interested in. +If you are not happy with any of the CentOS alternative themes +available, then go and design your own CentOS alternative theme as +described in @xref{trunk Identity Themes Motifs, Theme Motifs}. + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro.texi new file mode 100644 index 0000000..d10a829 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro.texi @@ -0,0 +1,83 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +It applies to all major releases of CentOS distribution. + +@subsubsection One theme for all major releases + +Sometimes, specific visual manifestations are formed by common +components which have internal differences. That is the case of CentOS +distribution visual manifestation. + +Since a visual style point of view, the CentOS distributions share +common artwork components like Anaconda ---to cover the CentOS +distribution installation---, BootUp ---to cover the CentOS +distribution start up---, and Backgrounds ---to cover the CentOS +distribution desktop---. Now, since a technical point of view, those +common artwork components are made of software improved constantly. +So, we need to find a way to keep one unique name and one unique +visual style in artwork components that have internal difference and +also remark internal difference as well. + +@quotation +@strong{Important} Remarking the CentOS release schema inside each +major release of CentOS distribution ---or similar visual +manifestation--- takes @emph{high attention} inside The CentOS Project +corporate visual identity. It should be very clear for people which +major release of CentOS distribution they are using. +@end quotation + +In order to remark the CentOS release schema, the CentOS Artwork SIG +uses a release-specific brand design named ``The CentOS Release +Brand''. The CentOS release brand is compossed by the CentOS logotype +@emph{and} the CentOS major release number (as specified in CentOS +release schema definition). In this solution, the CentOS release brand +is set inside all release-specific artworks (e.g., distribution, +installation media, etc.) in remarkable way. The CentOS release +brand is the design component that lets us remark the CentOS release +schema inside the monolithic corporate visual identity structure we +propose to use. + +@subsubsection One theme for each major release + +Other way we've been using to remark CentOS release schema is +applying one unique theme for @emph{each} major release of CentOS +distribution. That is, if we have 4 major releases of CentOS +distribution, we need to provide 4 different themes to cover each +CentOS distribution available. + +Inside CentOS Artwork Repository, you can create many themes and that +is very convenient. But using one unique theme for @emph{each} major +release of CentOS distribution would bring visual isolation among +distributions, websites and promotion visual manifestations. If the +CentOS project would maintain just one CentOS distribution (and many +experienced graphic designers ready to create beautiful artworks) this +model would be nice. Indeed, this model looks quite similar to that +one used by Fedora project, doesn't it. But no, the CentOS project +maintains near to 4 major releases of CentOS distribution in parallel, +and that fact makes a huge difference since the corporate visual +identity point of view. + +If we use one unique theme for @emph{each} major release of CentOS +distribution, which one of those themes, does we use to cover other +CentOS visual manifestations, like websites and promotion stuff? + +In whatever case you choose some release-specific distribution user +will be visually isolated from other CentOS visual manifestations like +websites and promotion stuff, even if the CentOS brand is present in +all visual manifestations. In such a case, probably, users will end up +asking themselves, why my CentOS distribution has this design and the +CentOS website another one? Isn't them on the same project? With luck +the CentOS brand will exonerate user form visual isolation. + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro/Anaconda.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro/Anaconda.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Distro/Anaconda.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Promo.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Promo.texi new file mode 100644 index 0000000..7bfbe48 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Promo.texi @@ -0,0 +1,27 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +It applies to all tangible and non tangible items CentOS uses to +promote its existence. Clothes, posters, installation media, +stationery, release countdown images, banners, stickers, are all +examples of promotion designs. + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Web.texi b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Web.texi new file mode 100644 index 0000000..427850f --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Models/Default/Web.texi @@ -0,0 +1,26 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +It applies to all web applications CentOS uses to handle its needs +(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving +HTML standards should be consider here. + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs.texi new file mode 100644 index 0000000..7b8c0e0 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs.texi @@ -0,0 +1,114 @@ +@subsection Goals + +The @file{trunk/Identity/Themes/Motifs} directory exists to: + +@itemize +@item Organize CentOS themes' artistic motifs. +@end itemize + +@subsection Description + +The artistic motif of theme is a graphic design component that +provides the visual style of themes, it is used as pattern to connect +all visual manifestations inside one unique theme. + +Artistic motifs are based on conceptual ideas. Conceptual ideas bring +the motivation, they are fuel for the engines of human imagination. +Good conceptual ideas may produce good motivation to produce almost +anything, and art works don't escape from it. + +@table @samp +@item TreeFlower +CentOS like trees, has roots, trunk, branches, leaves and flowers. Day +by day they work together in freedom, ruled by the laws of nature and +open standards, to show the beauty of its existence. +@item Modern +Modern, squares and circles flowing up. +@end table + +If you have new conceptual ideas for CentOS, then you can say that you +want to create a new artistic motif for CentOS. To create a new +artistic motif you need to create a directory under +@file{Identity/Themes/Motifs/} using a name coherent with your +conceptual idea. That name will be the name of your artistic motif. If +possible, when creating new conceptual ideas for CentOS, think about +what CentOS means for you, what does it makes you feel, take your +time, think deep, and share; you can improve the idea as time goes on. + +Once you have defined a name for your theme, you need to create the +motif structure of your theme. The motif structure is the basic +direcotry structure you'll use to work your ideas. Here is where you +organize your graphic design projects. + +To add a new motif structure to CentOS Artwork Repository, you need to +use the @command{centos-art} command line in the +@file{Identity/Themes/Motifs/} directory as described below: + +@example +centos-art add --motif=ThemeName +@end example + +The previous command will create the basic structure of themes for +you. The basic structure produced by @command{centos-art} command is +illustrated in the following figure: + +@example +trunk/Identity/Themes/Motifs/$ThemeName/ +|-- Backgrounds +| |-- Img +| `-- Tpl +|-- Info +| |-- Img +| `-- Tpl +|-- Palettes +`-- Screenshots +@end example + +@subsection Usage + +When designing artistic motifs for CentOS, consider the following +recommendations: + +@itemize +@item Give a unique (case-sensitive) name to your Motif. This name is +used as value wherever theme variable (@b{$THEME}) or translation marker +(@b{=THEME=}) is. Optionally, you can add a description about +inspiration and concepts behind your work. + +@item Use the location @file{trunk/Identity/Themes/Motifs/$THEME/} to +store your work. If it doesn't exist create it. Note that this require +you to have previous commit access in CentOS Artwork Repository. + +@item The CentOS Project is using the blue color (@b{#204c8d}) as base +color for its corporate visual identity. Use such base corporate color +information as much as possible in your artistic motif designs. + +@item Try to make your design fit one of the theme models. + +@item Feel free to make your art enterprise-level and beautiful. + +@item Add the following information on your artwork (both in a visible +design area and document metadata): + +@itemize + +@item The name (or logo) of your artistic motif. + +@item The copyright sentence: @b{Copyright (C) YEAR YOURNAME} + +@item The license under which the work is released. All CentOS Art +works are released under +@url{http://creativecommons.org/licenses/by-sa/3.0/,Creative Common +Share-Alike License 3.0} +(@url{http://creativecommons.org/licenses/by-sa/3.0/}). + +@end itemize +@end itemize + +@subsection See also + +@menu +* trunk Identity Themes:: +* trunk Identity:: +* trunk:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Flame.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Flame.texi new file mode 100644 index 0000000..b9e787a --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Flame.texi @@ -0,0 +1,206 @@ +@subsection Goals + +This section describes the steps we followed to construct the +@emph{Flame} artistic motif. This section may be useful for anyone +interested in reproducing the @emph{Flame} artistic motif, or in +creating new artistic motifs for The CentOS Project corporate visual +identity (@pxref{trunk Identity}). + +@subsection Description + +The @emph{Flame} artistic motif was built using the flame filter of +Gimp 2.2 in CentOS 5.5. + +The flame filter of Gimp can produce stunning, randomly generated +fractal patterns. The flame filter of Gimp gives us a great oportunity +to reduce the time used to produce new artistic motifs, because of its +``randomly generated'' nature. Once the artistic motif be created, it +is propagated through all visual manifestations of CentOS Project +corporate visual identity using the @file{centos-art.sh} script +(@pxref{trunk Scripts Bash}) inside the CentOS Artwork Repository. + +To set the time intervals between each new visual style production, we +could reuse the CentOS distribution major release schema. I.e., we +could produce a new visual style, every two years, based on a new +``randomly generated'' flame pattern, and publish the whole corporate +visual identity (i.e., distribution stuff, promotion stuff, websites +stuff, etc.) with the new major release of CentOS distribution all +together at once. + +Producing a new visual style is not one day's task. Once we have +defined the artistic motif, we need to propagate it through all visual +manifestations of The CentOS Project corporate visual identity. When +we say that we could produce one new visual style every two years we +really mean: to work two years long in order to propagate a new visual +style to all visual manifestations of The CentOS Project corporate +visual identity. + +Obviously, in order to propagate one visual style to all different +visual manifestations of The CentOS Project corporate visual identity, +we need first to know which the visual manifestations are. To define +which visual manifestations are inside The CentOS Project corporate +visual identity is one of the goals the CentOS Artwork Repository and +this documentation manual are both aimed to satisfy. + +Once we define which the visual manifestation are, it is possible to +define how to produce them, and this way, organize the automation +process. Such automation process is one of the goals of +@file{centos-art.sh} script. + +With the combination of both CentOS Artwork Repository and +@file{centos-art.sh} scripts we define work lines where translators, +programmers, and graphic designers work together to distribute and +reduce the amount of time employed to produce The CentOS Project +monolithic corporate identity. + +From a monolithic corporate visual identity point of view, notice that +we are producing a new visual style for the same theme (i.e., +@emph{Flame}). It would be another flame design but still a flame +design. This idea is very important to be aware of, because we are +somehow ``refreshing'' the theme, not changing it at all. + +This way, as we are ``refreshing'' the theme, we still keep oursleves +inside the monolithic conception we are trying to be attached to +(i.e., one unique name, and one unique visual style for all visual +manifestations). + +Producing artistic motifs is a creative process that may consume long +time, specially for people without experienced knowledge on graphic +design land. Using ``randomly generated'' conception to produce +artistic motifs could be, practically, a way for anyone to follow in +order to produce maintainable artistic motifs in few steps. + +Due to the ``randomly generated'' nature of Flame filter, we find that +@emph{Flame} pattern is not always the same when we use @emph{Flame} +filter interface. + +Using the same pattern design for each visual manifestation is +essential in order to maintain the visual connection among all visual +manifestations inside the same theme. Occasionally, we may introduce +pattern variations in opacity, size, or even position but never change +the pattern design itself, nor the color information used by images +considered part of the same theme. + +@quotation +@strong{Important} +When we design background images, which are considered part of the +same theme, it is essential to use the same design pattern always. +This is what makes theme images to be visually connected among +themeselves, and so, the reason we use to define the word ``theme'' +as: a set of images visually connected among themeselves. +@end quotation + +In order for us to reproduce the same flame pattern always, +@emph{Flame} filter interface provides the @samp{Save} and @samp{Open} +options. The @samp{Save} option brings up a file save dialog that +allows you to save the current Flame settings for the plug-in, so that +you can recreate them later. The @samp{Open} option brings up a file +selector that allows you to open a previously saved Flame settings +file. + +The Flame settings we used in our example are saved in the file: + +@verbatim +trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def +@end verbatim + +@subsection Construction + +@subsubsection Step 1: Set image size + +Create an empty image and fill the @samp{Background} layer with black +(@code{000000}) color. Image dimensions depend on the final +destination you plan to use the image for. For the sake of our +construction example we used an image of 640x480 pixels and 300 pixels +per inch (ppi). + +@subsubsection Step 2: Add base color and pattern information + +Create a new layer named @samp{Base}, place it over @samp{Background} +layer and fill it with the base color (@code{7800ff}) you want to have +your background image set in. Add a mask to @samp{Base} layer using +radial gradient and blur it. You may need to repeat this step more +than once in order to achieve a confortable black radial degradation +on the right side of your design. + +Duplicate @samp{Base} layer and name it @samp{Paper}. Place +@samp{Paper} layer over @samp{Base} layer. Remove content of +@samp{Paper} layer and fill it with @samp{Paper (100x100)} pattern. +Once you've done with black radial degradation, reduce the +@samp{Paper} layer opacity to 20%. + +Notice that when we duplicate one layer, the mask information related +to layer is preserved from previous to next layer. This saves us some +of the time required to produce different layers with the same mask +information on them. + +Duplicate @samp{Paper} layer and rename it @samp{Stripes}. Remove +paper pattern from @samp{Stripes} layer. Fill @samp{Stripes} layer +with @samp{Stripes (48x48)} pattern and reduce the @samp{Stripes} +layer opacity to 15%. + +@subsubsection Step 3: Add flame motif + +Create a new layer named @samp{Flame}. Set the foreground +(@code{003cff}) and background (@code{0084ff}) colors to the gradient +you want to build the flame motif. + +To build flame motif, use the flame filter (@samp{Filters > Render > +Nature > Flame...}) on @samp{Flame} layer. We used a layer mask, with +a radial gradient on it to control the boundaries of flame motif on +@samp{Flame} layer. + +Duplicate @samp{Flame} layer and rename it `Flame Blur'. Place `Flame +Blur' below @samp{Flame} layer. Apply Gussian blur filter +(@samp{Filters > Blur > Gussian Blur...}) until reaching the desiered +effect. + +The opacity value, in @samp{Flame} layers, may vary from one image to +another based on the place the image will be finally placed on. For +example, images used as desktop background have the @samp{Flame} layer +opacity set at 100% but @samp{Flame Blur} is set to 70%. However, you +may find that background images used in anaconda progress slides have +opacity reduced differently, in order to reduce brightness in a way +that texts could look clean and readable over it. + +@subsubsection Step 4: Add foreground color + +Create a new layer named @samp{Color}, place it on top of all visible +layers and fill it with plain color (@code{4c005a}). Reduce +@samp{Color} layer opacity to 20%. You can use the @samp{Color} layer +to control the right side color information you want to produce the +image for. + +Duplicate @samp{Flame} layer and create a new layer named +@samp{Color#1}. Place @samp{Color#1} layer on top of layer named +@samp{Color}. Remove the mask information from @samp{Color#1} layer +and recreate a new one using an inverted alpha channel as reference. +Remove @samp{Color#1} layer content and fill it back with plain black +(@code{000000}) color. Reduce @samp{Color#1} opacity to 20%. In this +step we created a mask to protect the flame artistic motif from black +color, so when we decrement or increment the opacity of layer, the +flame artistic motif wouldn't be affected, just the environment +suround it. + +When you set color information, remember that the same artistic motif +needs to be indexed to 14 and 16 colors, in order to produce Grub and +Syslinux visual manifestations respectively. Using many different +colors in the artistic motif may reduce the possibility of your design +to fix all different situations in. Likewise, using more colors in +one design, and less colors in another design will reduce the +connectivity among your designs, since color information is relevant +to visual identity. + +When you propagate your artistic motif visual style to different +visual manifestations of CentOS Project corporate visual identity, it +is up to you to find out justice and compromise among all possible +variables you may face. + +@subsection See also + +@menu +* trunk Identity Themes Motifs:: +* trunk Identity Themes:: +* trunk Identity:: +* trunk:: +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern.texi new file mode 100644 index 0000000..306ab79 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern.texi @@ -0,0 +1,14 @@ +@subsection Presentation + +@subsection Construction + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds.texi new file mode 100644 index 0000000..adda528 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds.texi @@ -0,0 +1,143 @@ +@subsection Goals + +@itemize +@item Organize background images for Modern theme. +@end itemize + +@subsection Description + +Inside @file{Motifs} directory, the @file{Backgrounds/} directory is +used to create vectorial designs using Inkscape and background images +using Gimp. Later, you can export background images as @file{.png} and +load them in your vectorial design project using the import feautre of +Inkscape. + +You may need to repeat this technic for different screen resoluions. +In that case you need to create one file for each screen resolution +and do the appropriate linking inside .svg to .png files. For example +if you need to produce background images in 800x600 you need to create +the following file: + +@example +xcf/800x600.xcf +@end example + +to produce the background image: + +@example +img/800x600-bg.png +@end example + +which is loaded in: + +@example +svg/800x600.svg +@end example + +to produce the final background image: + +@example +img/800x600.png +@end example + +The @file{img/800x600.png} background image is produced automatically +by means of rendering scripts. + +In other cases (e.g. Anaconda), it is possible that you need to make +some variations to one background image that don't want to appear on +regular background images of the same resolution. In this case you +need to create a new and specific background image for that art +component. For example, if you need to produce the background image +used by Anconda (800x600) art works you create the file: + +@example +xcf/800x600-anaconda.xcf +@end example + +to produce the background image: + +@example +img/800x600-anaconda-bg.png +@end example + +which is loaded in: + +@example +svg/800x600-anaconda.svg +@end example + +to produce the file: + +@example +img/800x600-anaconda.png +@end example + +The 800x600-anaconda.png file is used by all Anaconda art works +sharing a common 800x600 screen resolution (e.g., Header, Progress, +Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors +and 640x480 pixels so you need to create a 640x480 background image +for it, and take the color limitation into account when designing it. + +Background images without artistic motif are generally used as based +to build the Background images that do contain the theme artistic +motif. + +Background images are linked (using the @b{import} feature of +Inkscape) inside almost all theme art works. This structure let you +make centralized changes on the visual identity and propagate them +quickly to other areas. + +In this structure you design background images for different screen +resolutions based on the theme artistic motif. + +You may create different artistic motifs propositions based +on the same conceptual idea. The conceptual idea is what defines a +theme. Artistic motifs are interpretations of that idea. + +Inside this directory artistic motifs are organized by name (e.g., +TreeFlower, Modern, etc.). + +Each artistic motif directory represents just one unique artistic +motif. + +The artistic motif is graphic design used as common pattern to connect +all visual manifestations inside one unique theme. The artistic motif +is based on a conceptual idea. Artistic motifs provide visual style +to themes. + +Designing artistic motifs is for anyone interested in creating +beautiful themes for CentOS. When building a theme for CentOS, the +first design you need to define is the artistic motif. + + +Inside CentOS Artwork Repository, theme visual styles (Motifs) and +theme visual structures (Models) are two different working lines. +When you design an artistic motif for CentOS you concentrate on its +visual style, and eventualy, use the @command{centos-art} command line +interface to render the visual style, you are currently producing, +against an already-made theme model in order to produce the final +result. Final images are stored under @file{Motifs/} directory using +the model name, and the model directory structure as reference. + +The artistic motif base structure is used by @command{centos-art} to +produce images automatically. This section describes each directory of +CentOS artistic motif base structure. + +@subsection Usage + +The @file{Backgrounds/} directory is probably the core component, +inside @file{Motifs/} directory structure. Inside @file{Backgrounds/} +directory you produce background images used by almost all theme +models (e.g., Distribution, Websites, Promotion, etc.). The +@file{Backgrounds/} directory can contain subdirectories to help you +organize the design process. + +@subsection See also + +@menu +* trunk Identity Themes Motifs Modern Backgrounds Img:: +* trunk Identity Themes Motifs Modern Backgrounds Tpl:: +* trunk Identity Themes Motifs Modern Backgrounds Xcf:: +@comment --- Removed(* trunk Translations Identity Themes Backgrounds::) --- +@end menu + diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi new file mode 100644 index 0000000..fc1ecfb --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi @@ -0,0 +1,19 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +In this directory is where you store all background images (e.g., +.png, .jpg, .xpm, etc.). This directory is required by +@file{centos-art} command line interface. + +@subsection See also + +@menu +@end menu + diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi new file mode 100644 index 0000000..4b3308a --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi @@ -0,0 +1,18 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +In this directory is where you store all the scalable vector graphics +(e.g., .svg) files. This directory is required by @file{centos-art} +command line interface. + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi new file mode 100644 index 0000000..b572a3d --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi @@ -0,0 +1,27 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + + +@subsection Usage + +In this directory is where you store the project files (e.g, .xcf) of +Gimp. This directory is not required by @file{centos-art} command +line interface. If you can create a beautiful background images using +scalable vector graphics only, then there is no need to use the +@file{Xcf/} directory to store background projects. Of course, you can +merge both Gimp and Inkscape power to produce images based on them. +In this last case you need the @file{Xcf/} directory. + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi new file mode 100644 index 0000000..8735b28 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi @@ -0,0 +1,59 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +To render Anaconda progress slide images using the @emph{Modern} +artistic motif design, the Default theme model, and available +translation files (--- @strong{Removed}(pxref:trunk Translations Identity Themes Distro +Anaconda Progress) ---); use the following commands: + +@example +cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/ +centos-art render --identity +@end example + +The above command will create the following structure: + +@example +trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress +|-- 3 +| |-- en +| | |-- 01-welcome.png +| | |-- 02-donate.png +| | `-- 03-yum.png +| `-- es +| |-- 01-welcome.png +| |-- 02-donate.png +| `-- 03-yum.png +|-- 4 +| |-- en +| | |-- 01-welcome.png +| | |-- 02-donate.png +| | `-- 03-yum.png +| `-- es +| |-- 01-welcome.png +| |-- 02-donate.png +| `-- 03-yum.png +`-- 5 + |-- en + | |-- 01-welcome.png + | |-- 02-donate.png + | `-- 03-yum.png + `-- es + |-- 01-welcome.png + |-- 02-donate.png + `-- 03-yum.png +@end example + + +@subsection See also + +@menu +@end menu + diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Palettes.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Palettes.texi new file mode 100644 index 0000000..79765d1 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/Modern/Palettes.texi @@ -0,0 +1,20 @@ +@subsection Goals + +@itemize +@item Organize palette files for Modern theme. +@end itemize + +@subsection Description + +@subsection Usage + +Here is where graphic designers define theme palettes for +color-limited art works. Theme palettes contain the color information +that rendering functions need, in order to produce images with color +limitations. Theme palettes contain the unique color information +required by theme. + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi new file mode 100644 index 0000000..32e0626 --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi @@ -0,0 +1,323 @@ +@subsection Goals + +This section exists to orgnize backgrounds of @emph{TreeFlower} +artistic motif. + +@subsection Description + +@subsubsection Desktop background + +Once you have defined the vectorial artistic motif design, use the +@command{centos-art.sh} script (as described in usage section below) +to produce the png version of it. With the png version of your +vectorial design do the following: + +Open the png version with GIMP. + +Save the png version as a project of GIMP inside +@file{trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf} +directory, using the same name of your vectorial design but with the +@samp{.xcf} extension. + +Now use GIMP to improve your design. Here you may add one layer for +pattern, another for colors, and so on until you find yourself +confortable with your artwork. For example, the following layer +distribution (from bottom to top) was used to build revision 285 of +file @file{1360x768.xcf} using @emph{TreeFlower} artistic motif at +revision 241. + +@table @strong +@item Layer 1: Background + +The first thing we did with GIMP was to create a layer named +@samp{Background} to store the artistic motif (File > Open as layer). +This layer is the lowest layer in the image. Later, we started to +create layers one upon another to change the artistic motif visual +style. + +@item Layer 2: Shadow#1 + +This layer is above @samp{Background} and contains a linear gradient +from left (000000) to right (transparent) covering the whole image. +This layer masks the artistic motif to avoid the effect of linear +gradient. This layer is 100% of opacity. + +@item Layer 3: Shadow#2 + +This layer is above @samp{Shadow#1} and contains a linear gradient +from left (000000) to right (transparent) covering just the 70% of the +whole image aproximatly. This layer doesn't mask the artistic motif +which make the left part of it fall into the dark of linear gradient. +This layer is 100% of opacity. + +@item Layer 4: Pattern (Paper) + +This layer is above @samp{Shadow#2} an contains the paper pattern +shipped with GIMP 2.2. This layer doesn't mask the artistic motif so +the pattern is applied over the whole image. This layer is set to 15% +of opacity. + +@item Layer 5: Pattern (Stripes) + +This layer is above @samp{Pattern (Paper)} and contains the stripes +used over the artistic motif. This layer do masks the artistic motif +so the stripes are only applied to it. This layer is set to 10% of +opacity. + +@item Layer 6: Shadow#3 + +This layer is above @samp{Pattern (Stripes)} and contains a linear +gradient from right (6600ff) to left (transparent). This layer masks +the artistic motif so the linear gradient doesn't affect it. This +layer is set to 15% of opacity. + +@item Layer 7: Shadow#4 + +This layer is above @samp{Shadow#3} and contains a +linear gradient from left (000000) to right (transparent). This layer +do masks the artistic motif so the linear gradient doesn't affect it. +This layer is set to 10% of opacity. + +@item Layer 8: Color#1 + +This layer is above @samp{Shadow#4} and is filled with orange (ffae00) +color over the whole image. This layer is set to 10% of opacity. + +@item Layer 9: Color#2 + +This layer is above @samp{Color#1} and is filled with +blue (010a88) color over the whole image. This layer is set to 10% of +opacity. + +@end table + +@quotation +@strong{Note} There is no definite combination. To get the appropriate +visual design is a matter of constant testing and personal taste. +@end quotation + +Finally, use @samp{Save as copy ...} option to export the final +design. To export the final design use the same name of your vectorial +design plus @samp{-final.png} extension. + +You can repeat these steps to create images for other screen +resolutions. + +@subsubsection Anaconda Prompt (syslinux) background + +When building syslinux backgrounds it is needed to take into account +that the final image is reduced to 16 colors. In desktop background +there is no color limitation but syslinux does have. The goal of this +section is achieving a final syslinux background as close as possible +to desktop backgrounds using 16 colors only. + +Another point to consider is the forground and background definition +used by syslinux. The syslinux documentation says that the color set +in position 0 is the background and color set in position 7 is the +forground. The final palette of color used by our background will +match that specification. For great contrast we'll use black as +background and white as forground. At this poing we have black +(000000) and white (ffffff) colors in our syslinux palette, which left +us with 14 colors to play with. + +Let's begin with @file{Xcf/640x300.xcf} layer distribution from bottom +to top: + +@table @strong +@item Layer 1: Background + +This layer is the lowest layer in the image composition and contains +the artistic motif image rendered for the same resolution (i.e., +@file{Img/Png/640x300.png}). This layer is set to 100% of opacity. + +@item Layer 2: Pattern (Paper) + +This layer is placed above @samp{Background} layer and contains the +paper pattern shipped with GIMP 2.2. This layer doesn't mask the +artistic motif. This layer is set to 30% of opacity. + +@item Layer 3: Pattern (Stripes) + +This layer is placed above @samp{Pattern (Paper)} layer and contains +the stripes pattern shipped with GIMP 2.2. This layer does mask the +artistic motif in order to apply the stripes over it only. The +background is not affected by the stripes pattern just the artistic +motif. This layer is set to 20% of opacity. + +@item Layer 4: Shadow#1 + +This layer is placed above @samp{Pattern (Stripes)} layer and fills +the entire layer area with violet (6600ff) color. This layer do mask +the artistic motif in order to applied the violet color to the +background area outside the artistic motif only. This layer is set to +15% of opacity. + +@item Layer 5: Color#1 + +This layer is above @samp{Shadow#1} and is filled with orange (ffae00) +color to cover the whole image. This layer is set to 10% of opacity. + +@item Layer 6: Color#2 + +This layer is above @samp{Color#1} and is filled with blue (010a88) +color to cover the whole image. This layer is set to 10% of opacity. + +@item Layer 7: Shadow#2 + +This layer is above @samp{Color#1} and contains a linear gradient from +left (000000) to right (transparent) covering 70% of the image +approximately. + +@end table + +At this point we have the composition and should look like the desktop +backgrounds. Compared with desktop backgrounds there are some +differences in opacity. This is because in our testings the final +color information found with this composition produces an acceptable +16 color image. Of course this is something we haven't seen yet. + +To define the color information of our current coposition, save the +syslinux background composition we've done using @samp{File > Save as +Copy ...} option in the following location: + +@verbatim +trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png +@end verbatim + +Now, create the final png version of syslinux backgrounds using the +following command: + +@verbatim +centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt +@end verbatim + +This command will create syslinux-splash final images for all major +releases of CentOS distribution the repository has been configured to. +The important files here are @file{syslinux-splash.png}, other +files may contain the wrong information because we haven't defined yet +the correct color information to use. + +Open one @file{syslinux-splash.png} file with GIMP and use the +@samp{Image > Mode > Indexed} to reduce image colors up to 16 colors, +using the @samp{Generate optimum palette} feature of GIMP. If the +image looks aceptable after reducing colors, use the @samp{Palettes} +menu (Ctrl+P) of GIMP to import a new palette from file and name it +@samp{CentOS-TreeFlower-Syslinux}. Once you've saved the palette, the +color information is stored at: + +@verbatim +~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl +@end verbatim + +You need to edit @file{CentOS-TreeFlower-Syslinux.gpl} file in order +to set the appropriate order of colors. Remember black (000000) in +position 0, and white (ffffff) in position 7. Other positions are +irrelevant. When editing this file you may find that color reduction +did not set black and white colors to their respective values exactly. +Change that manually. For example, consider the following palette: + +@verbatim +GIMP Palette +Name: CentOS-TreeFlower-Syslinux +Columns: 16 +# + 0 0 0 Background (black) + 23 20 35 Untitled + 34 25 48 Untitled + 37 35 60 Untitled + 47 36 68 Untitled + 37 54 86 Untitled + 60 48 90 Untitled +255 255 255 Foreground (white) + 66 54 99 Untitled + 74 61 98 Untitled + 49 78 126 Untitled + 43 87 151 Untitled + 92 89 95 Untitled + 54 104 183 Untitled +158 153 156 Untitled +201 196 195 Untitled +@end verbatim + +Update the @samp{Palettes} menu to get the new color positions from +the file you just edited and open the palette with double click. + +Update the @file{syslinux.gpl} file copying the following file: + +@verbatim +~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl +@end verbatim + +to + +@verbatim +trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl +@end verbatim + +With the @samp{CentOS-TreeFlower-Syslinux} palette opened in the +@samp{Palette Editor}, open (Ctrl+O) the following file: + +@verbatim +trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm +@end verbatim + +and replace its color information with that one in +@samp{CentOS-TreeFlower-Syslinux} palette. When you are replacing +color information inside @file{syslilnux.ppm}, remember to keep the +order of colors just as they are in the +@samp{CentOS-TreeFlower-Palette} palette. + +The @file{syslinux.ppm} file is 16 pixels width and 1 pixel height, so +you probably need to zoom it a bit to set the color information in +their place when using the pen tool with the brush @samp{Circle (01) +(1 x 1)}. + +Once you've updated the @samp{syslinux.ppm} file, it is time to update +the following file: + +@verbatim +trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex +@end verbatim + +The @file{syslinux.hex} file contains the color information in +hexadecimal notation. The color information in hexadecimal notation +is required by @command{ppmtolss16} command. The @command{ppmtolss16} +command produces the final LSS16 image format that is used by syslinux +program inside CentOS distribution. + +The color information inside @file{syslinux.hex} must match the one in +@file{syslinux.ppm} and @file{syslinux.gpl}. For example, based on +@file{CentOS-TreeFlower-Syslinux} palette of colors above, consider +the following @file{syslinux.hex} file: + +@verbatim +#000000=0 +#171423=1 +#221930=2 +#25233c=3 +#2f2444=4 +#253656=5 +#3c305a=6 +#ffffff=7 +#423663=8 +#4a3d62=9 +#314e7e=10 +#2b5797=11 +#5c595f=12 +#3668b7=13 +#9e999c=14 +#c9c4c3=15 +@end verbatim + +@subsubsection Grub background + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Identity/Widgets.texi b/Manuals/Repository/Filesystem/Identity/Widgets.texi new file mode 100644 index 0000000..9cf9a6e --- /dev/null +++ b/Manuals/Repository/Filesystem/Identity/Widgets.texi @@ -0,0 +1,14 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales.texi b/Manuals/Repository/Filesystem/Locales.texi new file mode 100644 index 0000000..98a4746 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales.texi @@ -0,0 +1,56 @@ +The @file{trunk/Locales} directory exists to store the translation +messages used to produce content in different languages. + +Translation messages are organized using the directory structure of +the component being translated. For example, if we want to provide +translation messages for @file{trunk/Manuals/Filesystem}, then the +@file{trunk/Locales/Manuals/Filesystem} directory needs to be created. + +Once the locale directory exists for the component we want to provide +translation messages for, it is necessary to create the translation +files where translation messages are. The translation files follows +the concepts of @command{xml2po} and GNU @command{gettext} tools. + +The basic translation process is as follow: first, translatable +strings are extracted from files and a portable object template (.pot) +is created or updated with the information. Using the portable object +template, a portable object (.po) is created or updated for translator +to locale the messages retrived. Finally, a machine object (.mo) is +created from portable object to sotore the translated messages. + +Inside the repository there are two ways to retrive translatable +strings from files. The first one is through @command{xml2po} command +and the second through @command{xgettext} command. The @command{xml2po} +is used to retrive translatable strings from XML files (e.g., Scalable +Vector Graphics, DocBook, etc.) and the @command{xgettext} command is +used to retrive translatable strings from shell scripts files (e.g., +the files that make the @command{centos-art.sh} command-line +interface). + +When translatable strings are retrived from XML files, using the +@command{xml2po} command, there is no need to create the machine +object as we do when translatable strings ar retrived from shell +files, using the @command{xgettext} command. The @command{xml2po} +produces a temporal machine object in order to create a translated XML +file. Once the translated XML file has been created the machine object +is no longer needed. On the other hand, the machine object produced by +the @command{xgettext} command is required by the system in order for +the show shell script localized messages. + +Another difference between @command{xml2po} and @command{xgettext} we +need to be aware of is the directory structure used to store machine +objects. In @command{xml2po}, the machine object is created in the +current working directory as @file{.xml2po.mo} and can be safetly +removed once the translated XML file has been created. In the case of +@command{xgettext}, the machine object needs to be stored in the +@file{$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo} file in order +for the system to interpret it and should not be removed since it is +the file that contain the translation messages themselves. + +Automation of localization tasks is achived through the @code{locale} +functionality of command-line interface. + +@menu +* trunk Scripts Bash Cli Functions Locale:: +@end menu + diff --git a/Manuals/Repository/Filesystem/Locales/Identity.texi b/Manuals/Repository/Filesystem/Locales/Identity.texi new file mode 100644 index 0000000..5bf1b70 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity.texi @@ -0,0 +1,29 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@comment --- Removed(* trunk Translations Identity Brands::) --- +@comment --- Removed(* trunk Translations Identity Fonts::) --- +@comment --- Removed(* trunk Translations Identity Models::) --- +@comment --- Removed(* trunk Translations Identity Release::) --- +@comment --- Removed(* trunk Translations Identity Themes::) --- +@comment --- Removed(* trunk Translations Identity Widgets::) --- +* trunk Identity:: +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Brands.texi b/Manuals/Repository/Filesystem/Locales/Identity/Brands.texi new file mode 100644 index 0000000..6f771ef --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Brands.texi @@ -0,0 +1,105 @@ +@subsection Goals + +@itemize +@item Organize brands' translation files. +@end itemize + +@subsection Description + +Translation files, inside @file{trunk/Translations/Identity/Brands} +translation entry, don't use default rendering translation +functionality, they use the following translation pre-rendering +configuration file instead: + +@verbatim +/home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh +@end verbatim + +Inside @file{trunk/Translations/Identity/Brands} translation entry, +translation files are symbolic links pointing to the common template +translation structure, inside the translation template (@samp{Tpl/}) +directory. + +Inside @file{trunk/Translations/Identity/Brands} translation entry, +translation files are created using identity design templates as +reference. The translation pre-rendering script creates a translation +structure where the translation template (@samp{Tpl/}) directory +structure applies to each single design template available. + +For example, if the brands' translation template (@samp{Tpl/}) +directory has 30 translation files, and there are 20 design templates; +the brands' translation pre-rendering script creates a translation +structure of symbolic links where the 30 translation files apply the +20 design templates one by one, producing 600 translation symbolic +links as result. At this point, when rendering identity, the +@command{centos-art} script considers translation symbolic links as +translation files. + +Translation file names, inside brands' translation template +(@samp{Tpl}) directory have special meaning: + +@subsubsection Conventional file names +@cindex Translation brands file names + +Convenctional file names look like @file{blue.sed}, @file{2c-a.sed}, +etc. Replacement commands inside translation file are applied to +design templates and translation file names are used as final image +name. The image dimensions use the same dimensions that design +template has. + +@subsubsection Numeric file names +@cindex Translation brands file names + +Numeric file names look like @file{300.sed}, @file{200.sed}, etc. +Replacements commands inside translation files are applied to design +templates, and translation file names are used as final image name. +The final image is saved using an specific @samp{width} defined by the +number part of the translation file name. The image @samp{height} is +automatically scaled based on the previous @samp{width} definition to +maintain the designing ratio. + +For example, if your design template has 400x200 pixels of dimension, +and you apply a translation file named `300.sed' to it, the final +image you get as result will have 300x100 pixels of dimension. The +same is true if you use higher numbers like `1024.sed', `2048.sed', +etc. In these cases you have bigger images proportionally. + +As we are using scalable vector graphics to design identity templates, +the image size you produce is not limitted in size. You can use one +design template produced in 400x200 pixels to produce larger or +shorter PNG images using numeric translation files as described +above. + +@subsubsection Translation markers + +Inside @file{trunk/Translations/Identity/Brands/}, translation files +combine the following translation markers: + +@table @samp +@item #000000 + +Specify which color to use when rendering brand images. + +@quotation +@strong{Note} As translation files inside +@file{trunk/Translations/Identity/Brands} are symbolic links that +point to template translation files, translation markers are defined +inside template translation files. +@end quotation +@end table + +@subsection Usage +@cindex How to render brands' translation files + +To render brands' translation files, use the following command: + +@verbatim +centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands +@end verbatim + +@subsection See also + +@menu +@comment --- Removed(* trunk Translations Identity Brands Tpl::) --- +* trunk Identity Brands:: +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Brands/Tpl.texi b/Manuals/Repository/Filesystem/Locales/Identity/Brands/Tpl.texi new file mode 100644 index 0000000..b53171e --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Brands/Tpl.texi @@ -0,0 +1,10 @@ +@subsection Goals + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Fonts.texi b/Manuals/Repository/Filesystem/Locales/Identity/Fonts.texi new file mode 100644 index 0000000..2699334 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Fonts.texi @@ -0,0 +1,62 @@ +@subsection Goals + +This section exists to organize fonts translation files. +@subsection Description + +Translation files, inside @file{trunk/Translations/Fonts}, have the +following structure: + +@verbatim +s!font-family:Denmark!font-family:DejaVu LGC Sans! +s!font-weight:normal!font-weight:bold! +s!font-style:normal!font-style:italic! +@end verbatim + +Inside @file{trunk/Translations/Fonts}, there is one translation file +for each font preview image you want to produce. This way, we create +one translation file for each font-family we use somewhere inside +CentOS visual identity. + +@quotation +@strong{Important} Do not create translation files for +font-families not used somewhere inside CentOS visual identity. The +identity of font entry (@pxref{trunk Identity Fonts}) is used as +reference when someone needs to know which font-families are allowed +to use inside CentOS visual identity. +@end quotation + +@subsubsection Translation Markers + +Inside @file{trunk/Translations/Identity/Fonts}, translation files +combine the following translation markers: + +@table @samp +@item font-family:Denmark +Specify which font family to use when rendering font preview images. +@item font-weight:normal +Specify which font weight to use when rendering font preview images. +@item font-style:normal +Specify which font style to use when rendering font preview images. +@end table + +@subsection Usage +@cindex How to render fonts' translation files + +Inside @file{trunk/Translations/Fonts} you use your favorite text +editor to create translation files. Inside +@file{trunk/Translations/Fonts} there is not translation template +directory (@file{Tpl/}), nor translation rendering using +@command{centos-art} script. For example, to create the +@file{dejavu_lgc_sans-boldoblique.sed} translation file using +@command{vim} editor, type the following command: + +@verbatim +vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed +@end verbatim + +@subsection See also + +@menu +* trunk Identity Fonts:: +@end menu + diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Models.texi b/Manuals/Repository/Filesystem/Locales/Identity/Models.texi new file mode 100644 index 0000000..b53171e --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Models.texi @@ -0,0 +1,10 @@ +@subsection Goals + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Release.texi b/Manuals/Repository/Filesystem/Locales/Identity/Release.texi new file mode 100644 index 0000000..b53171e --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Release.texi @@ -0,0 +1,10 @@ +@subsection Goals + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Themes.texi b/Manuals/Repository/Filesystem/Locales/Identity/Themes.texi new file mode 100644 index 0000000..b53171e --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Themes.texi @@ -0,0 +1,10 @@ +@subsection Goals + +@subsection Description + +@subsection Usage + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Themes/Backgrounds.texi b/Manuals/Repository/Filesystem/Locales/Identity/Themes/Backgrounds.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Themes/Backgrounds.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Themes/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/Locales/Identity/Themes/Distro/Anaconda/Progress.texi new file mode 100644 index 0000000..f2d99e2 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Themes/Distro/Anaconda/Progress.texi @@ -0,0 +1,94 @@ +@subsection Goals + +@itemize +@item Organize Anaconda progress translation templates. +@item Organize Anaconda progress translation files in several +languages and major releases of CentOS distribution. +@end itemize + +@subsection Description + +Use the following command to produce translation files based: + +@example +trunk/Translations/Identity/Themes/Distro/Anaconda/Progress +`-- Tpl + |-- en + | |-- 01-welcome.sed + | |-- 02-donate.sed + | `-- 03-yum.sed + `-- es + |-- 01-welcome.sed + |-- 02-donate.sed + `-- 03-yum.sed +@end example + +In order to produce the slide images in PNG format we need to have the +translation files first. So we use the following commands to create +translation files for CentOS 3, 4, and 5 major releases: + +@example +centos-art render --translation --filter='3,4,5' +@end example + +The above commands will produce the following translation structure: + +@example +trunk/Translations/Identity/Themes/Distro/Anaconda/Progress +|-- 3 +| |-- en +| | |-- 01-welcome.sed +| | |-- 02-donate.sed +| | `-- 03-yum.sed +| `-- es +| |-- 01-welcome.sed +| |-- 02-donate.sed +| `-- 03-yum.sed +|-- 4 +| |-- en +| | |-- 01-welcome.sed +| | |-- 02-donate.sed +| | `-- 03-yum.sed +| `-- es +| |-- 01-welcome.sed +| |-- 02-donate.sed +| `-- 03-yum.sed +|-- 5 +| |-- en +| | |-- 01-welcome.sed +| | |-- 02-donate.sed +| | `-- 03-yum.sed +| `-- es +| |-- 01-welcome.sed +| |-- 02-donate.sed +| `-- 03-yum.sed +`-- Tpl + |-- en + | |-- 01-welcome.sed + | |-- 02-donate.sed + | `-- 03-yum.sed + `-- es + |-- 01-welcome.sed + |-- 02-donate.sed + `-- 03-yum.sed +@end example + +At this point we have all the translation files we need to produce +Anaconda progress welcome, donate and yum slides images; in English +and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is, +a sum of 18 images around. + +Now, with translation files in place, let's move to +@file{trunk/Identity} structure and render them. + +@itemize +@item @xref{trunk Identity Themes Motifs Modern Distro Anaconda Progress}. +@end itemize + +@subsection Usage + +Translation rendering is described in @samp{trunk/Translations} +documentation entry (--- @strong{Removed}(pxref:trunk Translations) ---). + + +@subsection See also diff --git a/Manuals/Repository/Filesystem/Locales/Identity/Widgets.texi b/Manuals/Repository/Filesystem/Locales/Identity/Widgets.texi new file mode 100644 index 0000000..fda4863 --- /dev/null +++ b/Manuals/Repository/Filesystem/Locales/Identity/Widgets.texi @@ -0,0 +1,23 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@comment --- Removed(* trunk Translations Identity Widgets::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Manuals.texi b/Manuals/Repository/Filesystem/Manuals.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Manuals.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts.texi b/Manuals/Repository/Filesystem/Scripts.texi new file mode 100644 index 0000000..c9b371f --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts.texi @@ -0,0 +1,25 @@ +@subsection Goals + +The @file{trunk/Scripts} directory exists to: + +@itemize +@item Organize the ``trunk'' development line of automation scripts by +programming language. +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash.texi b/Manuals/Repository/Filesystem/Scripts/Bash.texi new file mode 100644 index 0000000..0b387e6 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash.texi @@ -0,0 +1,156 @@ +@subsection Goals + +The @file{trunk/Scripts/Bash} directory exists to organize the trunk +development line of @file{centos-art.sh} automation script. The +@file{centos-art.sh} script standardizes frequent tasks inside your +working copy of CentOS Artwork Repository. + +@subsection 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 (--- @strong{Removed}(pxref:trunk Scripts Bash Functions +Verify) ---), 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 +executing the @file{trunk/Scripts/Bash/initEnvironment.sh} script to +initialize global variables (e.g., @command{gettext} variables) and +global function scripts. Global function scripts are located inside +@file{trunk/Scripts/Bash/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 (--- @strong{Removed}(pxref:trunk Scripts Bash Functions) ---). + +As convenction, the @file{centos-art.sh} command-line arguments have +the following format: + +@verbatim +centos-art arg1 --arg2=val2 --arg3=val3 +@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,fig:trunk/Scripts/Bash:Initialization +@verbatim ++----------------------------------------------------------------------+ +| [centos@host]$ centos-art function --action='value' --option='value' | ++----------------------------------------------------------------------+ +| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh | ++---v-----------------------------------------v------------------------+ + | centos-art.sh | + +---v---------------------------------v---+ + . | initEnvironment.sh | . + . +---------------------------------+ . + . | cli $@ | . + . +---v-------------------------v---+ . + . . | cli_getFunctions | . . + . . +---v-----------------v---+ . . + . . . | function1 | . . . + . . . | function2 | . . . + . . . | function3 | . . . + . . . +-----------------+ . . . + . . ........................... . . + . ................................... . + ........................................... +@end verbatim +@caption{The 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. + +@float Figure,fig:trunk/Scripts/Bash/Functions:Initialization +@verbatim ++--------------------------------------+ +| cli_getFunctions | ++---v------------------------------v---+ +. | function1 | . +. +---v----------------------v---+ . +. . | function1_getActions | . . +. . +---v--------------v---+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . ........................ . . +. ................................ . +. +------------------------------+ . +. | function2 | . +. +---v----------------------v---+ . +. . | function2_getActions | . . +. . +---v--------------v---+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . ........................ . . +. ................................ . +. +------------------------------+ . +. | function3 | . +. +---v----------------------v---+ . +. . | function3_getActions | . . +. . +---v--------------v---+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . ........................ . . +. ................................ . +........................................ +@end verbatim +@caption{The actions initialization environment.} +@end float + +@subsection Usage + +The @file{centos-art.sh} script usage information is described inside +each specific function documentation (--- @strong{Removed}(pxref:trunk Scripts Bash +Functions) ---). + +@subsection See also + +@menu +* trunk Scripts:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@comment --- Removed(* trunk Scripts Bash Locale::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli.texi new file mode 100755 index 0000000..e69de29 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli.texi diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions.texi new file mode 100755 index 0000000..2a421ab --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions.texi @@ -0,0 +1,1222 @@ +@subsection Goals + +The @file{trunk/Scripts/Bash/Functions} directory exists to organize +@file{centos-art.sh} specific functionalities. + +@subsection Description + +The specific functions of @file{centos-art.sh} script are designed +with ``Software Toolbox'' philosophy (@pxref{Toolbox +introduction,,,coreutils.info}) in mind: each program ``should do one +thing well''. Inside @file{centos-art.sh} script, each specific +functionality is considered a program that should do one thing well. +Of course, if you find that they still don't do it, feel free to +improve them in order for them to do so. + +The specific functions of @file{centos-art.sh} script are organized +inside specific directories under @file{trunk/Scripts/Bash/Functions} +location. Each specific function directory should be named as the +function it represents, with the first letter in uppercase. For +example, if the function name is @code{render}, the specific function +directory for it would be @samp{trunk/Scripts/Bash/Functions/Render}. + +To better understand how specific functions of @file{centos-art.sh} +script are designed, lets create one function which only goal is to +output different kind of greetings to your screen. + +When we create specific functions for @file{centos-art.sh} script it +is crucial to know what these functions will do exactly and if there +is any function that already does what we intend to do. If there is no +one, it is good time to create them then. Otherwise, if +functionalities already available don't do what you exactly expect, +contact their authors and work together to improve them. + +@quotation +@strong{Tip} Join CentOS developers mailing list +@email{centos-art@@centos.org} to share your ideas. +@end quotation + +It is also worth to know what global functions and variables do we +have available inside @file{centos-art.sh} script, so advantage can be +taken from them. Global variables are defined inside global function +scripts. Global functions scripts are stored immediatly under +@file{trunk/Scripts/Bash/Functions} directory, in files begining with +@samp{cli} prefix. + +OK, let's begin with our functionality example. + +What function name do we use? Well, lets use @code{greet}. Note that +@samp{hello} word is not a verb; but an expression, a kind of +greeting, an interjection specifically. In contrast, @samp{greet} is a +verb and describes what we do when we say @samp{Hello!}, @samp{Hi!}, +and similar expressions. + +So far, we've gathered the following function information: + +@verbatim +Name: greet +Path: trunk/Scripts/Bash/Functions/Greet +File: trunk/Scripts/Bash/Functions/Greet/greet.sh +@end verbatim + +The @file{greet.sh} function script is the first file +@file{centos-art.sh} script loads when the @samp{greet} functionality +is called using commands like @samp{centos-art greet --hello='World'}. +The @file{greet.sh} function script contains the @code{greet} function +definition. + +Inside @file{centos-art.sh} script, as convenction, each function +script has one top commentary, followed by one blank line, and then +one function defintion below it only. + +Inside @file{centos-art.sh} script functions, top commentaries have +the following components: the functionality description, one-line for +copyright note with your personal information, the license under +which the function source code is released ---the @file{centos-art.sh} +script is released as GPL, so do all its functions---, the @code{$Id$} +keyword of Subversion is later expanded by @command{svn propset} +command. + +In our @code{greet} function example, top commentary for +@file{greet.sh} function script would look like the following: + +@verbatim +#!/bin/bash +# +# greet.sh -- This function outputs different kind of greetings to +# your screen. Use this function to understand how centos-art.sh +# script specific functionalities work. +# +# Copyright (C) YEAR YOURFULLNAME +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 +# USA. +# +# ---------------------------------------------------------------------- +# $Id$ +# ---------------------------------------------------------------------- +@end verbatim + +After top commentary, separated by one blank line, the @code{greet} +function definition would look like the following: + +@verbatim +function greet { + + # Define global variables. + + # Define command-line interface. + greet_getActions + +} +@end verbatim + +The first definition inside @code{greet} function, are global +variables that will be available along @code{greet} function execution +environment. This time we didn't use global variable definitions for +@code{greet} function execution environment, so we left that section +empty. + +Later, we call @code{greet_getActions} function to define the +command-line interface of @code{greet} functionality. The command-line +interface of @code{greet} functionality defines what and how actions +are performed, based on arguments combination passed to +@file{centos-art.sh} script. + +@verbatim +function greet_getActions { + + case "$ACTIONNAM" in + + --hello ) + greet_doHello + ;; + + --bye ) + greet_doBye + ;; + + * ) + cli_printMessage "`gettext "The option provided is not valid."`" + cli_printMessage "$(caller)" 'AsToKnowMoreLine' + + esac + +} +@end verbatim + +The @var{ACTIONNAM} global variable is defined in @file{cli.sh} +function script and contains the value passed before the equal sign +(i.e., @samp{=}) in the second command-line argument of +@file{centos-art.sh} script. For example, if the second command-line +argument is @option{--hello='World'}, the value of @var{ACTIONNAM} +variable would be @samp{--hello}. Using this configuration let us +deside which action to perform based on the action name passed to +@file{centos-art.sh} script as second argument. + +The @code{greet} function definition makes available two valid +greetings through @option{--hello} and @option{--bye} options. If no +one of them is provided as second command-line argument, the @samp{*} +case is evaluated instead. + +The @samp{*} case and its two lines further on should always be +present in @file{_getActions.sh} function scripts, no matter what +specific functionality you are creating. This convenction helps the +user to find out documentation about current functionality in use, +when no valid action is provided. + +The @code{greet_doHello} and @code{greet_doBye} function definitions +are the core of @code{greet} specific functionality. In such function +definitions we set what our @code{greet} function really does: to +output different kinds of greetings. + +@verbatim +function greet_doHello { + + cli_printMessage "`gettext "Hello"` $ACTIONVAL" + +} +@end verbatim + +The @code{greet_doHello} function definition is stored in +@file{greet_doHello.sh} function script. + +@verbatim +function greet_doBye { + + cli_printMessage "`gettext "Goodbye"` $ACTIONVAL" + +} +@end verbatim + +The @code{greet_doBye} function definition is stored in the +@file{greet_doBye.sh} function script. + +Both @file{greet_doHello.sh} and @file{greet_doBye.sh} function +scripts are stored inside @code{greet} function directory path (i.e. +@file{trunk/Scripts/Bash/Functions/Greet}). + +The @var{ACTIONVAL} global variable is defined in @file{cli.sh} +function script and contains the value passed after the equal sign +(i.e., @samp{=}) in the second command-line argument of +@file{centos-art.sh} script. For example, if the second command-line +argument is @option{--hello='World'}, the value of @var{ACTIONVAL} +variable would be @samp{World} without quotes. + +Let's see how @code{greet} specific functionality files are organzied +under @code{greet} function directory. To see file organization we use +the @command{tree} command: + +@verbatim +trunk/Scripts/Bash/Functions/Greet +|-- greet_doBye.sh +|-- greet_doHello.sh +|-- greet_getActions.sh +`-- greet.sh +@end verbatim + +To try the @code{greet} specific functionality we've just created, +pass the function name (i.e., @samp{greet}) as first argument to +@file{centos-art.sh} script, and any of the valid options as second +argument. Some examples are illustrated below: + +@verbatim +[centos@projects ~]$ centos-art greet --hello='World' +Hello World +[centos@projects ~]$ centos-art greet --bye='World' +Goodbye World +[centos@projects ~]$ +@end verbatim + +The word @samp{World} in the examples above can be anything. In fact, +change it to have a little fun. + +Now that we have a specific function that works as we expect, it is +time to document it. To document @code{greet} specific functionality, +we use its directory path and the @code{manual} functionality +(--- @strong{Removed}(pxref:trunk Scripts Bash Functions Manual) ---) of @file{centos-art.sh} +script, just as the following command illustrates: + +@verbatim +centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet +@end verbatim + +To have a well documented function helps user to understand how your +function really works, and how it should be used. When no valid +action is passed to a function, the @file{centos-art.sh} script uses +the function documentation entry as vehicle to communicate which the +valid functions are. When no documentation entry exists for a +function, the @file{centos-art.sh} script informs that no +documentation entry exists for such function and requests user to +create it right at that time. + +Now that we have documented our function, it is time to translate its +output messages to different languages. To translate specific +functionality output messages to different languages we use the +@code{locale} functionality (--- @strong{Removed}(pxref:trunk Scripts Bash Functions +Locale) ---) of @file{centos-art.sh} script, just as the following command +illustrates: + +@verbatim +centos-art locale --edit +@end verbatim + +@quotation +@strong{Warning} To translate output messages in different languages, +your system locale information ---as in @env{LANG} environment +variable--- must be set to that locale you want to produce translated +messages for. For example, if you want to produce translated messages +for Spanish language, your system locale information must be set to +@samp{es_ES.UTF-8}, or similar, first. +@end quotation + +Well, it seems that our example is rather complete by now. + +In @code{greet} function example we've described so far, we only use +@command{cli_printMessage} global function in action specific function +definitions in order to print messages, but more interesting things +can be achieved inside action specific function definitions. For +example, if you pass a directory path as action value in second +argument, you could retrive a list of files from therein, and process +them. If the list of files turns too long or you just want to control +which files to process, you could add the third argument in the form +@option{--filter='regex'} and reduce the amount of files to process +using a regular expression pattern. + +The @code{greet} function described in this section may serve you as +an introduction to understand how specific functionalities work inside +@file{centos-art.sh} script. With some of luck this introduction will +also serve you as motivation to create your own @file{centos-art.sh} +script specific functionalities. + +By the way, the @code{greet} functionality doesn't exist inside +@file{centos-art.sh} script yet. Would you like to create it? + +@subsection Usage + +@subsubsection Global variables + +The following global variables of @file{centos-art.sh} script, are +available for you to use inside specific functions: + +@defvar TEXTDOMAIN +Default domain used to retrieve translated messages. This value is set +in @file{initFunctions.sh} and shouldn't be changed. +@end defvar + +@defvar TEXTDOMAINDIR +Default directory used to retrieve translated messages. This value is +set in @file{initFunctions.sh} and shouldn't be changed. +@end defvar + +@defvar FUNCNAM +Define function name. + +Function names associate sets of actions. There is one set of actions +for each unique function name inside @file{centos-art.sh} script. + +Dunction names are passed as first argument in @file{centos-art.sh} +command-line interface. For example, in the command @samp{centos-art +render --entry=path/to/dir --filter=regex}, the @var{ACTION} passed to +@file{centos-art.sh} script is @option{render}. + +When first argument is not provided, the @file{centos-art.sh} script +immediatly ends its execution. +@end defvar + +@defvar FUNCDIR +@end defvar + +@defvar FUNCDIRNAME +@end defvar + +@defvar FUNCSCRIPT +@end defvar + +@defvar FUNCCONFIG +@end defvar + +@defvar ACTIONNAM +Define action name. + +Each action name identifies an specific action to perform, inside an +specific function. + +Action name names aare passed as second argument in +@file{centos-art.sh} command-line interface. For example, in the +command @samp{centos-art render --entry=path/to/dir --filter=regex}, +the @var{ACTIONNAM} passed to @file{centos-art.sh} script is +@option{--entry}. + +When second argument is not provided, the @file{centos-art.sh} script +immediatly ends its execution. +@end defvar + +@defvar ACTIONVAL +Define action value. + +Action values are associated to just one action name. Action values +contain the working copy entry over which its associated action will be +performed in. Working copy entries can be files or directories inside +the working copy. +@end defvar + +@defvar REGEX +Define regular expression used as pattern to build the list of files +to process. + +By default, @var{REGEX} variable is set to @code{.+} to match all +files. + +Functions that need to build a list of files to process use the option +@option{--filter} to redefine @var{REGEX} variable default value, and +so, control the amount of files to process. +@end defvar + +@defvar ARGUMENTS +Define optional arguments. + +Optional arguments, inside @file{centos-art.sh} script, are considered +as all command-line arguments passed to @file{centos-art.sh} script, +from third argument position on. For example, in the command +@samp{centos-art render --entry=path/to/dir --filter=regex} , the +optional arguments are from @samp{--filter=regex} argument on. + +Optional arguments are parsed using @command{getopt} command through +the following base construction: + +@verbatim +# Define short options we want to support. +local ARGSS="" + +# Define long options we want to support. +local ARGSL="filter:,to:" + +# Parse arguments using getopt(1) command parser. +cli_doParseArguments + +# Reset positional parameters using output from (getopt) argument +# parser. +eval set -- "$ARGUMENTS" + +# Define action to take for each option passed. +while true; do + case "$1" in + --filter ) + REGEX="$2" + shift 2 + ;; + --to ) + TARGET="$2" + shift 2 + ;; + * ) + break + esac +done +@end verbatim + +Optional arguments provide support to command options inside +@file{centos-art.sh} script. For instance, consider the Subversion +(@command{svn}) command, where there are many options (e.g., +@option{copy}, @option{delete}, @option{move}, etc), and inside each +option there are several modifiers (e.g., @samp{--revision}, +@samp{--message}, @samp{--username}, etc.) that can be combined one +another in their short or long variants. + +The @var{ARGUMENTS} variable is used to store arguments passed from +command-line for later use inside @file{centos-art.sh} script. Storing +arguments is specially useful when we want to run a command with some +specific options from them. Consider the following command: + +@verbatim +centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe' +@end verbatim + +In the above command, the @option{--message}, and @option{--username} +options are specific to @command{svn copy} command. In such cases, +options are not interpreted by @file{centos-art.sh} script itself. +Instead, the @file{centos-art.sh} script uses @command{getopt} to +retrive them and store them in the @var{ARGUMENTS} variable for later +use, as described in the following command: + +@verbatim +# Build subversion command to duplicate locations inside the +# workstation. +eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS +@end verbatim + +When @command{getopt} parses @var{ARGUMENTS}, we may use short options +(e.g., @option{-m}) or long options (e.g., @option{--message}). When +we use short options, arguments are separated by one space from the +option (e.g., @option{-m 'This is a commit message.'}). When we use +long options arguments are separated by an equal sign (@samp{=}) +(e.g., @option{--message='This is a commit message'}). + +In order for @command{getopt} to parse @var{ARGUMENTS} correctly, it +is required to provide the short and long definition of options that +will be passed or at least supported by the command performing the +final action the function script exists for. + +As convenction, inside @file{centos-art.sh} script, short option +definitions are set in the @var{ARGSS} variable; and long option +definitions are set in the @var{ARGSL} variable. + +When you define short and long options, it may be needed to define +which of these option arguments are required and which not. To define +an option argument as required, you need to set one colon @samp{:} +after the option definition (e.g., @option{-o m: -l message:}). On +the other hand, to define an option argument as not required, you need +to set two colons @samp{::} after the option definition (e.g., +@option{-o m:: -l message::}). +@end defvar + +@defvar 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. + +If @env{EDITOR} environment variable is not set, @file{centos-art.sh} +script uses @file{/usr/bin/vim} as default text editor. Otherwise, the +following values are recognized by @file{centos-art.sh} script: + +@itemize +@item @file{/usr/bin/vim} +@item @file{/usr/bin/emacs} +@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. +@end defvar + +@subsubsection Global functions + +Function scripts stored directly under +@file{trunk/Scripts/Bash/Functions/} directory are used to define +global functions. Global functions can be used inside action specific +functionalities and or even be reused inside themselves. This section +provides introductory information to global functions you can use +inside @file{centos-art.sh} script. + +@defun cli_checkActionArguments +Validate action value (@var{ACTIONVAL}) variable. + +The action value variable can take one of the following values: + +@enumerate +@item Path to one directory inside the local working copy, +@item Path to one file inside the local working copy, +@end enumerate + +If another value different from that specified above is passed to +action value variable, the @file{centos-art.sh} script prints an error +message and ends script execution. +@end defun + +@defun cli_checkFiles FILE [TYPE] +Verify file existence. + +@code{cli_checkFiles} receives a @var{FILE} absolute path and performs +file verification as specified in @var{TYPE}. When @var{TYPE} is not +specified, @code{cli_checkFiles} verifies @var{FILE} existence, no +matter what kind of file it be. If @var{TYPE} is specified, use one +of the following values: + +@table @option +@item d +@itemx directory +Ends script execution if @var{FILE} is not a directory. + +When you verify directories with cli_checkFiles, if directory doesn't +exist, @file{centos-art.sh} script asks you for confirmation in order +to create that directory. If you answer positively, +@file{centos-art.sh} script creates that directory and continues +script flows normally. Otherwise, if you answer negatively, +@file{centos-art.sh} ends script execution with an error and +documentation message. + +@item f +@item regular-file +Ends script execution if @var{FILE} is not a regular file. +@item h +@itemx symbolic-link +Ends script execution if @var{FILE} is not a symbolic link. +@item x +@itemx execution +Ends script execution if @var{FILE} is not executable. +@item fh +Ends script execution if @var{FILE} is neither a regular file nor a +symbolic link. +@item fd +Ends script execution if @var{FILE} is neither a regular file nor a +directory. +@item isInWorkingCopy +Ends script execution if @var{FILE} is not inside the working copy. +@end table + +As default behaviour, if @var{FILE} passes all verifications, +@file{centos-art.sh} script continues with its normal flow. +@end defun + +@defun cli_commitRepoChanges [LOCATION] + +Syncronize changes between repository and working copy. + +The @code{cli_commitRepoChanges} function brings changes from the +central repository down to the working copy---using @command{svn +update}---, checks the working copy changes---using @command{svn +status} command---, prints status report---using both @command{svn +update} and @command{svn status} commands output, and finally, commits +recent changes from the working copy up to the repository---using +@command{svn commit} command---. + +Previous to commit the working copy changes up to the central +repository, the @code{cli_commitRepoChanges} function asks you to +verify changes---using @command{svn diff} command---, and later, +another confirmation question is shown to be sure you really want to +commit changes up to central repository. + +If @var{LOCATION} argument is not specified, the value of +@var{ACTIONVAL} variable is used as reference instead. + +@float Figure, trunk/Scripts/Bash/Functions/cli_commitRepoChanges +@verbatim +---------------------------------------------------------------------- +--> Bringing changes from the repository into the working copy +--> Checking changes in the working copy +---------------------------------------------------------------------- +Added 0 file from the repository. +Deleted 0 file from the repository. +Updated 0 file from the repository. +Conflicted 0 file from the repository. +Merged 0 file from the repository. +Modified 4 files from the working copy. +Unversioned 0 file from the working copy. +Deleted 0 file from the working copy. +Added 0 file from the working copy. +---------------------------------------------------------------------- +@end verbatim +@caption{The @code{cli_commitRepoChanges} function output.} +@end float + +Call the @code{cli_commitRepoChanges} function before or/and after +calling functions that modify files or directories inside the working +copy as you may need to. +@end defun + +@defun cli_doParseArguments +Redefine arguments (@var{ARGUMENTS}) global variable using +@command{getopt} command output. For more information about how to use +@code{cli_doParseArguments} function, see @var{ARGUMENTS} variable +description above. +@end defun + +@defun cli_doParseArgumentsReDef $@@ +Initialize/reset arguments (@var{ARGUMENTS}) global variable using +positional parameters variable (@var{$@@}) as reference. + +When we work inside function definitions, positional parameters are +reset to the last function definition positional parameters. If you +need to redefine positional parameters from one specific function, you +need to call @code{cli_doParseArgumentsReDef} with the positional +parameters variable (@var{$@@}), set as first argument, to that +specific function you want to redefine positional parameters at. +@end defun + +@defun cli_getArguments + +Initialize function name (@var{FUNCNAM}), action name +(@var{ACTIONNAM}), and action value (@var{ACTIONVAL}) global +variables, using positional parameters passed in @var{$@@} variable. + +The @code{cli_getArguments} function is called from @code{cli.sh} +function script, using @code{cli} function positional parameters +(i.e., the positional parameters passed as arguments in the +command-line) as first function argument. + +Once command-line positional parameters are accesible to +@file{centos-art.sh} script execution evironment, +@code{cli_getArguments} uses regular expression to retrive +action variables from first and second argument. The first argument +defines the value used as function name (@var{FUNCNAM}), and the +second argument defines both values used as action name +(@var{ACTIONNAM}) and action value (@var{ACTIONVAL}), respectively. + +The first argument is a word in lower case. This word specifies the +name of the functionality you want to use (e.g., @samp{render} to +render images, @samp{manual} to work on documentation, and so on.) + +The second argument has a long option style (e.g., +@samp{--option=value}). The @samp{--option} represents the action name +(@var{ACTIONNAM}), and the characters inbetween the equal sign +(@samp{=}) and the first space character, are considered as the action +value (@var{ACTIONVAL}). In order to provide action values with space +characters inbetween you need to enclose action value with quotes like +in @samp{--option='This is long value with spaces inbetween'}. +Generally, action values are used to specify paths over which the +action name acts on. + +Once action related variables (i.e., @var{FUNCNAM}, @var{ACTIONNAM}, +and @var{ACTIONVAL}) are defined and validated, +@code{cli_getArguments} shifts the positional arguments to remove the +first two arguments passed (i.e., those used to retrive action related +variables) and redefine the arguments (@var{ARGUMENTS}) global +variable with the new positional parameters information. +@end defun + +@defun cli_getFunctions +Initialize funtionalities supported by @file{centos-art.sh} script. + +Functionalities supported by @file{centos-art.sh} script are organized +in functionality directories under +@file{trunk/Scripts/Bash/Functions/} directory. Each functionality +directory stores function scripts to the functionality such directory +was created for. Function scripts contain function definitions. +Function definitions contain several commands focused on achieving one +specific task only (i.e., the one such functionality was created for). + +In order for @file{centos-art.sh} script to recognize a functionality, +such functionality needs to be stored under +@file{trunk/Scripts/Bash/Functions/} in a directory written +capitalized (i.e., the whole name is written in lowercase except the +first character which is in uppercase). The directory where one +specific functionality is stored is known as the @samp{functionality +directory}. + +Inside each functionality directory, the functionalty itself is +implemented through function scripts. Function scripts are organized +in files independently one another and written in @samp{camelCase} +format with the function name as prefix. Separation between prefix +and description is done using underscore (@samp{_}) character. + +In order for @file{centos-art.sh} script to load functionalities +correctly, function definition inside function scripts should be set +using the @samp{function} reserved word, just as in the following +example: + +@verbatim +function prefix_doSomething { + + # Do something here... + +} +@end verbatim + +The above function definition is just a convenction we use, in order +to make identification of function names easier read and automate by +@file{centos-art.sh} script initialization commands, once +@file{centos-art.sh} script determines which functionality directory +to use. Specifically, in order to initialize and export functions, +@file{centos-art.sh} script executes all function scripts inside the +functionality directory, and later @command{grep} on them using a +regular expression pattern, where the @samp{function} reserved word is +used as reference to retrive the function names and export them to +@file{centos-art.sh} script execution environment, and so, make +function definitions ---from function scripts inside the functionality +directory--- available for further calls. + +If the functionality specified in the command-line first argument +doesn't have a functionality directory, @file{centos-art.sh} script +considers the functionality provided in the command-line as invalid +functionality and immediatly stops script execution with an error +message. + +In order to keep visual consistency among function scripts, please +consider using the following function script design model as template +for your own function scripts: + +@verbatim +#!/bin/bash +# +# prefix_doSomething.sh -- This function illustrates function scripts +# design model you can use to create your own function scripts inside +# centos-art.sh script. +# +# Copyright (C) YEAR YOURFULLNAME +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 +# USA. +# +# ---------------------------------------------------------------------- +# $Id$ +# ---------------------------------------------------------------------- + +function prefix_doSomething { + + # Do something here... + +} +@end verbatim +@end defun + +@defun cli_getCountryCodes [FILTER] +Output country codes supported by @file{centos-art.sh} script. + +The @code{cli_getCountryCodes} function outputs a list with country +codes as defined in ISO3166 standard. When @var{FILTER} is provided, +@code{cli_getCountryCodes} outputs country codes that match +@var{FILTER} regular expression pattern. +@end defun + +@defun cli_getCountryName [FILTER] +Outputs country name supported by @file{centos-art.sh} script. + +The @code{cli_getCountryName} function reads one language locale code +in the format LL_CC and outputs the name of its related country as in +ISO3166. If filter is specified, @code{cli_getCountryName} returns the +country name that matches the locale code specified in @var{FILTER}, +exactly. +@end defun + +@defun cli_getCurrentLocale +Output current locale used by @file{centos-art.sh} script. + +The @code{cli_getCurrentLocale} function uses @env{LANG} environment +variable to build a locale pattern that is later applied to +@code{cli_getLocales} function output in order to return the current +locale that @file{centos-art.sh} script works with. + +The current locale information, returned by +@code{cli_getCurrentLocale}, is output from more specific to less +specific. For example, if @samp{en_GB} locale exists in +@code{cli_getLocales} function output, the @samp{en_GB} locale would +take precedence before @samp{en} locale. + +Locale precedence selection is quite important in order to define the +locale type we use for message translations. For example, if +@samp{en_GB} is used, we are also saying that the common language +specification for English language (i.e., @samp{en}) is no longer +used. Instead, we are using English non-common country-specific +language specifications like @samp{en_AU}, @samp{en_BW}, @samp{en_GB}, +@samp{en_US}, etc., for message translations. + +Use @code{cli_getCurrentLocale} function to know what current locale +information to use inside @file{centos-art.sh} script. +@end defun + +@defun cli_getFilesList [LOCATION] +Output list of files to process. + +The @code{cli_getFilesList} function uses @var{LOCATION} variable as +source location to build a list of files just as specified by regular +expression (@var{REGEX}) global variable. Essentially, what the +@code{cli_getFilesList} function does is using @command{find} command +to look for files in the location (@var{LOCATION}) just as posix-egrep +regular expression (@var{REGEX}) specifies. + +If @var{LOCATION} is not specified when @code{cli_getFilesList} +function is called, the action value (@var{ACTIONVAL}) global variable +is used as location value instead. + +By default, if the regular expression (@var{REGEX}) global variable is +not redefined after its first definition in the @code{cli} function, +all files that match default regular expression value (i.e., +@samp{.+}) will be added to the list of files to process. Otherwise, +if you redefine the regular expression global variable after its first +definition in the @code{cli} function and before calling +@code{cli_getFilesList} function, the last value you specifed is used +instead. + +When you need to customize the regular expression (@var{REGEX}) global +variable value inside a function, do not redefine the global variable +(at least you be absolutly convinced you need to). Instead, set the +regular expression global variable as @samp{local} to the function you +need a customized regular expression value for. If we don't redefine +the regular expression global variable as local to the function, or +use another name for the regular expression variable (which is not +very convenient in order to keep the amount of names to remember low), +you may experiment undesired concantenation issues that make your +regular expression to be something different from that you expect them +to be, specially if the function where you are doing the variable +redefinition is called several times during the same script execution. + +As result, the @code{cli_getFilesList} re-defines the value of +@var{FILES} variable with the list of files the @command{find} command +returned. As example, consider the following construction: + +@verbatim +function prefix_doSomething { + + # Initialize the list of files to process. + local FILES='' + + # Initialize location. + local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default + + # Re-define regular expression to match scalable vector graphic + # files only. Note how we use the global value of REGEX to build a + # new local REGEX value here. + local REGEX="${REGEX}.*\.(svgz|svg)" + + # Redefine list of files to process. + cli_getFilesList $LOCATION + + # Process list of files. + for FILE in $FILES;do + cli_printMessages "$FILE" 'AsResponseLine' + # Do something else here on... + done + +} +@end verbatim + +@end defun + +@defun cli_getLangCodes [FILTER] +Outputs language codes supported by @file{centos-art.sh} script. + +@code{cli_getLangCodes} function outputs a list of language codes as +defined in ISO639 standard. When @var{FILTER} is provided, +@code{cli_getLangCodes} outputs language codes that match @var{FILTER} +regular expression pattern. +@end defun + +@defun cli_getLangName [FILTER] +Outputs language names supported by @file{centos-art.sh} script. + +@code{cli_getLangName} function reads one language locale code in the +format LL_CC and outputs the language related name as in ISO639. If +filter is specified, @code{cli_getLangName} returns the language name +that matches the locale code specified in @var{FILTER}, exactly. +@end defun + +@defun cli_getLocales +Output locale codes supported by @file{centos-art.sh} script. + +Occasionally, you use @code{cli_getLocales} function to add locale +information in non-common country-specific language (@samp{LL_CC}) +format for those languages (e.g., @samp{bn_IN}, @samp{pt_BR}, etc.) +which locale differences cannot be solved using common language +specifications (@samp{LL}) into one unique common locale specification +(e.g., @samp{bn}, @samp{pt}, etc.). +@end defun + +@defun cli_getRepoName NAME TYPE +Sanitate file names. + +Inside @file{centos-art.sh} script, specific functionalities rely both +in @code{cli_getRepoName} and repository file system organization to +achieve their goals. Consider @code{cli_getRepoName} function as +central place to manage file name convenctions for other functions +inside @file{centos-art.sh} script. + +@quotation +@strong{Important} @code{cli_getRepoName} function doesn't verify file +or directory existence, for that purpose use @code{cli_checkFiles} +function instead. +@end quotation + +The @var{NAME} variable contains the file name or directory name you +want to sanitate. + +The @var{TYPE} variable specifies what type of sanitation you want to +perform on @var{NAME}. The @var{TYPE} can be one of the following +values: + +@table @option +@item d +@itemx directory +Sanitate directory @var{NAME}s. +@item f +@item regular-file +Sanitate regular file @var{NAME}s. +@end table + +Use @code{cli_getRepoName} function to sanitate file names and +directory names before their utilization. + +Use @code{cli_getRepoName} when you need to change file name +convenctions inside @file{centos-art.sh} script. + +When we change file name convenctions inside @code{cli_getRepoName} +what we are really changing is the way functions interpret repository +file system organization. Notice that when we change a file name +(e.g., a function name), it is necessary to update all files where +such file name is placed on. This may require a massive substitution +inside the repository, each time we change name convenctions in the +repository (--- @strong{Removed}(pxref:trunk Scripts Bash Functions Path) ---, for more +information). +@end defun + +@defun cli_getRepoStatus [LOCATION] +Request repository status. + +This function requests the status of a @var{LOCATION} inside the +working copy using the @command{svn status} command and returns the +first character in the output line, just as described in @command{svn +help status}. If @var{LOCATION} is not a regular file or a directory, +inside the working copy, the @file{centos-art.sh} script prints a +message and ends its execution. + +Use this function to perform verifications based a repository +@var{LOCATION} status. +@end defun + +@defun cli_getTemporalFile @var{NAME} +Output absolute path to temporal file @var{NAME}. + +The @code{cli_getTemporalFile} function uses @file{/tmp} directory as +source location to store temporal files, the @file{centos-art.sh} +script name, and a random identification string to let you run more +than one @file{centos-art.sh} script simultaneously on the same user +session. For example, due the following temporal file defintion: + +@verbatim +cli_getTemporalFile $FILE +@end verbatim + +If @var{FILE} name is @file{instance.svg} and the unique random string +is @samp{f16f7b51-ac12-4b7f-9e66-72df847f12de}, the final temporal +file, built from previous temporal file definition, would be: + +@verbatim +/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg +@end verbatim + +When you use the @code{cli_getTemporalFile} function to create +temporal files, be sure to remove temporal files created once you've +ended up with them. For example, consider the following construction: + +@verbatim +for FILE in $FILES;do + + # Initialize temporal instance of file. + INSTANCE=$(cli_getTemporalFile $FILE) + + # Do something ... + + # Remove temporal instance of file. + if [[ -f $INSTANCE ]];then + rm $INSTANCE + fi + +done +@end verbatim + +Use the @code{cli_getTemporalFile} function whenever you need to +create temporal files inside @file{centos-art.sh} script. +@end defun + +@defun cli_getThemeName +Output theme name. + +In order for @code{cli_getThemeName} function to extract theme name +correctly, the @var{ACTIONVAL} variable must contain a directory path +under @file{trunk/Identity/Themes/Motifs/} directory structure. +Otherwise, @code{cli_getThemeName} returns an empty string. +@end defun + +@defun cli_printMessage MESSAGE [FORMAT] +Define standard output message definition supported by +@file{centos-art.sh} script. + +When @var{FORMAT} is not specified, @code{cli_printMessage} outputs +information just as it was passed in @var{MESSAGE} variable. +Otherwise, @var{FORMAT} can take one of the following values: + +@table @option +@item AsHeadingLine +To print heading messages. +@verbatim +---------------------------------------------------------------------- +$MESSAGE +---------------------------------------------------------------------- +@end verbatim + +@item AsWarningLine +To print warning messages. +@verbatim +---------------------------------------------------------------------- +WARNING: $MESSAGE +---------------------------------------------------------------------- +@end verbatim + +@item AsNoteLine +To print note messages. +@verbatim +---------------------------------------------------------------------- +NOTE: $MESSAGE +---------------------------------------------------------------------- +@end verbatim + +@item AsUpdatingLine +To print @samp{Updating} messages on two-columns format. +@verbatim +Updating $MESSAGE +@end verbatim + +@item AsRemovingLine +To print @samp{Removing} messages on two-columns format. +@verbatim +Removing $MESSAGE +@end verbatim + +@item AsCheckingLine +To print @samp{Checking} messages on two-columns format. +@verbatim +Checking $MESSAGE +@end verbatim + +@item AsCreatingLine +To print @samp{Creating} messages on two-columns format. +@verbatim +Creating $MESSAGE +@end verbatim + +@item AsSavedAsLine +To print @samp{Saved as} messages on two-columns format. +@verbatim +Saved as $MESSAGE +@end verbatim + +@item AsLinkToLine +To print @samp{Linked to} messages on two-columns format. +@verbatim +Linked to $MESSAGE +@end verbatim + +@item AsMovedToLine +To print @samp{Moved to} messages on two-columns format. +@verbatim +Moved to $MESSAGE +@end verbatim + +@item AsTranslationLine +To print @samp{Translation} messages on two-columns format. +@verbatim +Translation $MESSAGE +@end verbatim + +@item AsConfigurationLine +To print @samp{Configuration} messages on two-columns format. +@verbatim +Configuration $MESSAGE +@end verbatim + +@item AsResponseLine +To print response messages on one-column format. +@verbatim +--> $MESSAGE +@end verbatim + +@item AsRequestLine +To print request messages on one-column format. Request messages +output messages with one colon (@samp{:}) and without trailing newline +(@samp{\n}) at message end. +@verbatim +$MESSAGE: +@end verbatim + +@item AsYesOrNoRequestLine +To print @samp{yes or no} request messages on one-column format. If +something different from @samp{y} is answered (when using +@code{en_US.UTF-8} locale), script execution ends immediatly. + +@verbatim +$MESSAGE [y/N]: +@end verbatim + +When we use @file{centos-art.sh} script in a locale different from +@code{en_US.UTF-8}, confirmation answer may be different from +@samp{y}. For example, if you use @code{es_ES.UTF-8} locale, the +confirmation question would look like: + +@verbatim +$MESSAGE [s/N]: +@end verbatim + +and the confirmation answer would be @samp{s}, as it is on Spanish +@samp{sí} word. + +Definition of which confirmation word to use is set on translation +messages for your specific locale information. --- @strong{Removed}(xref:trunk Scripts +Bash Functions Locale) ---, for more information about locale-specific +translation messages. + +@item AsToKnowMoreLine +To standardize @samp{to know more, run the following command:} +messages. When the @option{AsToKnowMoreLine} option is used, the +@var{MESSAGE} value should be set to @code{"$(caller)"}. @code{caller} +is a Bash builtin that returns the context of the current subroutine +call. @option{AsToKnowMoreLine} option uses @code{caller} builtin +output to build documentation entries dynamically. + +@verbatim +---------------------------------------------------------------------- +To know more, run the following command: +centos-art manual --read='path/to/dir' +---------------------------------------------------------------------- +@end verbatim + +Use @option{AsToKnowMoreLine} option after errors and for intentional +script termination. + +@item AsRegularLine +To standardize regular messages on one-column format. + +When @var{MESSAGE} contains a colon inside (e.g., @samp{description: +message}), the @code{cli_printMessage} function outputs @var{MESSAGE} +on two-columns format. +@end table + +Use @code{cli_printMessage} function whenever you need to output +information from @file{centos-art.sh} script. + +@quotation +@strong{Tip} To improve two-columns format, change the following file: +@verbatim +trunk/Scripts/Bash/Styles/output_forTwoColumns.awk +@end verbatim +@end quotation +@end defun + +@subsubsection Specific functions + +The following specific functions of @file{centos-art.sh} script, are +available for you to use: + +@menu +@comment --- Removed(* trunk Scripts Bash Functions Html::) --- +@comment --- Removed(* trunk Scripts Bash Functions Locale::) --- +@comment --- Removed(* trunk Scripts Bash Functions Manual::) --- +@comment --- Removed(* trunk Scripts Bash Functions Path::) --- +@comment --- Removed(* trunk Scripts Bash Functions Render::) --- +@comment --- Removed(* trunk Scripts Bash Functions Render Config::) --- +@comment --- Removed(* trunk Scripts Bash Functions Shell::) --- +@comment --- Removed(* trunk Scripts Bash Functions Svg::) --- +@comment --- Removed(* trunk Scripts Bash Functions Verify::) --- +@end menu + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Locale::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Help.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Help.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Help.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Html.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Html.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Html.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Locale.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Locale.texi new file mode 100644 index 0000000..bf264c9 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Locale.texi @@ -0,0 +1,85 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +This command looks for @samp{.sh} files inside Bash directory and +extracts translatable strings from files, using @command{xgettext} +command, in order to create a portable object template +(@file{centos-art.sh.pot}) file for them. + +With the @file{centos-art.sh.pot} file up to date, the +@command{centos-art} command removes the temporal list of files sotred +inside @file{/tmp} directory and checks the current language of your +user's session to create a portable object file for it, in the +location @file{$CLI_LANG/$CLI_LANG.po}. + +The @var{CLI_LANG} variable discribes the locale language used to +output messages inside @command{centos-art} command. The locale +language used inside @command{centos-art} command is taken from the +@env{LANG} environment variable. The @var{CLI_LANG} variable has the +@samp{LL_CC} format, where @samp{LL} is a language code from the +ISO-639 standard, and @samp{CC} a country code from the ISO-3166 +standard. + +The @env{LANG} environment variable is set when you do log in to your +system. If you are using a graphical session, change language to your +native language and do login. That would set and exoprt the @env{LANG} +environment variable to the correct value. On the other side, if you +are using a text session edit your @file{~/.bash_profile} file to set +and export the @env{LANG} environment variable to your native locale +as defines the @command{locale -a} command output; do logout, and do +login again. + +At this point, the @env{LANG} environment variable has the appropriate +value you need, in order to translate @command{centos-art.sh} messages +to your native language (the one set in @env{LANG} environment +variable). + +With the @file{$CLI_LANG/$CLI_LANG.po} file up to date, the +@command{centos-art} opens it for you to update translation strings. +The @command{centos-art} command uses the value of @var{EDITOR} +environment variable to determine your favorite text editor. If no +value is defined on @var{EDITOR}, the @file{/usr/bin/vim} text editor +is used as default. + +When you finishd PO file edition and quit text editor, the +@command{centos-art} command creates the related machine object in the +location @file{$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo}. + +At this point, all translations you made in the PO file should be +available to your language when runing @command{centos-art.sh} script. + +In order to make the @command{centos-art.sh} internationalization, the +@command{centos-art.sh} script was modified as described in the +@command{gettext} info documentation (@command{info gettext}). You +can find such modifications in the following files: + +@itemize +@item @file{trunk/Scripts/Bash/initFunctions.sh} +@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh} +@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh} +@end itemize + +@itemize +@item ... +@end itemize + +@subsection Usage + +@table @samp +@item centos-art locale --edit +Use this command to translate command-line interface output messages +in the current system locale you are using (as specified in @env{LANG} +environment variable). +@item centos-art locale --list +Use this command to see the command-line interface locale report. +@end table + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Manual.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Manual.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Manual.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Path.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Path.texi new file mode 100644 index 0000000..a7c6c55 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Path.texi @@ -0,0 +1,327 @@ +@subsection Goals + +This section exists to organize files related to @code{path} +functiontionality. The @code{path} functionality standardizes +movement, syncronization, branching, tagging, and general file +maintainance inside the repository. + +@subsection Description + +@emph{''CentOS like trees, has roots, trunk, branches, leaves and +flowers. Day by day they work together in freedom, ruled by the laws +of nature and open standards, to show the beauty of its existence.''} + +@subsubsection 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: @file{trunk/}, @file{branches/}, +and @file{tags/}. + +The @file{trunk/} directory (@pxref{trunk}) organizes the main +development line of CentOS corporate visual identity. Inside +@file{trunk/} directory structure, the CentOS corporate visual +identity concepts are implemented using directories. There is one +directory level for each relevant concept inside the repository. The +@file{trunk/} directory structure is mainly used to perform +development tasks related to CentOS corporate visual identity. + +The @file{branches/} directory (@pxref{branches}) oranizes parallel +development lines to @file{trunk/} directory. The @file{branches/} +directory is used to set points in time where develpment lines are +devided one from another taking separte and idependent lives that +share a common past from the point they were devided on. The +@file{branches/} directory is mainly used to perform quality assurance +tasks related to CentOS corporate visual identity. + +The @file{tags/} directory (@pxref{tags}) organizes parallel frozen +lines to @file{branches/} directory. The parallel frozen lines are +immutable, nothing change inside them once they has been created. The +@file{tags/} directory is mainly used to publish final releases of +CentOS corporate visual identity. + +The CentOS Artwork Repository layout is firmly grounded on a +Subversion base. Subversion (@url{http://subversion.tigris.org}) is a +version control system, which allows you to keep old versions of files +and directories (usually source code), keep a log of who, when, and +why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a +single copy of the master sources. This copy is called the source +``repository''; it contains all the information to permit extracting +previous versions of those files at any time. + +@subsubsection 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 +(@samp{01-welcome.png}, @samp{splash.png}, @samp{anaconda_header.png}, +etc.) and directory names are all written capitalized (e.g., +@samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower}, +etc.). + +Repository name convenctions are implemented inside the +@code{cli_getRepoName} function of @file{centos-art.sh} script. With +@code{cli_getRepoName} function we reduce the amount of commands and +convenctions to remember, concentrating them in just one single place +to look for fixes and improvements. + +@subsubsection 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., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we +organize information that cannot be produced automatically (i.e., +background images, concepts, color information, screenshots, etc.). + +Later, when theme trunk development line is considered ``ready'' for +implementation (e.g., all required backgrounds have been designed), +we create a branch for it (e.g., +@file{branches/Identity/Themes/Motifs/TreeFlower/1/}). Once the +branch has been created, we forget that branch and continue working +the trunk development line while others (e.g., an artwork quality +assurance team) test the new branch for tunning it up. + +Once the branch has been tunned up, and considered ``ready'' for +release, it is freezed under @file{tags/} directory (e.g., +@file{tags/Identity/Themes/Motifs/TreeFower/1.0/}) for packagers, +webmasters, promoters, and anyone who needs images from that CentOS +theme the tag was created for. + +Both branches and tags, inside CentOS Artwork Repository, use +numerical values to identify themselves under the same location. +Branches start at one (i.e., @samp{1}) and increment one unit for each +branch created from the same trunk development line. Tags start at +zero (i.e., @samp{0}) and increment one unit for each tag created from +the same branch development line. + +@quotation +@strong{Convenction} Do not freeze trunk development lines using tags +directly. If you think you need to freeze a trunk development line, +create a branch for it and then freeze that branch instead. +@end quotation + +The trunk development line may introduce problems we cannot see +immediatly. Certainly, the high changable nature of trunk development +line complicates finding and fixing such problems. On the other hand, +the branched development lines provide a more predictable area where +only fixes/corrections to current content are commited up to +repository. + +If others find and fix bugs inside the branched development line, we +could merge such changes/experiences back to trunk development line +(not visversa) in order for future branches, created from trunk, to +benefit. + +Time intervals used to create branches and tags may vary, just as +different needs may arrive. For example, consider the release schema +of CentOS distribution: one major release every 2 years, security +updates every 6 months, support for 7 years long. Each time a CentOS +distribution is released, specially if it is a major release, there is +a theme need in order to cover CentOS distribution artwork +requirements. At this point, is where CentOS Artwork Repository comes +up to scene. + +Before releasing a new major release of CentOS distribution we create +a branch for one of several theme development lines available inside +the CentOS Artwork Repository, perform quality assurance on it, and +later, freeze that branch using tags. Once a the theme branch has been +frozen (under @file{tags/} directory), CentOS Packagers (the persons +whom build CentOS distribution) can use that frozen branch as source +location to fulfill CentOS distribution artwork needs. The same +applies to CentOS Webmasters (the persons whom build CentOS websites), +and any other visual manifestation required by the project. + +@subsubsection Parallel directories + +Inside CentOS Artwork Repository, parallel directories are simple +directory entries built from a common parent directory and placed in a +location different to that, the common parent directory is placed on. +Parallel directories are useful to create branches, tags, +translations, documentation, pre-rendering configuration script, and +similar directory structures. + +Parallel directories take their structure from one unique parent +directory. Inside CentOS Artwork Repository, this unique parent +directory is under @file{trunk/Identity} location. The +@file{trunk/Identity} location must be considered the reference for +whatever information you plan to create inside the repository. + +In some circumstances, parallel directories may be created removing +uncommon information from their paths. Uncommon path information +refers to those directory levels in the path which are not common for +other parallel directories. For example, when rendering +@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory +structure, the @file{centos-art.sh} script removes the +@file{Motifs/TreeFlower/} directory levels from path, in order to +build the parallel directory used to retrived translations, and +pre-rendering configuration scripts required by @code{render} +functionality. + +Another example of parallel directory is the documentation structure +created by @code{manual} functionality. This time, +@file{centos-art.sh} script uses parallel directory information with +uncommon directory levels to build the documentation entry required by +Texinfo documentation system, inside the repository. + +Othertimes, parallel directories may add uncommon information to their +paths. This is the case we use to create branches and tags. When we +create branches and tags, a numerical identifier is added to parallel +directory structure path. The place where the numerical identifier is +set on is relevant to corporate visual identity structure and should +be carefully considered where it will be. + +When one parent directory changes, all their related parallel +directories need to be changed too. This is required in order for +parallel directories to retain their relation with the parent +directory structure. In the other hand, parallel directories should +never be modified under no reason but to satisfy the relation to their +parent directory structure. Liberal change of parallel directories +may suppresses the conceptual idea they were initially created for; +and certainly, things may stop working the way they should do. + +@subsubsection Syncronizing path information + +Parallel directories are very useful to keep repository organized but +introduce some complications. For instance, consider what would +happen to functionalities like @code{manual} (@samp{trunk Scripts Bash +Functions Manual}) that rely on parent directory structures to create +documentation entries (using parallel directory structures) if one of +those parent directory structures suddenly changes after the +documentation entry has been already created for it? + +In such cases, functionalities like @code{manual} may confuse +themselves if path information is not updated to reflect the relation +with its parent directory. Such functionalities work with parent +directory structure as reference; if a parent directory changes, the +functionalities dont't even note it because they work with the last +parent directory structure available in the repository, no matter what +it is. + +In the specific case of documentation (the @code{manual} +functionality), the problem mentioned above provokes that older parent +directories, already documented, remain inside documentation directory +structures as long as you get your hands into the documentation +directory structure (@file{trunk/Manuals}) and change what must be +changed to match the new parent directory structure. + +There is no immediate way for @code{manual}, and similar +functionalities that use parent directories as reference, to know when +and how directory movements take place inside the repository. Such +information is available only when the file movement itself takes +place inside the repository. So, is there, at the moment of moving +files, when we need to syncronize parallel directories with their +unique parent directory structure. + +@quotation +@strong{Warning} There is not support for URL reference inside +@file{centos-art.sh} script. The @file{centos-art.sh} script is +designed to work with local files inside the working copy only. +@end quotation + +As CentOS Artwork Repository is built over a version control system, +file movements inside the repository are considered repository +changes. In order for these repository changes to be versioned, we +need to, firstly, add changes into the version control system, commit +them, and later, perform movement actions using version control system +commands. This configuration makes possible for everyone to know about +changes details inside the repository; and if needed, revert or update +them back to a previous revision. + +Finally, once all path information has been corrected, it is time to +take care of information inside the files. For instance, considere +what would happen if you make a reference to a documentation node, and +later the documentation node you refere to is deleted. That would make +Texinfo to produce error messages at export time. So, the +@file{centos-art.sh} script needs to know when such changes happen, in +a way they could be noted and handled without producing errors. + +@subsubsection What is the right place to store it? + +Occasionly, you may find that new corporate visual identity components +need to be added to the repository. If that is your case, the first +question you need to ask yourself, before start to create directories +blindly all over, is: What is the right place to store it? + +The CentOS Community different free support vains (see: +@url{http://wiki.centos.org/GettingHelp}) are the best place to find +answers to your question, but going there with hands empty is not good +idea. It may give the impression you don't really care about. Instead, +consider the following suggestions to find your own comprehension and +so, make your propositions based on it. + +When we are looking for the correct place to store new files, to bear +in mind the corporate visual identity structure used inside the CentOS +Artwork Repository (@pxref{trunk Identity}) would be probaly the best +advice we could offer, the rest is just matter of choosing appropriate +names. To illustrate this desition process let's consider the +@file{trunk/Identity/Themes/Motifs/TreeFlower} directory as example. +It is the trunk development line of @emph{TreeFlower} artistic motif. +Artistic motifs are considered part of themes, which in turn are +considered part of CentOS corporate visual identity. + +When building parent directory structures, you may find that reaching +an acceptable location may take some time, and as it uses to happen +most of time; once you've find it, that may be not a definite +solution. There are many concepts that you need to play with, in +order to find a result that match the conceptual idea you try to +implement in the new directory location. To know which these concepts +are, split the location in words and read its documentation entry from +less specific to more specific. + +For example, the @file{trunk/Identity/Themes/Motifs/TreeFlower} +location evolved through several months of contant work and there is +no certain it won't change in the future, even it fixes quite well the +concept we are trying to implement. The concepts used in +@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} location are +described in the following commands, respectively: + +@verbatim +centos-art manual --read=turnk/ +centos-art manual --read=turnk/Identity/ +centos-art manual --read=turnk/Identity/Themes/ +centos-art manual --read=turnk/Identity/Themes/Motifs/ +centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ +@end verbatim + +Other location concepts can be found similary as we did above, just +change the location we used above by the one you are trying to know +concepts for. + +@subsection Usage + +@table @command +@item centos-art path --copy='SRC' --to='DST' + +Copy @option{SRC} to @option{DST} and schedule @option{DST} for +addition (with history). In this command, @file{SRC} and @file{DST} +are both working copy (WC) entries. + +@item centos-art path --delete='SRC' + +Delete @option{DST}. In order for this command to work the file or +directory you intend to delete should be under version control first. +In this command, @file{SRC} is a working copy (WC) entry. + +@end table + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render.texi new file mode 100644 index 0000000..7dfe2c5 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render.texi @@ -0,0 +1,736 @@ +The @code{render} functionality exists to produce both identity and +translation files on different levels of information (i.e., different +languages, release numbers, architectures, etc.). + +The @code{render} functionality relies on ``renderable directory +structures'' to produce files. Renderable directory structures can be +either ``identity directory structures'' or ``translation directory +structures'' with special directories inside. + +@subsection Renderable identity directory structures + +Renderable identity directory structures are the starting point of +identity rendition. Whenever we want to render a component of CentOS +corporate visual identity, we need to point @file{centos-art.sh} to a +renderable identity directory structure. If such renderable identity +directory structure doesn't exist, then it is good time to create it. + +Inside the working copy, one renderable identity directory structures +represents one visual manifestation of CentOS corporate visual +identity, or said differently, each visual manifestation of CentOS +corporate visual identity should have one renderable identity +directory structure. + +Inside renderable identity directory structures, @file{centos-art.sh} +can render both image-based and text-based files. Specification of +whether a renderable identity directory structure produces image-based +or text-based content is a configuration action that takes place in +the pre-rendition configuration script of that renderable identity +directory structure. + +Inside renderable identity directory structures, content production is +organized in different configurations. A content production +configuration is a unique combination of the components that make an +identity directory structure renderable. One content production +configuration does one thing only (e.g., to produce untranslated +images), but it can be extended (e.g., adding translation files) to +achieve different needs (e.g., to produce translated images). + +@subsubsection Design template without translation + +The design template without translation configuration is based on a +renderable identity directory structure with an empty translation +directory structure. In this configuration, one design template +produces one untranslated file. Both design templates and final +untranslated files share the same file name, but they differ one +another in file-type and file-extension. + +For example, to produce images without translations (there is no much +use in producing text-based files without translations), consider the +following configuration: + +@table @strong +@item One renderable identity directory structure: + +In this example we used @file{Identity/Path/To/Dir} as the identity +component we want to produce untranslated images for. Identity +components can be either under @file{trunk/} or @file{branches/} +directory structure. + +The identity component (i.e., @file{Identity/Path/To/Dir}, in this +case) is also the bond component we use to connect the identity +directory structures with their respective auxiliar directories (i.e., +translation directory structres and pre-rendition configuration +structures). The bond component is the path convenction that +@file{centos-art.sh} uses to know where to look for related +translations, configuration scripts and whatever auxiliar thing a +renderable directory structure may need to have. + +@verbatim + | The bond component + |----------------->| +trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. +|-- Tpl <-- Design template directory. +| `-- file.svg <-- Design template file. +`-- Img <-- Directory used to store final files. + `-- file.png <-- Final image-based file produced from + design template file. +@end verbatim + +Inside design template directory, design template files are based on +@acronym{SVG,Scalable Vector Graphics} and use the extension +@code{.svg}. Design template files can be organized using several +directory levels to create a simple but extensible configuration, +specially if translated images are not required. + +In order for @acronym{SVG,Scalable Vector Graphics} files to be +considered ``design template'' files, they should be placed under the +design template directory and to have set a @code{CENTOSARTWORK} +object id inside. + +The @code{CENTOSARTWORK} word itself is a convenction name we use to +define which object/design area, inside a design template, the +@file{centos-art.sh} script will use to export as +@acronym{PNG,Portable Network Graphic} image at rendition time. +Whithout such object id specification, the @file{centos-art.sh} script +cannot know what object/design area you (as designer) want to export +as @acronym{PNG,Portable Network Graphic} image file. + +@quotation +@strong{Note} At rendition time, the content of @file{Img/} directory +structure is produced by @file{centos-art.sh} automatically. +@end quotation + +When a renderable identity directory structure is configured to +produce image-based content, @file{centos-art.sh} produces +@acronym{PNG,Portable Network Graphics} files with the @code{.png} +extension. Once the base image format has been produced, it is +possible for @file{centos-art.sh} to use it in order to automatically +create other image formats that may be needed (--- @strong{Removed}(pxref:trunk Scripts +Bash Functions Render Config) ---). + +Inside the working copy, you can find an example of ``design template +without translation'' configuration at @file{trunk/Identity/Models/}. + +@xref{trunk Identity}, for more information. + +@item One translation directory structure: + +In order for an identity entry to be considered an identity renderable +directory structure, it should have a translation entry. The content +of the translation entry is relevant to determine how to process the +identity renderable directory entry. + +If the translation entry is empty (i.e., there is no file inside it), +@file{centos-art.sh} interprets the identity renderable directory +structure as a ``design templates without translation'' configuration. + +@verbatim + | The bond component + |----------------->| +trunk/Translations/Identity/Path/To/Dir +`-- (empty) +@end verbatim + +If the translation entry is not empty, @file{centos-art.sh} can +interpret the identity renderable directory structure as one of the +following configurations: ``design template with translation +(one-to-one)'' or ``design template with translation (optimized)''. +Which one of these configurations is used depends on the value +assigned to the matching list (@var{MATCHINGLIST}) variable in the +pre-rendition configuration script of the renderable identity +directory structure we are producing images for. + +If the matching list variable is empty (as it is by default), then +``design template with translation (one-to-one)'' configuration is +used. In this configuration it is required that both design templates +and translation files have the same file names. This way, @emph{one} +translation files is applied to @emph{one} design template, to produce +@emph{one} translated image. + +If the matching list variable is not empty (because you redefine it in +the pre-rendition configuration script), then ``design template with +translation (optimized)'' configuration is used instead. In this +configuration, design templates and translation files don't need to +have the same names since such name relationship between them is +specified in the matching list properly. + +--- @strong{Removed}(xref:trunk Translations) ---, for more information. + +@item One pre-rendition configuration script: + +In order to make an identity directory structure renderable, a +pre-rendition configuration script should exist for it. The +pre-rendition configuration script specifies what type of rendition +does @file{centos-art.sh} will perform over the identity directory +structure and how does it do that. + +@verbatim + | The bond component + |----------------->| +trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir +`-- render.conf.sh +@end verbatim + +In this configuration the pre-rendition configuration script +(@file{render.conf.sh}) would look like the following: + +@verbatim +function render_loadConfig { + + # Define rendition actions. + ACTIONS[0]='BASE:renderImage' + +} +@end verbatim + +Since translation directory structure is empty, @file{centos-art.sh} +assumes a ``design template without translation'' configuration to +produce untranslated images. + +To produce untranslated images, @file{centos-art.sh} takes one design +template and creates one temporal instance from it. Later, +@file{centos-art.sh} uses the temporal design template instance as +source file to export the final untranslated image. The action of +exporting images from @acronym{SVG,Scalable Vector Graphics} to +@acronym{PNG,Portable Network Graphics} is possible thanks to +Inkscape's command-line interface and the @code{CENTOSARTWORK} object +id we previously set inside design templates. + +@verbatim +centos-art.sh render --identity=trunk/Identity/Path/To/Dir +------------------------------------------------- +0 | Execute centos-art.sh on renderable identity directory structure. +--v---------------------------------------------- +trunk/Identity/Path/To/Dir/Tpl/file.svg +------------------------------------------------- +1 | Create instance from design template. +--v---------------------------------------------- +/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg +------------------------------------------------- +2 | Render untranslated image from design template instance. +--v---------------------------------------------- +trunk/Identity/NewDir/Img/file.png +------------------------------------------------- +3 | Remove design template instance. +@end verbatim + +Finally, when the untranslated image has been created, the temporal +design template instance is removed. At this point, +@file{centos-art.sh} takes the next design template and repeats the +whole production flow once again (design template by design template), +until all design templates be processed. + +--- @strong{Removed}(xref:trunk Scripts Bash Functions Render Config) ---, for more +information. +@end table + +@subsubsection Design template with translation (one-to-one) + +Producing untranslated images is fine in many cases, but not always. +Sometimes it is required to produce images in different languages and +that is something that untrasnlated image production cannot achieve. +However, if we fill its empty translation entry with translation files +(one for each design template) we extend the production flow from +untranslated image production to translated image production. + +In order for @file{centos-art.sh} to produce images correctly, each +design template should have one translation file and each translation +file should have one design template. Otherwise, if there is a +missing design template or a missing translation file, +@file{centos-art.sh} will not produce the final image related to the +missing component. + +In order for @file{centos-art.sh} to know which is the relation +between translation files and design templates the translation +directory structure is taken as reference. For example, the +@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation +file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design +template, but it doesn't match +@file{trunk/Identity/Path/To/Dir/File.svg} or +@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or +@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design +templates. + +The pre-rendition configuration script used to produce untranslated +images is the same we use to produce translated images. There is no +need to modify it. So, as we are using the same pre-rendition +configuration script, we can say that translated image production is +somehow an extended/improved version of untranslated image production. + +@quotation +@strong{Note} If we use no translation file in the translation entry +(i.e., an empty directory), @file{centos-art.sh} assumes the +untranslated image production. If we fill the translation entry with +translation files, @file{centos-art.sh} assumes the translated image +production. +@end quotation + +To produce final images, @file{centos-art.sh} applies one translation +file to one design template and produce a translated design template +instance. Later, @file{centos-art.sh} uses the translated template +instance to produce the translated image. Finally, when the translated +image has been produced, @file{centos-art.sh} removes the translated +design template instance. This production flow is repeated for each +translation file available in the translatio entry. + +@verbatim +centos-art.sh render --identity=trunk/Identity/Path/To/Dir +------------------------------------------------- +0 | Execute centos-art.sh on directory structure. +--v---------------------------------------------- +trunk/Translations/Identity/Path/To/Dir/file.sed +------------------------------------------------- +1 | Apply translation to design template. +--v---------------------------------------------- +trunk/Identity/Path/To/Dir/Tpl/file.svg +------------------------------------------------- +2 | Create design template instance. +--v---------------------------------------------- +/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg +------------------------------------------------- +3 | Render PNG image from template instance. +--v---------------------------------------------- +trunk/Identity/NewDir/Img/file.png +------------------------------------------------- +4 | Remove design template instance. +@end verbatim + +@subsubsection Design template with translation (optimized) + +Producing translated images satisfies almost all our production images +needs, but there is still a pitfall in them. In order to produce +translated images as in the ``one-to-one'' configuration describes +previously, it is required that one translation file has one design +template. That's useful in many cases, but what would happen if we +need to apply many different translation files to the same design +template? Should we have to duplicate the same design template file +for each translation file, in order to satisfy the ``one-to-one'' +relation? What if we need to assign translation files to design +templates arbitrarily? + +Certenly, that's something the ``one-to-one'' configuration cannot +handle. So, that's why we had to ``optimize'' it. The optimized +configuration consists on using a matching list (@var{MATCHINGLIST}) +variable that specifies the relationship between translation files and +design templates in an arbitrary way. Using such matching list between +translation files and design templates let us use as many assignment +combinations as translation files and design templates we are working +with. + +The @var{MATCHINGLIST} variable is set in the pre-rendition +configuration script of the component we want to produce images for. +By default, the @var{MATCHINGLIST} variable is empty which means no +matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a +value different to empty value then, @file{centos-art.sh} interprets +the matching list in order to know how translation files are applied +to design templates. + +For example, consider the following configuration: + +@table @strong +@item One entry under @file{trunk/Identity/}: + +In this configuration we want to produce three images using a +paragraph-based style, controlled by @file{paragraph.svg} design +template; and one image using a list-based style, controlled by +@file{list.svg} design template. + +@verbatim +trunk/Identity/Path/To/Dir +|-- Tpl +| |-- paragraph.svg +| `-- list.svg +`-- Img + |-- 01-welcome.png + |-- 02-donate.png + |-- 03-docs.png + `-- 04-support.png +@end verbatim + +@item One entry under @file{trunk/Translations/}: + +In order to produce translated images we need to have one translation +file for each translated image we want to produce. Notice how +translation names do match final image file names, but how translation +names do not match design template names. When we use matching list +there is no need for translation files to match the names of design +templates, such name relation is set inside the matching list itself. + +@verbatim +trunk/Translations/Identity/Path/To/Dir +|-- 01-welcome.sed +|-- 02-donate.sed +|-- 03-docs.sed +`-- 04-support.sed +@end verbatim + +@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}: + +In order to produce different translated images using specific design +templates, we need to specify the relation between translation files +and design templates in a way that @file{centos-art.sh} could know +exactly what translation file to apply to what design template. This +relation between translation files and design templates is set using +the matching list @var{MATCHINGLIST} variable inside the pre-rendition +configuration script of the component we want to produce images for. + +@verbatim +trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir +`-- render.conf.sh +@end verbatim + +In this configuration the pre-rendition configuration script +(@file{render.conf.sh}) would look like the following: + +@verbatim +function render_loadConfig { + + # Define rendition actions. + ACTIONS[0]='BASE:renderImage' + + # Define matching list. + MATCHINGLIST="\ + paragraph.svg:\ + 01-welcome.sed\ + 02-donate.sed\ + 04-support.sed + list.svg:\ + 03-docs.sed + " + +} +@end verbatim + +As result, @file{centos-art.sh} will produce @file{01-welcome.png}, +@file{02-donate.png} and @file{04-support.png} using the +paragraph-based design template, but @file{03-docs.png} using the +list-based design template. +@end table + +@subsubsection Design template with translation (optimized+flexibility) + +In the production models we've seen so far, there are design templates +to produce untranslated images and translation files which combiend +with design templates produce translated images. That may seems like +all our needs are covered, doesn't it? Well, it @emph{almost} does. + +Generally, we use design templates to define how final images will +look like. Generally, each renderable directory structure has one +@file{Tpl/} directory where we organize design templates for that +identity component. So, we can say that there is only one unique +design template definition for each identity component; or what is the +same, said differently, identity components can be produced in one way +only, the way its own design template directory specifies. This is +not enough for theme production. It is a limitation, indeed. + +Initially, to create one theme, we created one renderable directory +structure for each theme component. When we found ourselves with many +themes, and components inside them, it was obvious that the same +design model was duplicated inside each theme. As design models were +independently one another, if we changed one theme's design model, +that change was useless to other themes. So, in order to reuse design +model changes, we unified design models into one common directory +structure. + +With design models unified in a common structure, another problem rose +up. As design models also had the visual style of theme components, +there was no difference between themes, so there was no apparent need +to have an independent theme directory structure for each different +theme. So, it was also needed to separate visual styles from design +models. + +At this point there are two independent worklines: one directory +structure to store design models (the final image characteristics +[i.e., dimensions, translation markers, etc.]) and one directory +structure to store visual styles (the final image visual style [i.e., +the image look and feel]). So, it is possible to handle both +different design models and different visual styles independtly one +another and later create combinations among them using +@file{centos-art.sh}. + +For example, consider the following configuration: + +@table @strong +@item One entry under @file{trunk/Identity/Themes/Models/}: + +The design model entry exists to organize design model files (similar +to design templates). Both design models and design templates are very +similar; they both should have the @code{CENTOSARTWORK} export id +present to identify the exportation area, translation marks, etc. +However, design models do use dynamic backgrounds inclusion while +design templates don't. + +@verbatim + THEMEMODEL | | The bond component + |<----| |--------------------->| +trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ +|-- paragraph.svg +`-- list.svg +@end verbatim + +Inisde design models, dynamic backgrounds are required in order for +different artistic motifs to reuse common design models. Firstly, in +order to create dynamic backgrounds inside design models, we import a +bitmap to cover design model's background and later, update design +model's path information to replace fixed values to dynamic values. + +@item One entry under @file{trunk/Identity/Themes/Motifs/}: + +The artistic motif entry defines the visual style we want to produce +images for, only. Final images (i.e., those built from combining both +design models and artistic motif backrounds) are not stored here, but +under branches directory structure. In the artistic motif entry, we +only define those images that cannot be produced automatically by +@file{centos-art.sh} (e.g., Backgrounds, Color information, +Screenshots, etc.). + +@verbatim + Artistic motif name | | Artistic motif backgrounds + |<-------| |-------->| +trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ +|-- Img +| |-- Png +| | |-- 510x300.png +| | `-- 510x300-final.png +| `-- Jpg +| |-- 510x300.jpg +| `-- 510x300-final.jpg +|-- Tpl +| `-- 510x300.svg +`-- Xcf + `-- 510x300.xcf +@end verbatim + +@item One entry under @file{trunk/Translations/}: + +The translation entry specifies, by means of translation files, the +language-specific information we want to produce image for. When we +create the translation entry we don't use the name of neither design +model nor artistic motif, just the design model component we want to +produce images for. + +@verbatim + | The bond component + |--------------------->| +trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ +`-- 5 + |-- en + | |-- 01-welcome.sed + | |-- 02-donate.sed + | `-- 03-docs.sed + `-- es + |-- 01-welcome.sed + |-- 02-donate.sed + `-- 03-docs.sed +@end verbatim + +@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}: + +There is one pre-rendition configuration script for each theme +component. So, each time a theme component is rendered, its +pre-rendition configuration script is evaluated to teach +@file{centos-art.sh} how to render the component. + +@verbatim +trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/ +`-- render.conf.sh +@end verbatim + +In this configuration the pre-rendition configuration script +(@file{render.conf.sh}) would look like the following: + +@verbatim +function render_loadConfig { + + # Define rendition actions. + ACTIONS[0]='BASE:renderImage' + + # Define matching list. + MATCHINGLIST="\ + paragraph.svg:\ + 01-welcome.sed\ + 02-donate.sed + list.svg:\ + 03-docs.sed + " + + # Deifne theme model. + THEMEMODEL='Default' + +} +@end verbatim +@end table + +The production flow of ``optimize+flexibility'' configuration@dots{} +@subsection Renderable translation directory structures + +Translation directory structures are auxiliar structures of renderable +identity directory structures. There is one translation directory +structure for each renderable identity directory structure. Inside +translation directory structures we organize translation files used by +renderable identity directory structures that produce translated +images. Renderable identity directory structures that produce +untranslated images don't use translation files, but they do use a +translation directory structure, an empty translation directory +structure, to be precise. + +In order to aliviate production of translation file, we made +translation directory structures renderable adding a template +(@file{Tpl/}) directory structure to handle common content inside +translation files. This way, we work on translation templates and +later use @file{centos-art.sh} to produce specific translation files +(based on translation templates) for different information (e.g., +languages, release numbers, architectures, etc.). + +If for some reason, translation files get far from translation +templates and translation templates become incovenient to produce such +translation files then, care should be taken to avoid replacing the +content of translation files with the content of translation templates +when @file{centos-art.sh} is executed to produce translation files +from translation templates. + +Inside renderable translation directory structures, +@file{centos-art.sh} can produce text-based files only. + +@subsection Copying renderable directory structures + +A renderable layout is formed by design models, design images, +pre-rendition configuration scripts and translations files. This way, +when we say to duplicate rendition stuff we are saying to duplicate +these four directory structures (i.e., design models, design images, +pre-rendition configuration scripts, and related translations files). + +When we duplicate directories, inside `trunk/Identity' directory +structure, we need to be aware of renderable layout described above +and the source location used to perform the duplication action. The +source location is relevant to centos-art.sh script in order to +determine the required auxiliar information inside directory +structures that need to be copied too (otherwise we may end up with +orphan directory structures unable to be rendered, due the absence of +required information). + +In order for a renderable directory structure to be valid, the new +directory structure copied should match the following conditions: + +@enumerate +@item To have a unique directory structure under +@file{trunk/Identity}, organized by any one of the above +organizational designs above. + +@item To have a unique directory structure under +@file{trunk/Translations} to store translation files. + +@item To have a unique directory structure under +@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition +configuration script. +@end enumerate + +As convenction, the @code{render_doCopy} function uses +@file{trunk/Identity} directory structure as source location. Once +the @file{trunk/Identity} directory structure has been specified and +verified, the related path information is built from it and copied +automatically to the new location specified by @var{FLAG_TO} variable. + +Design templates + No translation: + +Command: +- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir + +Sources: +- trunk/Identity/Path/To/Dir +- trunk/Translations/Identity/Path/To/Dir +- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir + +Targets: +- trunk/Identity/NewPath/To/Dir +- trunk/Translations/Identity/NewPath/To/Dir +- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir + +Renderable layout 2: + +Command: +- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \ + --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir + +Sources: +- trunk/Identity/Themes/Motifs/TreeFlower +- trunk/Translations/Identity/Themes +- trunk/Translations/Identity/Themes/Motifs/TreeFlower +- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes +- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower + +Targets: +- trunk/Identity/Themes/Motifs/NewPath/To/Dir +- trunk/Translations/Identity/Themes +- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir +- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes +- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir + +Notice that design models are not included in source or target +locations. This is intentional. In ``Renderable layout 2'', design +models live by their own, they just exist, they are there, available +for any artistic motif to use. By default `Themes/Models/Default' +design model directory structure is used, but other design models +directory structures (under Themes/Models/) can be created and used +changing the value of THEMEMODEL variable inside the pre-rendition +configuration script of the artistic motif source location you want to +produce. + +Notice how translations and pre-rendition configuration scripts may +both be equal in source and target. This is because such structures +are common to all artistic motifs (the default values to use when no +specific values are provided). + +- The common directory structures are not copied or deleted. We cannot + copy a directory structure to itself. + +- The common directory structures represent the default value to use + when no specific translations and/or pre-rendition configuration + script are provided inside source location. + +- The specific directory structures, if present, are both copiable and + removable. This is, when you perform a copy or delete action from + source, that source specific auxiliar directories are transfered in + the copy action to a new location (that specified by FLAG_TO + variable). + +- When translations and/or pre-rendition configuration scripts are + found inside the source directory structure, the centos-art.sh + script loads common auxiliar directories first and later specific + auxiliar directories. This way, identity rendition of source + locations can be customized idividually over the base of common + default values. + +- The specific auxiliar directories are optional. + +- The common auxiliar directories should be present always. This is, + in order to provide the information required by render functionality + (i.e., to make it functional in the more basic level of its + existence). + +Notice how the duplication process is done from `trunk/Identity' on, +not the oposite. If you try to duplicate a translation structure (or +similar auxiliar directory structures like pre-rendition configuration +scripts), the `trunk/Identity' for that translation is not created. +This limitation is impossed by the fact that many `trunk/Identity' +directory structures may reuse/share the same translation directory +structure. We cannot delete one translation (or similar) directory +structures while a related `trunk/Identity/' directory structure is +still in need of it. + +The `render_doCopy' functionality does duplicate directory structures +directly involved in rendition process only. Once such directories +have been duplicated, the functionality stops thereat. + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@comment --- Removed(* trunk Scripts Bash Functions Render Config::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render/Config.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render/Config.texi new file mode 100644 index 0000000..3b3322b --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Render/Config.texi @@ -0,0 +1,192 @@ +@subsection Goals + +The @file{trunk/Scripts/Bash/Config} directory exists to oraganize +pre-rendering configuration scripts. + +@subsection Description + +Pre-rendering configuration scripts let you customize the way +@command{centos-art.sh} script renders identity and translation +repository entries. Pre-rendering configuration scripts are +@file{render.conf.sh} files with @command{render_loadConfig} function +definition inside. + +There is one @file{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. + +@subsubsection The @file{render.conf.sh} identity model + +Inside CentOS Artwork Repository, we consider identity entries to all +directories under @file{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: + +@verbatim +#!/bin/bash + +function render_loadConfig { + + # Define rendering actions. + ACTIONS[0]='BASE:renderImage' + ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm' + +} +@end verbatim + +Inside identity pre-rendering configuration scripts, text-based +pre-rendering configuration scripts look like the following: + +@verbatim +#!/bin/bash + +function render_loadConfig { + + # Define rendering actions. + ACTIONS[0]='BASE:renderText' + ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing' + +} +@end verbatim + +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. + +@subsubsection The @file{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. + +@subsubsection The @file{render.conf.sh} rendering actions + +Inside both image-based and text-based identity pre-rendering +configuration scripts, we use the @samp{ACTIONS} array variable to +define the way @command{centos-art.sh} script performs identity +rendering. Identity rendering is organized by one @samp{BASE} action, +and optional @samp{POST} and @samp{LAST} rendering actions. + +The @samp{BASE} action specifies what kind of rendering does the +@command{centos-art.sh} script will perform with the files related to +the pre-rendering configuration script. The @samp{BASE} action is +required. Possible values to @samp{BASE} action are either +@samp{renderImage} or @samp{renderText} only. + +To specify the @samp{BASE} action you need to set the @samp{BASE:} +string followed by one of the possible values. For example, if you +want to render images, consider the following definition of +@samp{BASE} action: + +@verbatim +ACTIONS[0]='BASE:renderImage' +@end verbatim + +Only one @samp{BASE} action must be specified. If more than one +@samp{BASE} action is specified, the last one is used. If no +@samp{BASE} action is specified at all, an error is triggered and the +@command{centos-art.sh} script ends its execution. + +The @samp{POST} action specifies which action to apply for +each file rendered (at the rendering time). This action is optional. +You can set many different @samp{POST} actions to apply many different +actions over the same already rendered file. Possible values to +@samp{POST} action are @samp{renderFormats}, @samp{renderSyslinux}, +@samp{renderGrub}, etc. + +To specify the @samp{POST} action, you need to use set the +@samp{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 @samp{xpm}, @samp{jpg}, and +@samp{tif} images, based on already rendered @samp{png} image, and +also organize the produced files in directories named as their own +extensions: + +@verbatim +ACTIONS[0]='BASE:renderImage' +ACTIONS[1]='POST:renderFormats: xpm jpg tif' +ACTIONS[2]='POST:groupByFormat: png xpm jpg tif' +@end verbatim + +In the previous example, file organization takes place at the moment +of rendering, just after producing the @samp{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 @samp{POST:groupByFormat} action line: + +@verbatim +ACTIONS[0]='BASE:renderImage' +ACTIONS[1]='POST:renderFormats: xpm jpg tif' +@end verbatim + +The @samp{LAST} action specifies which actions to apply once the last +file in the list of files to process has been rendered. The +@samp{LAST} action is optional. Possible values for @samp{LAST} +actions may be @samp{groupByFormat}, @samp{renderGdmTgz}, etc. + +@quotation +@strong{Note} --- @strong{Removed}(xref:trunk Scripts Bash Functions Render) ---, to know more +about possible values for @samp{BASE}, @samp{POST} and @samp{LAST} +action definitions. +@end quotation + +To specify the @samp{LAST} action, you need to set the @samp{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: + +@verbatim +ACTIONS[0]='BASE:renderImage' +ACTIONS[1]='POST:renderFormats: xpm jpg tif' +ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' +@end verbatim + +@subsection Usage + +Use the following commands to administer both identity and translation +pre-rendering configuration scripts: + +@table @samp + +@item centos-art config --create='path/to/dir/' + +Use this command to create @samp{path/to/dir} related pre-rendering +configuration script. + +@item centos-art config --edit='path/to/dir/' + +Use this command to edit @samp{path/to/dir} related pre-rendering +configuration script. + +@item centos-art config --read='path/to/dir/' + +Use this command to read @samp{path/to/dir} related pre-rendering +configuration script. + +@item centos-art config --remove='path/to/dir/' + +Use this command to remove @samp{path/to/dir} related pre-rendering +configuration script. + +@end table + +In the commands above, @samp{path/to/dir} refers to one renderable +directory path under @file{trunk/Identity} or +@file{trunk/Translations} structures only. + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@comment --- Removed(* trunk Scripts Bash Functions Render::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Shell.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Shell.texi new file mode 100644 index 0000000..a5016fe --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Shell.texi @@ -0,0 +1,184 @@ +@subsection Goals + +This section exists to organize files related to @code{shell} +functionality of @file{centos-art.sh} script. + +@subsection Description + +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: + +@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:1 +@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 +@caption{The functions script base comment structure} +@end float + +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: + +@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:2 +@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 +@caption{The function script comment example} +@end float + +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. +59 Temple Place - Suite 330, Boston, MA 02111-1307, 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, +CentOS Developers mailing list}. +@end quotation + +@subsection Usage + +@table @command +@item centos-art sh --update-copyright='path/to/dir' +@itemx centos-art sh --update-copyright='path/to/dir' --filter='regex' +Use these commands to update copyright information in @samp{.sh} files +under @samp{path/to/dir} directory. +@end table + +When you provide @option{--filter='regex'} argument, the list of files +to process is reduced as specified in @samp{regex} regular expression. +Inside @file{centos-art.sh} script, the @samp{regex} regular +expression is used in combination with @command{find} command to look +for files matching the regular expression path pattern. + +@quotation +@strong{Warning} In order for @samp{regex} regular expression to match +a file, the @samp{regex} regular expresion must match the whole file +path not just the file name. +@end quotation + +For example, if you want to match all @file{render.conf.sh} files +inside @file{path/to/dir}, use the @code{.+/render.conf} regular +expression. Later, @file{centos-art.sh} script uses this value inside +@code{^$REGEX\.sh$} expression in order to build the final regular +expression (i.e., @code{^.+/render.conf\.sh$}) that is evaluated +against available file paths inside the list of files to process. + +Exceptionally, when you provide @option{--filter='regex'} in the way +that @samp{regex}, appended to @samp{path/to/dir/} (i.e. +@samp{path/to/dir/regex}), matches a regular file; the +@file{centos-art.sh} script uses the file matching as only file in the +list of files to process. + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Svg.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Svg.texi new file mode 100644 index 0000000..341745d --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Svg.texi @@ -0,0 +1,192 @@ +@subsection Goals + +This section exists to organize files related to @code{svg} +functionality of @file{centos-art.sh} script. + +@subsection Description + +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. + +@cindex Metadata maintainance +@subsubsection Metadata maintainance + +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. + +The @file{centos-art.sh} script modifies the following metadata: + +@table @samp +@item Title +Name by which this document is formally known. If no value is set +here, @file{centos-art.sh} script uses the file name as title. + +@item Date +Date associated with the creation of this document (YYYY-MM-DD). If no +value is set here, @file{centos-art.sh} script uses the current date +information as in @command{date +%Y-%m-%d}. + +@item Creator +Name of entity primarily responsible for making the content of this +document. If no value is set here, @file{centos-art.sh} script uses +the string @samp{The CentOS Project}. + +@item Rights +Name of entity with rights to the intellectual Property of this +document. If no value is set here, @file{centos-art.sh} script uses +the string @samp{The CentOS Project}. + +@item Publisher +Name of entity responsible for making this document available. If no +value is set here, @file{centos-art.sh} script uses the string +@samp{The CentOS Project}. + +@item Identifier +Unique URI to reference this document. If no value is set here, +@file{centos-art.sh} script uses the current file path to build the +related url that points to current file location inside repository +central server. + +@item Source +Unique URI to reference the source of this document. If no value is +set here, @file{centos-art.sh} script uses current file path to build +the related url that points to current file location inside repository +central server. + +@item Relation +Unique URI to a related document. If no value is set here, +@file{centos-art.sh} script uses current file path to build the +related url that points to current file location inside repository +central server. + +@item Language +Two-letter language tag with optional subtags for the language of this +document. (e.g. @samp{en-GB}). If no value is set here, +@file{centos-art.sh} script uses the current locale information as in +@code{cli_getCurrentLocale} function. + +@item Keywords +The topic of this document as comma-separated key words, prhases, or +classifications. If no value is set here, @file{centos-art.sh} script +uses file path to build + +@item Coverage +Extent or scope of this document. If no value is set here, +@file{centos-art.sh} script uses the string @samp{The CentOS Project}. + +@item Description +Description about the document. If no value is set here, +@file{centos-art.sh} script uses uses empty value as default. + +@item Contributors +People that contributes in the creation/maintainance of the document. +If no value is set here, @file{centos-art.sh} script uses uses empty +value as default. +@end table + +The @samp{License} metadatum is not set as a choise, by now. It is +fixed @url{http://creativecommons.org/licenses/by-sa/3.0/, Creative +Common Attribution Share-Alike 3.0 License}. This is done in order to +grant license consistency among all SVG files we manage inside CentOS +Artwork Repository. + +@cindex Unused definitions +@subsubsection Unused definitions + +Many of the no-longer-used gradients, patterns, and markers (more +precisely, those which you edited manually) remain in the +corresponding palettes and can be reused for new objects. However if +you want to optimize your document, use the @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. + +@subsection Usage + +@table @command +@item centos-art svg --update-metadata='path/to/dir' +@item centos-art svg --update-metadata='path/to/dir' --filter='regex' +Use these commands to update metadata information to @samp{.svg} files +under @samp{path/to/dir} directory. + +@item centos-art svg --vacuum-defs='path/to/dir' +@item centos-art svg --vacuum-defs='path/to/dir' --filter='regex' +Use these commands to remove unused definitions inside @samp{.svg} +files under @samp{path/to/dir} directory. +@end table + +When you provide @option{--filter='regex'} argument, the list of files +to process is reduced as specified in @samp{regex} regular expression. +Inside @file{centos-art.sh} script, the @samp{regex} regular +expression is used in combination with @command{find} command to look +for files matching the regular expression path pattern. + +@quotation +@strong{Warning} In order for @samp{regex} regular expression to match +a file, the @samp{regex} regular expresion must match the whole file +path not just the file name. +@end quotation + +For example, if you want to match all @file{summary.svg} files inside +@file{path/to/dir}, use the @code{.+/summary} regular expression. +Later, @file{centos-art.sh} script uses this value inside +@code{^$REGEX\.svg$} expression in order to build the final regular +expression (i.e., @code{^.+/summary\.svg$}) that is evaluated against +available file paths inside the list of files to process. + +Exceptionally, when you provide @option{--filter='regex'} in the way +that @samp{regex}, appended to @samp{path/to/dir/} (i.e. +@samp{path/to/dir/regex}), matches a regular file; the +@file{centos-art.sh} script uses the file matching as only file in the +list of files to process. + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Verify.texi b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Verify.texi new file mode 100644 index 0000000..ff98b51 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Bash/Cli/Functions/Verify.texi @@ -0,0 +1,245 @@ +@subsection Goals + +This section exists to organize files related to @file{centos-art.sh} +script @samp{verify} functionality. The @samp{verify} +functionality of @file{centos-art.sh} script helps you to verify the +workstation configuration you are planning to use as host for your +working copy of CentOS Artwork Repository. + +@subsection 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{verify} 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{verify} 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. + +@subsubsection 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. + +@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} +@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{verify} 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. + +@subsubsection 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. + +@subsubsection 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{verify} functionality of @file{centos-art.sh} script doesn't +modify your @file{~/.bash_profile} file. + +The @samp{verify} 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. + +If @env{EDITOR} environment variable is not set, @file{centos-art.sh} +script uses @file{/usr/bin/vim} as default text editor. Otherwise, the +following values are recognized by @file{centos-art.sh} script: + +@itemize +@item @file{/usr/bin/vim} +@item @file{/usr/bin/emacs} +@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 + +Default directory used to retrieve translated messages. This variable +is set in @file{initFunctions.sh} and shouldn't be changed. + +@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 +@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. + +@end table + +@subsection Usage + +@table @command + +@item centos-art verify --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. + +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. + +@item centos-art verify --links + +Verify required links your workstation needs in order to run the +centos-art command correctly. If any required link is missing, the +@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. + +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. + +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. + +@item centos-art verify --environment +@itemx centos-art verify --environment --filter='regex' + +Output a brief description of environment variables used by +@file{centos-art.sh} script. + +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. + +@end table + +@subsection See also + +@menu +* trunk Scripts Bash:: +@comment --- Removed(* trunk Scripts Bash Functions::) --- +@end menu diff --git a/Manuals/Repository/Filesystem/Scripts/Python.texi b/Manuals/Repository/Filesystem/Scripts/Python.texi new file mode 100644 index 0000000..fb39647 --- /dev/null +++ b/Manuals/Repository/Filesystem/Scripts/Python.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manuals/Repository/Filesystem/branches/chapter-intro.texi b/Manuals/Repository/Filesystem/branches/chapter-intro.texi deleted file mode 100644 index e69de29..0000000 --- a/Manuals/Repository/Filesystem/branches/chapter-intro.texi +++ /dev/null diff --git a/Manuals/Repository/Filesystem/branches/chapter-menu.texi b/Manuals/Repository/Filesystem/branches/chapter-menu.texi deleted file mode 100644 index 8b13789..0000000 --- a/Manuals/Repository/Filesystem/branches/chapter-menu.texi +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Manuals/Repository/Filesystem/branches/chapter-nodes.texi b/Manuals/Repository/Filesystem/branches/chapter-nodes.texi deleted file mode 100644 index 8b13789..0000000 --- a/Manuals/Repository/Filesystem/branches/chapter-nodes.texi +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Manuals/Repository/Filesystem/branches/chapter.texi b/Manuals/Repository/Filesystem/branches/chapter.texi deleted file mode 100644 index e053279..0000000 --- a/Manuals/Repository/Filesystem/branches/chapter.texi +++ /dev/null @@ -1,6 +0,0 @@ -@node branches -@chapter branches -@cindex branches -@include branches/chapter-intro.texi -@include branches/chapter-menu.texi -@include branches/chapter-nodes.texi diff --git a/Manuals/Repository/Filesystem/tags/chapter-intro.texi b/Manuals/Repository/Filesystem/tags/chapter-intro.texi deleted file mode 100644 index e69de29..0000000 --- a/Manuals/Repository/Filesystem/tags/chapter-intro.texi +++ /dev/null diff --git a/Manuals/Repository/Filesystem/tags/chapter-menu.texi b/Manuals/Repository/Filesystem/tags/chapter-menu.texi deleted file mode 100644 index 8b13789..0000000 --- a/Manuals/Repository/Filesystem/tags/chapter-menu.texi +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Manuals/Repository/Filesystem/tags/chapter-nodes.texi b/Manuals/Repository/Filesystem/tags/chapter-nodes.texi deleted file mode 100644 index 8b13789..0000000 --- a/Manuals/Repository/Filesystem/tags/chapter-nodes.texi +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Manuals/Repository/Filesystem/tags/chapter.texi b/Manuals/Repository/Filesystem/tags/chapter.texi deleted file mode 100644 index 2b05ba0..0000000 --- a/Manuals/Repository/Filesystem/tags/chapter.texi +++ /dev/null @@ -1,6 +0,0 @@ -@node tags -@chapter tags -@cindex tags -@include tags/chapter-intro.texi -@include tags/chapter-menu.texi -@include tags/chapter-nodes.texi diff --git a/Manuals/Repository/Filesystem/trunk/Identity.texi b/Manuals/Repository/Filesystem/trunk/Identity.texi deleted file mode 100644 index 65f22ca..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity.texi +++ /dev/null @@ -1,126 +0,0 @@ -@subsection Goals - -The @file{trunk/Identity} directory exists to organize CentOS -corporate identity artworks. - -@subsection Description - -The CentOS Project corporate identity is the ``persona'' of the -organization known as The CentOS Project. The CentOS Project -corporate identity plays a significant role in the way the CentOS -Project, as organization, presents itself to both internal and -external stakeholders. In general terms, the CentOS Project corporate -visual identity expresses the values and ambitions of the CentOS -Project organization, its business, and its characteristics. - -The CentOS Project corporate identity provides visibility, -recognizability, reputation, structure and identification to the -CentOS Project organization by means of corporate design, corporate -communication, and corporate behaviour. - -The CentOS Project settles down its corporate visual identity on a -``monolithic corporate visual identity structure''. In this structure -The CentOS Project uses one unique name (The CentOS Brand) and one -unique visual style (The CentOS Default Theme) in all its -manifestations. - -@table @strong - -@item The CentOS Brands -The CentOS brand is the name or trademark that conncects the producer -with their products. In this case, the producer is The CentOS Project -and the products are the CentOS distributions, the CentOS web sites, -the CentOS promotion stuff, etc. - -@xref{trunk Identity Brands}, for more information. - -@item The CentOS Themes - -The CentOS themes are a set of image files connected all together by -one unique visual style. Each theme is organized in different visual -manifestations, in order to cover each visual manifestation of The -CentOS Project (i.e., distributions, websites, promotion stuff, etc.). -@xref{trunk Identity Themes}, for more information. -@end table - -Inside a monolithic corporate visual identity structure, internal and -external stakeholders use to feel a strong sensation of uniformity, -orientation, and identification with the organization. No matter if -you are visiting websites, using the distribution, or acting on social -events, the one unique name and one unique visual style conect them -all to say: Hey! we are all parts of the CentOS project. And, -probably, some vister will say: Can I join the party? Yes you can, it -is free. :) - -@subsection Usage - -To produce identity artworks, use the following commands: - -@table @samp -@item centos-art render 'path/to/dir' - -When @samp{path/to/dir} refers to one renderable directory under -@file{trunk/Identity}, this command renders identity artworks using -both related design models and related translation files. - -@item centos-art render 'path/to/dir' --filter='pattern' - -When @samp{path/to/dir} refers to one renderable directory under -@file{trunk/Identity}, this command renders identity artworks using -both related design models and related translation files that match -the regular expression passed in @samp{--filter='pattern'} argument. - -To control the number of files produced by @command{centos-art} -command, you need to look into the translation path and provide a -regular expression pattern that matches the translation path, or -paths, related to the file, or files, you want to produce. - -The regular expression pattern you provide to @command{centos-art} -command is applied to the translation path from its very beginning. -It is not the same to say @samp{5/en/01-welcome} that -@samp{01-welcome}, the frist expression matches but the last one does -not. - -When using @samp{--filter='pattern'} you don't need to specify the -file extension. It is removed from translation path before applying -the pattern, so it doesn't count here. -@end table - -@subsection File name convenctions - -As file name convenction, inside CentOS Artwork Repository, both -text-based and image-based file name produced by @command{centos-art.sh} -script has the same name of their translation files without -the @samp{.sed} extension. The file extension is set as follow: - -@subsubsection When text-based files are rendered - -Text-based files end up having the same extension of their design -template file. - -@subsubsection When image-based files are rendered - -Image-based files always end up having the @file{.png} extension. - -@quotation -@strong{Tip} Once @file{.png} images are created, other image formats -may be created using the @command{renderFormats} post-rendering -action, inside the image-based related pre-rendering configuration -script. - -@xref{trunk Scripts Bash}, for more information. -@end quotation - -@subsection See also - -@menu -@comment --- Removed(* trunk Translations::) --- -@end menu - -@subsection References - -@itemize -@item @url{http://en.wikipedia.org/Corporate_identity} (and related -links). -@end itemize - diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi b/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Brands.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi b/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi deleted file mode 100644 index ef6730a..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Fonts.texi +++ /dev/null @@ -1,79 +0,0 @@ -@subsection Goals - -This section exists to organize digital typographies used by the -CentOS project. - -@subsection Description - -@subsection Usage - -The CentOS corporate identity is attached to @samp{DejaVu LGC} -font-family. Whatever artwork you design for CentOS project, that -requires typography usage, must be done using @samp{DejaVu LGC} -font-family. - -@table @strong -@item Recommendation-1: - -For screen desings (e.g., anything that final destination will never -be printed on paper or any medium outside computer screens) use -@samp{DejaVu LGC Sans} font-family. - -@item Recommendation-2: - -For non-screen designs (e.g., anything that final desition will be -printed on paper or any other medium outside computer screens) use -@samp{DejaVu LGC Serif} font-family. As convenction files described in -this rule are stored under @samp{Stationery} directories. -@end table - -The only execption for the two recommendations above is the typography -used inside CentOS logo. The CentOS logo is the main visual -representation of the CentOS project so the typography used in it must -be the same always, no matter where it be shown. It also has to be -clear enough to dismiss any confussion between similar typefaces -(e.g., the number one (1) sometimes is confuesed with the letter -@samp{el} (l) or letter @samp{ai} (i)). - -As CentOS logo typography convenction, the word @samp{CentOS} uses -@samp{Denmark} typography as base, both for the word @samp{CentOS} and -the phrase @samp{Community Enterprise Operating System}. The phrase -size of CentOS logo is half the size in poits the word @samp{CentOS} -has and 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. - -When the CentOS release brand is built, use @samp{Denmark} typography -for the release number. The release number size is two times larger -(in height) than default @samp{CentOS} word. The separation between -release number and @samp{CentOS} word is twice the size in points of -separation between @samp{CentOS} word and phrase @samp{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 @samp{CentOS} word. The trademark -symbol must not exceed haf the distance, in points, between -@samp{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. - -@quotation -@strong{Note} The information about trademarks and corporate identity -is my personal interpretation of -@url{http://en.wikipedia.org/Corporate_identity} and -@url{http://en.wikipedia.org/Trademark} description. If you have -practical experiences with these affairs, please serve yourself to -improve this section with your reasons. -@end quotation - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi b/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Icons.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi b/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Isolinux.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models.texi deleted file mode 100644 index 3973252..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models.texi +++ /dev/null @@ -1,19 +0,0 @@ -@subsection Goals - -This section exists to organize design models. - -@subsection Description - -Design models are representative designs useful to understand how -to build artworks. - -@subsection Usage - -@subsection See also - -@menu -* trunk Identity Models Html:: -* trunk Identity Models Css:: -* trunk Identity Models Tpl:: -* trunk Identity Models Xcf:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi deleted file mode 100644 index 5639459..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Css.texi +++ /dev/null @@ -1,21 +0,0 @@ -@subsection Goals - -This directory exists to provide common style sheets (CSS) definitions -to HTML design models. - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Html.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi deleted file mode 100644 index ec9b88b..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Img/Promo/Web.texi +++ /dev/null @@ -1,23 +0,0 @@ -@subsection Goals - -@itemize -@item Provide images related to CentOS web interface. -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -* trunk Identity Models Tpl Promo Web:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi deleted file mode 100644 index 56b7f37..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Tpl/Promo/Web.texi +++ /dev/null @@ -1,329 +0,0 @@ -@subsection Goals - -Organize scalable vector graphics (svg) to help describe the CentOS -web environment. - -@subsection The CentOS web environment - -Inside CentOS corporate identity, the CentOS web environment is -considered a promotion component. The CentOS web environment is formed -by a central web application ---to cover base needs (e.g., per-major -release information like release notes, lifetime, downloads, -documentation, support, security advisories, bugs, etc.)--- and many -different free web applications ---to cover specific needs (e.g., -wiki, mailing lists, etc.)---. - -The CentOS web environment is addressed to solve the following issues: - -@itemize -@item One unique name and one unique visual style to all web -applications used inside the web environment. - -@item One-step navigation to web applications inside the environment. - -@item High degree of customization to change the visual style of all -web applications with few changes (e.g, updating just two or three -images plus common style sheet [CSS] definitions). -@end itemize - -The CentOS project is attached to a monolithic corporate visual -identity (@pxref{trunk Identity}), where all visual manifestations -have one unique name and one unique visual style. This way, the CentOS -web environment has one unique name (the CentOS brand) and one unique -visual style (the CentOS default theme) for all its visual -manifestations, the web applications in this case. - -Since a maintainance point of view, achiving the one unique visual -style inside CentOS web environment is not a simple task. The CentOS -web environment is built upon many different web applications which -have different visual styles and different internal ways to customize -their own visual styles. For example: MoinMoin, the web application -used to support the CentOS wiki (@url{http://wiki.centos.org/}) is -highly customizable but Mailman (in its 2.x.x serie), the web -application used to support the CentOS mailing list, doesn't -support@footnote{The theme support of Mailman may be introduced in -mailman-3.x.x release.} a customization system that separates -presentation from logic, similar to that used by MoinMoin. - -This visual style diversity complicates our goal of one unique visual -style for all web applications. So, if we want one unique visual style -for all web applications used, it is innevitable to modify the web -applications in order to implement the CentOS one unique visual style -customization in them. Direct modification of upstream applications is -not convenient because upstream applications come with their one -visual style and administrators take the risk of loosing all -customization changes the next time the application be updated (since -not all upstream web applications, used in CentOS web environment, -separate presentation from logic). - -To solve the ``one unique visual style'' issue, installation and -actualization of web applications ---used inside CentOS web -environment--- need to be independent from upstream web applications -development line; in a way that CentOS web environment administrators -can install and update web applications freely without risk of loosing -the one unique visual style customization changes. - -At the surface of this issue we can see the need of one specific yum -repository to store CentOS web environment customized web applications. - -@subsubsection Design model (without ads) - -@subsubsection Design model (with ads) - -@subsubsection HTML definitions - -@subsubsection Controlling visual style - -Inside CentOS web environment, the visual style is controlled by the -following compenents: - -@table @strong -@item Webenv header background -@verbatim -trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png -@end verbatim - -@item CSS definitions -@verbatim -trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css -@end verbatim -@end table - -@subsubsection Producing visual style - -The visual style of CentOS web environment is defined in the following -files: - -@verbatim -trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf -trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png -trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png -trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg -@end verbatim - -As graphic designer you use @file{1024x250.xcf} file to produce -@file{1024x250-bg.png} file. Later, inside @file{1024x250.svg} file, -you use the @file{1024x250-bg.png} file as background layer to draw -your vectorial design. When you consider you artwork ready, use the -@command{centos-art.sh} script, as described below, to produce the -visual style controller images of CentOS web environment. - -@verbatim -centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250' -@end verbatim - -Once you have rendered required image files, changing the visual style -of CentOS web environment is a matter of replacing old image files -with new ones, inside webenv repository file system structure. The -visual style changes will take effect the next time customization line -of CentOS web applications be packaged, uploded, and installed from -[webenv] or [webenv-test] repositories. - -@subsubsection Navigation - -Inside CentOS web environment, the one-step navegation between web -applications is addressed using the web environment navigation bar. -The web environment navigation bar contains links to main applications -and is always visible no matter where you are inside the web -environment. - -@subsubsection Development and release cycle - -The CentOS web environment development and relase cycle is described -below: - -@table @strong - -@item Download - -The first action is download the source code of web applications we -want to use inside CentOS web environment. - -@quotation -@strong{Important} The source location from which web application are -downloaded is very important. Use SRPMs from CentOS @strong{[base]} -and @strong{[updates]} repositories as first choise, and third party -repositories (e.g. RPMForge, EPEL, etc.) as last resource. -@end quotation - -@item Prepare - -Once web application source code has been downloaded, our duty is -organize its files inside @samp{webenv} version controlled repository. - -When preparing the structure keep in mind that different web -applications have different visual styles, and also different ways to -implement it. A convenient way to organize the file system structure -would be create one development line for each web application we use -inside CentOS web environment. For example, consider the following -file system structure: - -@verbatim -https://projects.centos.org/svn/webenv/trunk/ -|-- WebApp1/ -| |-- Sources/ -| | `-- webapp1-0.0.1/ -| |-- Rpms/ -| | `-- webapp1-0.0.1.rpm -| |-- Srpms/ -| | `-- webapp1-0.0.1.srpm -| `-- Specs/ -| `-- webapp1-0.0.1.spec -|-- WebApp2/ -`-- WebAppN/ -@end verbatim - -@item Customize - -Once web applications have been organized inside the version -controlled repository file system, use subversion to create the CentOS -customization development line of web applications source code. For -example, using the above file system structure, you can create the -customization development line of @file{webapp1-0.0.1/} with the -following command: - -@verbatim -svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv -@end verbatim - -The command above creates the following structure: - -@verbatim -https://projects.centos.org/svn/webenv/trunk/ -|-- WebApp1/ -| |-- Sources/ -| | |-- webapp1-0.0.1/ -| | `-- webapp1-0.0.1-webenv/ -| |-- Rpms/ -| | `-- webapp1-0.0.1.rpm -| |-- Srpms/ -| | `-- webapp1-0.0.1.srpm -| `-- Specs/ -| `-- webapp1-0.0.1.spec -|-- WebApp2/ -`-- WebAppN/ -@end verbatim - -In the above structure, the @file{webapp1-0.0.1-webenv/} directory is -the place where you customize the visual style of -@file{webapp1-0.0.1/} web application. - -@quotation -@strong{Tip} Use the @command{diff} command of Subversion between -CentOS customization and upstream development lines to know what you -are changing exactly. -@end quotation - -@item Build packages - -When web application has been customized, build the web application -RPM and SRPM using the source location with @samp{-webenv} prefix. - -@verbatim -https://projects.centos.org/svn/webenv/trunk/ -|-- WebApp1/ -| |-- Sources/ -| | |-- webapp1-0.0.1/ -| | `-- webapp1-0.0.1-webenv/ -| |-- Rpms/ -| | |-- webapp1-0.0.1.rpm -| | `-- webapp1-0.0.1-webenv.rpm -| |-- Srpms/ -| | |-- webapp1-0.0.1.srpm -| | `-- webapp1-0.0.1-webenv.srpm -| `-- Specs/ -| |-- webapp1-0.0.1.spec -| `-- webapp1-0.0.1-webenv.spec -|-- WebApp2/ -`-- WebAppN/ -@end verbatim - -@item Release for testing - -When the customized web application has been packaged, make packages -available for testing and quality assurance. This can be achives using -a [webenv-test] yum repository. - -@quotation -@strong{Note} The [webenv-test] repository is not shipped inside -CentOS distribution default yum configuraiton. In order to use -[webenv-test] repository you need to configure it first. -@end quotation - -If some problem is found to install/update/use the customized version -of web application, the problem is notified somewhere (a bugtracker -maybe) and the customization face is repated in order to fix the -problem. To release the new package add a number after @samp{-webenv} -prefix. For example, if some problem is found in -@file{webapp1-0.0.1-webenv.rpm}, when it be fixed the new package will -be named @file{webapp1-0.0.1-webenv-1.rpm}. If a problem is found in -@file{webapp1-0.0.1-webenv-1.rpm}, when it be fixed the new package -will be named @file{webapp1-0.0.1-webenv-2.rpm}, and so on. - -The ``customization --- release for testing'' process is repeated -until CentOS quality assurance team considers the package is ready for -production. - -@item Release for production - -When customized web application packages are considered ready for -production they are moved from [webenv-test] to [webenv] repository. -This action is commited by CentOS quality assurance team. - -@quotation -@strong{Note} The [webenv] repository is not shipped inside CentOS -distribution default yum configuraiton. In order to use [webenv] -repository you need to configure it first. -@end quotation -@end table - -@subsubsection The [webenv-test] repository - -@verbatim -/etc/yum.repos.d/CentOS-Webenv-test.repo -@end verbatim - -@verbatim -[webenv-test] -name=CentOS-$releasever - Webenv-test -mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test -#baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/ -gpgcheck=1 -gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever -enabled=1 -priority=10 -@end verbatim - -@subsubsection The [webenv] repository - -@verbatim -/etc/yum.repos.d/CentOS-Webenv.repo -@end verbatim - -@verbatim -[webenv] -name=CentOS-$releasever - Webenv -mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv -#baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/ -gpgcheck=1 -gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever -enabled=1 -priority=10 -@end verbatim - -@subsubsection Priority configuration - -Both [webenv] and [webenv-test] repositories update packages inside -CentOS [base] and CentOS [updates] repositories. - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -* trunk Identity Models Img Promo Web:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi b/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Models/Xcf.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Release.texi b/Manuals/Repository/Filesystem/trunk/Identity/Release.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Release.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi deleted file mode 100644 index 01a20c1..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes.texi +++ /dev/null @@ -1,26 +0,0 @@ -@subsection Goals - -The @file{trunk/Identity/Themes/} directory exists to organize -production of CentOS themes. - -@subsection Description - -@subsection Usage - -In this location themes are organized in ``Models'' ---to store common -information--- and ``Motifs''---to store unique information. At -rendering time, both motifs and models are combined to produce the -final CentOS themes. CentOS themes can be tagged as ``Default'' or -``Alternative''. CentOS themes are maintained by CentOS community. - -@menu -* trunk Identity Themes Models:: -* trunk Identity Themes Motifs:: -@end menu - -@subsection See also - -@menu -* trunk Identity:: -* trunk:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi deleted file mode 100644 index b91973a..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models.texi +++ /dev/null @@ -1,30 +0,0 @@ -@subsection Goals - -@itemize -@item Organize theme models. -@end itemize - -@subsection Description - -Theme models let you modeling characteristics (e.g., dimensions, -translation markers, position of each element on the display area, -etc.) common to all themes. Theme models let you reduce the time -needed when propagating artistic motifs to different visual -manifestations. - -Theme models serves as a central pool of design templates for themes -to use. This way you can produce themes with different artistic motifs -but same characteristics. - -@subsection Usage - -Inside the framework location above, you find theme models organized -by name. You can add your own theme models to the structure by adding -a directory to the list. By default you have the `@xref{trunk Identity -Themes Models Default, Default},' and `@xref{trunk Identity Themes -Models Alternative, Alternative},' ready-to-use theme models. - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi deleted file mode 100644 index 483226a..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Alternative.texi +++ /dev/null @@ -1,26 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -CentOS alternative theme models exist for people how want to use a -different visual style on their installations of CentOS distribution. -As the visual style is needed for a system already installed -components like Anaconda are not required inside alternative themes. -Inside alternative themes you find post-installation visual style only -(i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative -themes are maintained by CentOS Community. - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi deleted file mode 100644 index 6ce9103..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default.texi +++ /dev/null @@ -1,27 +0,0 @@ -@subsection Goals - -This location stores CentOS default theme model. The default theme -model of CentOS is used in all visual manifestations of CentOS Project -corporate visual identity (e.g., distributions, web sites, promotion, -etc.). - -@subsection Description - -@subsection Usage - -Changing CentOS default theme is not very convenient because that -affects the ``recognition'' of CentOS Project. Nevertheless, we are -interested on seeing your art work propositions. Specially if your -art work is an improvement to the base idea behind CentOS default -theme (@strong{Modern}, squares and circles flowing up.). - -If you are not happy with CentOS default theme, you can look inside -CentOS alternative themes and download the one you are interested in. -If you are not happy with any of the CentOS alternative themes -available, then go and design your own CentOS alternative theme as -described in @xref{trunk Identity Themes Motifs, Theme Motifs}. - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi deleted file mode 100644 index d10a829..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro.texi +++ /dev/null @@ -1,83 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -It applies to all major releases of CentOS distribution. - -@subsubsection One theme for all major releases - -Sometimes, specific visual manifestations are formed by common -components which have internal differences. That is the case of CentOS -distribution visual manifestation. - -Since a visual style point of view, the CentOS distributions share -common artwork components like Anaconda ---to cover the CentOS -distribution installation---, BootUp ---to cover the CentOS -distribution start up---, and Backgrounds ---to cover the CentOS -distribution desktop---. Now, since a technical point of view, those -common artwork components are made of software improved constantly. -So, we need to find a way to keep one unique name and one unique -visual style in artwork components that have internal difference and -also remark internal difference as well. - -@quotation -@strong{Important} Remarking the CentOS release schema inside each -major release of CentOS distribution ---or similar visual -manifestation--- takes @emph{high attention} inside The CentOS Project -corporate visual identity. It should be very clear for people which -major release of CentOS distribution they are using. -@end quotation - -In order to remark the CentOS release schema, the CentOS Artwork SIG -uses a release-specific brand design named ``The CentOS Release -Brand''. The CentOS release brand is compossed by the CentOS logotype -@emph{and} the CentOS major release number (as specified in CentOS -release schema definition). In this solution, the CentOS release brand -is set inside all release-specific artworks (e.g., distribution, -installation media, etc.) in remarkable way. The CentOS release -brand is the design component that lets us remark the CentOS release -schema inside the monolithic corporate visual identity structure we -propose to use. - -@subsubsection One theme for each major release - -Other way we've been using to remark CentOS release schema is -applying one unique theme for @emph{each} major release of CentOS -distribution. That is, if we have 4 major releases of CentOS -distribution, we need to provide 4 different themes to cover each -CentOS distribution available. - -Inside CentOS Artwork Repository, you can create many themes and that -is very convenient. But using one unique theme for @emph{each} major -release of CentOS distribution would bring visual isolation among -distributions, websites and promotion visual manifestations. If the -CentOS project would maintain just one CentOS distribution (and many -experienced graphic designers ready to create beautiful artworks) this -model would be nice. Indeed, this model looks quite similar to that -one used by Fedora project, doesn't it. But no, the CentOS project -maintains near to 4 major releases of CentOS distribution in parallel, -and that fact makes a huge difference since the corporate visual -identity point of view. - -If we use one unique theme for @emph{each} major release of CentOS -distribution, which one of those themes, does we use to cover other -CentOS visual manifestations, like websites and promotion stuff? - -In whatever case you choose some release-specific distribution user -will be visually isolated from other CentOS visual manifestations like -websites and promotion stuff, even if the CentOS brand is present in -all visual manifestations. In such a case, probably, users will end up -asking themselves, why my CentOS distribution has this design and the -CentOS website another one? Isn't them on the same project? With luck -the CentOS brand will exonerate user form visual isolation. - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi deleted file mode 100644 index 7bfbe48..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Promo.texi +++ /dev/null @@ -1,27 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -It applies to all tangible and non tangible items CentOS uses to -promote its existence. Clothes, posters, installation media, -stationery, release countdown images, banners, stickers, are all -examples of promotion designs. - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi deleted file mode 100644 index 427850f..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Models/Default/Web.texi +++ /dev/null @@ -1,26 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -It applies to all web applications CentOS uses to handle its needs -(Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving -HTML standards should be consider here. - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi deleted file mode 100644 index 7b8c0e0..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs.texi +++ /dev/null @@ -1,114 +0,0 @@ -@subsection Goals - -The @file{trunk/Identity/Themes/Motifs} directory exists to: - -@itemize -@item Organize CentOS themes' artistic motifs. -@end itemize - -@subsection Description - -The artistic motif of theme is a graphic design component that -provides the visual style of themes, it is used as pattern to connect -all visual manifestations inside one unique theme. - -Artistic motifs are based on conceptual ideas. Conceptual ideas bring -the motivation, they are fuel for the engines of human imagination. -Good conceptual ideas may produce good motivation to produce almost -anything, and art works don't escape from it. - -@table @samp -@item TreeFlower -CentOS like trees, has roots, trunk, branches, leaves and flowers. Day -by day they work together in freedom, ruled by the laws of nature and -open standards, to show the beauty of its existence. -@item Modern -Modern, squares and circles flowing up. -@end table - -If you have new conceptual ideas for CentOS, then you can say that you -want to create a new artistic motif for CentOS. To create a new -artistic motif you need to create a directory under -@file{Identity/Themes/Motifs/} using a name coherent with your -conceptual idea. That name will be the name of your artistic motif. If -possible, when creating new conceptual ideas for CentOS, think about -what CentOS means for you, what does it makes you feel, take your -time, think deep, and share; you can improve the idea as time goes on. - -Once you have defined a name for your theme, you need to create the -motif structure of your theme. The motif structure is the basic -direcotry structure you'll use to work your ideas. Here is where you -organize your graphic design projects. - -To add a new motif structure to CentOS Artwork Repository, you need to -use the @command{centos-art} command line in the -@file{Identity/Themes/Motifs/} directory as described below: - -@example -centos-art add --motif=ThemeName -@end example - -The previous command will create the basic structure of themes for -you. The basic structure produced by @command{centos-art} command is -illustrated in the following figure: - -@example -trunk/Identity/Themes/Motifs/$ThemeName/ -|-- Backgrounds -| |-- Img -| `-- Tpl -|-- Info -| |-- Img -| `-- Tpl -|-- Palettes -`-- Screenshots -@end example - -@subsection Usage - -When designing artistic motifs for CentOS, consider the following -recommendations: - -@itemize -@item Give a unique (case-sensitive) name to your Motif. This name is -used as value wherever theme variable (@b{$THEME}) or translation marker -(@b{=THEME=}) is. Optionally, you can add a description about -inspiration and concepts behind your work. - -@item Use the location @file{trunk/Identity/Themes/Motifs/$THEME/} to -store your work. If it doesn't exist create it. Note that this require -you to have previous commit access in CentOS Artwork Repository. - -@item The CentOS Project is using the blue color (@b{#204c8d}) as base -color for its corporate visual identity. Use such base corporate color -information as much as possible in your artistic motif designs. - -@item Try to make your design fit one of the theme models. - -@item Feel free to make your art enterprise-level and beautiful. - -@item Add the following information on your artwork (both in a visible -design area and document metadata): - -@itemize - -@item The name (or logo) of your artistic motif. - -@item The copyright sentence: @b{Copyright (C) YEAR YOURNAME} - -@item The license under which the work is released. All CentOS Art -works are released under -@url{http://creativecommons.org/licenses/by-sa/3.0/,Creative Common -Share-Alike License 3.0} -(@url{http://creativecommons.org/licenses/by-sa/3.0/}). - -@end itemize -@end itemize - -@subsection See also - -@menu -* trunk Identity Themes:: -* trunk Identity:: -* trunk:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi deleted file mode 100644 index b9e787a..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Flame.texi +++ /dev/null @@ -1,206 +0,0 @@ -@subsection Goals - -This section describes the steps we followed to construct the -@emph{Flame} artistic motif. This section may be useful for anyone -interested in reproducing the @emph{Flame} artistic motif, or in -creating new artistic motifs for The CentOS Project corporate visual -identity (@pxref{trunk Identity}). - -@subsection Description - -The @emph{Flame} artistic motif was built using the flame filter of -Gimp 2.2 in CentOS 5.5. - -The flame filter of Gimp can produce stunning, randomly generated -fractal patterns. The flame filter of Gimp gives us a great oportunity -to reduce the time used to produce new artistic motifs, because of its -``randomly generated'' nature. Once the artistic motif be created, it -is propagated through all visual manifestations of CentOS Project -corporate visual identity using the @file{centos-art.sh} script -(@pxref{trunk Scripts Bash}) inside the CentOS Artwork Repository. - -To set the time intervals between each new visual style production, we -could reuse the CentOS distribution major release schema. I.e., we -could produce a new visual style, every two years, based on a new -``randomly generated'' flame pattern, and publish the whole corporate -visual identity (i.e., distribution stuff, promotion stuff, websites -stuff, etc.) with the new major release of CentOS distribution all -together at once. - -Producing a new visual style is not one day's task. Once we have -defined the artistic motif, we need to propagate it through all visual -manifestations of The CentOS Project corporate visual identity. When -we say that we could produce one new visual style every two years we -really mean: to work two years long in order to propagate a new visual -style to all visual manifestations of The CentOS Project corporate -visual identity. - -Obviously, in order to propagate one visual style to all different -visual manifestations of The CentOS Project corporate visual identity, -we need first to know which the visual manifestations are. To define -which visual manifestations are inside The CentOS Project corporate -visual identity is one of the goals the CentOS Artwork Repository and -this documentation manual are both aimed to satisfy. - -Once we define which the visual manifestation are, it is possible to -define how to produce them, and this way, organize the automation -process. Such automation process is one of the goals of -@file{centos-art.sh} script. - -With the combination of both CentOS Artwork Repository and -@file{centos-art.sh} scripts we define work lines where translators, -programmers, and graphic designers work together to distribute and -reduce the amount of time employed to produce The CentOS Project -monolithic corporate identity. - -From a monolithic corporate visual identity point of view, notice that -we are producing a new visual style for the same theme (i.e., -@emph{Flame}). It would be another flame design but still a flame -design. This idea is very important to be aware of, because we are -somehow ``refreshing'' the theme, not changing it at all. - -This way, as we are ``refreshing'' the theme, we still keep oursleves -inside the monolithic conception we are trying to be attached to -(i.e., one unique name, and one unique visual style for all visual -manifestations). - -Producing artistic motifs is a creative process that may consume long -time, specially for people without experienced knowledge on graphic -design land. Using ``randomly generated'' conception to produce -artistic motifs could be, practically, a way for anyone to follow in -order to produce maintainable artistic motifs in few steps. - -Due to the ``randomly generated'' nature of Flame filter, we find that -@emph{Flame} pattern is not always the same when we use @emph{Flame} -filter interface. - -Using the same pattern design for each visual manifestation is -essential in order to maintain the visual connection among all visual -manifestations inside the same theme. Occasionally, we may introduce -pattern variations in opacity, size, or even position but never change -the pattern design itself, nor the color information used by images -considered part of the same theme. - -@quotation -@strong{Important} -When we design background images, which are considered part of the -same theme, it is essential to use the same design pattern always. -This is what makes theme images to be visually connected among -themeselves, and so, the reason we use to define the word ``theme'' -as: a set of images visually connected among themeselves. -@end quotation - -In order for us to reproduce the same flame pattern always, -@emph{Flame} filter interface provides the @samp{Save} and @samp{Open} -options. The @samp{Save} option brings up a file save dialog that -allows you to save the current Flame settings for the plug-in, so that -you can recreate them later. The @samp{Open} option brings up a file -selector that allows you to open a previously saved Flame settings -file. - -The Flame settings we used in our example are saved in the file: - -@verbatim -trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def -@end verbatim - -@subsection Construction - -@subsubsection Step 1: Set image size - -Create an empty image and fill the @samp{Background} layer with black -(@code{000000}) color. Image dimensions depend on the final -destination you plan to use the image for. For the sake of our -construction example we used an image of 640x480 pixels and 300 pixels -per inch (ppi). - -@subsubsection Step 2: Add base color and pattern information - -Create a new layer named @samp{Base}, place it over @samp{Background} -layer and fill it with the base color (@code{7800ff}) you want to have -your background image set in. Add a mask to @samp{Base} layer using -radial gradient and blur it. You may need to repeat this step more -than once in order to achieve a confortable black radial degradation -on the right side of your design. - -Duplicate @samp{Base} layer and name it @samp{Paper}. Place -@samp{Paper} layer over @samp{Base} layer. Remove content of -@samp{Paper} layer and fill it with @samp{Paper (100x100)} pattern. -Once you've done with black radial degradation, reduce the -@samp{Paper} layer opacity to 20%. - -Notice that when we duplicate one layer, the mask information related -to layer is preserved from previous to next layer. This saves us some -of the time required to produce different layers with the same mask -information on them. - -Duplicate @samp{Paper} layer and rename it @samp{Stripes}. Remove -paper pattern from @samp{Stripes} layer. Fill @samp{Stripes} layer -with @samp{Stripes (48x48)} pattern and reduce the @samp{Stripes} -layer opacity to 15%. - -@subsubsection Step 3: Add flame motif - -Create a new layer named @samp{Flame}. Set the foreground -(@code{003cff}) and background (@code{0084ff}) colors to the gradient -you want to build the flame motif. - -To build flame motif, use the flame filter (@samp{Filters > Render > -Nature > Flame...}) on @samp{Flame} layer. We used a layer mask, with -a radial gradient on it to control the boundaries of flame motif on -@samp{Flame} layer. - -Duplicate @samp{Flame} layer and rename it `Flame Blur'. Place `Flame -Blur' below @samp{Flame} layer. Apply Gussian blur filter -(@samp{Filters > Blur > Gussian Blur...}) until reaching the desiered -effect. - -The opacity value, in @samp{Flame} layers, may vary from one image to -another based on the place the image will be finally placed on. For -example, images used as desktop background have the @samp{Flame} layer -opacity set at 100% but @samp{Flame Blur} is set to 70%. However, you -may find that background images used in anaconda progress slides have -opacity reduced differently, in order to reduce brightness in a way -that texts could look clean and readable over it. - -@subsubsection Step 4: Add foreground color - -Create a new layer named @samp{Color}, place it on top of all visible -layers and fill it with plain color (@code{4c005a}). Reduce -@samp{Color} layer opacity to 20%. You can use the @samp{Color} layer -to control the right side color information you want to produce the -image for. - -Duplicate @samp{Flame} layer and create a new layer named -@samp{Color#1}. Place @samp{Color#1} layer on top of layer named -@samp{Color}. Remove the mask information from @samp{Color#1} layer -and recreate a new one using an inverted alpha channel as reference. -Remove @samp{Color#1} layer content and fill it back with plain black -(@code{000000}) color. Reduce @samp{Color#1} opacity to 20%. In this -step we created a mask to protect the flame artistic motif from black -color, so when we decrement or increment the opacity of layer, the -flame artistic motif wouldn't be affected, just the environment -suround it. - -When you set color information, remember that the same artistic motif -needs to be indexed to 14 and 16 colors, in order to produce Grub and -Syslinux visual manifestations respectively. Using many different -colors in the artistic motif may reduce the possibility of your design -to fix all different situations in. Likewise, using more colors in -one design, and less colors in another design will reduce the -connectivity among your designs, since color information is relevant -to visual identity. - -When you propagate your artistic motif visual style to different -visual manifestations of CentOS Project corporate visual identity, it -is up to you to find out justice and compromise among all possible -variables you may face. - -@subsection See also - -@menu -* trunk Identity Themes Motifs:: -* trunk Identity Themes:: -* trunk Identity:: -* trunk:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi deleted file mode 100644 index 306ab79..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Presentation - -@subsection Construction - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi deleted file mode 100644 index adda528..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi +++ /dev/null @@ -1,143 +0,0 @@ -@subsection Goals - -@itemize -@item Organize background images for Modern theme. -@end itemize - -@subsection Description - -Inside @file{Motifs} directory, the @file{Backgrounds/} directory is -used to create vectorial designs using Inkscape and background images -using Gimp. Later, you can export background images as @file{.png} and -load them in your vectorial design project using the import feautre of -Inkscape. - -You may need to repeat this technic for different screen resoluions. -In that case you need to create one file for each screen resolution -and do the appropriate linking inside .svg to .png files. For example -if you need to produce background images in 800x600 you need to create -the following file: - -@example -xcf/800x600.xcf -@end example - -to produce the background image: - -@example -img/800x600-bg.png -@end example - -which is loaded in: - -@example -svg/800x600.svg -@end example - -to produce the final background image: - -@example -img/800x600.png -@end example - -The @file{img/800x600.png} background image is produced automatically -by means of rendering scripts. - -In other cases (e.g. Anaconda), it is possible that you need to make -some variations to one background image that don't want to appear on -regular background images of the same resolution. In this case you -need to create a new and specific background image for that art -component. For example, if you need to produce the background image -used by Anconda (800x600) art works you create the file: - -@example -xcf/800x600-anaconda.xcf -@end example - -to produce the background image: - -@example -img/800x600-anaconda-bg.png -@end example - -which is loaded in: - -@example -svg/800x600-anaconda.svg -@end example - -to produce the file: - -@example -img/800x600-anaconda.png -@end example - -The 800x600-anaconda.png file is used by all Anaconda art works -sharing a common 800x600 screen resolution (e.g., Header, Progress, -Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors -and 640x480 pixels so you need to create a 640x480 background image -for it, and take the color limitation into account when designing it. - -Background images without artistic motif are generally used as based -to build the Background images that do contain the theme artistic -motif. - -Background images are linked (using the @b{import} feature of -Inkscape) inside almost all theme art works. This structure let you -make centralized changes on the visual identity and propagate them -quickly to other areas. - -In this structure you design background images for different screen -resolutions based on the theme artistic motif. - -You may create different artistic motifs propositions based -on the same conceptual idea. The conceptual idea is what defines a -theme. Artistic motifs are interpretations of that idea. - -Inside this directory artistic motifs are organized by name (e.g., -TreeFlower, Modern, etc.). - -Each artistic motif directory represents just one unique artistic -motif. - -The artistic motif is graphic design used as common pattern to connect -all visual manifestations inside one unique theme. The artistic motif -is based on a conceptual idea. Artistic motifs provide visual style -to themes. - -Designing artistic motifs is for anyone interested in creating -beautiful themes for CentOS. When building a theme for CentOS, the -first design you need to define is the artistic motif. - - -Inside CentOS Artwork Repository, theme visual styles (Motifs) and -theme visual structures (Models) are two different working lines. -When you design an artistic motif for CentOS you concentrate on its -visual style, and eventualy, use the @command{centos-art} command line -interface to render the visual style, you are currently producing, -against an already-made theme model in order to produce the final -result. Final images are stored under @file{Motifs/} directory using -the model name, and the model directory structure as reference. - -The artistic motif base structure is used by @command{centos-art} to -produce images automatically. This section describes each directory of -CentOS artistic motif base structure. - -@subsection Usage - -The @file{Backgrounds/} directory is probably the core component, -inside @file{Motifs/} directory structure. Inside @file{Backgrounds/} -directory you produce background images used by almost all theme -models (e.g., Distribution, Websites, Promotion, etc.). The -@file{Backgrounds/} directory can contain subdirectories to help you -organize the design process. - -@subsection See also - -@menu -* trunk Identity Themes Motifs Modern Backgrounds Img:: -* trunk Identity Themes Motifs Modern Backgrounds Tpl:: -* trunk Identity Themes Motifs Modern Backgrounds Xcf:: -@comment --- Removed(* trunk Translations Identity Themes Backgrounds::) --- -@end menu - diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi deleted file mode 100644 index fc1ecfb..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi +++ /dev/null @@ -1,19 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -In this directory is where you store all background images (e.g., -.png, .jpg, .xpm, etc.). This directory is required by -@file{centos-art} command line interface. - -@subsection See also - -@menu -@end menu - diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi deleted file mode 100644 index 4b3308a..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi +++ /dev/null @@ -1,18 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -In this directory is where you store all the scalable vector graphics -(e.g., .svg) files. This directory is required by @file{centos-art} -command line interface. - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi deleted file mode 100644 index b572a3d..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi +++ /dev/null @@ -1,27 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - - -@subsection Usage - -In this directory is where you store the project files (e.g, .xcf) of -Gimp. This directory is not required by @file{centos-art} command -line interface. If you can create a beautiful background images using -scalable vector graphics only, then there is no need to use the -@file{Xcf/} directory to store background projects. Of course, you can -merge both Gimp and Inkscape power to produce images based on them. -In this last case you need the @file{Xcf/} directory. - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi deleted file mode 100644 index 8735b28..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi +++ /dev/null @@ -1,59 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -To render Anaconda progress slide images using the @emph{Modern} -artistic motif design, the Default theme model, and available -translation files (--- @strong{Removed}(pxref:trunk Translations Identity Themes Distro -Anaconda Progress) ---); use the following commands: - -@example -cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/ -centos-art render --identity -@end example - -The above command will create the following structure: - -@example -trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress -|-- 3 -| |-- en -| | |-- 01-welcome.png -| | |-- 02-donate.png -| | `-- 03-yum.png -| `-- es -| |-- 01-welcome.png -| |-- 02-donate.png -| `-- 03-yum.png -|-- 4 -| |-- en -| | |-- 01-welcome.png -| | |-- 02-donate.png -| | `-- 03-yum.png -| `-- es -| |-- 01-welcome.png -| |-- 02-donate.png -| `-- 03-yum.png -`-- 5 - |-- en - | |-- 01-welcome.png - | |-- 02-donate.png - | `-- 03-yum.png - `-- es - |-- 01-welcome.png - |-- 02-donate.png - `-- 03-yum.png -@end example - - -@subsection See also - -@menu -@end menu - diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi deleted file mode 100644 index 79765d1..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/Modern/Palettes.texi +++ /dev/null @@ -1,20 +0,0 @@ -@subsection Goals - -@itemize -@item Organize palette files for Modern theme. -@end itemize - -@subsection Description - -@subsection Usage - -Here is where graphic designers define theme palettes for -color-limited art works. Theme palettes contain the color information -that rendering functions need, in order to produce images with color -limitations. Theme palettes contain the unique color information -required by theme. - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi deleted file mode 100644 index 32e0626..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi +++ /dev/null @@ -1,323 +0,0 @@ -@subsection Goals - -This section exists to orgnize backgrounds of @emph{TreeFlower} -artistic motif. - -@subsection Description - -@subsubsection Desktop background - -Once you have defined the vectorial artistic motif design, use the -@command{centos-art.sh} script (as described in usage section below) -to produce the png version of it. With the png version of your -vectorial design do the following: - -Open the png version with GIMP. - -Save the png version as a project of GIMP inside -@file{trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf} -directory, using the same name of your vectorial design but with the -@samp{.xcf} extension. - -Now use GIMP to improve your design. Here you may add one layer for -pattern, another for colors, and so on until you find yourself -confortable with your artwork. For example, the following layer -distribution (from bottom to top) was used to build revision 285 of -file @file{1360x768.xcf} using @emph{TreeFlower} artistic motif at -revision 241. - -@table @strong -@item Layer 1: Background - -The first thing we did with GIMP was to create a layer named -@samp{Background} to store the artistic motif (File > Open as layer). -This layer is the lowest layer in the image. Later, we started to -create layers one upon another to change the artistic motif visual -style. - -@item Layer 2: Shadow#1 - -This layer is above @samp{Background} and contains a linear gradient -from left (000000) to right (transparent) covering the whole image. -This layer masks the artistic motif to avoid the effect of linear -gradient. This layer is 100% of opacity. - -@item Layer 3: Shadow#2 - -This layer is above @samp{Shadow#1} and contains a linear gradient -from left (000000) to right (transparent) covering just the 70% of the -whole image aproximatly. This layer doesn't mask the artistic motif -which make the left part of it fall into the dark of linear gradient. -This layer is 100% of opacity. - -@item Layer 4: Pattern (Paper) - -This layer is above @samp{Shadow#2} an contains the paper pattern -shipped with GIMP 2.2. This layer doesn't mask the artistic motif so -the pattern is applied over the whole image. This layer is set to 15% -of opacity. - -@item Layer 5: Pattern (Stripes) - -This layer is above @samp{Pattern (Paper)} and contains the stripes -used over the artistic motif. This layer do masks the artistic motif -so the stripes are only applied to it. This layer is set to 10% of -opacity. - -@item Layer 6: Shadow#3 - -This layer is above @samp{Pattern (Stripes)} and contains a linear -gradient from right (6600ff) to left (transparent). This layer masks -the artistic motif so the linear gradient doesn't affect it. This -layer is set to 15% of opacity. - -@item Layer 7: Shadow#4 - -This layer is above @samp{Shadow#3} and contains a -linear gradient from left (000000) to right (transparent). This layer -do masks the artistic motif so the linear gradient doesn't affect it. -This layer is set to 10% of opacity. - -@item Layer 8: Color#1 - -This layer is above @samp{Shadow#4} and is filled with orange (ffae00) -color over the whole image. This layer is set to 10% of opacity. - -@item Layer 9: Color#2 - -This layer is above @samp{Color#1} and is filled with -blue (010a88) color over the whole image. This layer is set to 10% of -opacity. - -@end table - -@quotation -@strong{Note} There is no definite combination. To get the appropriate -visual design is a matter of constant testing and personal taste. -@end quotation - -Finally, use @samp{Save as copy ...} option to export the final -design. To export the final design use the same name of your vectorial -design plus @samp{-final.png} extension. - -You can repeat these steps to create images for other screen -resolutions. - -@subsubsection Anaconda Prompt (syslinux) background - -When building syslinux backgrounds it is needed to take into account -that the final image is reduced to 16 colors. In desktop background -there is no color limitation but syslinux does have. The goal of this -section is achieving a final syslinux background as close as possible -to desktop backgrounds using 16 colors only. - -Another point to consider is the forground and background definition -used by syslinux. The syslinux documentation says that the color set -in position 0 is the background and color set in position 7 is the -forground. The final palette of color used by our background will -match that specification. For great contrast we'll use black as -background and white as forground. At this poing we have black -(000000) and white (ffffff) colors in our syslinux palette, which left -us with 14 colors to play with. - -Let's begin with @file{Xcf/640x300.xcf} layer distribution from bottom -to top: - -@table @strong -@item Layer 1: Background - -This layer is the lowest layer in the image composition and contains -the artistic motif image rendered for the same resolution (i.e., -@file{Img/Png/640x300.png}). This layer is set to 100% of opacity. - -@item Layer 2: Pattern (Paper) - -This layer is placed above @samp{Background} layer and contains the -paper pattern shipped with GIMP 2.2. This layer doesn't mask the -artistic motif. This layer is set to 30% of opacity. - -@item Layer 3: Pattern (Stripes) - -This layer is placed above @samp{Pattern (Paper)} layer and contains -the stripes pattern shipped with GIMP 2.2. This layer does mask the -artistic motif in order to apply the stripes over it only. The -background is not affected by the stripes pattern just the artistic -motif. This layer is set to 20% of opacity. - -@item Layer 4: Shadow#1 - -This layer is placed above @samp{Pattern (Stripes)} layer and fills -the entire layer area with violet (6600ff) color. This layer do mask -the artistic motif in order to applied the violet color to the -background area outside the artistic motif only. This layer is set to -15% of opacity. - -@item Layer 5: Color#1 - -This layer is above @samp{Shadow#1} and is filled with orange (ffae00) -color to cover the whole image. This layer is set to 10% of opacity. - -@item Layer 6: Color#2 - -This layer is above @samp{Color#1} and is filled with blue (010a88) -color to cover the whole image. This layer is set to 10% of opacity. - -@item Layer 7: Shadow#2 - -This layer is above @samp{Color#1} and contains a linear gradient from -left (000000) to right (transparent) covering 70% of the image -approximately. - -@end table - -At this point we have the composition and should look like the desktop -backgrounds. Compared with desktop backgrounds there are some -differences in opacity. This is because in our testings the final -color information found with this composition produces an acceptable -16 color image. Of course this is something we haven't seen yet. - -To define the color information of our current coposition, save the -syslinux background composition we've done using @samp{File > Save as -Copy ...} option in the following location: - -@verbatim -trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png -@end verbatim - -Now, create the final png version of syslinux backgrounds using the -following command: - -@verbatim -centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt -@end verbatim - -This command will create syslinux-splash final images for all major -releases of CentOS distribution the repository has been configured to. -The important files here are @file{syslinux-splash.png}, other -files may contain the wrong information because we haven't defined yet -the correct color information to use. - -Open one @file{syslinux-splash.png} file with GIMP and use the -@samp{Image > Mode > Indexed} to reduce image colors up to 16 colors, -using the @samp{Generate optimum palette} feature of GIMP. If the -image looks aceptable after reducing colors, use the @samp{Palettes} -menu (Ctrl+P) of GIMP to import a new palette from file and name it -@samp{CentOS-TreeFlower-Syslinux}. Once you've saved the palette, the -color information is stored at: - -@verbatim -~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl -@end verbatim - -You need to edit @file{CentOS-TreeFlower-Syslinux.gpl} file in order -to set the appropriate order of colors. Remember black (000000) in -position 0, and white (ffffff) in position 7. Other positions are -irrelevant. When editing this file you may find that color reduction -did not set black and white colors to their respective values exactly. -Change that manually. For example, consider the following palette: - -@verbatim -GIMP Palette -Name: CentOS-TreeFlower-Syslinux -Columns: 16 -# - 0 0 0 Background (black) - 23 20 35 Untitled - 34 25 48 Untitled - 37 35 60 Untitled - 47 36 68 Untitled - 37 54 86 Untitled - 60 48 90 Untitled -255 255 255 Foreground (white) - 66 54 99 Untitled - 74 61 98 Untitled - 49 78 126 Untitled - 43 87 151 Untitled - 92 89 95 Untitled - 54 104 183 Untitled -158 153 156 Untitled -201 196 195 Untitled -@end verbatim - -Update the @samp{Palettes} menu to get the new color positions from -the file you just edited and open the palette with double click. - -Update the @file{syslinux.gpl} file copying the following file: - -@verbatim -~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl -@end verbatim - -to - -@verbatim -trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl -@end verbatim - -With the @samp{CentOS-TreeFlower-Syslinux} palette opened in the -@samp{Palette Editor}, open (Ctrl+O) the following file: - -@verbatim -trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm -@end verbatim - -and replace its color information with that one in -@samp{CentOS-TreeFlower-Syslinux} palette. When you are replacing -color information inside @file{syslilnux.ppm}, remember to keep the -order of colors just as they are in the -@samp{CentOS-TreeFlower-Palette} palette. - -The @file{syslinux.ppm} file is 16 pixels width and 1 pixel height, so -you probably need to zoom it a bit to set the color information in -their place when using the pen tool with the brush @samp{Circle (01) -(1 x 1)}. - -Once you've updated the @samp{syslinux.ppm} file, it is time to update -the following file: - -@verbatim -trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex -@end verbatim - -The @file{syslinux.hex} file contains the color information in -hexadecimal notation. The color information in hexadecimal notation -is required by @command{ppmtolss16} command. The @command{ppmtolss16} -command produces the final LSS16 image format that is used by syslinux -program inside CentOS distribution. - -The color information inside @file{syslinux.hex} must match the one in -@file{syslinux.ppm} and @file{syslinux.gpl}. For example, based on -@file{CentOS-TreeFlower-Syslinux} palette of colors above, consider -the following @file{syslinux.hex} file: - -@verbatim -#000000=0 -#171423=1 -#221930=2 -#25233c=3 -#2f2444=4 -#253656=5 -#3c305a=6 -#ffffff=7 -#423663=8 -#4a3d62=9 -#314e7e=10 -#2b5797=11 -#5c595f=12 -#3668b7=13 -#9e999c=14 -#c9c4c3=15 -@end verbatim - -@subsubsection Grub background - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi b/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi deleted file mode 100644 index 9cf9a6e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Identity/Widgets.texi +++ /dev/null @@ -1,14 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales.texi b/Manuals/Repository/Filesystem/trunk/Locales.texi deleted file mode 100644 index 98a4746..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales.texi +++ /dev/null @@ -1,56 +0,0 @@ -The @file{trunk/Locales} directory exists to store the translation -messages used to produce content in different languages. - -Translation messages are organized using the directory structure of -the component being translated. For example, if we want to provide -translation messages for @file{trunk/Manuals/Filesystem}, then the -@file{trunk/Locales/Manuals/Filesystem} directory needs to be created. - -Once the locale directory exists for the component we want to provide -translation messages for, it is necessary to create the translation -files where translation messages are. The translation files follows -the concepts of @command{xml2po} and GNU @command{gettext} tools. - -The basic translation process is as follow: first, translatable -strings are extracted from files and a portable object template (.pot) -is created or updated with the information. Using the portable object -template, a portable object (.po) is created or updated for translator -to locale the messages retrived. Finally, a machine object (.mo) is -created from portable object to sotore the translated messages. - -Inside the repository there are two ways to retrive translatable -strings from files. The first one is through @command{xml2po} command -and the second through @command{xgettext} command. The @command{xml2po} -is used to retrive translatable strings from XML files (e.g., Scalable -Vector Graphics, DocBook, etc.) and the @command{xgettext} command is -used to retrive translatable strings from shell scripts files (e.g., -the files that make the @command{centos-art.sh} command-line -interface). - -When translatable strings are retrived from XML files, using the -@command{xml2po} command, there is no need to create the machine -object as we do when translatable strings ar retrived from shell -files, using the @command{xgettext} command. The @command{xml2po} -produces a temporal machine object in order to create a translated XML -file. Once the translated XML file has been created the machine object -is no longer needed. On the other hand, the machine object produced by -the @command{xgettext} command is required by the system in order for -the show shell script localized messages. - -Another difference between @command{xml2po} and @command{xgettext} we -need to be aware of is the directory structure used to store machine -objects. In @command{xml2po}, the machine object is created in the -current working directory as @file{.xml2po.mo} and can be safetly -removed once the translated XML file has been created. In the case of -@command{xgettext}, the machine object needs to be stored in the -@file{$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo} file in order -for the system to interpret it and should not be removed since it is -the file that contain the translation messages themselves. - -Automation of localization tasks is achived through the @code{locale} -functionality of command-line interface. - -@menu -* trunk Scripts Bash Cli Functions Locale:: -@end menu - diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi deleted file mode 100644 index 5bf1b70..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity.texi +++ /dev/null @@ -1,29 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@comment --- Removed(* trunk Translations Identity Brands::) --- -@comment --- Removed(* trunk Translations Identity Fonts::) --- -@comment --- Removed(* trunk Translations Identity Models::) --- -@comment --- Removed(* trunk Translations Identity Release::) --- -@comment --- Removed(* trunk Translations Identity Themes::) --- -@comment --- Removed(* trunk Translations Identity Widgets::) --- -* trunk Identity:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi deleted file mode 100644 index 6f771ef..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands.texi +++ /dev/null @@ -1,105 +0,0 @@ -@subsection Goals - -@itemize -@item Organize brands' translation files. -@end itemize - -@subsection Description - -Translation files, inside @file{trunk/Translations/Identity/Brands} -translation entry, don't use default rendering translation -functionality, they use the following translation pre-rendering -configuration file instead: - -@verbatim -/home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh -@end verbatim - -Inside @file{trunk/Translations/Identity/Brands} translation entry, -translation files are symbolic links pointing to the common template -translation structure, inside the translation template (@samp{Tpl/}) -directory. - -Inside @file{trunk/Translations/Identity/Brands} translation entry, -translation files are created using identity design templates as -reference. The translation pre-rendering script creates a translation -structure where the translation template (@samp{Tpl/}) directory -structure applies to each single design template available. - -For example, if the brands' translation template (@samp{Tpl/}) -directory has 30 translation files, and there are 20 design templates; -the brands' translation pre-rendering script creates a translation -structure of symbolic links where the 30 translation files apply the -20 design templates one by one, producing 600 translation symbolic -links as result. At this point, when rendering identity, the -@command{centos-art} script considers translation symbolic links as -translation files. - -Translation file names, inside brands' translation template -(@samp{Tpl}) directory have special meaning: - -@subsubsection Conventional file names -@cindex Translation brands file names - -Convenctional file names look like @file{blue.sed}, @file{2c-a.sed}, -etc. Replacement commands inside translation file are applied to -design templates and translation file names are used as final image -name. The image dimensions use the same dimensions that design -template has. - -@subsubsection Numeric file names -@cindex Translation brands file names - -Numeric file names look like @file{300.sed}, @file{200.sed}, etc. -Replacements commands inside translation files are applied to design -templates, and translation file names are used as final image name. -The final image is saved using an specific @samp{width} defined by the -number part of the translation file name. The image @samp{height} is -automatically scaled based on the previous @samp{width} definition to -maintain the designing ratio. - -For example, if your design template has 400x200 pixels of dimension, -and you apply a translation file named `300.sed' to it, the final -image you get as result will have 300x100 pixels of dimension. The -same is true if you use higher numbers like `1024.sed', `2048.sed', -etc. In these cases you have bigger images proportionally. - -As we are using scalable vector graphics to design identity templates, -the image size you produce is not limitted in size. You can use one -design template produced in 400x200 pixels to produce larger or -shorter PNG images using numeric translation files as described -above. - -@subsubsection Translation markers - -Inside @file{trunk/Translations/Identity/Brands/}, translation files -combine the following translation markers: - -@table @samp -@item #000000 - -Specify which color to use when rendering brand images. - -@quotation -@strong{Note} As translation files inside -@file{trunk/Translations/Identity/Brands} are symbolic links that -point to template translation files, translation markers are defined -inside template translation files. -@end quotation -@end table - -@subsection Usage -@cindex How to render brands' translation files - -To render brands' translation files, use the following command: - -@verbatim -centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands -@end verbatim - -@subsection See also - -@menu -@comment --- Removed(* trunk Translations Identity Brands Tpl::) --- -* trunk Identity Brands:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi deleted file mode 100644 index b53171e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Brands/Tpl.texi +++ /dev/null @@ -1,10 +0,0 @@ -@subsection Goals - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi deleted file mode 100644 index 2699334..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Fonts.texi +++ /dev/null @@ -1,62 +0,0 @@ -@subsection Goals - -This section exists to organize fonts translation files. -@subsection Description - -Translation files, inside @file{trunk/Translations/Fonts}, have the -following structure: - -@verbatim -s!font-family:Denmark!font-family:DejaVu LGC Sans! -s!font-weight:normal!font-weight:bold! -s!font-style:normal!font-style:italic! -@end verbatim - -Inside @file{trunk/Translations/Fonts}, there is one translation file -for each font preview image you want to produce. This way, we create -one translation file for each font-family we use somewhere inside -CentOS visual identity. - -@quotation -@strong{Important} Do not create translation files for -font-families not used somewhere inside CentOS visual identity. The -identity of font entry (@pxref{trunk Identity Fonts}) is used as -reference when someone needs to know which font-families are allowed -to use inside CentOS visual identity. -@end quotation - -@subsubsection Translation Markers - -Inside @file{trunk/Translations/Identity/Fonts}, translation files -combine the following translation markers: - -@table @samp -@item font-family:Denmark -Specify which font family to use when rendering font preview images. -@item font-weight:normal -Specify which font weight to use when rendering font preview images. -@item font-style:normal -Specify which font style to use when rendering font preview images. -@end table - -@subsection Usage -@cindex How to render fonts' translation files - -Inside @file{trunk/Translations/Fonts} you use your favorite text -editor to create translation files. Inside -@file{trunk/Translations/Fonts} there is not translation template -directory (@file{Tpl/}), nor translation rendering using -@command{centos-art} script. For example, to create the -@file{dejavu_lgc_sans-boldoblique.sed} translation file using -@command{vim} editor, type the following command: - -@verbatim -vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed -@end verbatim - -@subsection See also - -@menu -* trunk Identity Fonts:: -@end menu - diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi deleted file mode 100644 index b53171e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Models.texi +++ /dev/null @@ -1,10 +0,0 @@ -@subsection Goals - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi deleted file mode 100644 index b53171e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Release.texi +++ /dev/null @@ -1,10 +0,0 @@ -@subsection Goals - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi deleted file mode 100644 index b53171e..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes.texi +++ /dev/null @@ -1,10 +0,0 @@ -@subsection Goals - -@subsection Description - -@subsection Usage - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Backgrounds.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi deleted file mode 100644 index f2d99e2..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi +++ /dev/null @@ -1,94 +0,0 @@ -@subsection Goals - -@itemize -@item Organize Anaconda progress translation templates. -@item Organize Anaconda progress translation files in several -languages and major releases of CentOS distribution. -@end itemize - -@subsection Description - -Use the following command to produce translation files based: - -@example -trunk/Translations/Identity/Themes/Distro/Anaconda/Progress -`-- Tpl - |-- en - | |-- 01-welcome.sed - | |-- 02-donate.sed - | `-- 03-yum.sed - `-- es - |-- 01-welcome.sed - |-- 02-donate.sed - `-- 03-yum.sed -@end example - -In order to produce the slide images in PNG format we need to have the -translation files first. So we use the following commands to create -translation files for CentOS 3, 4, and 5 major releases: - -@example -centos-art render --translation --filter='3,4,5' -@end example - -The above commands will produce the following translation structure: - -@example -trunk/Translations/Identity/Themes/Distro/Anaconda/Progress -|-- 3 -| |-- en -| | |-- 01-welcome.sed -| | |-- 02-donate.sed -| | `-- 03-yum.sed -| `-- es -| |-- 01-welcome.sed -| |-- 02-donate.sed -| `-- 03-yum.sed -|-- 4 -| |-- en -| | |-- 01-welcome.sed -| | |-- 02-donate.sed -| | `-- 03-yum.sed -| `-- es -| |-- 01-welcome.sed -| |-- 02-donate.sed -| `-- 03-yum.sed -|-- 5 -| |-- en -| | |-- 01-welcome.sed -| | |-- 02-donate.sed -| | `-- 03-yum.sed -| `-- es -| |-- 01-welcome.sed -| |-- 02-donate.sed -| `-- 03-yum.sed -`-- Tpl - |-- en - | |-- 01-welcome.sed - | |-- 02-donate.sed - | `-- 03-yum.sed - `-- es - |-- 01-welcome.sed - |-- 02-donate.sed - `-- 03-yum.sed -@end example - -At this point we have all the translation files we need to produce -Anaconda progress welcome, donate and yum slides images; in English -and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is, -a sum of 18 images around. - -Now, with translation files in place, let's move to -@file{trunk/Identity} structure and render them. - -@itemize -@item @xref{trunk Identity Themes Motifs Modern Distro Anaconda Progress}. -@end itemize - -@subsection Usage - -Translation rendering is described in @samp{trunk/Translations} -documentation entry (--- @strong{Removed}(pxref:trunk Translations) ---). - - -@subsection See also diff --git a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi b/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi deleted file mode 100644 index fda4863..0000000 --- a/Manuals/Repository/Filesystem/trunk/Locales/Identity/Widgets.texi +++ /dev/null @@ -1,23 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@comment --- Removed(* trunk Translations Identity Widgets::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Manuals.texi b/Manuals/Repository/Filesystem/trunk/Manuals.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Manuals.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts.texi b/Manuals/Repository/Filesystem/trunk/Scripts.texi deleted file mode 100644 index c9b371f..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts.texi +++ /dev/null @@ -1,25 +0,0 @@ -@subsection Goals - -The @file{trunk/Scripts} directory exists to: - -@itemize -@item Organize the ``trunk'' development line of automation scripts by -programming language. -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi deleted file mode 100644 index 0b387e6..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash.texi +++ /dev/null @@ -1,156 +0,0 @@ -@subsection Goals - -The @file{trunk/Scripts/Bash} directory exists to organize the trunk -development line of @file{centos-art.sh} automation script. The -@file{centos-art.sh} script standardizes frequent tasks inside your -working copy of CentOS Artwork Repository. - -@subsection 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 (--- @strong{Removed}(pxref:trunk Scripts Bash Functions -Verify) ---), 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 -executing the @file{trunk/Scripts/Bash/initEnvironment.sh} script to -initialize global variables (e.g., @command{gettext} variables) and -global function scripts. Global function scripts are located inside -@file{trunk/Scripts/Bash/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 (--- @strong{Removed}(pxref:trunk Scripts Bash Functions) ---). - -As convenction, the @file{centos-art.sh} command-line arguments have -the following format: - -@verbatim -centos-art arg1 --arg2=val2 --arg3=val3 -@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,fig:trunk/Scripts/Bash:Initialization -@verbatim -+----------------------------------------------------------------------+ -| [centos@host]$ centos-art function --action='value' --option='value' | -+----------------------------------------------------------------------+ -| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh | -+---v-----------------------------------------v------------------------+ - | centos-art.sh | - +---v---------------------------------v---+ - . | initEnvironment.sh | . - . +---------------------------------+ . - . | cli $@ | . - . +---v-------------------------v---+ . - . . | cli_getFunctions | . . - . . +---v-----------------v---+ . . - . . . | function1 | . . . - . . . | function2 | . . . - . . . | function3 | . . . - . . . +-----------------+ . . . - . . ........................... . . - . ................................... . - ........................................... -@end verbatim -@caption{The 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. - -@float Figure,fig:trunk/Scripts/Bash/Functions:Initialization -@verbatim -+--------------------------------------+ -| cli_getFunctions | -+---v------------------------------v---+ -. | function1 | . -. +---v----------------------v---+ . -. . | function1_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . -. ................................ . -. +------------------------------+ . -. | function2 | . -. +---v----------------------v---+ . -. . | function2_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . -. ................................ . -. +------------------------------+ . -. | function3 | . -. +---v----------------------v---+ . -. . | function3_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . -. ................................ . -........................................ -@end verbatim -@caption{The actions initialization environment.} -@end float - -@subsection Usage - -The @file{centos-art.sh} script usage information is described inside -each specific function documentation (--- @strong{Removed}(pxref:trunk Scripts Bash -Functions) ---). - -@subsection See also - -@menu -* trunk Scripts:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@comment --- Removed(* trunk Scripts Bash Locale::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi deleted file mode 100755 index e69de29..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli.texi +++ /dev/null diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi deleted file mode 100755 index 2a421ab..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions.texi +++ /dev/null @@ -1,1222 +0,0 @@ -@subsection Goals - -The @file{trunk/Scripts/Bash/Functions} directory exists to organize -@file{centos-art.sh} specific functionalities. - -@subsection Description - -The specific functions of @file{centos-art.sh} script are designed -with ``Software Toolbox'' philosophy (@pxref{Toolbox -introduction,,,coreutils.info}) in mind: each program ``should do one -thing well''. Inside @file{centos-art.sh} script, each specific -functionality is considered a program that should do one thing well. -Of course, if you find that they still don't do it, feel free to -improve them in order for them to do so. - -The specific functions of @file{centos-art.sh} script are organized -inside specific directories under @file{trunk/Scripts/Bash/Functions} -location. Each specific function directory should be named as the -function it represents, with the first letter in uppercase. For -example, if the function name is @code{render}, the specific function -directory for it would be @samp{trunk/Scripts/Bash/Functions/Render}. - -To better understand how specific functions of @file{centos-art.sh} -script are designed, lets create one function which only goal is to -output different kind of greetings to your screen. - -When we create specific functions for @file{centos-art.sh} script it -is crucial to know what these functions will do exactly and if there -is any function that already does what we intend to do. If there is no -one, it is good time to create them then. Otherwise, if -functionalities already available don't do what you exactly expect, -contact their authors and work together to improve them. - -@quotation -@strong{Tip} Join CentOS developers mailing list -@email{centos-art@@centos.org} to share your ideas. -@end quotation - -It is also worth to know what global functions and variables do we -have available inside @file{centos-art.sh} script, so advantage can be -taken from them. Global variables are defined inside global function -scripts. Global functions scripts are stored immediatly under -@file{trunk/Scripts/Bash/Functions} directory, in files begining with -@samp{cli} prefix. - -OK, let's begin with our functionality example. - -What function name do we use? Well, lets use @code{greet}. Note that -@samp{hello} word is not a verb; but an expression, a kind of -greeting, an interjection specifically. In contrast, @samp{greet} is a -verb and describes what we do when we say @samp{Hello!}, @samp{Hi!}, -and similar expressions. - -So far, we've gathered the following function information: - -@verbatim -Name: greet -Path: trunk/Scripts/Bash/Functions/Greet -File: trunk/Scripts/Bash/Functions/Greet/greet.sh -@end verbatim - -The @file{greet.sh} function script is the first file -@file{centos-art.sh} script loads when the @samp{greet} functionality -is called using commands like @samp{centos-art greet --hello='World'}. -The @file{greet.sh} function script contains the @code{greet} function -definition. - -Inside @file{centos-art.sh} script, as convenction, each function -script has one top commentary, followed by one blank line, and then -one function defintion below it only. - -Inside @file{centos-art.sh} script functions, top commentaries have -the following components: the functionality description, one-line for -copyright note with your personal information, the license under -which the function source code is released ---the @file{centos-art.sh} -script is released as GPL, so do all its functions---, the @code{$Id$} -keyword of Subversion is later expanded by @command{svn propset} -command. - -In our @code{greet} function example, top commentary for -@file{greet.sh} function script would look like the following: - -@verbatim -#!/bin/bash -# -# greet.sh -- This function outputs different kind of greetings to -# your screen. Use this function to understand how centos-art.sh -# script specific functionalities work. -# -# Copyright (C) YEAR YOURFULLNAME -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, but -# WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 -# USA. -# -# ---------------------------------------------------------------------- -# $Id$ -# ---------------------------------------------------------------------- -@end verbatim - -After top commentary, separated by one blank line, the @code{greet} -function definition would look like the following: - -@verbatim -function greet { - - # Define global variables. - - # Define command-line interface. - greet_getActions - -} -@end verbatim - -The first definition inside @code{greet} function, are global -variables that will be available along @code{greet} function execution -environment. This time we didn't use global variable definitions for -@code{greet} function execution environment, so we left that section -empty. - -Later, we call @code{greet_getActions} function to define the -command-line interface of @code{greet} functionality. The command-line -interface of @code{greet} functionality defines what and how actions -are performed, based on arguments combination passed to -@file{centos-art.sh} script. - -@verbatim -function greet_getActions { - - case "$ACTIONNAM" in - - --hello ) - greet_doHello - ;; - - --bye ) - greet_doBye - ;; - - * ) - cli_printMessage "`gettext "The option provided is not valid."`" - cli_printMessage "$(caller)" 'AsToKnowMoreLine' - - esac - -} -@end verbatim - -The @var{ACTIONNAM} global variable is defined in @file{cli.sh} -function script and contains the value passed before the equal sign -(i.e., @samp{=}) in the second command-line argument of -@file{centos-art.sh} script. For example, if the second command-line -argument is @option{--hello='World'}, the value of @var{ACTIONNAM} -variable would be @samp{--hello}. Using this configuration let us -deside which action to perform based on the action name passed to -@file{centos-art.sh} script as second argument. - -The @code{greet} function definition makes available two valid -greetings through @option{--hello} and @option{--bye} options. If no -one of them is provided as second command-line argument, the @samp{*} -case is evaluated instead. - -The @samp{*} case and its two lines further on should always be -present in @file{_getActions.sh} function scripts, no matter what -specific functionality you are creating. This convenction helps the -user to find out documentation about current functionality in use, -when no valid action is provided. - -The @code{greet_doHello} and @code{greet_doBye} function definitions -are the core of @code{greet} specific functionality. In such function -definitions we set what our @code{greet} function really does: to -output different kinds of greetings. - -@verbatim -function greet_doHello { - - cli_printMessage "`gettext "Hello"` $ACTIONVAL" - -} -@end verbatim - -The @code{greet_doHello} function definition is stored in -@file{greet_doHello.sh} function script. - -@verbatim -function greet_doBye { - - cli_printMessage "`gettext "Goodbye"` $ACTIONVAL" - -} -@end verbatim - -The @code{greet_doBye} function definition is stored in the -@file{greet_doBye.sh} function script. - -Both @file{greet_doHello.sh} and @file{greet_doBye.sh} function -scripts are stored inside @code{greet} function directory path (i.e. -@file{trunk/Scripts/Bash/Functions/Greet}). - -The @var{ACTIONVAL} global variable is defined in @file{cli.sh} -function script and contains the value passed after the equal sign -(i.e., @samp{=}) in the second command-line argument of -@file{centos-art.sh} script. For example, if the second command-line -argument is @option{--hello='World'}, the value of @var{ACTIONVAL} -variable would be @samp{World} without quotes. - -Let's see how @code{greet} specific functionality files are organzied -under @code{greet} function directory. To see file organization we use -the @command{tree} command: - -@verbatim -trunk/Scripts/Bash/Functions/Greet -|-- greet_doBye.sh -|-- greet_doHello.sh -|-- greet_getActions.sh -`-- greet.sh -@end verbatim - -To try the @code{greet} specific functionality we've just created, -pass the function name (i.e., @samp{greet}) as first argument to -@file{centos-art.sh} script, and any of the valid options as second -argument. Some examples are illustrated below: - -@verbatim -[centos@projects ~]$ centos-art greet --hello='World' -Hello World -[centos@projects ~]$ centos-art greet --bye='World' -Goodbye World -[centos@projects ~]$ -@end verbatim - -The word @samp{World} in the examples above can be anything. In fact, -change it to have a little fun. - -Now that we have a specific function that works as we expect, it is -time to document it. To document @code{greet} specific functionality, -we use its directory path and the @code{manual} functionality -(--- @strong{Removed}(pxref:trunk Scripts Bash Functions Manual) ---) of @file{centos-art.sh} -script, just as the following command illustrates: - -@verbatim -centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet -@end verbatim - -To have a well documented function helps user to understand how your -function really works, and how it should be used. When no valid -action is passed to a function, the @file{centos-art.sh} script uses -the function documentation entry as vehicle to communicate which the -valid functions are. When no documentation entry exists for a -function, the @file{centos-art.sh} script informs that no -documentation entry exists for such function and requests user to -create it right at that time. - -Now that we have documented our function, it is time to translate its -output messages to different languages. To translate specific -functionality output messages to different languages we use the -@code{locale} functionality (--- @strong{Removed}(pxref:trunk Scripts Bash Functions -Locale) ---) of @file{centos-art.sh} script, just as the following command -illustrates: - -@verbatim -centos-art locale --edit -@end verbatim - -@quotation -@strong{Warning} To translate output messages in different languages, -your system locale information ---as in @env{LANG} environment -variable--- must be set to that locale you want to produce translated -messages for. For example, if you want to produce translated messages -for Spanish language, your system locale information must be set to -@samp{es_ES.UTF-8}, or similar, first. -@end quotation - -Well, it seems that our example is rather complete by now. - -In @code{greet} function example we've described so far, we only use -@command{cli_printMessage} global function in action specific function -definitions in order to print messages, but more interesting things -can be achieved inside action specific function definitions. For -example, if you pass a directory path as action value in second -argument, you could retrive a list of files from therein, and process -them. If the list of files turns too long or you just want to control -which files to process, you could add the third argument in the form -@option{--filter='regex'} and reduce the amount of files to process -using a regular expression pattern. - -The @code{greet} function described in this section may serve you as -an introduction to understand how specific functionalities work inside -@file{centos-art.sh} script. With some of luck this introduction will -also serve you as motivation to create your own @file{centos-art.sh} -script specific functionalities. - -By the way, the @code{greet} functionality doesn't exist inside -@file{centos-art.sh} script yet. Would you like to create it? - -@subsection Usage - -@subsubsection Global variables - -The following global variables of @file{centos-art.sh} script, are -available for you to use inside specific functions: - -@defvar TEXTDOMAIN -Default domain used to retrieve translated messages. This value is set -in @file{initFunctions.sh} and shouldn't be changed. -@end defvar - -@defvar TEXTDOMAINDIR -Default directory used to retrieve translated messages. This value is -set in @file{initFunctions.sh} and shouldn't be changed. -@end defvar - -@defvar FUNCNAM -Define function name. - -Function names associate sets of actions. There is one set of actions -for each unique function name inside @file{centos-art.sh} script. - -Dunction names are passed as first argument in @file{centos-art.sh} -command-line interface. For example, in the command @samp{centos-art -render --entry=path/to/dir --filter=regex}, the @var{ACTION} passed to -@file{centos-art.sh} script is @option{render}. - -When first argument is not provided, the @file{centos-art.sh} script -immediatly ends its execution. -@end defvar - -@defvar FUNCDIR -@end defvar - -@defvar FUNCDIRNAME -@end defvar - -@defvar FUNCSCRIPT -@end defvar - -@defvar FUNCCONFIG -@end defvar - -@defvar ACTIONNAM -Define action name. - -Each action name identifies an specific action to perform, inside an -specific function. - -Action name names aare passed as second argument in -@file{centos-art.sh} command-line interface. For example, in the -command @samp{centos-art render --entry=path/to/dir --filter=regex}, -the @var{ACTIONNAM} passed to @file{centos-art.sh} script is -@option{--entry}. - -When second argument is not provided, the @file{centos-art.sh} script -immediatly ends its execution. -@end defvar - -@defvar ACTIONVAL -Define action value. - -Action values are associated to just one action name. Action values -contain the working copy entry over which its associated action will be -performed in. Working copy entries can be files or directories inside -the working copy. -@end defvar - -@defvar REGEX -Define regular expression used as pattern to build the list of files -to process. - -By default, @var{REGEX} variable is set to @code{.+} to match all -files. - -Functions that need to build a list of files to process use the option -@option{--filter} to redefine @var{REGEX} variable default value, and -so, control the amount of files to process. -@end defvar - -@defvar ARGUMENTS -Define optional arguments. - -Optional arguments, inside @file{centos-art.sh} script, are considered -as all command-line arguments passed to @file{centos-art.sh} script, -from third argument position on. For example, in the command -@samp{centos-art render --entry=path/to/dir --filter=regex} , the -optional arguments are from @samp{--filter=regex} argument on. - -Optional arguments are parsed using @command{getopt} command through -the following base construction: - -@verbatim -# Define short options we want to support. -local ARGSS="" - -# Define long options we want to support. -local ARGSL="filter:,to:" - -# Parse arguments using getopt(1) command parser. -cli_doParseArguments - -# Reset positional parameters using output from (getopt) argument -# parser. -eval set -- "$ARGUMENTS" - -# Define action to take for each option passed. -while true; do - case "$1" in - --filter ) - REGEX="$2" - shift 2 - ;; - --to ) - TARGET="$2" - shift 2 - ;; - * ) - break - esac -done -@end verbatim - -Optional arguments provide support to command options inside -@file{centos-art.sh} script. For instance, consider the Subversion -(@command{svn}) command, where there are many options (e.g., -@option{copy}, @option{delete}, @option{move}, etc), and inside each -option there are several modifiers (e.g., @samp{--revision}, -@samp{--message}, @samp{--username}, etc.) that can be combined one -another in their short or long variants. - -The @var{ARGUMENTS} variable is used to store arguments passed from -command-line for later use inside @file{centos-art.sh} script. Storing -arguments is specially useful when we want to run a command with some -specific options from them. Consider the following command: - -@verbatim -centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe' -@end verbatim - -In the above command, the @option{--message}, and @option{--username} -options are specific to @command{svn copy} command. In such cases, -options are not interpreted by @file{centos-art.sh} script itself. -Instead, the @file{centos-art.sh} script uses @command{getopt} to -retrive them and store them in the @var{ARGUMENTS} variable for later -use, as described in the following command: - -@verbatim -# Build subversion command to duplicate locations inside the -# workstation. -eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS -@end verbatim - -When @command{getopt} parses @var{ARGUMENTS}, we may use short options -(e.g., @option{-m}) or long options (e.g., @option{--message}). When -we use short options, arguments are separated by one space from the -option (e.g., @option{-m 'This is a commit message.'}). When we use -long options arguments are separated by an equal sign (@samp{=}) -(e.g., @option{--message='This is a commit message'}). - -In order for @command{getopt} to parse @var{ARGUMENTS} correctly, it -is required to provide the short and long definition of options that -will be passed or at least supported by the command performing the -final action the function script exists for. - -As convenction, inside @file{centos-art.sh} script, short option -definitions are set in the @var{ARGSS} variable; and long option -definitions are set in the @var{ARGSL} variable. - -When you define short and long options, it may be needed to define -which of these option arguments are required and which not. To define -an option argument as required, you need to set one colon @samp{:} -after the option definition (e.g., @option{-o m: -l message:}). On -the other hand, to define an option argument as not required, you need -to set two colons @samp{::} after the option definition (e.g., -@option{-o m:: -l message::}). -@end defvar - -@defvar 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. - -If @env{EDITOR} environment variable is not set, @file{centos-art.sh} -script uses @file{/usr/bin/vim} as default text editor. Otherwise, the -following values are recognized by @file{centos-art.sh} script: - -@itemize -@item @file{/usr/bin/vim} -@item @file{/usr/bin/emacs} -@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. -@end defvar - -@subsubsection Global functions - -Function scripts stored directly under -@file{trunk/Scripts/Bash/Functions/} directory are used to define -global functions. Global functions can be used inside action specific -functionalities and or even be reused inside themselves. This section -provides introductory information to global functions you can use -inside @file{centos-art.sh} script. - -@defun cli_checkActionArguments -Validate action value (@var{ACTIONVAL}) variable. - -The action value variable can take one of the following values: - -@enumerate -@item Path to one directory inside the local working copy, -@item Path to one file inside the local working copy, -@end enumerate - -If another value different from that specified above is passed to -action value variable, the @file{centos-art.sh} script prints an error -message and ends script execution. -@end defun - -@defun cli_checkFiles FILE [TYPE] -Verify file existence. - -@code{cli_checkFiles} receives a @var{FILE} absolute path and performs -file verification as specified in @var{TYPE}. When @var{TYPE} is not -specified, @code{cli_checkFiles} verifies @var{FILE} existence, no -matter what kind of file it be. If @var{TYPE} is specified, use one -of the following values: - -@table @option -@item d -@itemx directory -Ends script execution if @var{FILE} is not a directory. - -When you verify directories with cli_checkFiles, if directory doesn't -exist, @file{centos-art.sh} script asks you for confirmation in order -to create that directory. If you answer positively, -@file{centos-art.sh} script creates that directory and continues -script flows normally. Otherwise, if you answer negatively, -@file{centos-art.sh} ends script execution with an error and -documentation message. - -@item f -@item regular-file -Ends script execution if @var{FILE} is not a regular file. -@item h -@itemx symbolic-link -Ends script execution if @var{FILE} is not a symbolic link. -@item x -@itemx execution -Ends script execution if @var{FILE} is not executable. -@item fh -Ends script execution if @var{FILE} is neither a regular file nor a -symbolic link. -@item fd -Ends script execution if @var{FILE} is neither a regular file nor a -directory. -@item isInWorkingCopy -Ends script execution if @var{FILE} is not inside the working copy. -@end table - -As default behaviour, if @var{FILE} passes all verifications, -@file{centos-art.sh} script continues with its normal flow. -@end defun - -@defun cli_commitRepoChanges [LOCATION] - -Syncronize changes between repository and working copy. - -The @code{cli_commitRepoChanges} function brings changes from the -central repository down to the working copy---using @command{svn -update}---, checks the working copy changes---using @command{svn -status} command---, prints status report---using both @command{svn -update} and @command{svn status} commands output, and finally, commits -recent changes from the working copy up to the repository---using -@command{svn commit} command---. - -Previous to commit the working copy changes up to the central -repository, the @code{cli_commitRepoChanges} function asks you to -verify changes---using @command{svn diff} command---, and later, -another confirmation question is shown to be sure you really want to -commit changes up to central repository. - -If @var{LOCATION} argument is not specified, the value of -@var{ACTIONVAL} variable is used as reference instead. - -@float Figure, trunk/Scripts/Bash/Functions/cli_commitRepoChanges -@verbatim ----------------------------------------------------------------------- ---> Bringing changes from the repository into the working copy ---> Checking changes in the working copy ----------------------------------------------------------------------- -Added 0 file from the repository. -Deleted 0 file from the repository. -Updated 0 file from the repository. -Conflicted 0 file from the repository. -Merged 0 file from the repository. -Modified 4 files from the working copy. -Unversioned 0 file from the working copy. -Deleted 0 file from the working copy. -Added 0 file from the working copy. ----------------------------------------------------------------------- -@end verbatim -@caption{The @code{cli_commitRepoChanges} function output.} -@end float - -Call the @code{cli_commitRepoChanges} function before or/and after -calling functions that modify files or directories inside the working -copy as you may need to. -@end defun - -@defun cli_doParseArguments -Redefine arguments (@var{ARGUMENTS}) global variable using -@command{getopt} command output. For more information about how to use -@code{cli_doParseArguments} function, see @var{ARGUMENTS} variable -description above. -@end defun - -@defun cli_doParseArgumentsReDef $@@ -Initialize/reset arguments (@var{ARGUMENTS}) global variable using -positional parameters variable (@var{$@@}) as reference. - -When we work inside function definitions, positional parameters are -reset to the last function definition positional parameters. If you -need to redefine positional parameters from one specific function, you -need to call @code{cli_doParseArgumentsReDef} with the positional -parameters variable (@var{$@@}), set as first argument, to that -specific function you want to redefine positional parameters at. -@end defun - -@defun cli_getArguments - -Initialize function name (@var{FUNCNAM}), action name -(@var{ACTIONNAM}), and action value (@var{ACTIONVAL}) global -variables, using positional parameters passed in @var{$@@} variable. - -The @code{cli_getArguments} function is called from @code{cli.sh} -function script, using @code{cli} function positional parameters -(i.e., the positional parameters passed as arguments in the -command-line) as first function argument. - -Once command-line positional parameters are accesible to -@file{centos-art.sh} script execution evironment, -@code{cli_getArguments} uses regular expression to retrive -action variables from first and second argument. The first argument -defines the value used as function name (@var{FUNCNAM}), and the -second argument defines both values used as action name -(@var{ACTIONNAM}) and action value (@var{ACTIONVAL}), respectively. - -The first argument is a word in lower case. This word specifies the -name of the functionality you want to use (e.g., @samp{render} to -render images, @samp{manual} to work on documentation, and so on.) - -The second argument has a long option style (e.g., -@samp{--option=value}). The @samp{--option} represents the action name -(@var{ACTIONNAM}), and the characters inbetween the equal sign -(@samp{=}) and the first space character, are considered as the action -value (@var{ACTIONVAL}). In order to provide action values with space -characters inbetween you need to enclose action value with quotes like -in @samp{--option='This is long value with spaces inbetween'}. -Generally, action values are used to specify paths over which the -action name acts on. - -Once action related variables (i.e., @var{FUNCNAM}, @var{ACTIONNAM}, -and @var{ACTIONVAL}) are defined and validated, -@code{cli_getArguments} shifts the positional arguments to remove the -first two arguments passed (i.e., those used to retrive action related -variables) and redefine the arguments (@var{ARGUMENTS}) global -variable with the new positional parameters information. -@end defun - -@defun cli_getFunctions -Initialize funtionalities supported by @file{centos-art.sh} script. - -Functionalities supported by @file{centos-art.sh} script are organized -in functionality directories under -@file{trunk/Scripts/Bash/Functions/} directory. Each functionality -directory stores function scripts to the functionality such directory -was created for. Function scripts contain function definitions. -Function definitions contain several commands focused on achieving one -specific task only (i.e., the one such functionality was created for). - -In order for @file{centos-art.sh} script to recognize a functionality, -such functionality needs to be stored under -@file{trunk/Scripts/Bash/Functions/} in a directory written -capitalized (i.e., the whole name is written in lowercase except the -first character which is in uppercase). The directory where one -specific functionality is stored is known as the @samp{functionality -directory}. - -Inside each functionality directory, the functionalty itself is -implemented through function scripts. Function scripts are organized -in files independently one another and written in @samp{camelCase} -format with the function name as prefix. Separation between prefix -and description is done using underscore (@samp{_}) character. - -In order for @file{centos-art.sh} script to load functionalities -correctly, function definition inside function scripts should be set -using the @samp{function} reserved word, just as in the following -example: - -@verbatim -function prefix_doSomething { - - # Do something here... - -} -@end verbatim - -The above function definition is just a convenction we use, in order -to make identification of function names easier read and automate by -@file{centos-art.sh} script initialization commands, once -@file{centos-art.sh} script determines which functionality directory -to use. Specifically, in order to initialize and export functions, -@file{centos-art.sh} script executes all function scripts inside the -functionality directory, and later @command{grep} on them using a -regular expression pattern, where the @samp{function} reserved word is -used as reference to retrive the function names and export them to -@file{centos-art.sh} script execution environment, and so, make -function definitions ---from function scripts inside the functionality -directory--- available for further calls. - -If the functionality specified in the command-line first argument -doesn't have a functionality directory, @file{centos-art.sh} script -considers the functionality provided in the command-line as invalid -functionality and immediatly stops script execution with an error -message. - -In order to keep visual consistency among function scripts, please -consider using the following function script design model as template -for your own function scripts: - -@verbatim -#!/bin/bash -# -# prefix_doSomething.sh -- This function illustrates function scripts -# design model you can use to create your own function scripts inside -# centos-art.sh script. -# -# Copyright (C) YEAR YOURFULLNAME -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, but -# WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 -# USA. -# -# ---------------------------------------------------------------------- -# $Id$ -# ---------------------------------------------------------------------- - -function prefix_doSomething { - - # Do something here... - -} -@end verbatim -@end defun - -@defun cli_getCountryCodes [FILTER] -Output country codes supported by @file{centos-art.sh} script. - -The @code{cli_getCountryCodes} function outputs a list with country -codes as defined in ISO3166 standard. When @var{FILTER} is provided, -@code{cli_getCountryCodes} outputs country codes that match -@var{FILTER} regular expression pattern. -@end defun - -@defun cli_getCountryName [FILTER] -Outputs country name supported by @file{centos-art.sh} script. - -The @code{cli_getCountryName} function reads one language locale code -in the format LL_CC and outputs the name of its related country as in -ISO3166. If filter is specified, @code{cli_getCountryName} returns the -country name that matches the locale code specified in @var{FILTER}, -exactly. -@end defun - -@defun cli_getCurrentLocale -Output current locale used by @file{centos-art.sh} script. - -The @code{cli_getCurrentLocale} function uses @env{LANG} environment -variable to build a locale pattern that is later applied to -@code{cli_getLocales} function output in order to return the current -locale that @file{centos-art.sh} script works with. - -The current locale information, returned by -@code{cli_getCurrentLocale}, is output from more specific to less -specific. For example, if @samp{en_GB} locale exists in -@code{cli_getLocales} function output, the @samp{en_GB} locale would -take precedence before @samp{en} locale. - -Locale precedence selection is quite important in order to define the -locale type we use for message translations. For example, if -@samp{en_GB} is used, we are also saying that the common language -specification for English language (i.e., @samp{en}) is no longer -used. Instead, we are using English non-common country-specific -language specifications like @samp{en_AU}, @samp{en_BW}, @samp{en_GB}, -@samp{en_US}, etc., for message translations. - -Use @code{cli_getCurrentLocale} function to know what current locale -information to use inside @file{centos-art.sh} script. -@end defun - -@defun cli_getFilesList [LOCATION] -Output list of files to process. - -The @code{cli_getFilesList} function uses @var{LOCATION} variable as -source location to build a list of files just as specified by regular -expression (@var{REGEX}) global variable. Essentially, what the -@code{cli_getFilesList} function does is using @command{find} command -to look for files in the location (@var{LOCATION}) just as posix-egrep -regular expression (@var{REGEX}) specifies. - -If @var{LOCATION} is not specified when @code{cli_getFilesList} -function is called, the action value (@var{ACTIONVAL}) global variable -is used as location value instead. - -By default, if the regular expression (@var{REGEX}) global variable is -not redefined after its first definition in the @code{cli} function, -all files that match default regular expression value (i.e., -@samp{.+}) will be added to the list of files to process. Otherwise, -if you redefine the regular expression global variable after its first -definition in the @code{cli} function and before calling -@code{cli_getFilesList} function, the last value you specifed is used -instead. - -When you need to customize the regular expression (@var{REGEX}) global -variable value inside a function, do not redefine the global variable -(at least you be absolutly convinced you need to). Instead, set the -regular expression global variable as @samp{local} to the function you -need a customized regular expression value for. If we don't redefine -the regular expression global variable as local to the function, or -use another name for the regular expression variable (which is not -very convenient in order to keep the amount of names to remember low), -you may experiment undesired concantenation issues that make your -regular expression to be something different from that you expect them -to be, specially if the function where you are doing the variable -redefinition is called several times during the same script execution. - -As result, the @code{cli_getFilesList} re-defines the value of -@var{FILES} variable with the list of files the @command{find} command -returned. As example, consider the following construction: - -@verbatim -function prefix_doSomething { - - # Initialize the list of files to process. - local FILES='' - - # Initialize location. - local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default - - # Re-define regular expression to match scalable vector graphic - # files only. Note how we use the global value of REGEX to build a - # new local REGEX value here. - local REGEX="${REGEX}.*\.(svgz|svg)" - - # Redefine list of files to process. - cli_getFilesList $LOCATION - - # Process list of files. - for FILE in $FILES;do - cli_printMessages "$FILE" 'AsResponseLine' - # Do something else here on... - done - -} -@end verbatim - -@end defun - -@defun cli_getLangCodes [FILTER] -Outputs language codes supported by @file{centos-art.sh} script. - -@code{cli_getLangCodes} function outputs a list of language codes as -defined in ISO639 standard. When @var{FILTER} is provided, -@code{cli_getLangCodes} outputs language codes that match @var{FILTER} -regular expression pattern. -@end defun - -@defun cli_getLangName [FILTER] -Outputs language names supported by @file{centos-art.sh} script. - -@code{cli_getLangName} function reads one language locale code in the -format LL_CC and outputs the language related name as in ISO639. If -filter is specified, @code{cli_getLangName} returns the language name -that matches the locale code specified in @var{FILTER}, exactly. -@end defun - -@defun cli_getLocales -Output locale codes supported by @file{centos-art.sh} script. - -Occasionally, you use @code{cli_getLocales} function to add locale -information in non-common country-specific language (@samp{LL_CC}) -format for those languages (e.g., @samp{bn_IN}, @samp{pt_BR}, etc.) -which locale differences cannot be solved using common language -specifications (@samp{LL}) into one unique common locale specification -(e.g., @samp{bn}, @samp{pt}, etc.). -@end defun - -@defun cli_getRepoName NAME TYPE -Sanitate file names. - -Inside @file{centos-art.sh} script, specific functionalities rely both -in @code{cli_getRepoName} and repository file system organization to -achieve their goals. Consider @code{cli_getRepoName} function as -central place to manage file name convenctions for other functions -inside @file{centos-art.sh} script. - -@quotation -@strong{Important} @code{cli_getRepoName} function doesn't verify file -or directory existence, for that purpose use @code{cli_checkFiles} -function instead. -@end quotation - -The @var{NAME} variable contains the file name or directory name you -want to sanitate. - -The @var{TYPE} variable specifies what type of sanitation you want to -perform on @var{NAME}. The @var{TYPE} can be one of the following -values: - -@table @option -@item d -@itemx directory -Sanitate directory @var{NAME}s. -@item f -@item regular-file -Sanitate regular file @var{NAME}s. -@end table - -Use @code{cli_getRepoName} function to sanitate file names and -directory names before their utilization. - -Use @code{cli_getRepoName} when you need to change file name -convenctions inside @file{centos-art.sh} script. - -When we change file name convenctions inside @code{cli_getRepoName} -what we are really changing is the way functions interpret repository -file system organization. Notice that when we change a file name -(e.g., a function name), it is necessary to update all files where -such file name is placed on. This may require a massive substitution -inside the repository, each time we change name convenctions in the -repository (--- @strong{Removed}(pxref:trunk Scripts Bash Functions Path) ---, for more -information). -@end defun - -@defun cli_getRepoStatus [LOCATION] -Request repository status. - -This function requests the status of a @var{LOCATION} inside the -working copy using the @command{svn status} command and returns the -first character in the output line, just as described in @command{svn -help status}. If @var{LOCATION} is not a regular file or a directory, -inside the working copy, the @file{centos-art.sh} script prints a -message and ends its execution. - -Use this function to perform verifications based a repository -@var{LOCATION} status. -@end defun - -@defun cli_getTemporalFile @var{NAME} -Output absolute path to temporal file @var{NAME}. - -The @code{cli_getTemporalFile} function uses @file{/tmp} directory as -source location to store temporal files, the @file{centos-art.sh} -script name, and a random identification string to let you run more -than one @file{centos-art.sh} script simultaneously on the same user -session. For example, due the following temporal file defintion: - -@verbatim -cli_getTemporalFile $FILE -@end verbatim - -If @var{FILE} name is @file{instance.svg} and the unique random string -is @samp{f16f7b51-ac12-4b7f-9e66-72df847f12de}, the final temporal -file, built from previous temporal file definition, would be: - -@verbatim -/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg -@end verbatim - -When you use the @code{cli_getTemporalFile} function to create -temporal files, be sure to remove temporal files created once you've -ended up with them. For example, consider the following construction: - -@verbatim -for FILE in $FILES;do - - # Initialize temporal instance of file. - INSTANCE=$(cli_getTemporalFile $FILE) - - # Do something ... - - # Remove temporal instance of file. - if [[ -f $INSTANCE ]];then - rm $INSTANCE - fi - -done -@end verbatim - -Use the @code{cli_getTemporalFile} function whenever you need to -create temporal files inside @file{centos-art.sh} script. -@end defun - -@defun cli_getThemeName -Output theme name. - -In order for @code{cli_getThemeName} function to extract theme name -correctly, the @var{ACTIONVAL} variable must contain a directory path -under @file{trunk/Identity/Themes/Motifs/} directory structure. -Otherwise, @code{cli_getThemeName} returns an empty string. -@end defun - -@defun cli_printMessage MESSAGE [FORMAT] -Define standard output message definition supported by -@file{centos-art.sh} script. - -When @var{FORMAT} is not specified, @code{cli_printMessage} outputs -information just as it was passed in @var{MESSAGE} variable. -Otherwise, @var{FORMAT} can take one of the following values: - -@table @option -@item AsHeadingLine -To print heading messages. -@verbatim ----------------------------------------------------------------------- -$MESSAGE ----------------------------------------------------------------------- -@end verbatim - -@item AsWarningLine -To print warning messages. -@verbatim ----------------------------------------------------------------------- -WARNING: $MESSAGE ----------------------------------------------------------------------- -@end verbatim - -@item AsNoteLine -To print note messages. -@verbatim ----------------------------------------------------------------------- -NOTE: $MESSAGE ----------------------------------------------------------------------- -@end verbatim - -@item AsUpdatingLine -To print @samp{Updating} messages on two-columns format. -@verbatim -Updating $MESSAGE -@end verbatim - -@item AsRemovingLine -To print @samp{Removing} messages on two-columns format. -@verbatim -Removing $MESSAGE -@end verbatim - -@item AsCheckingLine -To print @samp{Checking} messages on two-columns format. -@verbatim -Checking $MESSAGE -@end verbatim - -@item AsCreatingLine -To print @samp{Creating} messages on two-columns format. -@verbatim -Creating $MESSAGE -@end verbatim - -@item AsSavedAsLine -To print @samp{Saved as} messages on two-columns format. -@verbatim -Saved as $MESSAGE -@end verbatim - -@item AsLinkToLine -To print @samp{Linked to} messages on two-columns format. -@verbatim -Linked to $MESSAGE -@end verbatim - -@item AsMovedToLine -To print @samp{Moved to} messages on two-columns format. -@verbatim -Moved to $MESSAGE -@end verbatim - -@item AsTranslationLine -To print @samp{Translation} messages on two-columns format. -@verbatim -Translation $MESSAGE -@end verbatim - -@item AsConfigurationLine -To print @samp{Configuration} messages on two-columns format. -@verbatim -Configuration $MESSAGE -@end verbatim - -@item AsResponseLine -To print response messages on one-column format. -@verbatim ---> $MESSAGE -@end verbatim - -@item AsRequestLine -To print request messages on one-column format. Request messages -output messages with one colon (@samp{:}) and without trailing newline -(@samp{\n}) at message end. -@verbatim -$MESSAGE: -@end verbatim - -@item AsYesOrNoRequestLine -To print @samp{yes or no} request messages on one-column format. If -something different from @samp{y} is answered (when using -@code{en_US.UTF-8} locale), script execution ends immediatly. - -@verbatim -$MESSAGE [y/N]: -@end verbatim - -When we use @file{centos-art.sh} script in a locale different from -@code{en_US.UTF-8}, confirmation answer may be different from -@samp{y}. For example, if you use @code{es_ES.UTF-8} locale, the -confirmation question would look like: - -@verbatim -$MESSAGE [s/N]: -@end verbatim - -and the confirmation answer would be @samp{s}, as it is on Spanish -@samp{sí} word. - -Definition of which confirmation word to use is set on translation -messages for your specific locale information. --- @strong{Removed}(xref:trunk Scripts -Bash Functions Locale) ---, for more information about locale-specific -translation messages. - -@item AsToKnowMoreLine -To standardize @samp{to know more, run the following command:} -messages. When the @option{AsToKnowMoreLine} option is used, the -@var{MESSAGE} value should be set to @code{"$(caller)"}. @code{caller} -is a Bash builtin that returns the context of the current subroutine -call. @option{AsToKnowMoreLine} option uses @code{caller} builtin -output to build documentation entries dynamically. - -@verbatim ----------------------------------------------------------------------- -To know more, run the following command: -centos-art manual --read='path/to/dir' ----------------------------------------------------------------------- -@end verbatim - -Use @option{AsToKnowMoreLine} option after errors and for intentional -script termination. - -@item AsRegularLine -To standardize regular messages on one-column format. - -When @var{MESSAGE} contains a colon inside (e.g., @samp{description: -message}), the @code{cli_printMessage} function outputs @var{MESSAGE} -on two-columns format. -@end table - -Use @code{cli_printMessage} function whenever you need to output -information from @file{centos-art.sh} script. - -@quotation -@strong{Tip} To improve two-columns format, change the following file: -@verbatim -trunk/Scripts/Bash/Styles/output_forTwoColumns.awk -@end verbatim -@end quotation -@end defun - -@subsubsection Specific functions - -The following specific functions of @file{centos-art.sh} script, are -available for you to use: - -@menu -@comment --- Removed(* trunk Scripts Bash Functions Html::) --- -@comment --- Removed(* trunk Scripts Bash Functions Locale::) --- -@comment --- Removed(* trunk Scripts Bash Functions Manual::) --- -@comment --- Removed(* trunk Scripts Bash Functions Path::) --- -@comment --- Removed(* trunk Scripts Bash Functions Render::) --- -@comment --- Removed(* trunk Scripts Bash Functions Render Config::) --- -@comment --- Removed(* trunk Scripts Bash Functions Shell::) --- -@comment --- Removed(* trunk Scripts Bash Functions Svg::) --- -@comment --- Removed(* trunk Scripts Bash Functions Verify::) --- -@end menu - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Locale::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Help.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Html.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi deleted file mode 100644 index bf264c9..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Locale.texi +++ /dev/null @@ -1,85 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -This command looks for @samp{.sh} files inside Bash directory and -extracts translatable strings from files, using @command{xgettext} -command, in order to create a portable object template -(@file{centos-art.sh.pot}) file for them. - -With the @file{centos-art.sh.pot} file up to date, the -@command{centos-art} command removes the temporal list of files sotred -inside @file{/tmp} directory and checks the current language of your -user's session to create a portable object file for it, in the -location @file{$CLI_LANG/$CLI_LANG.po}. - -The @var{CLI_LANG} variable discribes the locale language used to -output messages inside @command{centos-art} command. The locale -language used inside @command{centos-art} command is taken from the -@env{LANG} environment variable. The @var{CLI_LANG} variable has the -@samp{LL_CC} format, where @samp{LL} is a language code from the -ISO-639 standard, and @samp{CC} a country code from the ISO-3166 -standard. - -The @env{LANG} environment variable is set when you do log in to your -system. If you are using a graphical session, change language to your -native language and do login. That would set and exoprt the @env{LANG} -environment variable to the correct value. On the other side, if you -are using a text session edit your @file{~/.bash_profile} file to set -and export the @env{LANG} environment variable to your native locale -as defines the @command{locale -a} command output; do logout, and do -login again. - -At this point, the @env{LANG} environment variable has the appropriate -value you need, in order to translate @command{centos-art.sh} messages -to your native language (the one set in @env{LANG} environment -variable). - -With the @file{$CLI_LANG/$CLI_LANG.po} file up to date, the -@command{centos-art} opens it for you to update translation strings. -The @command{centos-art} command uses the value of @var{EDITOR} -environment variable to determine your favorite text editor. If no -value is defined on @var{EDITOR}, the @file{/usr/bin/vim} text editor -is used as default. - -When you finishd PO file edition and quit text editor, the -@command{centos-art} command creates the related machine object in the -location @file{$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo}. - -At this point, all translations you made in the PO file should be -available to your language when runing @command{centos-art.sh} script. - -In order to make the @command{centos-art.sh} internationalization, the -@command{centos-art.sh} script was modified as described in the -@command{gettext} info documentation (@command{info gettext}). You -can find such modifications in the following files: - -@itemize -@item @file{trunk/Scripts/Bash/initFunctions.sh} -@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh} -@item @file{trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh} -@end itemize - -@itemize -@item ... -@end itemize - -@subsection Usage - -@table @samp -@item centos-art locale --edit -Use this command to translate command-line interface output messages -in the current system locale you are using (as specified in @env{LANG} -environment variable). -@item centos-art locale --list -Use this command to see the command-line interface locale report. -@end table - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Manual.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi deleted file mode 100644 index a7c6c55..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Path.texi +++ /dev/null @@ -1,327 +0,0 @@ -@subsection Goals - -This section exists to organize files related to @code{path} -functiontionality. The @code{path} functionality standardizes -movement, syncronization, branching, tagging, and general file -maintainance inside the repository. - -@subsection Description - -@emph{''CentOS like trees, has roots, trunk, branches, leaves and -flowers. Day by day they work together in freedom, ruled by the laws -of nature and open standards, to show the beauty of its existence.''} - -@subsubsection 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: @file{trunk/}, @file{branches/}, -and @file{tags/}. - -The @file{trunk/} directory (@pxref{trunk}) organizes the main -development line of CentOS corporate visual identity. Inside -@file{trunk/} directory structure, the CentOS corporate visual -identity concepts are implemented using directories. There is one -directory level for each relevant concept inside the repository. The -@file{trunk/} directory structure is mainly used to perform -development tasks related to CentOS corporate visual identity. - -The @file{branches/} directory (@pxref{branches}) oranizes parallel -development lines to @file{trunk/} directory. The @file{branches/} -directory is used to set points in time where develpment lines are -devided one from another taking separte and idependent lives that -share a common past from the point they were devided on. The -@file{branches/} directory is mainly used to perform quality assurance -tasks related to CentOS corporate visual identity. - -The @file{tags/} directory (@pxref{tags}) organizes parallel frozen -lines to @file{branches/} directory. The parallel frozen lines are -immutable, nothing change inside them once they has been created. The -@file{tags/} directory is mainly used to publish final releases of -CentOS corporate visual identity. - -The CentOS Artwork Repository layout is firmly grounded on a -Subversion base. Subversion (@url{http://subversion.tigris.org}) is a -version control system, which allows you to keep old versions of files -and directories (usually source code), keep a log of who, when, and -why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a -single copy of the master sources. This copy is called the source -``repository''; it contains all the information to permit extracting -previous versions of those files at any time. - -@subsubsection 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 -(@samp{01-welcome.png}, @samp{splash.png}, @samp{anaconda_header.png}, -etc.) and directory names are all written capitalized (e.g., -@samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower}, -etc.). - -Repository name convenctions are implemented inside the -@code{cli_getRepoName} function of @file{centos-art.sh} script. With -@code{cli_getRepoName} function we reduce the amount of commands and -convenctions to remember, concentrating them in just one single place -to look for fixes and improvements. - -@subsubsection 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., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we -organize information that cannot be produced automatically (i.e., -background images, concepts, color information, screenshots, etc.). - -Later, when theme trunk development line is considered ``ready'' for -implementation (e.g., all required backgrounds have been designed), -we create a branch for it (e.g., -@file{branches/Identity/Themes/Motifs/TreeFlower/1/}). Once the -branch has been created, we forget that branch and continue working -the trunk development line while others (e.g., an artwork quality -assurance team) test the new branch for tunning it up. - -Once the branch has been tunned up, and considered ``ready'' for -release, it is freezed under @file{tags/} directory (e.g., -@file{tags/Identity/Themes/Motifs/TreeFower/1.0/}) for packagers, -webmasters, promoters, and anyone who needs images from that CentOS -theme the tag was created for. - -Both branches and tags, inside CentOS Artwork Repository, use -numerical values to identify themselves under the same location. -Branches start at one (i.e., @samp{1}) and increment one unit for each -branch created from the same trunk development line. Tags start at -zero (i.e., @samp{0}) and increment one unit for each tag created from -the same branch development line. - -@quotation -@strong{Convenction} Do not freeze trunk development lines using tags -directly. If you think you need to freeze a trunk development line, -create a branch for it and then freeze that branch instead. -@end quotation - -The trunk development line may introduce problems we cannot see -immediatly. Certainly, the high changable nature of trunk development -line complicates finding and fixing such problems. On the other hand, -the branched development lines provide a more predictable area where -only fixes/corrections to current content are commited up to -repository. - -If others find and fix bugs inside the branched development line, we -could merge such changes/experiences back to trunk development line -(not visversa) in order for future branches, created from trunk, to -benefit. - -Time intervals used to create branches and tags may vary, just as -different needs may arrive. For example, consider the release schema -of CentOS distribution: one major release every 2 years, security -updates every 6 months, support for 7 years long. Each time a CentOS -distribution is released, specially if it is a major release, there is -a theme need in order to cover CentOS distribution artwork -requirements. At this point, is where CentOS Artwork Repository comes -up to scene. - -Before releasing a new major release of CentOS distribution we create -a branch for one of several theme development lines available inside -the CentOS Artwork Repository, perform quality assurance on it, and -later, freeze that branch using tags. Once a the theme branch has been -frozen (under @file{tags/} directory), CentOS Packagers (the persons -whom build CentOS distribution) can use that frozen branch as source -location to fulfill CentOS distribution artwork needs. The same -applies to CentOS Webmasters (the persons whom build CentOS websites), -and any other visual manifestation required by the project. - -@subsubsection Parallel directories - -Inside CentOS Artwork Repository, parallel directories are simple -directory entries built from a common parent directory and placed in a -location different to that, the common parent directory is placed on. -Parallel directories are useful to create branches, tags, -translations, documentation, pre-rendering configuration script, and -similar directory structures. - -Parallel directories take their structure from one unique parent -directory. Inside CentOS Artwork Repository, this unique parent -directory is under @file{trunk/Identity} location. The -@file{trunk/Identity} location must be considered the reference for -whatever information you plan to create inside the repository. - -In some circumstances, parallel directories may be created removing -uncommon information from their paths. Uncommon path information -refers to those directory levels in the path which are not common for -other parallel directories. For example, when rendering -@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory -structure, the @file{centos-art.sh} script removes the -@file{Motifs/TreeFlower/} directory levels from path, in order to -build the parallel directory used to retrived translations, and -pre-rendering configuration scripts required by @code{render} -functionality. - -Another example of parallel directory is the documentation structure -created by @code{manual} functionality. This time, -@file{centos-art.sh} script uses parallel directory information with -uncommon directory levels to build the documentation entry required by -Texinfo documentation system, inside the repository. - -Othertimes, parallel directories may add uncommon information to their -paths. This is the case we use to create branches and tags. When we -create branches and tags, a numerical identifier is added to parallel -directory structure path. The place where the numerical identifier is -set on is relevant to corporate visual identity structure and should -be carefully considered where it will be. - -When one parent directory changes, all their related parallel -directories need to be changed too. This is required in order for -parallel directories to retain their relation with the parent -directory structure. In the other hand, parallel directories should -never be modified under no reason but to satisfy the relation to their -parent directory structure. Liberal change of parallel directories -may suppresses the conceptual idea they were initially created for; -and certainly, things may stop working the way they should do. - -@subsubsection Syncronizing path information - -Parallel directories are very useful to keep repository organized but -introduce some complications. For instance, consider what would -happen to functionalities like @code{manual} (@samp{trunk Scripts Bash -Functions Manual}) that rely on parent directory structures to create -documentation entries (using parallel directory structures) if one of -those parent directory structures suddenly changes after the -documentation entry has been already created for it? - -In such cases, functionalities like @code{manual} may confuse -themselves if path information is not updated to reflect the relation -with its parent directory. Such functionalities work with parent -directory structure as reference; if a parent directory changes, the -functionalities dont't even note it because they work with the last -parent directory structure available in the repository, no matter what -it is. - -In the specific case of documentation (the @code{manual} -functionality), the problem mentioned above provokes that older parent -directories, already documented, remain inside documentation directory -structures as long as you get your hands into the documentation -directory structure (@file{trunk/Manuals}) and change what must be -changed to match the new parent directory structure. - -There is no immediate way for @code{manual}, and similar -functionalities that use parent directories as reference, to know when -and how directory movements take place inside the repository. Such -information is available only when the file movement itself takes -place inside the repository. So, is there, at the moment of moving -files, when we need to syncronize parallel directories with their -unique parent directory structure. - -@quotation -@strong{Warning} There is not support for URL reference inside -@file{centos-art.sh} script. The @file{centos-art.sh} script is -designed to work with local files inside the working copy only. -@end quotation - -As CentOS Artwork Repository is built over a version control system, -file movements inside the repository are considered repository -changes. In order for these repository changes to be versioned, we -need to, firstly, add changes into the version control system, commit -them, and later, perform movement actions using version control system -commands. This configuration makes possible for everyone to know about -changes details inside the repository; and if needed, revert or update -them back to a previous revision. - -Finally, once all path information has been corrected, it is time to -take care of information inside the files. For instance, considere -what would happen if you make a reference to a documentation node, and -later the documentation node you refere to is deleted. That would make -Texinfo to produce error messages at export time. So, the -@file{centos-art.sh} script needs to know when such changes happen, in -a way they could be noted and handled without producing errors. - -@subsubsection What is the right place to store it? - -Occasionly, you may find that new corporate visual identity components -need to be added to the repository. If that is your case, the first -question you need to ask yourself, before start to create directories -blindly all over, is: What is the right place to store it? - -The CentOS Community different free support vains (see: -@url{http://wiki.centos.org/GettingHelp}) are the best place to find -answers to your question, but going there with hands empty is not good -idea. It may give the impression you don't really care about. Instead, -consider the following suggestions to find your own comprehension and -so, make your propositions based on it. - -When we are looking for the correct place to store new files, to bear -in mind the corporate visual identity structure used inside the CentOS -Artwork Repository (@pxref{trunk Identity}) would be probaly the best -advice we could offer, the rest is just matter of choosing appropriate -names. To illustrate this desition process let's consider the -@file{trunk/Identity/Themes/Motifs/TreeFlower} directory as example. -It is the trunk development line of @emph{TreeFlower} artistic motif. -Artistic motifs are considered part of themes, which in turn are -considered part of CentOS corporate visual identity. - -When building parent directory structures, you may find that reaching -an acceptable location may take some time, and as it uses to happen -most of time; once you've find it, that may be not a definite -solution. There are many concepts that you need to play with, in -order to find a result that match the conceptual idea you try to -implement in the new directory location. To know which these concepts -are, split the location in words and read its documentation entry from -less specific to more specific. - -For example, the @file{trunk/Identity/Themes/Motifs/TreeFlower} -location evolved through several months of contant work and there is -no certain it won't change in the future, even it fixes quite well the -concept we are trying to implement. The concepts used in -@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} location are -described in the following commands, respectively: - -@verbatim -centos-art manual --read=turnk/ -centos-art manual --read=turnk/Identity/ -centos-art manual --read=turnk/Identity/Themes/ -centos-art manual --read=turnk/Identity/Themes/Motifs/ -centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ -@end verbatim - -Other location concepts can be found similary as we did above, just -change the location we used above by the one you are trying to know -concepts for. - -@subsection Usage - -@table @command -@item centos-art path --copy='SRC' --to='DST' - -Copy @option{SRC} to @option{DST} and schedule @option{DST} for -addition (with history). In this command, @file{SRC} and @file{DST} -are both working copy (WC) entries. - -@item centos-art path --delete='SRC' - -Delete @option{DST}. In order for this command to work the file or -directory you intend to delete should be under version control first. -In this command, @file{SRC} is a working copy (WC) entry. - -@end table - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi deleted file mode 100644 index 7dfe2c5..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render.texi +++ /dev/null @@ -1,736 +0,0 @@ -The @code{render} functionality exists to produce both identity and -translation files on different levels of information (i.e., different -languages, release numbers, architectures, etc.). - -The @code{render} functionality relies on ``renderable directory -structures'' to produce files. Renderable directory structures can be -either ``identity directory structures'' or ``translation directory -structures'' with special directories inside. - -@subsection Renderable identity directory structures - -Renderable identity directory structures are the starting point of -identity rendition. Whenever we want to render a component of CentOS -corporate visual identity, we need to point @file{centos-art.sh} to a -renderable identity directory structure. If such renderable identity -directory structure doesn't exist, then it is good time to create it. - -Inside the working copy, one renderable identity directory structures -represents one visual manifestation of CentOS corporate visual -identity, or said differently, each visual manifestation of CentOS -corporate visual identity should have one renderable identity -directory structure. - -Inside renderable identity directory structures, @file{centos-art.sh} -can render both image-based and text-based files. Specification of -whether a renderable identity directory structure produces image-based -or text-based content is a configuration action that takes place in -the pre-rendition configuration script of that renderable identity -directory structure. - -Inside renderable identity directory structures, content production is -organized in different configurations. A content production -configuration is a unique combination of the components that make an -identity directory structure renderable. One content production -configuration does one thing only (e.g., to produce untranslated -images), but it can be extended (e.g., adding translation files) to -achieve different needs (e.g., to produce translated images). - -@subsubsection Design template without translation - -The design template without translation configuration is based on a -renderable identity directory structure with an empty translation -directory structure. In this configuration, one design template -produces one untranslated file. Both design templates and final -untranslated files share the same file name, but they differ one -another in file-type and file-extension. - -For example, to produce images without translations (there is no much -use in producing text-based files without translations), consider the -following configuration: - -@table @strong -@item One renderable identity directory structure: - -In this example we used @file{Identity/Path/To/Dir} as the identity -component we want to produce untranslated images for. Identity -components can be either under @file{trunk/} or @file{branches/} -directory structure. - -The identity component (i.e., @file{Identity/Path/To/Dir}, in this -case) is also the bond component we use to connect the identity -directory structures with their respective auxiliar directories (i.e., -translation directory structres and pre-rendition configuration -structures). The bond component is the path convenction that -@file{centos-art.sh} uses to know where to look for related -translations, configuration scripts and whatever auxiliar thing a -renderable directory structure may need to have. - -@verbatim - | The bond component - |----------------->| -trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. -|-- Tpl <-- Design template directory. -| `-- file.svg <-- Design template file. -`-- Img <-- Directory used to store final files. - `-- file.png <-- Final image-based file produced from - design template file. -@end verbatim - -Inside design template directory, design template files are based on -@acronym{SVG,Scalable Vector Graphics} and use the extension -@code{.svg}. Design template files can be organized using several -directory levels to create a simple but extensible configuration, -specially if translated images are not required. - -In order for @acronym{SVG,Scalable Vector Graphics} files to be -considered ``design template'' files, they should be placed under the -design template directory and to have set a @code{CENTOSARTWORK} -object id inside. - -The @code{CENTOSARTWORK} word itself is a convenction name we use to -define which object/design area, inside a design template, the -@file{centos-art.sh} script will use to export as -@acronym{PNG,Portable Network Graphic} image at rendition time. -Whithout such object id specification, the @file{centos-art.sh} script -cannot know what object/design area you (as designer) want to export -as @acronym{PNG,Portable Network Graphic} image file. - -@quotation -@strong{Note} At rendition time, the content of @file{Img/} directory -structure is produced by @file{centos-art.sh} automatically. -@end quotation - -When a renderable identity directory structure is configured to -produce image-based content, @file{centos-art.sh} produces -@acronym{PNG,Portable Network Graphics} files with the @code{.png} -extension. Once the base image format has been produced, it is -possible for @file{centos-art.sh} to use it in order to automatically -create other image formats that may be needed (--- @strong{Removed}(pxref:trunk Scripts -Bash Functions Render Config) ---). - -Inside the working copy, you can find an example of ``design template -without translation'' configuration at @file{trunk/Identity/Models/}. - -@xref{trunk Identity}, for more information. - -@item One translation directory structure: - -In order for an identity entry to be considered an identity renderable -directory structure, it should have a translation entry. The content -of the translation entry is relevant to determine how to process the -identity renderable directory entry. - -If the translation entry is empty (i.e., there is no file inside it), -@file{centos-art.sh} interprets the identity renderable directory -structure as a ``design templates without translation'' configuration. - -@verbatim - | The bond component - |----------------->| -trunk/Translations/Identity/Path/To/Dir -`-- (empty) -@end verbatim - -If the translation entry is not empty, @file{centos-art.sh} can -interpret the identity renderable directory structure as one of the -following configurations: ``design template with translation -(one-to-one)'' or ``design template with translation (optimized)''. -Which one of these configurations is used depends on the value -assigned to the matching list (@var{MATCHINGLIST}) variable in the -pre-rendition configuration script of the renderable identity -directory structure we are producing images for. - -If the matching list variable is empty (as it is by default), then -``design template with translation (one-to-one)'' configuration is -used. In this configuration it is required that both design templates -and translation files have the same file names. This way, @emph{one} -translation files is applied to @emph{one} design template, to produce -@emph{one} translated image. - -If the matching list variable is not empty (because you redefine it in -the pre-rendition configuration script), then ``design template with -translation (optimized)'' configuration is used instead. In this -configuration, design templates and translation files don't need to -have the same names since such name relationship between them is -specified in the matching list properly. - ---- @strong{Removed}(xref:trunk Translations) ---, for more information. - -@item One pre-rendition configuration script: - -In order to make an identity directory structure renderable, a -pre-rendition configuration script should exist for it. The -pre-rendition configuration script specifies what type of rendition -does @file{centos-art.sh} will perform over the identity directory -structure and how does it do that. - -@verbatim - | The bond component - |----------------->| -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - -} -@end verbatim - -Since translation directory structure is empty, @file{centos-art.sh} -assumes a ``design template without translation'' configuration to -produce untranslated images. - -To produce untranslated images, @file{centos-art.sh} takes one design -template and creates one temporal instance from it. Later, -@file{centos-art.sh} uses the temporal design template instance as -source file to export the final untranslated image. The action of -exporting images from @acronym{SVG,Scalable Vector Graphics} to -@acronym{PNG,Portable Network Graphics} is possible thanks to -Inkscape's command-line interface and the @code{CENTOSARTWORK} object -id we previously set inside design templates. - -@verbatim -centos-art.sh render --identity=trunk/Identity/Path/To/Dir -------------------------------------------------- -0 | Execute centos-art.sh on renderable identity directory structure. ---v---------------------------------------------- -trunk/Identity/Path/To/Dir/Tpl/file.svg -------------------------------------------------- -1 | Create instance from design template. ---v---------------------------------------------- -/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg -------------------------------------------------- -2 | Render untranslated image from design template instance. ---v---------------------------------------------- -trunk/Identity/NewDir/Img/file.png -------------------------------------------------- -3 | Remove design template instance. -@end verbatim - -Finally, when the untranslated image has been created, the temporal -design template instance is removed. At this point, -@file{centos-art.sh} takes the next design template and repeats the -whole production flow once again (design template by design template), -until all design templates be processed. - ---- @strong{Removed}(xref:trunk Scripts Bash Functions Render Config) ---, for more -information. -@end table - -@subsubsection Design template with translation (one-to-one) - -Producing untranslated images is fine in many cases, but not always. -Sometimes it is required to produce images in different languages and -that is something that untrasnlated image production cannot achieve. -However, if we fill its empty translation entry with translation files -(one for each design template) we extend the production flow from -untranslated image production to translated image production. - -In order for @file{centos-art.sh} to produce images correctly, each -design template should have one translation file and each translation -file should have one design template. Otherwise, if there is a -missing design template or a missing translation file, -@file{centos-art.sh} will not produce the final image related to the -missing component. - -In order for @file{centos-art.sh} to know which is the relation -between translation files and design templates the translation -directory structure is taken as reference. For example, the -@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation -file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design -template, but it doesn't match -@file{trunk/Identity/Path/To/Dir/File.svg} or -@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or -@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design -templates. - -The pre-rendition configuration script used to produce untranslated -images is the same we use to produce translated images. There is no -need to modify it. So, as we are using the same pre-rendition -configuration script, we can say that translated image production is -somehow an extended/improved version of untranslated image production. - -@quotation -@strong{Note} If we use no translation file in the translation entry -(i.e., an empty directory), @file{centos-art.sh} assumes the -untranslated image production. If we fill the translation entry with -translation files, @file{centos-art.sh} assumes the translated image -production. -@end quotation - -To produce final images, @file{centos-art.sh} applies one translation -file to one design template and produce a translated design template -instance. Later, @file{centos-art.sh} uses the translated template -instance to produce the translated image. Finally, when the translated -image has been produced, @file{centos-art.sh} removes the translated -design template instance. This production flow is repeated for each -translation file available in the translatio entry. - -@verbatim -centos-art.sh render --identity=trunk/Identity/Path/To/Dir -------------------------------------------------- -0 | Execute centos-art.sh on directory structure. ---v---------------------------------------------- -trunk/Translations/Identity/Path/To/Dir/file.sed -------------------------------------------------- -1 | Apply translation to design template. ---v---------------------------------------------- -trunk/Identity/Path/To/Dir/Tpl/file.svg -------------------------------------------------- -2 | Create design template instance. ---v---------------------------------------------- -/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg -------------------------------------------------- -3 | Render PNG image from template instance. ---v---------------------------------------------- -trunk/Identity/NewDir/Img/file.png -------------------------------------------------- -4 | Remove design template instance. -@end verbatim - -@subsubsection Design template with translation (optimized) - -Producing translated images satisfies almost all our production images -needs, but there is still a pitfall in them. In order to produce -translated images as in the ``one-to-one'' configuration describes -previously, it is required that one translation file has one design -template. That's useful in many cases, but what would happen if we -need to apply many different translation files to the same design -template? Should we have to duplicate the same design template file -for each translation file, in order to satisfy the ``one-to-one'' -relation? What if we need to assign translation files to design -templates arbitrarily? - -Certenly, that's something the ``one-to-one'' configuration cannot -handle. So, that's why we had to ``optimize'' it. The optimized -configuration consists on using a matching list (@var{MATCHINGLIST}) -variable that specifies the relationship between translation files and -design templates in an arbitrary way. Using such matching list between -translation files and design templates let us use as many assignment -combinations as translation files and design templates we are working -with. - -The @var{MATCHINGLIST} variable is set in the pre-rendition -configuration script of the component we want to produce images for. -By default, the @var{MATCHINGLIST} variable is empty which means no -matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a -value different to empty value then, @file{centos-art.sh} interprets -the matching list in order to know how translation files are applied -to design templates. - -For example, consider the following configuration: - -@table @strong -@item One entry under @file{trunk/Identity/}: - -In this configuration we want to produce three images using a -paragraph-based style, controlled by @file{paragraph.svg} design -template; and one image using a list-based style, controlled by -@file{list.svg} design template. - -@verbatim -trunk/Identity/Path/To/Dir -|-- Tpl -| |-- paragraph.svg -| `-- list.svg -`-- Img - |-- 01-welcome.png - |-- 02-donate.png - |-- 03-docs.png - `-- 04-support.png -@end verbatim - -@item One entry under @file{trunk/Translations/}: - -In order to produce translated images we need to have one translation -file for each translated image we want to produce. Notice how -translation names do match final image file names, but how translation -names do not match design template names. When we use matching list -there is no need for translation files to match the names of design -templates, such name relation is set inside the matching list itself. - -@verbatim -trunk/Translations/Identity/Path/To/Dir -|-- 01-welcome.sed -|-- 02-donate.sed -|-- 03-docs.sed -`-- 04-support.sed -@end verbatim - -@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}: - -In order to produce different translated images using specific design -templates, we need to specify the relation between translation files -and design templates in a way that @file{centos-art.sh} could know -exactly what translation file to apply to what design template. This -relation between translation files and design templates is set using -the matching list @var{MATCHINGLIST} variable inside the pre-rendition -configuration script of the component we want to produce images for. - -@verbatim -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - - # Define matching list. - MATCHINGLIST="\ - paragraph.svg:\ - 01-welcome.sed\ - 02-donate.sed\ - 04-support.sed - list.svg:\ - 03-docs.sed - " - -} -@end verbatim - -As result, @file{centos-art.sh} will produce @file{01-welcome.png}, -@file{02-donate.png} and @file{04-support.png} using the -paragraph-based design template, but @file{03-docs.png} using the -list-based design template. -@end table - -@subsubsection Design template with translation (optimized+flexibility) - -In the production models we've seen so far, there are design templates -to produce untranslated images and translation files which combiend -with design templates produce translated images. That may seems like -all our needs are covered, doesn't it? Well, it @emph{almost} does. - -Generally, we use design templates to define how final images will -look like. Generally, each renderable directory structure has one -@file{Tpl/} directory where we organize design templates for that -identity component. So, we can say that there is only one unique -design template definition for each identity component; or what is the -same, said differently, identity components can be produced in one way -only, the way its own design template directory specifies. This is -not enough for theme production. It is a limitation, indeed. - -Initially, to create one theme, we created one renderable directory -structure for each theme component. When we found ourselves with many -themes, and components inside them, it was obvious that the same -design model was duplicated inside each theme. As design models were -independently one another, if we changed one theme's design model, -that change was useless to other themes. So, in order to reuse design -model changes, we unified design models into one common directory -structure. - -With design models unified in a common structure, another problem rose -up. As design models also had the visual style of theme components, -there was no difference between themes, so there was no apparent need -to have an independent theme directory structure for each different -theme. So, it was also needed to separate visual styles from design -models. - -At this point there are two independent worklines: one directory -structure to store design models (the final image characteristics -[i.e., dimensions, translation markers, etc.]) and one directory -structure to store visual styles (the final image visual style [i.e., -the image look and feel]). So, it is possible to handle both -different design models and different visual styles independtly one -another and later create combinations among them using -@file{centos-art.sh}. - -For example, consider the following configuration: - -@table @strong -@item One entry under @file{trunk/Identity/Themes/Models/}: - -The design model entry exists to organize design model files (similar -to design templates). Both design models and design templates are very -similar; they both should have the @code{CENTOSARTWORK} export id -present to identify the exportation area, translation marks, etc. -However, design models do use dynamic backgrounds inclusion while -design templates don't. - -@verbatim - THEMEMODEL | | The bond component - |<----| |--------------------->| -trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ -|-- paragraph.svg -`-- list.svg -@end verbatim - -Inisde design models, dynamic backgrounds are required in order for -different artistic motifs to reuse common design models. Firstly, in -order to create dynamic backgrounds inside design models, we import a -bitmap to cover design model's background and later, update design -model's path information to replace fixed values to dynamic values. - -@item One entry under @file{trunk/Identity/Themes/Motifs/}: - -The artistic motif entry defines the visual style we want to produce -images for, only. Final images (i.e., those built from combining both -design models and artistic motif backrounds) are not stored here, but -under branches directory structure. In the artistic motif entry, we -only define those images that cannot be produced automatically by -@file{centos-art.sh} (e.g., Backgrounds, Color information, -Screenshots, etc.). - -@verbatim - Artistic motif name | | Artistic motif backgrounds - |<-------| |-------->| -trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ -|-- Img -| |-- Png -| | |-- 510x300.png -| | `-- 510x300-final.png -| `-- Jpg -| |-- 510x300.jpg -| `-- 510x300-final.jpg -|-- Tpl -| `-- 510x300.svg -`-- Xcf - `-- 510x300.xcf -@end verbatim - -@item One entry under @file{trunk/Translations/}: - -The translation entry specifies, by means of translation files, the -language-specific information we want to produce image for. When we -create the translation entry we don't use the name of neither design -model nor artistic motif, just the design model component we want to -produce images for. - -@verbatim - | The bond component - |--------------------->| -trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ -`-- 5 - |-- en - | |-- 01-welcome.sed - | |-- 02-donate.sed - | `-- 03-docs.sed - `-- es - |-- 01-welcome.sed - |-- 02-donate.sed - `-- 03-docs.sed -@end verbatim - -@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}: - -There is one pre-rendition configuration script for each theme -component. So, each time a theme component is rendered, its -pre-rendition configuration script is evaluated to teach -@file{centos-art.sh} how to render the component. - -@verbatim -trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/ -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - - # Define matching list. - MATCHINGLIST="\ - paragraph.svg:\ - 01-welcome.sed\ - 02-donate.sed - list.svg:\ - 03-docs.sed - " - - # Deifne theme model. - THEMEMODEL='Default' - -} -@end verbatim -@end table - -The production flow of ``optimize+flexibility'' configuration@dots{} -@subsection Renderable translation directory structures - -Translation directory structures are auxiliar structures of renderable -identity directory structures. There is one translation directory -structure for each renderable identity directory structure. Inside -translation directory structures we organize translation files used by -renderable identity directory structures that produce translated -images. Renderable identity directory structures that produce -untranslated images don't use translation files, but they do use a -translation directory structure, an empty translation directory -structure, to be precise. - -In order to aliviate production of translation file, we made -translation directory structures renderable adding a template -(@file{Tpl/}) directory structure to handle common content inside -translation files. This way, we work on translation templates and -later use @file{centos-art.sh} to produce specific translation files -(based on translation templates) for different information (e.g., -languages, release numbers, architectures, etc.). - -If for some reason, translation files get far from translation -templates and translation templates become incovenient to produce such -translation files then, care should be taken to avoid replacing the -content of translation files with the content of translation templates -when @file{centos-art.sh} is executed to produce translation files -from translation templates. - -Inside renderable translation directory structures, -@file{centos-art.sh} can produce text-based files only. - -@subsection Copying renderable directory structures - -A renderable layout is formed by design models, design images, -pre-rendition configuration scripts and translations files. This way, -when we say to duplicate rendition stuff we are saying to duplicate -these four directory structures (i.e., design models, design images, -pre-rendition configuration scripts, and related translations files). - -When we duplicate directories, inside `trunk/Identity' directory -structure, we need to be aware of renderable layout described above -and the source location used to perform the duplication action. The -source location is relevant to centos-art.sh script in order to -determine the required auxiliar information inside directory -structures that need to be copied too (otherwise we may end up with -orphan directory structures unable to be rendered, due the absence of -required information). - -In order for a renderable directory structure to be valid, the new -directory structure copied should match the following conditions: - -@enumerate -@item To have a unique directory structure under -@file{trunk/Identity}, organized by any one of the above -organizational designs above. - -@item To have a unique directory structure under -@file{trunk/Translations} to store translation files. - -@item To have a unique directory structure under -@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition -configuration script. -@end enumerate - -As convenction, the @code{render_doCopy} function uses -@file{trunk/Identity} directory structure as source location. Once -the @file{trunk/Identity} directory structure has been specified and -verified, the related path information is built from it and copied -automatically to the new location specified by @var{FLAG_TO} variable. - -Design templates + No translation: - -Command: -- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir - -Sources: -- trunk/Identity/Path/To/Dir -- trunk/Translations/Identity/Path/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir - -Targets: -- trunk/Identity/NewPath/To/Dir -- trunk/Translations/Identity/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir - -Renderable layout 2: - -Command: -- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \ - --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir - -Sources: -- trunk/Identity/Themes/Motifs/TreeFlower -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/TreeFlower -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower - -Targets: -- trunk/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir - -Notice that design models are not included in source or target -locations. This is intentional. In ``Renderable layout 2'', design -models live by their own, they just exist, they are there, available -for any artistic motif to use. By default `Themes/Models/Default' -design model directory structure is used, but other design models -directory structures (under Themes/Models/) can be created and used -changing the value of THEMEMODEL variable inside the pre-rendition -configuration script of the artistic motif source location you want to -produce. - -Notice how translations and pre-rendition configuration scripts may -both be equal in source and target. This is because such structures -are common to all artistic motifs (the default values to use when no -specific values are provided). - -- The common directory structures are not copied or deleted. We cannot - copy a directory structure to itself. - -- The common directory structures represent the default value to use - when no specific translations and/or pre-rendition configuration - script are provided inside source location. - -- The specific directory structures, if present, are both copiable and - removable. This is, when you perform a copy or delete action from - source, that source specific auxiliar directories are transfered in - the copy action to a new location (that specified by FLAG_TO - variable). - -- When translations and/or pre-rendition configuration scripts are - found inside the source directory structure, the centos-art.sh - script loads common auxiliar directories first and later specific - auxiliar directories. This way, identity rendition of source - locations can be customized idividually over the base of common - default values. - -- The specific auxiliar directories are optional. - -- The common auxiliar directories should be present always. This is, - in order to provide the information required by render functionality - (i.e., to make it functional in the more basic level of its - existence). - -Notice how the duplication process is done from `trunk/Identity' on, -not the oposite. If you try to duplicate a translation structure (or -similar auxiliar directory structures like pre-rendition configuration -scripts), the `trunk/Identity' for that translation is not created. -This limitation is impossed by the fact that many `trunk/Identity' -directory structures may reuse/share the same translation directory -structure. We cannot delete one translation (or similar) directory -structures while a related `trunk/Identity/' directory structure is -still in need of it. - -The `render_doCopy' functionality does duplicate directory structures -directly involved in rendition process only. Once such directories -have been duplicated, the functionality stops thereat. - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@comment --- Removed(* trunk Scripts Bash Functions Render Config::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi deleted file mode 100644 index 3b3322b..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Render/Config.texi +++ /dev/null @@ -1,192 +0,0 @@ -@subsection Goals - -The @file{trunk/Scripts/Bash/Config} directory exists to oraganize -pre-rendering configuration scripts. - -@subsection Description - -Pre-rendering configuration scripts let you customize the way -@command{centos-art.sh} script renders identity and translation -repository entries. Pre-rendering configuration scripts are -@file{render.conf.sh} files with @command{render_loadConfig} function -definition inside. - -There is one @file{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. - -@subsubsection The @file{render.conf.sh} identity model - -Inside CentOS Artwork Repository, we consider identity entries to all -directories under @file{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: - -@verbatim -#!/bin/bash - -function render_loadConfig { - - # Define rendering actions. - ACTIONS[0]='BASE:renderImage' - ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm' - -} -@end verbatim - -Inside identity pre-rendering configuration scripts, text-based -pre-rendering configuration scripts look like the following: - -@verbatim -#!/bin/bash - -function render_loadConfig { - - # Define rendering actions. - ACTIONS[0]='BASE:renderText' - ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing' - -} -@end verbatim - -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. - -@subsubsection The @file{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. - -@subsubsection The @file{render.conf.sh} rendering actions - -Inside both image-based and text-based identity pre-rendering -configuration scripts, we use the @samp{ACTIONS} array variable to -define the way @command{centos-art.sh} script performs identity -rendering. Identity rendering is organized by one @samp{BASE} action, -and optional @samp{POST} and @samp{LAST} rendering actions. - -The @samp{BASE} action specifies what kind of rendering does the -@command{centos-art.sh} script will perform with the files related to -the pre-rendering configuration script. The @samp{BASE} action is -required. Possible values to @samp{BASE} action are either -@samp{renderImage} or @samp{renderText} only. - -To specify the @samp{BASE} action you need to set the @samp{BASE:} -string followed by one of the possible values. For example, if you -want to render images, consider the following definition of -@samp{BASE} action: - -@verbatim -ACTIONS[0]='BASE:renderImage' -@end verbatim - -Only one @samp{BASE} action must be specified. If more than one -@samp{BASE} action is specified, the last one is used. If no -@samp{BASE} action is specified at all, an error is triggered and the -@command{centos-art.sh} script ends its execution. - -The @samp{POST} action specifies which action to apply for -each file rendered (at the rendering time). This action is optional. -You can set many different @samp{POST} actions to apply many different -actions over the same already rendered file. Possible values to -@samp{POST} action are @samp{renderFormats}, @samp{renderSyslinux}, -@samp{renderGrub}, etc. - -To specify the @samp{POST} action, you need to use set the -@samp{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 @samp{xpm}, @samp{jpg}, and -@samp{tif} images, based on already rendered @samp{png} image, and -also organize the produced files in directories named as their own -extensions: - -@verbatim -ACTIONS[0]='BASE:renderImage' -ACTIONS[1]='POST:renderFormats: xpm jpg tif' -ACTIONS[2]='POST:groupByFormat: png xpm jpg tif' -@end verbatim - -In the previous example, file organization takes place at the moment -of rendering, just after producing the @samp{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 @samp{POST:groupByFormat} action line: - -@verbatim -ACTIONS[0]='BASE:renderImage' -ACTIONS[1]='POST:renderFormats: xpm jpg tif' -@end verbatim - -The @samp{LAST} action specifies which actions to apply once the last -file in the list of files to process has been rendered. The -@samp{LAST} action is optional. Possible values for @samp{LAST} -actions may be @samp{groupByFormat}, @samp{renderGdmTgz}, etc. - -@quotation -@strong{Note} --- @strong{Removed}(xref:trunk Scripts Bash Functions Render) ---, to know more -about possible values for @samp{BASE}, @samp{POST} and @samp{LAST} -action definitions. -@end quotation - -To specify the @samp{LAST} action, you need to set the @samp{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: - -@verbatim -ACTIONS[0]='BASE:renderImage' -ACTIONS[1]='POST:renderFormats: xpm jpg tif' -ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' -@end verbatim - -@subsection Usage - -Use the following commands to administer both identity and translation -pre-rendering configuration scripts: - -@table @samp - -@item centos-art config --create='path/to/dir/' - -Use this command to create @samp{path/to/dir} related pre-rendering -configuration script. - -@item centos-art config --edit='path/to/dir/' - -Use this command to edit @samp{path/to/dir} related pre-rendering -configuration script. - -@item centos-art config --read='path/to/dir/' - -Use this command to read @samp{path/to/dir} related pre-rendering -configuration script. - -@item centos-art config --remove='path/to/dir/' - -Use this command to remove @samp{path/to/dir} related pre-rendering -configuration script. - -@end table - -In the commands above, @samp{path/to/dir} refers to one renderable -directory path under @file{trunk/Identity} or -@file{trunk/Translations} structures only. - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@comment --- Removed(* trunk Scripts Bash Functions Render::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi deleted file mode 100644 index a5016fe..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Shell.texi +++ /dev/null @@ -1,184 +0,0 @@ -@subsection Goals - -This section exists to organize files related to @code{shell} -functionality of @file{centos-art.sh} script. - -@subsection Description - -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: - -@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:1 -@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 -@caption{The functions script base comment structure} -@end float - -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: - -@float Figure,fig:trunk/Scripts/Bash/Functions/Shell:2 -@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 -@caption{The function script comment example} -@end float - -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. -59 Temple Place - Suite 330, Boston, MA 02111-1307, 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, -CentOS Developers mailing list}. -@end quotation - -@subsection Usage - -@table @command -@item centos-art sh --update-copyright='path/to/dir' -@itemx centos-art sh --update-copyright='path/to/dir' --filter='regex' -Use these commands to update copyright information in @samp{.sh} files -under @samp{path/to/dir} directory. -@end table - -When you provide @option{--filter='regex'} argument, the list of files -to process is reduced as specified in @samp{regex} regular expression. -Inside @file{centos-art.sh} script, the @samp{regex} regular -expression is used in combination with @command{find} command to look -for files matching the regular expression path pattern. - -@quotation -@strong{Warning} In order for @samp{regex} regular expression to match -a file, the @samp{regex} regular expresion must match the whole file -path not just the file name. -@end quotation - -For example, if you want to match all @file{render.conf.sh} files -inside @file{path/to/dir}, use the @code{.+/render.conf} regular -expression. Later, @file{centos-art.sh} script uses this value inside -@code{^$REGEX\.sh$} expression in order to build the final regular -expression (i.e., @code{^.+/render.conf\.sh$}) that is evaluated -against available file paths inside the list of files to process. - -Exceptionally, when you provide @option{--filter='regex'} in the way -that @samp{regex}, appended to @samp{path/to/dir/} (i.e. -@samp{path/to/dir/regex}), matches a regular file; the -@file{centos-art.sh} script uses the file matching as only file in the -list of files to process. - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi deleted file mode 100644 index 341745d..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Svg.texi +++ /dev/null @@ -1,192 +0,0 @@ -@subsection Goals - -This section exists to organize files related to @code{svg} -functionality of @file{centos-art.sh} script. - -@subsection Description - -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. - -@cindex Metadata maintainance -@subsubsection Metadata maintainance - -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. - -The @file{centos-art.sh} script modifies the following metadata: - -@table @samp -@item Title -Name by which this document is formally known. If no value is set -here, @file{centos-art.sh} script uses the file name as title. - -@item Date -Date associated with the creation of this document (YYYY-MM-DD). If no -value is set here, @file{centos-art.sh} script uses the current date -information as in @command{date +%Y-%m-%d}. - -@item Creator -Name of entity primarily responsible for making the content of this -document. If no value is set here, @file{centos-art.sh} script uses -the string @samp{The CentOS Project}. - -@item Rights -Name of entity with rights to the intellectual Property of this -document. If no value is set here, @file{centos-art.sh} script uses -the string @samp{The CentOS Project}. - -@item Publisher -Name of entity responsible for making this document available. If no -value is set here, @file{centos-art.sh} script uses the string -@samp{The CentOS Project}. - -@item Identifier -Unique URI to reference this document. If no value is set here, -@file{centos-art.sh} script uses the current file path to build the -related url that points to current file location inside repository -central server. - -@item Source -Unique URI to reference the source of this document. If no value is -set here, @file{centos-art.sh} script uses current file path to build -the related url that points to current file location inside repository -central server. - -@item Relation -Unique URI to a related document. If no value is set here, -@file{centos-art.sh} script uses current file path to build the -related url that points to current file location inside repository -central server. - -@item Language -Two-letter language tag with optional subtags for the language of this -document. (e.g. @samp{en-GB}). If no value is set here, -@file{centos-art.sh} script uses the current locale information as in -@code{cli_getCurrentLocale} function. - -@item Keywords -The topic of this document as comma-separated key words, prhases, or -classifications. If no value is set here, @file{centos-art.sh} script -uses file path to build - -@item Coverage -Extent or scope of this document. If no value is set here, -@file{centos-art.sh} script uses the string @samp{The CentOS Project}. - -@item Description -Description about the document. If no value is set here, -@file{centos-art.sh} script uses uses empty value as default. - -@item Contributors -People that contributes in the creation/maintainance of the document. -If no value is set here, @file{centos-art.sh} script uses uses empty -value as default. -@end table - -The @samp{License} metadatum is not set as a choise, by now. It is -fixed @url{http://creativecommons.org/licenses/by-sa/3.0/, Creative -Common Attribution Share-Alike 3.0 License}. This is done in order to -grant license consistency among all SVG files we manage inside CentOS -Artwork Repository. - -@cindex Unused definitions -@subsubsection Unused definitions - -Many of the no-longer-used gradients, patterns, and markers (more -precisely, those which you edited manually) remain in the -corresponding palettes and can be reused for new objects. However if -you want to optimize your document, use the @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. - -@subsection Usage - -@table @command -@item centos-art svg --update-metadata='path/to/dir' -@item centos-art svg --update-metadata='path/to/dir' --filter='regex' -Use these commands to update metadata information to @samp{.svg} files -under @samp{path/to/dir} directory. - -@item centos-art svg --vacuum-defs='path/to/dir' -@item centos-art svg --vacuum-defs='path/to/dir' --filter='regex' -Use these commands to remove unused definitions inside @samp{.svg} -files under @samp{path/to/dir} directory. -@end table - -When you provide @option{--filter='regex'} argument, the list of files -to process is reduced as specified in @samp{regex} regular expression. -Inside @file{centos-art.sh} script, the @samp{regex} regular -expression is used in combination with @command{find} command to look -for files matching the regular expression path pattern. - -@quotation -@strong{Warning} In order for @samp{regex} regular expression to match -a file, the @samp{regex} regular expresion must match the whole file -path not just the file name. -@end quotation - -For example, if you want to match all @file{summary.svg} files inside -@file{path/to/dir}, use the @code{.+/summary} regular expression. -Later, @file{centos-art.sh} script uses this value inside -@code{^$REGEX\.svg$} expression in order to build the final regular -expression (i.e., @code{^.+/summary\.svg$}) that is evaluated against -available file paths inside the list of files to process. - -Exceptionally, when you provide @option{--filter='regex'} in the way -that @samp{regex}, appended to @samp{path/to/dir/} (i.e. -@samp{path/to/dir/regex}), matches a regular file; the -@file{centos-art.sh} script uses the file matching as only file in the -list of files to process. - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi deleted file mode 100644 index ff98b51..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Bash/Cli/Functions/Verify.texi +++ /dev/null @@ -1,245 +0,0 @@ -@subsection Goals - -This section exists to organize files related to @file{centos-art.sh} -script @samp{verify} functionality. The @samp{verify} -functionality of @file{centos-art.sh} script helps you to verify the -workstation configuration you are planning to use as host for your -working copy of CentOS Artwork Repository. - -@subsection 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{verify} 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{verify} 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. - -@subsubsection 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. - -@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} -@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{verify} 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. - -@subsubsection 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. - -@subsubsection 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{verify} functionality of @file{centos-art.sh} script doesn't -modify your @file{~/.bash_profile} file. - -The @samp{verify} 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. - -If @env{EDITOR} environment variable is not set, @file{centos-art.sh} -script uses @file{/usr/bin/vim} as default text editor. Otherwise, the -following values are recognized by @file{centos-art.sh} script: - -@itemize -@item @file{/usr/bin/vim} -@item @file{/usr/bin/emacs} -@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 - -Default directory used to retrieve translated messages. This variable -is set in @file{initFunctions.sh} and shouldn't be changed. - -@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 -@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. - -@end table - -@subsection Usage - -@table @command - -@item centos-art verify --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. - -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. - -@item centos-art verify --links - -Verify required links your workstation needs in order to run the -centos-art command correctly. If any required link is missing, the -@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. - -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. - -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. - -@item centos-art verify --environment -@itemx centos-art verify --environment --filter='regex' - -Output a brief description of environment variables used by -@file{centos-art.sh} script. - -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. - -@end table - -@subsection See also - -@menu -* trunk Scripts Bash:: -@comment --- Removed(* trunk Scripts Bash Functions::) --- -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi b/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi deleted file mode 100644 index fb39647..0000000 --- a/Manuals/Repository/Filesystem/trunk/Scripts/Python.texi +++ /dev/null @@ -1,22 +0,0 @@ -@subsection Goals - -@itemize -@item ... -@end itemize - -@subsection Description - -@itemize -@item ... -@end itemize - -@subsection Usage - -@itemize -@item ... -@end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/chapter-intro.texi b/Manuals/Repository/Filesystem/trunk/chapter-intro.texi deleted file mode 100644 index e69de29..0000000 --- a/Manuals/Repository/Filesystem/trunk/chapter-intro.texi +++ /dev/null diff --git a/Manuals/Repository/Filesystem/trunk/chapter-menu.texi b/Manuals/Repository/Filesystem/trunk/chapter-menu.texi deleted file mode 100644 index 1dace8c..0000000 --- a/Manuals/Repository/Filesystem/trunk/chapter-menu.texi +++ /dev/null @@ -1,62 +0,0 @@ -@menu -* trunk Identity:: -* trunk Identity Brands:: -* trunk Identity Fonts:: -* trunk Identity Icons:: -* trunk Identity Isolinux:: -* trunk Identity Models:: -* trunk Identity Models Css:: -* trunk Identity Models Html:: -* trunk Identity Models Img Promo Web:: -* trunk Identity Models Tpl:: -* trunk Identity Models Tpl Promo Web:: -* trunk Identity Models Xcf:: -* trunk Identity Release:: -* trunk Identity Themes:: -* trunk Identity Themes Models:: -* trunk Identity Themes Models Alternative:: -* trunk Identity Themes Models Default:: -* trunk Identity Themes Models Default Distro:: -* trunk Identity Themes Models Default Distro Anaconda:: -* trunk Identity Themes Models Default Promo:: -* trunk Identity Themes Models Default Web:: -* trunk Identity Themes Motifs:: -* trunk Identity Themes Motifs Flame:: -* trunk Identity Themes Motifs Modern:: -* trunk Identity Themes Motifs Modern Backgrounds:: -* trunk Identity Themes Motifs Modern Backgrounds Img:: -* trunk Identity Themes Motifs Modern Backgrounds Tpl:: -* trunk Identity Themes Motifs Modern Backgrounds Xcf:: -* trunk Identity Themes Motifs Modern Distro Anaconda Progress:: -* trunk Identity Themes Motifs Modern Palettes:: -* trunk Identity Themes Motifs TreeFlower:: -* trunk Identity Themes Motifs TreeFlower Backgrounds:: -* trunk Identity Widgets:: -* trunk Locales:: -* trunk Locales Identity:: -* trunk Locales Identity Brands:: -* trunk Locales Identity Brands Tpl:: -* trunk Locales Identity Fonts:: -* trunk Locales Identity Models:: -* trunk Locales Identity Release:: -* trunk Locales Identity Themes:: -* trunk Locales Identity Themes Backgrounds:: -* trunk Locales Identity Themes Distro Anaconda Progress:: -* trunk Locales Identity Widgets:: -* trunk Manuals:: -* trunk Scripts:: -* trunk Scripts Bash:: -* trunk Scripts Bash Cli:: -* trunk Scripts Bash Cli Functions:: -* trunk Scripts Bash Cli Functions Help:: -* trunk Scripts Bash Cli Functions Html:: -* trunk Scripts Bash Cli Functions Locale:: -* trunk Scripts Bash Cli Functions Manual:: -* trunk Scripts Bash Cli Functions Path:: -* trunk Scripts Bash Cli Functions Render:: -* trunk Scripts Bash Cli Functions Render Config:: -* trunk Scripts Bash Cli Functions Shell:: -* trunk Scripts Bash Cli Functions Svg:: -* trunk Scripts Bash Cli Functions Verify:: -* trunk Scripts Python:: -@end menu diff --git a/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi b/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi deleted file mode 100644 index 2ab21f1..0000000 --- a/Manuals/Repository/Filesystem/trunk/chapter-nodes.texi +++ /dev/null @@ -1,300 +0,0 @@ -@node trunk Identity -@section trunk/Identity -@cindex trunk Identity -@include trunk/Identity.texi - -@node trunk Identity Brands -@section trunk/Identity/Brands -@cindex trunk Identity Brands -@include trunk/Identity/Brands.texi - -@node trunk Identity Fonts -@section trunk/Identity/Fonts -@cindex trunk Identity Fonts -@include trunk/Identity/Fonts.texi - -@node trunk Identity Icons -@section trunk/Identity/Icons -@cindex trunk Identity Icons -@include trunk/Identity/Icons.texi - -@node trunk Identity Isolinux -@section trunk/Identity/Isolinux -@cindex trunk Identity Isolinux -@include trunk/Identity/Isolinux.texi - -@node trunk Identity Models -@section trunk/Identity/Models -@cindex trunk Identity Models -@include trunk/Identity/Models.texi - -@node trunk Identity Models Css -@section trunk/Identity/Models/Css -@cindex trunk Identity Models Css -@include trunk/Identity/Models/Css.texi - -@node trunk Identity Models Html -@section trunk/Identity/Models/Html -@cindex trunk Identity Models Html -@include trunk/Identity/Models/Html.texi - -@node trunk Identity Models Img Promo Web -@section trunk/Identity/Models/Img/Promo/Web -@cindex trunk Identity Models Img Promo Web -@include trunk/Identity/Models/Img/Promo/Web.texi - -@node trunk Identity Models Tpl -@section trunk/Identity/Models/Tpl -@cindex trunk Identity Models Tpl -@include trunk/Identity/Models/Tpl.texi - -@node trunk Identity Models Tpl Promo Web -@section trunk/Identity/Models/Tpl/Promo/Web -@cindex trunk Identity Models Tpl Promo Web -@include trunk/Identity/Models/Tpl/Promo/Web.texi - -@node trunk Identity Models Xcf -@section trunk/Identity/Models/Xcf -@cindex trunk Identity Models Xcf -@include trunk/Identity/Models/Xcf.texi - -@node trunk Identity Release -@section trunk/Identity/Release -@cindex trunk Identity Release -@include trunk/Identity/Release.texi - -@node trunk Identity Themes -@section trunk/Identity/Themes -@cindex trunk Identity Themes -@include trunk/Identity/Themes.texi - -@node trunk Identity Themes Models -@section trunk/Identity/Themes/Models -@cindex trunk Identity Themes Models -@include trunk/Identity/Themes/Models.texi - -@node trunk Identity Themes Models Alternative -@section trunk/Identity/Themes/Models/Alternative -@cindex trunk Identity Themes Models Alternative -@include trunk/Identity/Themes/Models/Alternative.texi - -@node trunk Identity Themes Models Default -@section trunk/Identity/Themes/Models/Default -@cindex trunk Identity Themes Models Default -@include trunk/Identity/Themes/Models/Default.texi - -@node trunk Identity Themes Models Default Distro -@section trunk/Identity/Themes/Models/Default/Distro -@cindex trunk Identity Themes Models Default Distro -@include trunk/Identity/Themes/Models/Default/Distro.texi - -@node trunk Identity Themes Models Default Distro Anaconda -@section trunk/Identity/Themes/Models/Default/Distro/Anaconda -@cindex trunk Identity Themes Models Default Distro Anaconda -@include trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi - -@node trunk Identity Themes Models Default Promo -@section trunk/Identity/Themes/Models/Default/Promo -@cindex trunk Identity Themes Models Default Promo -@include trunk/Identity/Themes/Models/Default/Promo.texi - -@node trunk Identity Themes Models Default Web -@section trunk/Identity/Themes/Models/Default/Web -@cindex trunk Identity Themes Models Default Web -@include trunk/Identity/Themes/Models/Default/Web.texi - -@node trunk Identity Themes Motifs -@section trunk/Identity/Themes/Motifs -@cindex trunk Identity Themes Motifs -@include trunk/Identity/Themes/Motifs.texi - -@node trunk Identity Themes Motifs Flame -@section trunk/Identity/Themes/Motifs/Flame -@cindex trunk Identity Themes Motifs Flame -@include trunk/Identity/Themes/Motifs/Flame.texi - -@node trunk Identity Themes Motifs Modern -@section trunk/Identity/Themes/Motifs/Modern -@cindex trunk Identity Themes Motifs Modern -@include trunk/Identity/Themes/Motifs/Modern.texi - -@node trunk Identity Themes Motifs Modern Backgrounds -@section trunk/Identity/Themes/Motifs/Modern/Backgrounds -@cindex trunk Identity Themes Motifs Modern Backgrounds -@include trunk/Identity/Themes/Motifs/Modern/Backgrounds.texi - -@node trunk Identity Themes Motifs Modern Backgrounds Img -@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img -@cindex trunk Identity Themes Motifs Modern Backgrounds Img -@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img.texi - -@node trunk Identity Themes Motifs Modern Backgrounds Tpl -@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl -@cindex trunk Identity Themes Motifs Modern Backgrounds Tpl -@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl.texi - -@node trunk Identity Themes Motifs Modern Backgrounds Xcf -@section trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf -@cindex trunk Identity Themes Motifs Modern Backgrounds Xcf -@include trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf.texi - -@node trunk Identity Themes Motifs Modern Distro Anaconda Progress -@section trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress -@cindex trunk Identity Themes Motifs Modern Distro Anaconda Progress -@include trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress.texi - -@node trunk Identity Themes Motifs Modern Palettes -@section trunk/Identity/Themes/Motifs/Modern/Palettes -@cindex trunk Identity Themes Motifs Modern Palettes -@include trunk/Identity/Themes/Motifs/Modern/Palettes.texi - -@node trunk Identity Themes Motifs TreeFlower -@section trunk/Identity/Themes/Motifs/TreeFlower -@cindex trunk Identity Themes Motifs TreeFlower -@include trunk/Identity/Themes/Motifs/TreeFlower.texi - -@node trunk Identity Themes Motifs TreeFlower Backgrounds -@section trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds -@cindex trunk Identity Themes Motifs TreeFlower Backgrounds -@include trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds.texi - -@node trunk Identity Widgets -@section trunk/Identity/Widgets -@cindex trunk Identity Widgets -@include trunk/Identity/Widgets.texi - -@node trunk Locales -@section trunk/Locales -@cindex trunk Locales -@include trunk/Locales.texi - -@node trunk Locales Identity -@section trunk/Locales/Identity -@cindex trunk Locales Identity -@include trunk/Locales/Identity.texi - -@node trunk Locales Identity Brands -@section trunk/Locales/Identity/Brands -@cindex trunk Locales Identity Brands -@include trunk/Locales/Identity/Brands.texi - -@node trunk Locales Identity Brands Tpl -@section trunk/Locales/Identity/Brands/Tpl -@cindex trunk Locales Identity Brands Tpl -@include trunk/Locales/Identity/Brands/Tpl.texi - -@node trunk Locales Identity Fonts -@section trunk/Locales/Identity/Fonts -@cindex trunk Locales Identity Fonts -@include trunk/Locales/Identity/Fonts.texi - -@node trunk Locales Identity Models -@section trunk/Locales/Identity/Models -@cindex trunk Locales Identity Models -@include trunk/Locales/Identity/Models.texi - -@node trunk Locales Identity Release -@section trunk/Locales/Identity/Release -@cindex trunk Locales Identity Release -@include trunk/Locales/Identity/Release.texi - -@node trunk Locales Identity Themes -@section trunk/Locales/Identity/Themes -@cindex trunk Locales Identity Themes -@include trunk/Locales/Identity/Themes.texi - -@node trunk Locales Identity Themes Backgrounds -@section trunk/Locales/Identity/Themes/Backgrounds -@cindex trunk Locales Identity Themes Backgrounds -@include trunk/Locales/Identity/Themes/Backgrounds.texi - -@node trunk Locales Identity Themes Distro Anaconda Progress -@section trunk/Locales/Identity/Themes/Distro/Anaconda/Progress -@cindex trunk Locales Identity Themes Distro Anaconda Progress -@include trunk/Locales/Identity/Themes/Distro/Anaconda/Progress.texi - -@node trunk Locales Identity Widgets -@section trunk/Locales/Identity/Widgets -@cindex trunk Locales Identity Widgets -@include trunk/Locales/Identity/Widgets.texi - -@node trunk Manuals -@section trunk/Manuals -@cindex trunk Manuals -@include trunk/Manuals.texi - -@node trunk Scripts -@section trunk/Scripts -@cindex trunk Scripts -@include trunk/Scripts.texi - -@node trunk Scripts Bash -@section trunk/Scripts/Bash -@cindex trunk Scripts Bash -@include trunk/Scripts/Bash.texi - -@node trunk Scripts Bash Cli -@section trunk/Scripts/Bash/Cli -@cindex trunk Scripts Bash Cli -@include trunk/Scripts/Bash/Cli.texi - -@node trunk Scripts Bash Cli Functions -@section trunk/Scripts/Bash/Cli/Functions -@cindex trunk Scripts Bash Cli Functions -@include trunk/Scripts/Bash/Cli/Functions.texi - -@node trunk Scripts Bash Cli Functions Help -@section trunk/Scripts/Bash/Cli/Functions/Help -@cindex trunk Scripts Bash Cli Functions Help -@include trunk/Scripts/Bash/Cli/Functions/Help.texi - -@node trunk Scripts Bash Cli Functions Html -@section trunk/Scripts/Bash/Cli/Functions/Html -@cindex trunk Scripts Bash Cli Functions Html -@include trunk/Scripts/Bash/Cli/Functions/Html.texi - -@node trunk Scripts Bash Cli Functions Locale -@section trunk/Scripts/Bash/Cli/Functions/Locale -@cindex trunk Scripts Bash Cli Functions Locale -@include trunk/Scripts/Bash/Cli/Functions/Locale.texi - -@node trunk Scripts Bash Cli Functions Manual -@section trunk/Scripts/Bash/Cli/Functions/Manual -@cindex trunk Scripts Bash Cli Functions Manual -@include trunk/Scripts/Bash/Cli/Functions/Manual.texi - -@node trunk Scripts Bash Cli Functions Path -@section trunk/Scripts/Bash/Cli/Functions/Path -@cindex trunk Scripts Bash Cli Functions Path -@include trunk/Scripts/Bash/Cli/Functions/Path.texi - -@node trunk Scripts Bash Cli Functions Render -@section trunk/Scripts/Bash/Cli/Functions/Render -@cindex trunk Scripts Bash Cli Functions Render -@include trunk/Scripts/Bash/Cli/Functions/Render.texi - -@node trunk Scripts Bash Cli Functions Render Config -@section trunk/Scripts/Bash/Cli/Functions/Render/Config -@cindex trunk Scripts Bash Cli Functions Render Config -@include trunk/Scripts/Bash/Cli/Functions/Render/Config.texi - -@node trunk Scripts Bash Cli Functions Shell -@section trunk/Scripts/Bash/Cli/Functions/Shell -@cindex trunk Scripts Bash Cli Functions Shell -@include trunk/Scripts/Bash/Cli/Functions/Shell.texi - -@node trunk Scripts Bash Cli Functions Svg -@section trunk/Scripts/Bash/Cli/Functions/Svg -@cindex trunk Scripts Bash Cli Functions Svg -@include trunk/Scripts/Bash/Cli/Functions/Svg.texi - -@node trunk Scripts Bash Cli Functions Verify -@section trunk/Scripts/Bash/Cli/Functions/Verify -@cindex trunk Scripts Bash Cli Functions Verify -@include trunk/Scripts/Bash/Cli/Functions/Verify.texi - -@node trunk Scripts Python -@section trunk/Scripts/Python -@cindex trunk Scripts Python -@include trunk/Scripts/Python.texi - diff --git a/Manuals/Repository/Filesystem/trunk/chapter.texi b/Manuals/Repository/Filesystem/trunk/chapter.texi deleted file mode 100644 index 73ba088..0000000 --- a/Manuals/Repository/Filesystem/trunk/chapter.texi +++ /dev/null @@ -1,6 +0,0 @@ -@node trunk -@chapter trunk -@cindex trunk -@include trunk/chapter-intro.texi -@include trunk/chapter-menu.texi -@include trunk/chapter-nodes.texi