diff --git a/Manuals/Docbook/Book/abstract.docbook b/Manuals/Docbook/Book/abstract.docbook index 5041fc7..d73469b 100644 --- a/Manuals/Docbook/Book/abstract.docbook +++ b/Manuals/Docbook/Book/abstract.docbook @@ -1,6 +1,6 @@ This manuals documents relevant information regarding the - deployment, organization, and administration of the CentOS Artwork + deployment, organization, and administration of CentOS Artwork Repository. diff --git a/Manuals/Docbook/Book/parts.docbook b/Manuals/Docbook/Book/parts.docbook index 6bff43b..4135e18 100644 --- a/Manuals/Docbook/Book/parts.docbook +++ b/Manuals/Docbook/Book/parts.docbook @@ -4,6 +4,7 @@ &repository-history-chapter; &repository-copying-chapter; &repository-usage-chapter; + &repository-directories-chapter; diff --git a/Manuals/Docbook/Preface/chapter.docbook b/Manuals/Docbook/Preface/chapter.docbook index 493d63b..c905eee 100644 --- a/Manuals/Docbook/Preface/chapter.docbook +++ b/Manuals/Docbook/Preface/chapter.docbook @@ -3,12 +3,13 @@ Introduction - Welcome to CentOS Artwork Repository Manual. + Welcome to The CentOS Artwork Repository + Manual. The CentOS Artwork Repository Manual describes how The CentOS Project Corporate Visual Identity is organized and produced - inside the CentOS Artwork Repository - (@url{https://projects.centos.org/svn/artwork/}). If you are + inside the CentOS Artwork Repository (). If you are looking for a comprehensive, task-oriented guide for understanding how The CentOS Project Corporate Visual Identity is produced, this is the manual for you. @@ -24,8 +25,8 @@ This guide assumes you have a basic understanding of your CentOS system. If you need help with CentOS, refer to the help - page on the CentOS Wiki (@url{http://wiki.centos.org/Help}) for a - list of different places you can find help. + page on the CentOS Wiki () for a list of different places you can find help. &preface-section-1; &preface-section-2; diff --git a/Manuals/Docbook/Preface/section-1.docbook b/Manuals/Docbook/Preface/section-1.docbook index 2988b6e..c58c66f 100644 --- a/Manuals/Docbook/Preface/section-1.docbook +++ b/Manuals/Docbook/Preface/section-1.docbook @@ -3,9 +3,10 @@ Document convenctions - In this manual the personal pronoun @emph{we} is used to - repesent @emph{The CentOS Artwork SIG}. This is, the group of - persons building the CentOS Artwork Repository. + In this manual the personal pronoun we + is used to repesent The CentOS Artwork SIG, + the group of persons that build The CentOS Project corporate + visual identity through the CentOS Artwork Repository. In this manual, certain words are represented in different fonts, typefaces, sizes, and weights. This highlighting is @@ -27,10 +28,12 @@ considered to be part of the command, so the entire phrase is displayed as a command. For example: - Use the @command{centos-art identity - --render='path/to/dir'} command to produce contents - inside the @file{trunk/Identity} directory structure. - + Use the centos-art identity + --render='path/to/dir' command to produce + contents inside the trunk/Identity directory + structure. + @@ -42,14 +45,18 @@ indicates that a particular file or directory exists with that name on your system. Examples: - The @file{init.sh} file in - @file{trunk/Scripts/Bash/Cli/} directory is the - initialization script, written in Bash, used to - automate most of tasks in the repository. + The init.sh file in + trunk/Scripts/Bash/Cli/ + directory is the initialization script, written in + Bash, used to automate most of tasks in the + repository. + + The centos-art command uses + the ImageMagick RPM package to + convert images from PNG format to other + formats. - The @command{centos-art} command uses the - @file{ImageMagick} RPM package to convert images from - PNG format to other formats. @@ -90,8 +97,8 @@ shell prompt such as error messages and responses to commands. For example: - The @command{ls} command displays the contents of a - directory. For example: + The ls command displays the + contents of a directory. For example: Config help_renameEntry.sh @@ -112,32 +119,30 @@ help_deleteCrossReferences.sh help_searchIndex.sh caution, or warning. For example: - @strong{Note} Remember that Linux is case sensitive. In - other words, a rose is not a ROSE is not a rOsE. + Remember that Linux is case sensitive. In other words, a + rose is not a ROSE is not a rOsE. - @strong{Tip} The directory @file{/usr/share/doc/} - contains additional documentation for packages installed on - your system. + The directory @file{/usr/share/doc/} contains additional + documentation for packages installed on your system. - @strong{Important} If you modify the DHCP configuration - file, the changes do not take effect until you restart the - DHCP daemon. + If you modify the DHCP configuration file, the changes + do not take effect until you restart the DHCP daemon. - @strong{Caution} Do not perform routine tasks as root - — use a regular user account unless you need to use the root - account for system administration tasks. + Do not perform routine tasks as root — use a + regular user account unless you need to use the root account + for system administration tasks. - @strong{Warning} Be careful to remove only the necessary - partitions. Removing other partitions could result in data - loss or a corrupted system environment. + Be careful to remove only the necessary partitions. + Removing other partitions could result in data loss or a + corrupted system environment. diff --git a/Manuals/Docbook/Repository/Copying/section-1.docbook b/Manuals/Docbook/Repository/Copying/section-1.docbook index e5c20c7..082c06d 100644 --- a/Manuals/Docbook/Repository/Copying/section-1.docbook +++ b/Manuals/Docbook/Repository/Copying/section-1.docbook @@ -5,9 +5,10 @@ The CentOS Artwork Repository organizes files in a very specific way to implement The CentOS Project corporate visual - identity. This very specific organization of files is part of - centos-art.sh script, a bash script that - automate most of the frequent tasks inside the repository. + identity. This very specific organization of files must be + considered part of centos-art.sh script, a bash + script that automate most of the frequent tasks inside the + repository. The centos-art.sh script and the organization of files it needs to work are not in the public @@ -18,10 +19,11 @@ any version of this program that they might get from you. Specifically, we want to make sure that you have the right - to give away copies of centos-art.sh script, - that you receive source code or else can get it if you want it, - that you can change this program or use pieces of it in new free - programs, and that you know you can do these things. + to give away copies of centos-art.sh script and + the organization of files it needs to work, that you receive + source code or else can get it if you want it, that you can change + this program or use pieces of it in new free programs, and that + you know you can do these things. To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, @@ -38,12 +40,14 @@ any problems introduced by others will not reflect on our reputation. - The centos-art.sh script is released as a GPL work. - Individual packages used by centos-art.sh script include their own - licenses and the centos-art.sh script license applies to all - packages that it does not clash with. If there is a clash between - the centos-art.sh script license and individual package licenses, - the individual package license applies instead. + The centos-art.sh script is released as a + GPL work. Individual packages used by + centos-art.sh script include their own licenses + and the centos-art.sh script license applies to + all packages that it does not clash with. If there is a clash + between the centos-art.sh script license and + individual package licenses, the individual package license + applies instead. The precise conditions of the license for the centos-art.sh script are found in the + provides recognition among other similar projects available on the + Internet. Both The CentOS Brand and all the visual manifestations that derivate from it are available for you to study and propose @@ -17,8 +18,8 @@ Project. If you need to redistribute either The CentOS Brand or any - the visual manifestatinos that derivate from it, write your - intentions to the centos-devel@centos.org mailing - list. + visual manifestation derived from it, write your intentions to the + The CentOS Developers mailing list + (centos-devel@centos.org). diff --git a/Manuals/Docbook/Repository/History/section-1.docbook b/Manuals/Docbook/Repository/History/section-1.docbook index 31d3eab..59ebc75 100644 --- a/Manuals/Docbook/Repository/History/section-1.docbook +++ b/Manuals/Docbook/Repository/History/section-1.docbook @@ -25,8 +25,8 @@ Once the CentOS Artwork Repository was available, Alain Reguera Delagdo uploaded the bash script for rendering Anaconda - slides; Ralph Angenendt documented it very well and The CentOS - Translators started to download working copies of CentOS Artwork - Repository to produce slide images in their own languages. + slides; Ralph Angenendt documented it very well; and people + started to download working copies of CentOS Artwork Repository to + produce slide images in their own languages. diff --git a/Manuals/Docbook/Repository/History/section-2.docbook b/Manuals/Docbook/Repository/History/section-2.docbook index 815893b..a7dc742 100644 --- a/Manuals/Docbook/Repository/History/section-2.docbook +++ b/Manuals/Docbook/Repository/History/section-2.docbook @@ -3,10 +3,10 @@ 2009 - The rendition script is at a very rustic state where only - slide images can be produced, so it was redesigned to extend the + The rendition script was at a very rustic state where only + slide images could be produced, so it was redesigned to extend the image production to other areas, not just slide images. In this - configuration, one SVG file was used as input to produced a + configuration, one SVG file was used as input to produce a translated instance of it which, in turn, was used to produce one translated PNG image as output. The SVG translated instance was created through SED replacement commands. The translated PNG image diff --git a/Manuals/Docbook/Repository/History/section-3.docbook b/Manuals/Docbook/Repository/History/section-3.docbook index 8fbb114..43d2181 100644 --- a/Manuals/Docbook/Repository/History/section-3.docbook +++ b/Manuals/Docbook/Repository/History/section-3.docbook @@ -3,25 +3,27 @@ 2010 - The rendition script render.sh changes to - centos-art.sh script, a collection of - functionalities where rendition is one among others. The - centos-art.sh is created to organize automation - of most frequent tasks inside the repository. There was no need - to have links all around the repository if a command-line - interface can be created (through symbolic links, in the ~/bin directory) and be called - anywhere inside the repository as it would be usually done with - regular commands. + The rendition script changed its name from + render.sh to centos-art.sh + and became a collection of functionalities where rendition was + just one among others (e.g., documenting and localizing). + + The centos-art.sh was created to organize + automation of most frequent tasks inside the repository. There + was no need to have links all around the repository if a + command-line interface could be created (through symbolic links, + in the ~/bin directory) and + be called anywhere inside the repository as it would be a regular + command. Inside centos-art.sh, functionalities started to get identified and separated one another. For example, when images were rendered, there was no need to load - functionalities related to documentation manual. This moved us - onto common functionalities and specific functionalities inside + functionalities related to documentation manual. This layout moved + us onto common functionalities and specific functionalities inside centos-art.sh script. Common functionalities - are loaded when the script is initiated and are available to - specific functionalities but not the opposite. + are loaded when centos-art.sh script is + initiated and are available to specific functionalities. The centos-art.sh script was redesigned to handle command-line options trough getopt @@ -29,17 +31,19 @@ The repository directory structure was updated to improve the implementation of concepts related to corporate visual - identity. Specially in the area related to themes which was - divided into design models and artistic motifs. In this - configuration, themes are produced as result of arbitrary - combinations of both design models (structures) and artistic - motifs (visual styles). + identity. Specially in the area related to themes which were + divided into design models and + artistic motifs to eliminate the content + duplication produced by having both image structure and image + visual style in the same file. Now, themes are produced as result + of arbitrary combinations of both design models (structures) and + artistic motifs (visual styles). In the documentation area, the documentation files in LaTeX - format are migrated to Texinfo. In this configuration, each - directory structure in the repository has a documentation entry - associated in a Texinfo structure which can be read, edited and - administered (e.g., renamed, deleted, copied) interactively + format were migrated to Texinfo format. In this configuration, + each directory structure in the repository has a documentation + entry associated in a Texinfo structure which can be read, edited + and administered (e.g., renamed, deleted, copied) interactively throuch centos-art.sh. Additionally, the texi2html program was used to produced XHTML output customized by CSS from The CentOS Webenv. diff --git a/Manuals/Docbook/Repository/History/section-4.docbook b/Manuals/Docbook/Repository/History/section-4.docbook index fc8ae90..eeeffdc 100644 --- a/Manuals/Docbook/Repository/History/section-4.docbook +++ b/Manuals/Docbook/Repository/History/section-4.docbook @@ -9,11 +9,17 @@ and shell scripts files (e.g., Bash scripts) through GNU gettext tools. This configuration provided a stronger interface for graphic designers, translators and - programmers at time of producing localized content. The SED files - are no longer used to handle translations. + programmers to produce localized content. The SED files are no + longer used to handle translations. Improve option parsing through getopt. + + Consolidate the render, help and + locale functionalities as the most frequent tasks + performed inside the repository. Additionally, the + prepare and tuneup functionalities are + maintained as useful tasks. The centos-art.sh script is updated to organize functionalities in two groups: the administrative diff --git a/Manuals/Docbook/Repository/Usage/chapter.docbook b/Manuals/Docbook/Repository/Usage/chapter.docbook index 2eae5aa..aaa2edc 100644 --- a/Manuals/Docbook/Repository/Usage/chapter.docbook +++ b/Manuals/Docbook/Repository/Usage/chapter.docbook @@ -13,7 +13,7 @@ many "working copies" of that source repository. The working copies are independent one another, can be distributed all around the world and provide a local place for designers, documentors, - translators and programmers to perform their works in a + translators and programmers to perform their work in a descentralized way. The source repository, on the other hand, provides a central place for all independent working copies to interchange data and provides the information required to permit diff --git a/Manuals/Docbook/Repository/Usage/section-1.docbook b/Manuals/Docbook/Repository/Usage/section-1.docbook index ef43a34..024c597 100644 --- a/Manuals/Docbook/Repository/Usage/section-1.docbook +++ b/Manuals/Docbook/Repository/Usage/section-1.docbook @@ -17,11 +17,12 @@ Once you've received access to commit your changes, there is no need for you to request permission again to commit other changes from your working copy to CentOS Artwork Repository as - long as you behave as a good community - citizen. + long as you behave as a good cooperating + citizen. Otherwise, your rights to commit changes might + be temporarly revoked or completly banished. - As a good community citizen one understand of a person who - respects the work already done for others and share ideas with + As a good cooperating citizen one understand of a person who + respects the work already done by others and share ideas with authors before changing relevant parts of their work, specially in situations when the access required to realize the changes has been granted already. Of course, there is a time when @@ -35,14 +36,14 @@ The relationship between community citizens is monitored by repository administrators. Repository administrators are responsible of granting everything goes the way it needs to go in - order for the CentOS Artwork Repository to comply its mission + order for the CentOS Artwork Repository to accomplish its mission which is: to provide a colaborative tool for The CentOS Community where The CentOS Project Corporate Identity is built and - maintained from The CentOS Community itself. + maintained by The CentOS Community itself. It is also important to remember that all source files - inside CentOS Artwork Repository should comply the terms of GNU - General Public License () in order for them to remain inside the - repository. + inside CentOS Artwork Repository should comply the terms of in order for them to remain + inside the repository. diff --git a/Manuals/Docbook/Repository/Usage/section-2.docbook b/Manuals/Docbook/Repository/Usage/section-2.docbook index c5e1b2e..2b414a3 100644 --- a/Manuals/Docbook/Repository/Usage/section-2.docbook +++ b/Manuals/Docbook/Repository/Usage/section-2.docbook @@ -3,16 +3,8 @@ Organization - The CentOS Artwork Repository uses a trunk, branches, and tags organization. The turnk/ directory organizes the main - development line of CentOS Artwork Repository. The branches/ directory oranizes - intermediate development lines taken from the main development - line. The tags/ directory - organizes frozen development lines taken either from the main or - the intermediate lines of development. + The CentOS Artwork Repository organization is described in + the chapter . diff --git a/Manuals/Docbook/Repository/Usage/section-3.docbook b/Manuals/Docbook/Repository/Usage/section-3.docbook index a73a9e0..1d0ded6 100644 --- a/Manuals/Docbook/Repository/Usage/section-3.docbook +++ b/Manuals/Docbook/Repository/Usage/section-3.docbook @@ -1,5 +1,5 @@ - + File names @@ -8,9 +8,10 @@ splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity}, Identity, Themes, Motifs, TreeFlower, etc.). + role="directory">Motifs) and sometimes in cammel case + (e.g., TreeFlower, etc.). + diff --git a/Manuals/Docbook/Repository/Usage/section-4-1.docbook b/Manuals/Docbook/Repository/Usage/section-4-1.docbook index 19f1b3c..06c4c54 100644 --- a/Manuals/Docbook/Repository/Usage/section-4-1.docbook +++ b/Manuals/Docbook/Repository/Usage/section-4-1.docbook @@ -8,66 +8,8 @@ auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. - - Inside CentOS Artwork Repository graphic design is performed - through Inkscape (@url{http://www.inkscape.org/}) and GIMP - (@url{http://www.gimp.org/}). The Inkscape tool is used to create - and manipulate scalable vector graphics and export them to PNG - format; it also provides a command-line interface that we use to - perform massive exportation from SVG files to PNG files in - automation scripts. On the other hand, GIMP is used to create and - manipulate rastered images, create brushes, patterns and palettes - of colors. - - Combine both Inkscape and GIMP specific functionalities - and possibilities to produce very beautiful images. - - The CentOS Project Corporate Visual Identity is made of - different visual manifestations (e.g., Distributions, Web sites, - Stationery, etc.). Visual manifestations implement the corporate - identity concepts by mean of images. To produce these images, we - decompose image production in "design models" and "artistic - motifs". - - Design models provide the structural information of images - (i.e., dimension, position of common elements in the visible area, - translation markers, etc.) and they are generally produced as - scalable vector graphics to take advantage of SVG standard, an - XML-based standard. - - Artistic motifs provide the visual style (i.e., the - background information, the look and feel) some design models need - to complete the final image produced by automation scripts. - Artistic motifs are generally produced as rastered images. - - The result produced from combining one design model with one - artistic motif is what we know as a @emph{theme}. Inside themes - directory structure (@pxref{Directories trunk Identity Images - Themes}), you can find several design models and several artistic - motifs independently one another that can be albitrarily combined - through @emph{theme rendition}, a flexible way to produce images - for different visual manifestations in very specific visual - styles. Inside themes directory structure, theme rendition is - performed in @file{trunk/Identity/Images/Themes} directory - structure, the required design models are taken from - @file{trunk/Identity/Models/Themes} directory structure and the - action itself is controlled by the @code{render} functionality of - centos-art.sh script. - - In addition to theme rendition you can find @emph{direct - rendition}, too. Direct rendition is another way of image - production where there is no artistic motif at all but design - models only. Direct rendition is very useful to produce simple - content that doesn't need specific background information. Some of - these contents are brands, icons and illustrations. Direct - rendition is performed in @file{trunk/Identity/Images}, the - required design models are taken from @file{trunk/Identity/Models} - directory structure and the action itself is controlled by the - @code{render} functionality of centos-art.sh - script. - - @xref{Directories trunk Identity}, for more information - about The CentOS Corporate Identity and how graphic design fits on - it. + + The graphic design work line is organized in the trunk/Identity directory. diff --git a/Manuals/Docbook/Repository/Usage/section-4-2.docbook b/Manuals/Docbook/Repository/Usage/section-4-2.docbook index fb064dc..c063ad3 100644 --- a/Manuals/Docbook/Repository/Usage/section-4-2.docbook +++ b/Manuals/Docbook/Repository/Usage/section-4-2.docbook @@ -8,29 +8,7 @@ conceptual ideas behind them and, if possible, how automation scripts make use of them. - The CentOS Artwork Repository documentation is supported by - Texinfo, a documentation system that uses a single source file to - produce both online information and printed output. - - The repository documentation is organized under - @file{trunk/Manual} directory and uses the repository directory - structre as reference. Each directory in the repository has a - documentation entry associated in the documentation manual. - Documentation entries are stored under - @file{trunk/Manual/Directories} directory and the action itself is - controlled by the @code{help} functionality of - centos-art.sh script. - - The @code{help} functionality let you create, edit and - delete documentation entries in a way that you don't need to take - care of updating menus, nodes and cross reference information - inside the manual structure; the functionality takes care of it - for you. However, if you need to write repository documentation - that have nothing to do with repository directories (e.g., - Preface, Introduction and similar) you need to do it manually, - there is no functionality to automate such process yet. - - @xref{Directories trunk Manual}, for more information on - documentation. + The documentation work line is organized in the trunk/Manuals directory. diff --git a/Manuals/Docbook/Repository/Usage/section-4-3.docbook b/Manuals/Docbook/Repository/Usage/section-4-3.docbook index b1c8d03..86f4f6d 100644 --- a/Manuals/Docbook/Repository/Usage/section-4-3.docbook +++ b/Manuals/Docbook/Repository/Usage/section-4-3.docbook @@ -6,61 +6,9 @@ The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable - objects (e.g., .po, .pot) and machine objects (.mo) under - @file{trunk/Locales} directory structure. - - The procedure used to localize content is taken from - @command{gettext} standard specification. Basically, translatable - strings are retrived from source files in order to create portable - objects and machine objects for them. These portable objects are - editable files that contain the information used by translators to - localize the translatable strings retrived from source files. On - the other hand, machine objects are produced to be machine-redable - only, as its name implies, and are produced from portable - objects. - - Since @command{gettext} needs to extract translatable - strings form source files in order to let translators to localize - them, we are limitted to use source files supported by - @command{gettext} program. This is not a limitation at all since - @command{gettext} supports most popular programming laguages - (e.g., C, C++, Java, Bash, Python, Perl, PHP and GNU Awk just to - mention a few ones). Nevertheless, formats like SVG, XHTML and - Docbook don't figure as supported formats in the list of - @command{gettext} supported source files. - - To translate XML based source files like SVG, XHTML and - Docbook we use the @command{xml2po} program instead. The - @command{xml2po} comes with the @file{gnome-doc-utils} package and - retrives translatable strings from one XML file to produce - portable objects for them. - - Portable objects produced by @command{xml2po} have - the same format that portable objects produced by - @command{gettext}. This make the localization process quite - consistent from translators' point of view. No matter what the - source file be, the translator will always face the same - translation file format (i.e., the portable object format). - - - With the portable object in place, the @command{xml2po} - program is used again to create the final translated XML, just - with the same definition of the source file where translatable - strings were taken from (e.g., if we extract translatable strings - from a SVG file, as result we get the same SVG file but with - translatable strings already localized ---obviously, for this to - happen translators need to localize translatable strings inside - the portable object first, localization won't appear as art of - magic---). When using @command{xml2po}, the machine object is - used as temporal file to produce the final translated XML - file. - - If you want to have your content localized inside - CentOS Artwork Repository be sure to use source files supported - either by @command{gettext} or @command{xml2po} - programs. - - @xref{Directories trunk Locales}, for more - information. - + objects (e.g., .po, .pot) and machine objects (.mo). + + The localization work line is organized in the trunk/Locales directory. + diff --git a/Manuals/Docbook/Repository/Usage/section-4-4.docbook b/Manuals/Docbook/Repository/Usage/section-4-4.docbook index ab6d8ed..2675e81 100644 --- a/Manuals/Docbook/Repository/Usage/section-4-4.docbook +++ b/Manuals/Docbook/Repository/Usage/section-4-4.docbook @@ -4,25 +4,15 @@ Automation The automation work line exists to standardize content - production in CentOS Artwork Repository. There is no need to type - several tasks, time after time, if they can be programmed into - just one executable script. + production inside the working copies of CentOS Artwork Repository. + Here is developed the centos-art.sh script, a + bash script specially designed to automate most frequent tasks + (e.g., rendition, documentation and localization) inside the + repository. There is no need to type several tasks, time after + time, if they can be programmed into just one executable + script. - The automation work line takes place under - @file{trunk/Scripts} directory structure. Here is developed the - centos-art.sh script, a bash script specially - designed to automate most frequent tasks (e.g., rendition, - documentation and localization) inside the repository. Basically, - the centos-art.sh script is divided in several - functionalities independent one another that perform specific - tasks and relay on repository organization to work as - expected. - - If you need to improve the way content is produced, - look inside automation scripts and make your improvement there for - everyone to benefit. - - @xref{Directories trunk Scripts}, for more information on - automation. + The automation work line is organized in the trunk/Scripts directory. diff --git a/Manuals/Docbook/Repository/Usage/section-4.docbook b/Manuals/Docbook/Repository/Usage/section-4.docbook index 0c4790c..08f9d15 100644 --- a/Manuals/Docbook/Repository/Usage/section-4.docbook +++ b/Manuals/Docbook/Repository/Usage/section-4.docbook @@ -4,15 +4,15 @@ Work lines Inside CentOS Artwork Repository there are four major work - lines of production which are: "graphic design", "documentation", - "localization" and "automation". These work lines describe - different areas of content production. Content production inside - these specific areas may vary as much as persons be working on - them. Producing content in too many different ways may result + lines of production which are: graphic design, documentation, + localization and automation. These work lines describe different + areas of content production. Content production inside these + specific areas may vary as much as persons be working on them. + Producing content in too many different ways may result innapropriate in a collaborative environment like CentOS Artwork Repository where content produced in one area depends somehow from - content produced in another different area. So, a "content - production standard" is required for each available work + content produced in another different area. So, a content + production standard is required for each available work line. &repository-usage-section-4-1; diff --git a/Manuals/Docbook/Repository/Usage/section-5.docbook b/Manuals/Docbook/Repository/Usage/section-5.docbook index b310dc5..dc9613d 100644 --- a/Manuals/Docbook/Repository/Usage/section-5.docbook +++ b/Manuals/Docbook/Repository/Usage/section-5.docbook @@ -3,20 +3,27 @@ Connection between directories - In order to produce content in CentOS Artwork Repository, it - is required that all work lines be connected somehow. This is the - way automation scripts can know where to retrive the information - they need to work with (e.g., design model, translation messages, - output location, etc.). We build this kind of connection using - two path constructions named @emph{master paths} and - @emph{auxiliar paths}. - - The master path points only to directories that contain the + In order for automation scripts to produce content inside + working copies of CentOS Artwork Repository, it is required that + all work lines be connected somehow. Using this connection, + automation scripts can know where to retrive the information they + need to work with (e.g., design model, translation messages, + output locations, etc.). This connection is built using two path + constructions named master paths and + auxiliar paths. + + The master path points only to directories that contain source files (e.g., SVG files) required to produce base content (e.g., PNG files) through automation scripts. Each master path inside the repository may have several auxiliar paths associated, - but auxiliar paths can only have one master path - associated. + but auxiliar paths can only have one master path associated. + Master paths are organized under trunk/Identity/Models directory + structure and auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory + structures. The auxiliar paths can point either to directories or files. When an auxiliar path points to a directory, that directory @@ -27,102 +34,11 @@ file, that file has no other purpose but to document the master path it refers to. - The relation between auxiliar paths and master paths is - realized combining two path informations which are: the master - path itself and one second level directory structure from the - repository. Generally, the master path is considered the path - identifier and the second level directory structure taken from the - repository is considered the common part of the path where the - identifier is appended. - - ------+---------------+----------------------------+------+----------- -Path | Suffix | Identifier |Prefix| Type ------+---------------+----------------------------+------+----------- - A | |trunk/Identity/Models/Brands| | Directory ------+---------------+----------------------------+------+----------- - B | trunk/Manual/|trunk/Identity/Models/Brands|.texi | File ------+---------------+----------------------------+------+----------- - C | trunk/Locales/|trunk/Identity/Models/Brands| | Directory ------+---------------+----------------------------+------+----------- - D | |trunk/Identity/Images/Brands| | Directory ------+---------------+----------------------------+------+----------- - E | trunk/Locales/|trunk/Identity/Images/Brands|.texi | File ------+---------------+----------------------------+------+----------- - - A = Master path. - B = Auxiliar path to documentation entry. - C = Auxiliar path to translation messages. - D = Auxiliar path to final content output. - E = Auxiliar path to documentation entry. - - - The path information described above (@pxref{Path - construction}) is used by direct rendition and can be taken as - reference to add other components that are equally produced in the - repository. To add new components that make use of direct - rendition inside the repository, change just the component name - used above (e.g., @file{Brands}) to that one you want to add, - without changing the path structure around it. - - The file organization used by theme rendition extends direct - rendition by separating design models information from backgrounds - information. To better understand this configuration, you can - consider it as two independent lists, one of design models and one - of artistic motifs, which are arbitrary combined between - themselves in order to render images in specific ways. The - possibilities of this configuration are endless and let us - describe visual manifestations very well. For example, consider - the organization used to produce @file{Anaconda} images; for - CentOS distribution major release 5; using @file{Default} design - models and version @file{3} of @file{Flame} artistic motif: - - ------+---------------+------------------------------------------------------+------+----------- -Path | Suffix | Identifier |Prefix| Type ------+---------------+------------------------------------------------------+------+----------- - A | |trunk/Identity/Models/Themes/Default/Distro/5/Anaconda| | Directory ------+---------------+------------------------------------------------------+------+----------- - B | trunk/Manual/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|.texi | File ------+---------------+------------------------------------------------------+------+----------- - C | trunk/Locales/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda| | Directory ------+---------------+------------------------------------------------------+------+----------- - D | |trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda| | Directory ------+---------------+------------------------------------------------------+------+----------- - E | trunk/Locales/|trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda|.texi | File ------+---------------+------------------------------------------------------+------+----------- - - A = Master path. - B = Auxiliar path to documentation entry. - C = Auxiliar path to translation messages. - D = Auxiliar path to final content output. - E = Auxiliar path to documentation entry. - - - The path information described above (@pxref{Path - construction extended}) is used by theme rendition and can be - taken as reference to add other components that are equally - produced in the repository. - - In this configuration we can change both design model name - (e.g., @file{Default}) and artistic motif name (e.g., - @file{Flame/3}) to something else in order to achieve a different - result. The only limitations impossed are the storage space - provided in the server machine and your own creativeness as - graphic designer. - - A theme ready for implementation may consume from 100 - MB to 400 MB of storage space. The exact space consumed by a theme - depends on the amount of screen resolutions the theme supports. - The more screen resolutions the theme supports, the more storage - space demanded for it. - - In this configuration we saw how to build the path - information for @file{Anaconda} component as part of CentOS - Distribution visual manifestation, but that is not the only - component we have inside CentOS Distribution visual manifestation. - There are other components like Syslinux, Grub, Rhgb, Gdm, Kdm, - Gsplash and Ksplash that share a similar file organization to that - described above for @file{Anaconda} component. - + The relationship between auxiliar paths and master paths is + realized by combining the master path itself and the second level + directory structures of the repository. The master path is + considered the path identifier and the second level directory + structure taken from the repository is considered the common part + of the path where the path identifier is appended to. + diff --git a/Manuals/Docbook/Repository/Usage/section-6.docbook b/Manuals/Docbook/Repository/Usage/section-6.docbook index 95b34f1..59684cd 100644 --- a/Manuals/Docbook/Repository/Usage/section-6.docbook +++ b/Manuals/Docbook/Repository/Usage/section-6.docbook @@ -3,13 +3,14 @@ Syncronizing path information - Syncronizing path information is the action that keeps all + Syncronizing path information is the action of keeping all path information up to date in the repository. This action implies - both @emph{file movement} and @emph{file content replacement} in - this very specific order. File movement is related to duplicate, - delete and rename files and directories in the repository. File - content replacement is related to replace information, path - information in this case, inside files in the repository. + both file movement and replacement of content inside files already + moved, in this very specific order. File movement is related to + actions like duplicate, delete and rename files and directories in + the repository. Replacement of content inside files is related to + replace information, path information in this case, inside files + in the repository. The order followed to syncronize path information is relevant because the versioned nature of the files we are working diff --git a/Manuals/Docbook/repository.docbook b/Manuals/Docbook/repository.docbook index d6b1be8..4ea9afc 100644 --- a/Manuals/Docbook/repository.docbook +++ b/Manuals/Docbook/repository.docbook @@ -4,79 +4,87 @@ - - - - - - - - - + + + + + + + + + - - - + + + - - - - - + + + + + - - - + + + - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + + +