diff --git a/Manuals/Repository/Docbook/Introduction/Copying.docbook b/Manuals/Repository/Docbook/Introduction/Copying.docbook new file mode 100644 index 0000000..b51a071 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Copying.docbook @@ -0,0 +1,87 @@ + + + Copying Conditions + + + Copyright © 2009, 2010, 2011 The CentOS Artwork SIG + + + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + + Preamble + + + 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 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 + domain; they are copyrighted and there are restrictions on + their distribution, but these restrictions are designed to + permit everything that a good cooperating citizen would want + to do. What is not allowed is to try to prevent others from + further sharing any version of this program that they might + get from you. + + + + Specifically, we want to make sure that you have the right to + give away copies of centos-art.sh script + 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, if + you distribute copies of the centos-art.sh + script, you must give the recipients all the rights that you + have. You must make sure that they, too, receive or can get + the source code. And you must tell them their rights. + + + + Also, for our own protection, we must make certain that + everyone finds out that there is no warranty for the + centos-art.sh script. If this program is + modified by someone else and passed on, we want their + recipients to know that what they have is not what we + distributed, so that any problems introduced by others will + not reflect on our reputation. + + + + The 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 . This manual specifically is covered + by the . + + + + + diff --git a/Manuals/Repository/Docbook/Introduction/Docconvs.docbook b/Manuals/Repository/Docbook/Introduction/Docconvs.docbook new file mode 100644 index 0000000..8cbaf70 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Docconvs.docbook @@ -0,0 +1,149 @@ + + + Document Convenctions + + 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 + systematic; different words are represented in the same style to + indicate their inclusion in a specific category. The types of + words that are represented this way include the following: + + + + command + + Linux commands (and other operating system + commands, when used) are represented this way. This + style should indicate to you that you can type the + word or phrase on the command line and press Enter to + invoke a command. Sometimes a command contains words + that would be displayed in a different style on their + own (such as file names). In these cases, they are + considered to be part of the command, so the entire + phrase is displayed as a command. For example: + + Use the centos-art identity + --render='path/to/dir' command to produce + contents inside the trunk/Identity directory + structure. + + + + + + file name + + File names, directory names, paths, and RPM + package names are represented this way. This style + indicates that a particular file or directory exists + with that name on your system. Examples: + + 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. + + + + + + key + + A key on the keyboard is shown in this style. + For example: + + To use TAB completion to list + particular files in a directory, type @command{ls}, + then a character, and finally the Tab key. Your + terminal displays the list of files in the working + directory that begin with that character. + + + + + key-combination + + A combination of keystrokes is represented in + this way. For example: + + The CtrlAltBackspace + key combination exits your graphical session and + returns you to the graphical login screen or the + console. + + + + + + + computer output + + Text in this style indicates text displayed to a + shell prompt such as error messages and responses to + commands. For example: + + The ls command displays the + contents of a directory. For example: + + +Config help_renameEntry.sh +help_copyEntry.sh help_restoreCrossReferences.sh +help_deleteCrossReferences.sh help_searchIndex.sh + + + The output returned in response to the command (in this + case, the contents of the directory) is shown in this + style. + + + + + Additionally, we use several different strategies to draw + your attention to certain pieces of information. In order of + urgency, these items are marked as a note, tip, important, + caution, or warning. For example: + + + Remember that Linux is case sensitive. In other words, a + rose is not a ROSE is not a rOsE. + + + + The directory /usr/share/doc/ contains + additional documentation for packages installed on your + system. + + + + If you modify the DHCP configuration file, the changes + do not take effect until you restart the DHCP daemon. + + + + Do not perform routine tasks as root — use a + regular user account unless you need to use the root account + for system administration tasks. + + + + 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/Repository/Docbook/Introduction/Feedback.docbook b/Manuals/Repository/Docbook/Introduction/Feedback.docbook new file mode 100644 index 0000000..5068e59 --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Feedback.docbook @@ -0,0 +1,21 @@ + + + Send in Your Feedback + + + If you find an error in the CentOS Artwork + Repository, or if you have thought of a way to make + this manual better, we would like to hear from you! Share your + suggestions in the appropriate mailing list + (http://lists.centos.org/) and/or bug tracker + (http://bugs.centos.org/). + + + + When you make suggestion, try to be as specific as possible. + For example, if you have found an error in the manual, include + the section number and some of the surrounding text so we can + find it easily. + + + diff --git a/Manuals/Repository/Docbook/Introduction/History.docbook b/Manuals/Repository/Docbook/Introduction/History.docbook new file mode 100644 index 0000000..3b362bc --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/History.docbook @@ -0,0 +1,231 @@ + + + History + + + The CentOS Artwork Repository started during a discussion + about how to automate the slide images of Anaconda, at CentOS + Developers mailing list (centos-devel@centos.org) + around 2008. In such discussion, Ralph Angenendt rose up his + hand to ask —Do you have something to show?—. + + + + To answer the question, Alain Reguera Delgado suggested a bash + script which combined SVG and SED files in order to produce + PNG images in different languages —in conjunction with + the proposition of creating a Subversion repository where + translations and image production could be distributed inside + The CentOS Community—. + + + + Karanbirn Sighn considered the idea intresting and provided + the infrastructure necessary to support the effort. This way + the CentOS Artwork + SIG and the CentOS Artwork + Repository were officially created. + + + + Once the CentOS Artwork Repository was available, Alain + Reguera Delgado uploaded the bash script for rendering + Anaconda 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. + + + + 2009's + + + Around 2009, 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, + different from slide images. In this 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 was created + from the SVG translated instance using Inkscape command-line + interface. + + + + The repository directory structure was prepared to receive the + rendition script using design templates and translation files + in the same location. There was one directory structure for + each artwork that needed to be produced. In this + configuration, if you would want to produce the same artwork + with a different visual style or structure, it was needed to + create a new directory structure for it because both the image + structure and the image visual style were together in the + design template. + + + + The rendition script was moved to a common place and linked + from different directory structures. There was no need to have + the same code in different directory structures if it could be + in just one place and then be linked from different locations. + + + + Corporate identity concepts began to be considered. As + referece, it was used the book "Corporate Identity" by Wally + Olins (1989) and Wikipedia + related links. This way, the rendition script main's goal + becomes to: automate the production process of a + monolithic corporate visual identity structure, based on the + mission and the release schema of The CentOS + Project. + + + + The repository directory structures began to be documented by + mean of flat text files. Later, documentation in flat text + files was moved onto LaTeX format and this way the "The CentOS + Artwork Repository" documentation manual is initiated. + + + + + 2010's + + + Around 2010, 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., documentation and localization). + + + + The centos-art.sh was initially conceived + to automate frequent tasks inside the repository based in the + idea of Unix toolbox: to create small and specialized tools + that do one thing well. This way, functionalities inside + centos-art.sh began to be identified and + separated one another. For example, when images were rendered, + there was no need to load 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 + centos-art.sh script is initiated and are + available to specific functionalities. + + + + Suddenly, no need was found to keep all the links spreaded + around the repository in order to execute the + centos-art.sh script from different + locations. The centos-art command-line interface was used + instead. The centos-art command-line interface is a symbolic + link stored inside the ~/bin directory that point to + centos-art.sh script. As default + configuration, inside The CentOS Distribution, the path to + ~/bin is included in + the search path for commands (see PATH environment variable). + This way, using the centos-art command-line interface, it is + possible for us to execute the + centos-art.sh script from virtually + anywhere inside the workstation, just as we frequently do with + regular commands. + + + + Start using GNU getopt as default option parser inside the + centos-art.sh script. + + + + The repository directory structure was updated to improve the + implementation of corporate visual identity concepts. + Specially in the area related to themes. Having both structure + and style in the same file introduced content duplication when + producing art works. Because of this reason, they were + divided out to separate directory structures: the design + models and artistic motifs directory structures. From this + point on, the centos-art.sh is able to + produce themes as result of arbitrary combinations between + design models (structures) and artistic motifs (visual + styles). + + + + In the documentation area, the documents in LaTeX 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 and copied) + interactively through centos-art.sh script. + Additionally, the texi2html program was used to produced + customized XHTML output in conjunction with CSS from The + CentOS Webenv. + + + + + 2011's + + + Around 2011, the centos-art.sh script was + redesigned to start translating XML-based files (e.g., SVG and + Docbook files) through xml2po program and + shell scripts (e.g., Bash scripts) through GNU gettext tools. + This configuration provided a stronger localization interface + for graphic designers, translators and programmers. The SED + replacement files are no longer used to handle localization. + + + + The render, help and + locale functionalities were consolidated as the + most frequent tasks performed inside the repository. + Additionally, the prepare and tuneup functionalities are also + maintained as useful tasks. + + + + In the documentation area, support for producing localized + transformations of DocBook XML DTD instances was added through + the render and locale functionalities. The + render functionality uses the xsltproc + command-line XSLT parser in conjunction + with the styles provided by the + docbook-style-xsl package, both of them + included inside The CentOS Distribution. The locale + functionality creates the localized portable object + (PO) the render functionality + needs to produce localized transformations of DocBook XML DTD + instances. + + + + To build DocBook documentation, it was considered the idea of + using concepts behind repository directory structure as base, + not the opposite (as I've been doing with Texinfo backend, so + far). + + + + Producing documentation through DocBook XML as default + documentation backend consolidates render and + locale even more. In this configuration, once + the DocBook files are written, you use locale + functionality to localize the DocBook files in your prefered + language and later, using render functionality, + you produce the XTHML and PDF outputs as specified in a XSLT + or DSL customization layer. + + + + + diff --git a/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook b/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook new file mode 100644 index 0000000..7b8258c --- /dev/null +++ b/Manuals/Repository/Docbook/Introduction/Repoconvs.docbook @@ -0,0 +1,369 @@ + + + Repository Convenctions + + The CentOS Artwork Repository is supported by Subversion + (http://subversion.tigris.org/), 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. + + When using Subversion there is one "source repository" and + 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 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 + extracting previous versions of files at any time. + + + + Policy + + The CentOS Artwork Repository is a collaborative tool + that anyone can have access to. However, changing that tool in + any form is something that should be requested in the CentOS + Developers mailing list (centos-devel@centos.org). Generally, + people download working copies from CentOS Artwork Repository, + study the repository organization, make some changes in their + working copies, make some tests to verify such changes do work + the way expected and finally request access to commit them up + to the CentOS Artwork Repository (i.e., the source repository) + for others to benefit from them. + + 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 + cooperating citizen. Otherwise, your rights to + commit changes might be temporarly revoked or permanently + banished. + + 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 conversation has taken place, the paths has been + traced and changing the work is so obvious that there is no + need for you to talk about it; that's because you already did, + you already built the trust to keep going. Anyway, the mailing + list mentioned above is available for sharing ideas in a way + that good relationship between community citizens could be + constantly balanced. + + The relationship between community citizens is monitored + by repository administrators. Repository administrators are + responsible of granting that everything goes the way it needs + to go in 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 visual + identity is built and maintained by The CentOS Community + itself. + + It is also important to remember that all the program + and documentation source files inside CentOS Artwork + Repository must comply the terms of and + respectively in order for them to remain inside the + repository. + + + + + + Work Lines + + Content production inside the repository is organized by + work lines. There are three major work + lines of production inside The CentOS Artwork Repository, + which are: Graphic design, + Documentation and + Localization. The specific way of + producing content inside each specific work line is + standardized by mean of centos-art.sh + script (which in turn, can be considered a work line by itself + [e.g., the Automation work line]). The + centos-art.sh script provides one specific + functionality for automating each major work line of content + production (e.g., render for producing images, + help for manage documentation, and + locale for localizing contents). + + The graphic design work line exists to cover brand + design, typography design and themes design mainly. + Additionally, some auxiliar areas like icon design, + illustration design, brushes design, patterns designs and + palettes of colors are also included here for completeness. + The graphic design work line is organized in the trunk/Identity directory. + + The documentation work line exists to describe what each + directory inside the CentOS Artwork Repository is for, the + conceptual ideas behind them and, if possible, how automation + scripts make use of them. The documentation work line is + organized in the trunk/Manuals directory. + + 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). The localization work line is organized in the + trunk/Locales + directory. + + The automation work line exists to standardize content + 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 is organized in the + trunk/Scripts + directory. + + + + + + Relation Between Directories + + In order for automation scripts to produce content inside a + working copy of CentOS Artwork Repository, it is required that all + work lines be related somehow. The relation is used by automation + scripts to know where to retrive the information they need to work + with (e.g., design model, translation messages, output locations, + etc.). This kind of relation 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 output 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. + + Master paths used for producing images through SVG rendition + are organized under trunk/Identity/Models directory + structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory + structures. + + Auxiliar paths can point either to directories or files. + When an auxiliar path points to a directory, that directory + contains information that modifies somehow the content produced + from master paths (e.g., translation messages) or provides the + output information required to know where the content produced + from the master path should be stored. When an auxiliar path + points to a file, that file has no other purpose but to document + the master path it refers to. + + Auxiliar paths should never be modified under any reason but + to satisfy the relationship with the master path. Liberal change + of auxiliar paths may suppress the conceptual idea they were + initially created for; and certainly, automation scripts may stop + working as expected. + + The relationship between auxiliar paths and master paths is + built by combining the master path and the second level directory + structures of the repository. The master path is considered the + path identifier and the repository second level directory + structure is considered the common part of the path where the path + identifier is appended to. So, if we have the master path + trunk/Identity/Models/Brands, we'll + end up having, at least, the trunk/Identity/Images/Brands auxiliar + path for storing output files and, optionally, one path under + trunk/Manuals for storing + documentation and one path under trunk/Locales for storing + localizations. + + + + + + Syncronizing Paths + + Once both master paths and their auxiliar paths have been + set, they shouldn't be changed. Assuming one master path must be + changed it is required that all related auxiliar paths be changed, + too. This is required in order for master paths to retain their + relation with auxiliar paths. This process of keeping relation + between master paths and auxiliar paths is known as path + syncronization. + + Path syncronization is required for automation scripts to + know where to store final output, where to retrive translation + messages, documentation, and any information that might be + desired. If the relation between master paths and auxiliar paths + is lost, there is no way for centos-art.sh + script to know where to retrive the information it needs to work + with. Path syncronization is the way we use to organize and + extend the information stored in the repository. + + Path syncronization may imply both movement of files and + replacement of content inside files. Movement of files is related + to actions like renaming files and directories inside the + repository. Replacement of content inside files is related to + actions like replacing information (e.g., paths information) + inside files in order to keep file contents and file locations + consistent one another. + + The order followed to syncronize path information is very + important because the versioned nature of the repository files we + are working with. When a renaming action must be performed, we + avoid making replacements inside files first and file movements + later. This would require two commit actions: one for the files' + internal changes and another for the file movement itself. + Otherwise, we prefer to perform file movements first and file + internal replacements later. This way it is possible to commit + both changes as if they were just one. + + There is no support for URLs actions inside + centos-art.sh script. The + centos-art.sh script is designed to work with + local files inside the working copy only. If you need to perform + URL actions directly, use Subversion commands + instead. + + At this moment there is no full implementation of path + syncronization process inside centos-art.sh + script except by texinfo backend of + help functionality which provides a restricted + implementation of path syncronization to this specific area of + documentation through the , + and options. + The plan for a full implementation of path syncronization would be + to create individual restricted implementations like this one for + other areas that demand it and then, create a higher implmentation + that combines all restricted implementations as needed. This way, + if we try to rename a repository directory the higer action will + define which are all the restricted actions that should be + performed in order for make a full path syncronization. For + example, if the directory we are renaming is part of graphic + design work line, it is required to syncronize related paths in + documentation and localization work lines. Likewise, if the + directory we are renaming is in documentation work line, it is + required to syncronize related paths in graphic design and + localization work lines. In all these cases, the direction used + for syncronizing paths must be from master path to auxiliar path + and never the opposite (i.e., rename the master path first and + auxiliar paths later). + + A practical example, through which you can notice the + usefulness of path syncronization process, is what happen when + documentation entries are renamed (see section ...). + + + + + + Extending Repository Organization + + Occasionly, you may find that new components of The + CentOS Project corporate visual identity need to be added to + the repository in order to work them out. If that is the case, + the first question we need to ask ourselves, before start to + create directories blindly all over, is: What is the + right place to store it? + + The best place to find answers is in The CentOS + Community (see page http://wiki.centos.org/Help), 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 in order + to make your own propositions based on it. + + When extending respository structure it is very useful + to bear in mind The CentOS Project corporate visual identity + structure, The CentOS Mission and The CentOS Release Schema. + The rest is a matter of choosing appropriate names. It is also + worth to know that each directory in the repository responds + to a conceptual idea that justifies its existence. + + To build a directory structure inside the repository, + you need to define the conceptual idea first and later create + the directory, remembering that there are locations inside the + repository that define conceptual ideas you probably would + prefer to reuse. For example, the trunk/Identity/Images/Themes + directory stores theme artistic motifs, the trunk/Identity/Models/Themes + directory stores theme design models, the trunk/Manuals directory stores + documentation files, the trunk/Locales stores translation + messages, and the trunk/Scripts stores automation + scripts. + + To better illustrate this desition process, you can + consider to examin the trunk/Identity/Images/Themes/TreeFlower/3 + directory structure as example. This directory can be read + as: the theme development line of version 3 of + TreeFlower artistic motif. Additional, we can + say that TreeFlower artistic motif is part of + themes, as themes are part of The CentOS Project corporate + visual identity. + + The relationship between conceptual ideas can be + stablished by reading each repository documentation entry + individually, from trunk directory to a deeper + directory in the path. For reading repository documentation + entries we use the help functionality of + centos-art.sh script. + + + + + + File Names + + Inside the CentOS Artwork Repository, generally, file + names are all written in lowercase (e.g., + 01-welcome.png, + splash.png, + anaconda_header.png, etc.) and directory + names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel + case (e.g., TreeFlower, + etc.). + + In the very specific case of repository documentation + entries, file names follow the directory naming convenction. + This is because they are documenting directories and that is + something we want to remark. So, to better describe what we + are documenting, documentation entries follow the name + convenction used by the item they document. + + + + + + Repository Layout + + The CentOS Artwork Repository is organized through a + convenctional trunk, branches + and tags layout. Explanation of each directory + inside the repository can be found in the Directories + part. + + + + diff --git a/Manuals/Repository/Docbook/Introduction/copying.docbook b/Manuals/Repository/Docbook/Introduction/copying.docbook deleted file mode 100644 index b51a071..0000000 --- a/Manuals/Repository/Docbook/Introduction/copying.docbook +++ /dev/null @@ -1,87 +0,0 @@ - - - Copying Conditions - - - Copyright © 2009, 2010, 2011 The CentOS Artwork SIG - - - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - - Preamble - - - 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 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 - domain; they are copyrighted and there are restrictions on - their distribution, but these restrictions are designed to - permit everything that a good cooperating citizen would want - to do. What is not allowed is to try to prevent others from - further sharing any version of this program that they might - get from you. - - - - Specifically, we want to make sure that you have the right to - give away copies of centos-art.sh script - 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, if - you distribute copies of the centos-art.sh - script, you must give the recipients all the rights that you - have. You must make sure that they, too, receive or can get - the source code. And you must tell them their rights. - - - - Also, for our own protection, we must make certain that - everyone finds out that there is no warranty for the - centos-art.sh script. If this program is - modified by someone else and passed on, we want their - recipients to know that what they have is not what we - distributed, so that any problems introduced by others will - not reflect on our reputation. - - - - The 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 . This manual specifically is covered - by the . - - - - - diff --git a/Manuals/Repository/Docbook/Introduction/docconvs.docbook b/Manuals/Repository/Docbook/Introduction/docconvs.docbook deleted file mode 100644 index 8cbaf70..0000000 --- a/Manuals/Repository/Docbook/Introduction/docconvs.docbook +++ /dev/null @@ -1,149 +0,0 @@ - - - Document Convenctions - - 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 - systematic; different words are represented in the same style to - indicate their inclusion in a specific category. The types of - words that are represented this way include the following: - - - - command - - Linux commands (and other operating system - commands, when used) are represented this way. This - style should indicate to you that you can type the - word or phrase on the command line and press Enter to - invoke a command. Sometimes a command contains words - that would be displayed in a different style on their - own (such as file names). In these cases, they are - considered to be part of the command, so the entire - phrase is displayed as a command. For example: - - Use the centos-art identity - --render='path/to/dir' command to produce - contents inside the trunk/Identity directory - structure. - - - - - - file name - - File names, directory names, paths, and RPM - package names are represented this way. This style - indicates that a particular file or directory exists - with that name on your system. Examples: - - 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. - - - - - - key - - A key on the keyboard is shown in this style. - For example: - - To use TAB completion to list - particular files in a directory, type @command{ls}, - then a character, and finally the Tab key. Your - terminal displays the list of files in the working - directory that begin with that character. - - - - - key-combination - - A combination of keystrokes is represented in - this way. For example: - - The CtrlAltBackspace - key combination exits your graphical session and - returns you to the graphical login screen or the - console. - - - - - - - computer output - - Text in this style indicates text displayed to a - shell prompt such as error messages and responses to - commands. For example: - - The ls command displays the - contents of a directory. For example: - - -Config help_renameEntry.sh -help_copyEntry.sh help_restoreCrossReferences.sh -help_deleteCrossReferences.sh help_searchIndex.sh - - - The output returned in response to the command (in this - case, the contents of the directory) is shown in this - style. - - - - - Additionally, we use several different strategies to draw - your attention to certain pieces of information. In order of - urgency, these items are marked as a note, tip, important, - caution, or warning. For example: - - - Remember that Linux is case sensitive. In other words, a - rose is not a ROSE is not a rOsE. - - - - The directory /usr/share/doc/ contains - additional documentation for packages installed on your - system. - - - - If you modify the DHCP configuration file, the changes - do not take effect until you restart the DHCP daemon. - - - - Do not perform routine tasks as root — use a - regular user account unless you need to use the root account - for system administration tasks. - - - - 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/Repository/Docbook/Introduction/feedback.docbook b/Manuals/Repository/Docbook/Introduction/feedback.docbook deleted file mode 100644 index 5068e59..0000000 --- a/Manuals/Repository/Docbook/Introduction/feedback.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Send in Your Feedback - - - If you find an error in the CentOS Artwork - Repository, or if you have thought of a way to make - this manual better, we would like to hear from you! Share your - suggestions in the appropriate mailing list - (http://lists.centos.org/) and/or bug tracker - (http://bugs.centos.org/). - - - - When you make suggestion, try to be as specific as possible. - For example, if you have found an error in the manual, include - the section number and some of the surrounding text so we can - find it easily. - - - diff --git a/Manuals/Repository/Docbook/Introduction/history.docbook b/Manuals/Repository/Docbook/Introduction/history.docbook deleted file mode 100644 index 3b362bc..0000000 --- a/Manuals/Repository/Docbook/Introduction/history.docbook +++ /dev/null @@ -1,231 +0,0 @@ - - - History - - - The CentOS Artwork Repository started during a discussion - about how to automate the slide images of Anaconda, at CentOS - Developers mailing list (centos-devel@centos.org) - around 2008. In such discussion, Ralph Angenendt rose up his - hand to ask —Do you have something to show?—. - - - - To answer the question, Alain Reguera Delgado suggested a bash - script which combined SVG and SED files in order to produce - PNG images in different languages —in conjunction with - the proposition of creating a Subversion repository where - translations and image production could be distributed inside - The CentOS Community—. - - - - Karanbirn Sighn considered the idea intresting and provided - the infrastructure necessary to support the effort. This way - the CentOS Artwork - SIG and the CentOS Artwork - Repository were officially created. - - - - Once the CentOS Artwork Repository was available, Alain - Reguera Delgado uploaded the bash script for rendering - Anaconda 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. - - - - 2009's - - - Around 2009, 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, - different from slide images. In this 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 was created - from the SVG translated instance using Inkscape command-line - interface. - - - - The repository directory structure was prepared to receive the - rendition script using design templates and translation files - in the same location. There was one directory structure for - each artwork that needed to be produced. In this - configuration, if you would want to produce the same artwork - with a different visual style or structure, it was needed to - create a new directory structure for it because both the image - structure and the image visual style were together in the - design template. - - - - The rendition script was moved to a common place and linked - from different directory structures. There was no need to have - the same code in different directory structures if it could be - in just one place and then be linked from different locations. - - - - Corporate identity concepts began to be considered. As - referece, it was used the book "Corporate Identity" by Wally - Olins (1989) and Wikipedia - related links. This way, the rendition script main's goal - becomes to: automate the production process of a - monolithic corporate visual identity structure, based on the - mission and the release schema of The CentOS - Project. - - - - The repository directory structures began to be documented by - mean of flat text files. Later, documentation in flat text - files was moved onto LaTeX format and this way the "The CentOS - Artwork Repository" documentation manual is initiated. - - - - - 2010's - - - Around 2010, 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., documentation and localization). - - - - The centos-art.sh was initially conceived - to automate frequent tasks inside the repository based in the - idea of Unix toolbox: to create small and specialized tools - that do one thing well. This way, functionalities inside - centos-art.sh began to be identified and - separated one another. For example, when images were rendered, - there was no need to load 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 - centos-art.sh script is initiated and are - available to specific functionalities. - - - - Suddenly, no need was found to keep all the links spreaded - around the repository in order to execute the - centos-art.sh script from different - locations. The centos-art command-line interface was used - instead. The centos-art command-line interface is a symbolic - link stored inside the ~/bin directory that point to - centos-art.sh script. As default - configuration, inside The CentOS Distribution, the path to - ~/bin is included in - the search path for commands (see PATH environment variable). - This way, using the centos-art command-line interface, it is - possible for us to execute the - centos-art.sh script from virtually - anywhere inside the workstation, just as we frequently do with - regular commands. - - - - Start using GNU getopt as default option parser inside the - centos-art.sh script. - - - - The repository directory structure was updated to improve the - implementation of corporate visual identity concepts. - Specially in the area related to themes. Having both structure - and style in the same file introduced content duplication when - producing art works. Because of this reason, they were - divided out to separate directory structures: the design - models and artistic motifs directory structures. From this - point on, the centos-art.sh is able to - produce themes as result of arbitrary combinations between - design models (structures) and artistic motifs (visual - styles). - - - - In the documentation area, the documents in LaTeX 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 and copied) - interactively through centos-art.sh script. - Additionally, the texi2html program was used to produced - customized XHTML output in conjunction with CSS from The - CentOS Webenv. - - - - - 2011's - - - Around 2011, the centos-art.sh script was - redesigned to start translating XML-based files (e.g., SVG and - Docbook files) through xml2po program and - shell scripts (e.g., Bash scripts) through GNU gettext tools. - This configuration provided a stronger localization interface - for graphic designers, translators and programmers. The SED - replacement files are no longer used to handle localization. - - - - The render, help and - locale functionalities were consolidated as the - most frequent tasks performed inside the repository. - Additionally, the prepare and tuneup functionalities are also - maintained as useful tasks. - - - - In the documentation area, support for producing localized - transformations of DocBook XML DTD instances was added through - the render and locale functionalities. The - render functionality uses the xsltproc - command-line XSLT parser in conjunction - with the styles provided by the - docbook-style-xsl package, both of them - included inside The CentOS Distribution. The locale - functionality creates the localized portable object - (PO) the render functionality - needs to produce localized transformations of DocBook XML DTD - instances. - - - - To build DocBook documentation, it was considered the idea of - using concepts behind repository directory structure as base, - not the opposite (as I've been doing with Texinfo backend, so - far). - - - - Producing documentation through DocBook XML as default - documentation backend consolidates render and - locale even more. In this configuration, once - the DocBook files are written, you use locale - functionality to localize the DocBook files in your prefered - language and later, using render functionality, - you produce the XTHML and PDF outputs as specified in a XSLT - or DSL customization layer. - - - - - diff --git a/Manuals/Repository/Docbook/Introduction/usage.docbook b/Manuals/Repository/Docbook/Introduction/usage.docbook deleted file mode 100644 index 7b8258c..0000000 --- a/Manuals/Repository/Docbook/Introduction/usage.docbook +++ /dev/null @@ -1,369 +0,0 @@ - - - Repository Convenctions - - The CentOS Artwork Repository is supported by Subversion - (http://subversion.tigris.org/), 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. - - When using Subversion there is one "source repository" and - 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 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 - extracting previous versions of files at any time. - - - - Policy - - The CentOS Artwork Repository is a collaborative tool - that anyone can have access to. However, changing that tool in - any form is something that should be requested in the CentOS - Developers mailing list (centos-devel@centos.org). Generally, - people download working copies from CentOS Artwork Repository, - study the repository organization, make some changes in their - working copies, make some tests to verify such changes do work - the way expected and finally request access to commit them up - to the CentOS Artwork Repository (i.e., the source repository) - for others to benefit from them. - - 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 - cooperating citizen. Otherwise, your rights to - commit changes might be temporarly revoked or permanently - banished. - - 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 conversation has taken place, the paths has been - traced and changing the work is so obvious that there is no - need for you to talk about it; that's because you already did, - you already built the trust to keep going. Anyway, the mailing - list mentioned above is available for sharing ideas in a way - that good relationship between community citizens could be - constantly balanced. - - The relationship between community citizens is monitored - by repository administrators. Repository administrators are - responsible of granting that everything goes the way it needs - to go in 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 visual - identity is built and maintained by The CentOS Community - itself. - - It is also important to remember that all the program - and documentation source files inside CentOS Artwork - Repository must comply the terms of and - respectively in order for them to remain inside the - repository. - - - - - - Work Lines - - Content production inside the repository is organized by - work lines. There are three major work - lines of production inside The CentOS Artwork Repository, - which are: Graphic design, - Documentation and - Localization. The specific way of - producing content inside each specific work line is - standardized by mean of centos-art.sh - script (which in turn, can be considered a work line by itself - [e.g., the Automation work line]). The - centos-art.sh script provides one specific - functionality for automating each major work line of content - production (e.g., render for producing images, - help for manage documentation, and - locale for localizing contents). - - The graphic design work line exists to cover brand - design, typography design and themes design mainly. - Additionally, some auxiliar areas like icon design, - illustration design, brushes design, patterns designs and - palettes of colors are also included here for completeness. - The graphic design work line is organized in the trunk/Identity directory. - - The documentation work line exists to describe what each - directory inside the CentOS Artwork Repository is for, the - conceptual ideas behind them and, if possible, how automation - scripts make use of them. The documentation work line is - organized in the trunk/Manuals directory. - - 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). The localization work line is organized in the - trunk/Locales - directory. - - The automation work line exists to standardize content - 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 is organized in the - trunk/Scripts - directory. - - - - - - Relation Between Directories - - In order for automation scripts to produce content inside a - working copy of CentOS Artwork Repository, it is required that all - work lines be related somehow. The relation is used by automation - scripts to know where to retrive the information they need to work - with (e.g., design model, translation messages, output locations, - etc.). This kind of relation 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 output 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. - - Master paths used for producing images through SVG rendition - are organized under trunk/Identity/Models directory - structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory - structures. - - Auxiliar paths can point either to directories or files. - When an auxiliar path points to a directory, that directory - contains information that modifies somehow the content produced - from master paths (e.g., translation messages) or provides the - output information required to know where the content produced - from the master path should be stored. When an auxiliar path - points to a file, that file has no other purpose but to document - the master path it refers to. - - Auxiliar paths should never be modified under any reason but - to satisfy the relationship with the master path. Liberal change - of auxiliar paths may suppress the conceptual idea they were - initially created for; and certainly, automation scripts may stop - working as expected. - - The relationship between auxiliar paths and master paths is - built by combining the master path and the second level directory - structures of the repository. The master path is considered the - path identifier and the repository second level directory - structure is considered the common part of the path where the path - identifier is appended to. So, if we have the master path - trunk/Identity/Models/Brands, we'll - end up having, at least, the trunk/Identity/Images/Brands auxiliar - path for storing output files and, optionally, one path under - trunk/Manuals for storing - documentation and one path under trunk/Locales for storing - localizations. - - - - - - Syncronizing Paths - - Once both master paths and their auxiliar paths have been - set, they shouldn't be changed. Assuming one master path must be - changed it is required that all related auxiliar paths be changed, - too. This is required in order for master paths to retain their - relation with auxiliar paths. This process of keeping relation - between master paths and auxiliar paths is known as path - syncronization. - - Path syncronization is required for automation scripts to - know where to store final output, where to retrive translation - messages, documentation, and any information that might be - desired. If the relation between master paths and auxiliar paths - is lost, there is no way for centos-art.sh - script to know where to retrive the information it needs to work - with. Path syncronization is the way we use to organize and - extend the information stored in the repository. - - Path syncronization may imply both movement of files and - replacement of content inside files. Movement of files is related - to actions like renaming files and directories inside the - repository. Replacement of content inside files is related to - actions like replacing information (e.g., paths information) - inside files in order to keep file contents and file locations - consistent one another. - - The order followed to syncronize path information is very - important because the versioned nature of the repository files we - are working with. When a renaming action must be performed, we - avoid making replacements inside files first and file movements - later. This would require two commit actions: one for the files' - internal changes and another for the file movement itself. - Otherwise, we prefer to perform file movements first and file - internal replacements later. This way it is possible to commit - both changes as if they were just one. - - There is no support for URLs actions inside - centos-art.sh script. The - centos-art.sh script is designed to work with - local files inside the working copy only. If you need to perform - URL actions directly, use Subversion commands - instead. - - At this moment there is no full implementation of path - syncronization process inside centos-art.sh - script except by texinfo backend of - help functionality which provides a restricted - implementation of path syncronization to this specific area of - documentation through the , - and options. - The plan for a full implementation of path syncronization would be - to create individual restricted implementations like this one for - other areas that demand it and then, create a higher implmentation - that combines all restricted implementations as needed. This way, - if we try to rename a repository directory the higer action will - define which are all the restricted actions that should be - performed in order for make a full path syncronization. For - example, if the directory we are renaming is part of graphic - design work line, it is required to syncronize related paths in - documentation and localization work lines. Likewise, if the - directory we are renaming is in documentation work line, it is - required to syncronize related paths in graphic design and - localization work lines. In all these cases, the direction used - for syncronizing paths must be from master path to auxiliar path - and never the opposite (i.e., rename the master path first and - auxiliar paths later). - - A practical example, through which you can notice the - usefulness of path syncronization process, is what happen when - documentation entries are renamed (see section ...). - - - - - - Extending Repository Organization - - Occasionly, you may find that new components of The - CentOS Project corporate visual identity need to be added to - the repository in order to work them out. If that is the case, - the first question we need to ask ourselves, before start to - create directories blindly all over, is: What is the - right place to store it? - - The best place to find answers is in The CentOS - Community (see page http://wiki.centos.org/Help), 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 in order - to make your own propositions based on it. - - When extending respository structure it is very useful - to bear in mind The CentOS Project corporate visual identity - structure, The CentOS Mission and The CentOS Release Schema. - The rest is a matter of choosing appropriate names. It is also - worth to know that each directory in the repository responds - to a conceptual idea that justifies its existence. - - To build a directory structure inside the repository, - you need to define the conceptual idea first and later create - the directory, remembering that there are locations inside the - repository that define conceptual ideas you probably would - prefer to reuse. For example, the trunk/Identity/Images/Themes - directory stores theme artistic motifs, the trunk/Identity/Models/Themes - directory stores theme design models, the trunk/Manuals directory stores - documentation files, the trunk/Locales stores translation - messages, and the trunk/Scripts stores automation - scripts. - - To better illustrate this desition process, you can - consider to examin the trunk/Identity/Images/Themes/TreeFlower/3 - directory structure as example. This directory can be read - as: the theme development line of version 3 of - TreeFlower artistic motif. Additional, we can - say that TreeFlower artistic motif is part of - themes, as themes are part of The CentOS Project corporate - visual identity. - - The relationship between conceptual ideas can be - stablished by reading each repository documentation entry - individually, from trunk directory to a deeper - directory in the path. For reading repository documentation - entries we use the help functionality of - centos-art.sh script. - - - - - - File Names - - Inside the CentOS Artwork Repository, generally, file - names are all written in lowercase (e.g., - 01-welcome.png, - splash.png, - anaconda_header.png, etc.) and directory - names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel - case (e.g., TreeFlower, - etc.). - - In the very specific case of repository documentation - entries, file names follow the directory naming convenction. - This is because they are documenting directories and that is - something we want to remark. So, to better describe what we - are documenting, documentation entries follow the name - convenction used by the item they document. - - - - - - Repository Layout - - The CentOS Artwork Repository is organized through a - convenctional trunk, branches - and tags layout. Explanation of each directory - inside the repository can be found in the Directories - part. - - - -