| <?xml version="1.0"?> |
| <!DOCTYPE texinfo PUBLIC "-//GNU//DTD TexinfoML V4.8//EN" "http://www.gnu.org/software/texinfo/dtd/4.8/texinfo.dtd"> |
| <texinfo xml:lang="en"> |
| <setfilename>repository.xml</setfilename> |
| <settitle>CentOS Artwork Repository</settitle> |
| |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009, 2010, 2011 The CentOS Project</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. |
| </para> |
| <titlepage> |
| <booktitle>CentOS Artwork Repository</booktitle> |
| <booksubtitle>Manual</booksubtitle> |
| <author>Alain Reguera Delgado</author> |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009, 2010, 2011 The CentOS Project</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.</para> |
| </titlepage> |
| <contents></contents> |
| |
| <node> |
| <nodename>Top</nodename> |
| <nodeup>(dir)</nodeup> |
| <unnumbered> |
| <title>CentOS Artwork Repository</title> |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009, 2010, 2011 The CentOS Project</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.</para> |
| <menu> |
| <menuentry> |
| <menunode>Introduction</menunode> |
| <menutitle>Introduction</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories</menunode> |
| <menutitle>Directories</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Licenses</menunode> |
| <menutitle>Licenses</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Index</menunode> |
| <menutitle>Index</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>List of Figures</menunode> |
| <menutitle>List of Figures</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| |
| </unnumbered> |
| </node> |
| <node> |
| <nodename>Introduction</nodename> |
| <nodenext>Directories</nodenext> |
| <nodeprev>Top</nodeprev> |
| <nodeup>Top</nodeup> |
| <chapter> |
| <title>Introduction</title> |
| <para><indexterm index="cp">Introduction</indexterm>Welcome to CentOS Artwork Repository Manual.</para> |
| <para>The CentOS Artwork Repository Manual describes how The CentOS Project Corporate Visual Identity is organized and produced inside the CentOS Artwork Repository (<uref><urefurl>https://projects.centos.org/svn/artwork/</urefurl></uref>). 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.</para> |
| <para>This manual discusses the following intermedite topics:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The CentOS Brand</para> |
| </item> |
| <item> |
| <para>The CentOS Corporate Visual Structure</para> |
| </item> |
| <item> |
| <para>The CentOS Corporate Visual Style</para> |
| </item> |
| </itemize> |
| <para>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 (<uref><urefurl>http://wiki.centos.org/Help</urefurl></uref>) for a list of different places you can find help.</para> |
| <menu> |
| <menuentry> |
| <menunode>History</menunode> |
| <menutitle>History</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Authors</menunode> |
| <menutitle>Authors</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Copying Conditions</menunode> |
| <menutitle>Copying Conditions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Document Convenctions</menunode> |
| <menutitle>Document Convenctions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Repository Convenctions</menunode> |
| <menutitle>Repository Convenctions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Feedback</menunode> |
| <menutitle>Feedback</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </chapter> |
| </node> |
| <node> |
| <nodename>History</nodename> |
| <nodenext>Authors</nodenext> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>History</title> |
| <para><indexterm index="cp">History</indexterm>This section records noteworthy changes of CentOS Artwork Repository through years.</para> |
| <subheading>2008</subheading> |
| <para>The CentOS Artwork Repository started at CentOS Developers mailing list (<email><emailaddress>centos-devel@centos.org</emailaddress></email>) during a discussion about how to automate the slide images of Anaconda. In such discussion, Ralph Angenendt rose up his hand to ask: Do you have something to show?</para> |
| <para>To answer the question, Alain Reguera Delgado posted a bash script to produce slide images in different languages —together with the proposition of creating a Subversion centralized repository where translations and image production could be distributed inside The CentOS Community—.</para> |
| <para>Karanbirn Sighn considered the idea intresting and provides the infrastructure necessary to support the effort. This way the CentOS Artwork SIG and the CentOS Artwork Repository are officially created and made available in the following urls:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><uref><urefurl>https://projects.centos.org/trac/artwork/</urefurl></uref></para> |
| </item> |
| <item> |
| <para><uref><urefurl>https://projects.centos.org/svn/artwork/</urefurl></uref></para> |
| </item> |
| </itemize> |
| <para>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.</para> |
| <subheading>2009</subheading> |
| <para>The rendition script is at a very rustic state where only slide images can be produced.</para> |
| <para>The rendition script is improved to produce not only slide images, but PNG images using one SVG file as input. In this configuration one translated SVG instance was created from the SVG provided as input in order to produce one translated PNG image as output. The translation of SVG files is made through SED replacement commands and the rendition of PNG images is realized through Inkscape command line internface.</para> |
| <para>The rendition script is named <command>render.sh</command>. The directory structures are prepared to receive the rendition script so images could be produced inside them. Each directory structure has design templates (.svg), translation files (.sed), and translated images (.png).</para> |
| <para>The rendition script is unified in a common place and linked from different directory structures. There is no need to have the same code in different directory structures if it can be in just one place and then be linked from different locations.</para> |
| <para>The concepts of corporate identity started to be considered. As referece, it is used Wikipedia (<uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref>) and the book <emph>Corporate Identity</emph> by Wally Olins (1989).</para> |
| <para>The rendition script main's goal becomes to: automate production of a monolithic corporate visual identity structure based on The CentOS Mission and The CentOS Release Schema.</para> |
| <para>The documentation of CentOS Artwork Repository starts to take form in &latex; format.</para> |
| <subheading>2010</subheading> |
| <para>The rendition script <command>render.sh</command> is no longer a rendition script, but a collection of functionalities grouped into the <command>centos-art.sh</command> script where rendition is one functionality among others. The <command>centos-art.sh</command> is created to automate most frequent tasks inside the repository. There is no need to have links all around the repository if a command-line interface can be created and called anywhere inside the repository as it is usually done with regular commands.</para> |
| <para>Inside <command>centos-art.sh</command>, functionalities started to get identified and separated one another. For example, when images are rendered, there is no need to load functionalities related to documentation manual. There is now common functionalities and specific functionalities. Common functionalities are loaded when the script is initiated and are available to specific functionalities.</para> |
| <para>The <command>centos-art.sh</command> script is updated to handle options trough <command>getopt</command> option parser.</para> |
| <para>The repository directory structure is updated to improve the implementation of corporate visual identity concepts.</para> |
| <subheading>2011</subheading> |
| <para>The <command>centos-art.sh</command> script is updated to translate SVG and other XML-based files (e.g., XHTML and Docbook) through <command>xml2po</command> program and shell scripts files through <command>xgettext</command> command. In this configuration there is no need to use `.sed' translation files as they previously were used.</para> |
| <para>The <command>centos-art.sh</command> script is updated to improve option parsing through <command>getopt</command> program. All arguments are parsed by <command>getopt</command> now. Once all option arguments have been parsed, only non-option arguments remain for processing.</para> |
| <para>The <command>centos-art.sh</command> script is updated to organize functionalities in two groups: “the administrative functionalities” and “the productive functionalities”. The administrative functionalities cover actions like: copying, deleting and renaming directory structures inside the repository. Also, preparing your workstation for using <command>centos-art.sh</command> script, making backups of the distribution theme currently installed, installing themes created inside repository and restoring themes from backup. On the other hand, the productive functionalities cover actions like: content rendition, content localization, content documentation and content maintainance.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Authors</nodename> |
| <nodenext>Copying Conditions</nodenext> |
| <nodeprev>History</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Authors</title> |
| <para><indexterm index="cp">Authors</indexterm>This section records authoring information of CentOS Artwork Repository along the years:</para> |
| <subheading>Graphic Design</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Guideon de Kok</para> |
| </item> |
| <item> |
| <para><email><emailaddress>al@art.centos.org</emailaddress><emailname>Alain Reguera Delgado</emailname></email></para> |
| </item> |
| <item> |
| <para><email><emailaddress>mm@art.centos.org</emailaddress><emailname>Marcus Moeller</emailname></email></para> |
| </item> |
| </itemize> |
| <subheading>Documentation</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><email><emailaddress>al@art.centos.org</emailaddress><emailname>Alain Reguera Delgado</emailname></email></para> |
| </item> |
| <item> |
| <para><email><emailaddress>ralph@dev.centos.org</emailaddress><emailname>Ralph Angenendt</emailname></email></para> |
| </item> |
| </itemize> |
| <subheading>Localization</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><email><emailaddress>al@art.centos.org</emailaddress><emailname>Alain Reguera Delgado</emailname></email> (Spanish)</para> |
| </item> |
| </itemize> |
| <subheading>Automation</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><email><emailaddress>al@art.centos.org</emailaddress><emailname>Alain Reguera Delgado</emailname></email></para> |
| </item> |
| </itemize> |
| <subheading>Infrastructure</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><email><emailaddress>karan@dev.centos.org</emailaddress><emailname>Karanbirn Singh</emailname></email></para> |
| </item> |
| <item> |
| <para><email><emailaddress>ralph@dev.centos.org</emailaddress><emailname>Ralph Angenendt</emailname></email></para> |
| </item> |
| </itemize> |
| <subheading>Packaging</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><email><emailaddress>karan@dev.centos.org</emailaddress><emailname>Karanbirn Singh</emailname></email></para> |
| </item> |
| <item> |
| <para><email><emailaddress>ralph@dev.centos.org</emailaddress><emailname>Ralph Angenendt</emailname></email></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Copying Conditions</nodename> |
| <nodenext>Document Convenctions</nodenext> |
| <nodeprev>Authors</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Copying Conditions</title> |
| <para><indexterm index="cp">Copying conditions</indexterm></para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Copyright (C) 2009, 2010, 2011 The CentOS Project |
| ]]></verbatim> |
| <para>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.</para> |
| <subheading>Preamble</subheading> |
| <para>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 <command>centos-art.sh</command> script, a bash script that automates most of the frequent tasks inside the repository.</para> |
| <para>The <command>centos-art.sh</command> 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.</para> |
| <para>Specifically, we want to make sure that you have the right to give away copies of <command>centos-art.sh</command> 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.</para> |
| <para>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 <command>centos-art.sh</command> 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.</para> |
| <para>Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the <command>centos-art.sh</command> 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.</para> |
| <para>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.</para> |
| <para>The precise conditions of the license for the <command>centos-art.sh</command> script are found in the General Public Licenses (see <xref><xrefnodename>GNU General Public License</xrefnodename></xref>). This manual specifically is covered by the GNU Free Documentation License (see <xref><xrefnodename>GNU Free Documentation License</xrefnodename></xref>).</para> |
| <subheading>1. The CentOS Brand</subheading> |
| <para>The CentOS Brand (see <xref><xrefnodename>Directories trunk Identity Models Brands</xrefnodename></xref>) is the main visual manifestaion of The CentOS Project. The CentOS Project uses The CentOS Brand to connect all its visual manifestions (e.g., GNU/Linux Distributions, Websites, Stationery, etc.) and, this way, provide recognition among other similar projects.</para> |
| <para>Both The CentOS Brand and all the visual manifestations that derivate from it are available for you to be able to study and improve them around a good citizen's will inside The CentOS Community environment, but you are not allowed to redistribute them elsewhere, without the given permission of The CentOS Project.</para> |
| <para>If you need to redistribute either The CentOS Brand or any the visual manifestatinos that derivate from it, write your intentions to the <email><emailaddress>centos-devel@centos.org</emailaddress></email> mailing list.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Document Convenctions</nodename> |
| <nodenext>Repository Convenctions</nodenext> |
| <nodeprev>Copying Conditions</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Document Convenctions</title> |
| <para><indexterm index="cp">Document convenctions</indexterm>In this manual the personal pronoun <emph>we</emph> is used to repesent <emph>The CentOS Artwork SIG</emph>. This is, the group of persons building the CentOS Artwork Repository.</para> |
| <para>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:</para> |
| <table> |
| <tableitem> |
| <tableterm><command>command</command></tableterm> |
| <item> |
| <para>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:</para> |
| <para>Use the <command>centos-art identity --render='path/to/dir'</command> command to produce contents inside the <file>trunk/Identity</file> directory structure.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><file>file name</file></tableterm> |
| <item> |
| <para>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:</para> |
| <para>The <file>init.sh</file> file in <file>trunk/Scripts/Bash/Cli/</file> directory is the initialization script, written in Bash, used to automate most of tasks in the repository.</para> |
| <para>The <command>centos-art</command> command uses the <file>ImageMagick</file> RPM package to convert images from PNG format to other formats.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><key><key>key</key></key></tableterm> |
| <item> |
| <para>A key on the keyboard is shown in this style. For example:</para> |
| <para>To use <key>TAB</key> completion to list particular files in a directory, type <command>ls</command>, then a character, and finally the Tab key. Your terminal displays the list of files in the working directory that begin with that character.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><key><key>key-combination</key></key></tableterm> |
| <item> |
| <para>A combination of keystrokes is represented in this way. For example:</para> |
| <para>The <key>Ctrl-Alt-Backspace</key> key combination exits your graphical session and returns you to the graphical login screen or the console.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><code><code>computer output</code></code></tableterm> |
| <item> |
| <para>Text in this style indicates text displayed to a shell prompt such as error messages and responses to commands. For example:</para> |
| <para>The <command>ls</command> command displays the contents of a directory. For example:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Config manual_renameEntry.sh |
| manual_copyEntry.sh manual_restoreCrossReferences.sh |
| manual_deleteCrossReferences.sh manual_searchIndex.sh |
| ]]></verbatim> |
| <para>The output returned in response to the command (in this case, the contents of the directory) is shown in this style.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>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:</para> |
| <quotation> |
| <para><strong>Note</strong> Remember that Linux is case sensitive. In other words, a rose is not a ROSE is not a rOsE.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Tip</strong> The directory <file>/usr/share/doc/</file> contains additional documentation for packages installed on your system.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Important</strong> If you modify the DHCP configuration file, the changes do not take effect until you restart the DHCP daemon.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Caution</strong> Do not perform routine tasks as root — use a regular user account unless you need to use the root account for system administration tasks.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Warning</strong> Be careful to remove only the necessary partitions. Removing other partitions could result in data loss or a corrupted system environment.</para> |
| </quotation> |
| </section> |
| </node> |
| <node> |
| <nodename>Repository Convenctions</nodename> |
| <nodenext>Feedback</nodenext> |
| <nodeprev>Document Convenctions</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Repository Convenctions</title> |
| <para><indexterm index="cp">Repository convenctions</indexterm>The CentOS Artwork Repository is supported by Subversion (<uref><urefurl>http://subversion.tigris.org/</urefurl></uref>), 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.</para> |
| <para>When using Subversion there is one <emph>source repository</emph> and many <emph>working copies</emph> 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 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.</para> |
| |
| <subsection> |
| <title>Repository policy</title> |
| <para><indexterm index="cp">Repository policy</indexterm> 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 <email><emailaddress>centos-devel@centos.org</emailaddress></email> mailing list. 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.</para> |
| <para>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 <emph>good community citizen</emph>.</para> |
| <para>As a good community citizen one understand of a person who respects the work already done for 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.</para> |
| <para>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 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.</para> |
| <para>It is also important to remember that all source files inside CentOS Artwork Repository should comply the terms of GNU General Public License (see <xref><xrefnodename>GNU General Public License</xrefnodename></xref>) in order for them to remain inside the repository.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Repository organization</title> |
| <para><indexterm index="cp">Repository organization</indexterm> The CentOS Artwork Repository uses a <file>trunk</file>, <file>branches</file>, and <file>tags</file> organization.</para> |
| <table> |
| <tableitem> |
| <tableterm><file>trunk</file></tableterm> |
| <item> |
| <para>The <file>trunk</file> directory organizes the main development line of CentOS Artwork Repository. See <xref><xrefnodename>Directories trunk</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><file>branches</file></tableterm> |
| <item> |
| <para>The <file>branches</file> directory oranizes intermediate development lines taken from the main development line. See <xref><xrefnodename>Directories branches</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><file>tags</file></tableterm> |
| <item> |
| <para>The <file>tags</file> directory organizes frozen development lines taken either from the main or the intermediate lines of development. See <xref><xrefnodename>Directories tags</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>Repository file names</title> |
| <para><indexterm index="cp">Repository file names</indexterm> Inside the CentOS Artwork Repository, file names are all written in lowercase (e.g., <samp>01-welcome.png</samp>, <samp>splash.png</samp>, <samp>anaconda_header.png</samp>, etc.) and directory names are all written capitalized (e.g., <samp>Identity</samp>, <samp>Themes</samp>, <samp>Motifs</samp>, <samp>TreeFlower</samp>, etc.).</para> |
| </subsection> |
| |
| <subsection> |
| <title>Repository work lines</title> |
| <para>Inside CentOS Artwork Repository there are four major work lines of production which are: <emph>graphic design</emph>, <emph>documentation</emph>, <emph>localization</emph> and <emph>automation</emph>. 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 <emph>content production standard</emph> is required for each available work line.</para> |
| |
| <subsubsection> |
| <title>Graphic design</title> |
| <para><indexterm index="cp">Graphic design work line</indexterm> 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.</para> |
| <para>Inside CentOS Artwork Repository graphic design is performed through Inkscape (<uref><urefurl>http://www.inkscape.org/</urefurl></uref>) and GIMP (<uref><urefurl>http://www.gimp.org/</urefurl></uref>). 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.</para> |
| <quotation> |
| <para><strong>Tip</strong> Combine both Inkscape and GIMP specific functionalities and possibilities to produce very beautiful images.</para> |
| </quotation> |
| <para>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 <emph>design models</emph> and <emph>artistic motifs</emph>.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>The result produced from combining one design model with one artistic motif is what we know as a <emph>theme</emph>. Inside themes directory structure (see <xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>), you can find several design models and several artistic motifs independently one another that can be albitrarily combined through <emph>theme rendition</emph>, 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</file> directory structure, the required design models are taken from <file>trunk/Identity/Models/Themes</file> directory structure and the action itself is controlled by the <code>render</code> functionality of <command>centos-art.sh</command> script.</para> |
| <para>In addition to theme rendition you can find <emph>direct rendition</emph>, 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</file>, the required design models are taken from <file>trunk/Identity/Models</file> directory structure and the action itself is controlled by the <code>render</code> functionality of <command>centos-art.sh</command> script.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>, for more information about The CentOS Corporate Identity and how graphic design fits on it.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Documentation</title> |
| <para><indexterm index="cp">Documentation work line</indexterm> 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.</para> |
| <para>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.</para> |
| <para>The repository documentation is organized under <file>trunk/Manual</file> directory structure and uses the repository directories as reference. Each directory structure in the repository has a documentation entry associated in the documentation manual. Documentation entries are stored under <file>trunk/Manual/Directories</file> directory structure and the action itself is controlled by the <code>help</code> functionality of <command>centos-art.sh</command> script.</para> |
| <para>The <code>help</code> 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.</para> |
| <para>See <xref><xrefnodename>Directories trunk Manual</xrefnodename></xref>, for more information on documentation.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Localization</title> |
| <para><indexterm index="cp">Localization work line</indexterm> 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</file> directory structure.</para> |
| <para>The procedure used to localize content is taken from <command>gettext</command> 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.</para> |
| <para>Since <command>gettext</command> 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</command> program. This is not a limitation at all since <command>gettext</command> 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</command> supported source files.</para> |
| <para>To translate XML based source files like SVG, XHTML and Docbook we use the <command>xml2po</command> program instead. The <command>xml2po</command> comes with the <file>gnome-doc-utils</file> package and retrives translatable strings from one XML file to produce portable objects for them.</para> |
| <quotation> |
| <para><strong>Note</strong> Portable objects produced by <command>xml2po</command> have the same format that portable objects produced by <command>gettext</command>. 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).</para> |
| </quotation> |
| <para>With the portable object in place, the <command>xml2po</command> 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</command>, the machine object is used as temporal file to produce the final translated XML file.</para> |
| <quotation> |
| <para><strong>Tip</strong> If you want to have your content localized inside CentOS Artwork Repository be sure to use source files supported either by <command>gettext</command> or <command>xml2po</command> programs.</para> |
| </quotation> |
| <para>See <xref><xrefnodename>Directories trunk Locales</xrefnodename></xref>, for more information.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Automation</title> |
| <para><indexterm index="cp">Automation work line</indexterm> 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.</para> |
| <para>The automation work line takes place under <file>trunk/Scripts</file> directory structure. Here is developed the <command>centos-art.sh</command> script, a bash script specially designed to automate most frequent tasks (e.g., rendition, documentation and localization) inside the repository. Basically, the <command>centos-art.sh</command> script is divided in several functionalities independent one another that perform specific tasks and relay on repository organization to work as expected.</para> |
| <quotation> |
| <para><strong>Tip</strong> If you need to improve the way content is produced, look inside automation scripts and make your improvement there for everyone to benefit.</para> |
| </quotation> |
| <para>See <xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref>, for more information on automation.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Connection between directories</title> |
| <para><indexterm index="cp">Connection between directories</indexterm><indexterm index="cp">Master paths</indexterm><indexterm index="cp">Auxiliar paths</indexterm> 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</emph> and <emph>auxiliar paths</emph>.</para> |
| <para>The master path points only to directories that contain the 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.</para> |
| <para>The 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 to store the content produced from master path. When an auxiliar path points to a file, that file has no other purpose but to document the master path it refers to.</para> |
| <para>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.</para> |
| <float name="Path construction"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| -----+---------------+----------------------------+------+----------- |
| 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. |
| ]]></verbatim> |
| <caption>Path construction.</caption> |
| </float> |
| <para>The path information described above (see <xref><xrefnodename>Path construction</xrefnodename></xref>) 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</file>) to that one you want to add, without changing the path structure around it.</para> |
| <para>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</file> images; for CentOS distribution major release 5; using <file>Default</file> design models and version <file>3</file> of <file>Flame</file> artistic motif:</para> |
| <float name="Path construction extended"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| -----+---------------+------------------------------------------------------+------+----------- |
| 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. |
| ]]></verbatim> |
| <caption>Path construction extended.</caption> |
| </float> |
| <para>The path information described above (see <xref><xrefnodename>Path construction extended</xrefnodename></xref>) is used by theme rendition and can be taken as reference to add other components that are equally produced in the repository.</para> |
| <para>In this configuration we can change both design model name (e.g., <file>Default</file>) and artistic motif name (e.g., <file>Flame/3</file>) 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.</para> |
| <quotation> |
| <para><strong>Note</strong> 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.</para> |
| </quotation> |
| <para>In this configuration we saw how to build the path information for <file>Anaconda</file> 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</file> component.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Syncronizing path information</title> |
| <para><indexterm index="cp">Syncronizing path information</indexterm> Syncronizing path information is the action that keeps all path information up to date in the repository. This action implies both <emph>file movement</emph> and <emph>file content replacement</emph> 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.</para> |
| <para>The order followed to syncronize path information is relevant because the versioned nature of the files we are working with. We don't perform file content replacement first because that would imply a repository change which will immediatly demmand a commit in order for actions like duplicate, delete or rename to take place. However, if we perform file movement first, it is possible to commit both file moved and file content replacements as if they were just one change. In this case the file content replacement takes palce in the target location that have been duplicated or renamed, not the one use as source location. This configuration is specially useful when files are renamed (i.e., one file is copied from a source location to a target location and then the source location of it is removed from repository).</para> |
| <quotation> |
| <para><strong>Warning</strong> There is no support for URLs actions inside <command>centos-art.sh</command> script. The <command>centos-art.sh</command> 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.</para> |
| </quotation> |
| <para>When one master path is 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 way, automation scripts are able to know where to retrive translation messages from, where to store final output images to and where to look for documentation. If relation between master paths and auxiliar paths is lost, there is no way for automation scripts to know where to retrive the information they need.</para> |
| <para>The 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 update direction to rename path information must be from master path to auxiliar path and never the opposite.</para> |
| <para>The relation between master and auxiliar paths is useful to keep repository organized but introduce some complications when we work with files that use master path information as reference to build structural information. This is the case of repository documentation manual source files where inclusions, menus, nodes and cross references are built using master path information as reference. Now, to see what kind of complication we are talking about, consider what would happen to a structural definitions (i.e., inlusions, menus, nodes and cross refereces) already set in the manual from one master path that is suddenly renamed to something different. If the path information is not syncronized, at this point, we lose connection between the master path and the auxiliar path created to store the related documentation entry, as well as the related structural definitions that end up pointing to a master path that no longer exist.</para> |
| <para>The syncronization of path information is aimed to solve these kind of issues.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Extending repository organization</title> |
| <para><indexterm index="cp">Extending repository organization</indexterm> Occasionly, you may find that new components of The CentOS Project Corporate 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: <emph>What is the right place to store it?</emph></para> |
| <para>The best place to find answers is in The CentOS Community (see page <uref><urefurl>http://wiki.centos.org/GettingHelp</urefurl></uref>), 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.</para> |
| <para>When extending respository structure it is very useful to bear in mind The CentOS Project Corporate Identity Structure (see <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>) The CentOS Mission and The CentOS Release Schema. The rest is just 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.</para> |
| <para>To build a directory structure, you need to define the conceptual idea first and later create the directory. There are some locations inside the repository that already define some concepts you probably want to reuse. For example, <file>trunk/Identity/Images/Themes</file> to store theme artistic motifs, <file>trunk/Identity/Models/Themes</file> to store theme design models, <file>trunk/Manual</file> to store documentation files, <file>trunk/Locales</file> to store translation messages, <file>trunk/Scripts</file> to store automation scripts and so on.</para> |
| <para>To illustrate this desition process let's consider the <file>trunk/Identity/Images/Themes/TreeFlower/3</file> directory structure as example. This directory can be read as: the theme development line of version <file>3</file> of <file>TreeFlower</file> artistic motif. Additional, we can identify that artistic motifs are part of themes as well as themes are part of The CentOS Project Corporate Identity. These concepts are better described independently in each documentation entry related to the directory structure as it is respectively shown in the list of commands bellow.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art help --read turnk |
| centos-art help --read turnk/Identity |
| centos-art help --read turnk/Identity/Themes |
| centos-art help --read turnk/Identity/Images/Themes |
| centos-art help --read turnk/Identity/Images/Themes/TreeFlower |
| centos-art help --read turnk/Identity/Images/Themes/TreeFlower/3 |
| ]]></verbatim> |
| <para>The concepts behind other location can be found in the same way described above, just change the path information used above to the one you are trying to know concepts for.</para> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Feedback</nodename> |
| <nodeprev>Repository Convenctions</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Send in Your Feedback</title> |
| <para><indexterm index="cp">Feedback</indexterm>If you find an error in the <emph>CentOS Artwork Repository</emph>, 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 (<uref><urefurl>http://lists.centos.org/</urefurl></uref>) and/or bug tracker (<uref><urefurl>http://bugs.centos.org/</urefurl></uref>).</para> |
| <para>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.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories</nodename> |
| <nodenext>Licenses</nodenext> |
| <nodeprev>Introduction</nodeprev> |
| <nodeup>Top</nodeup> |
| <chapter> |
| <title>The Repository Directories</title> |
| <para><indexterm index="cp">Repository directories</indexterm>The CentOS Artwork Repository uses directories to organize files and describe conceptual idea about corporate identity. Such conceptual ideas are explained in each directory related documentation entry.</para> |
| <para>In this chapter you'll learn what each directory inside The CentOS Artwork Repository is for and so, how you can make use of them. For that purpose, the following list of directories is available for you to explore:</para> |
| <menu> |
| <menuentry> |
| <menunode>Directories branches</menunode> |
| <menutitle>Directories branches</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories tags</menunode> |
| <menutitle>Directories tags</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Brushes</menunode> |
| <menutitle>Directories trunk Identity Brushes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Fonts</menunode> |
| <menutitle>Directories trunk Identity Fonts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images</menunode> |
| <menutitle>Directories trunk Identity Images</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes</menunode> |
| <menutitle>Directories trunk Identity Images Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes Motifs</menunode> |
| <menutitle>Directories trunk Identity Images Themes Motifs</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes Motifs Flame</menunode> |
| <menutitle>Directories trunk Identity Images Themes Motifs Flame</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes Motifs Modern</menunode> |
| <menutitle>Directories trunk Identity Images Themes Motifs Modern</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes Motifs Pipes</menunode> |
| <menutitle>Directories trunk Identity Images Themes Motifs Pipes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes Motifs TreeFlower</menunode> |
| <menutitle>Directories trunk Identity Images Themes Motifs TreeFlower</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models</menunode> |
| <menutitle>Directories trunk Identity Models</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Brands</menunode> |
| <menutitle>Directories trunk Identity Models Brands</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes</menunode> |
| <menutitle>Directories trunk Identity Models Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Concept</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Concept</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Anaconda</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Anaconda</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Firstboot</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Firstboot</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Gdm</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Gdm</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Grub</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Grub</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Gsplash</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Gsplash</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Kdm</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Kdm</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Ksplash</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Ksplash</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Rhgb</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Rhgb</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Distro 5 Syslinux</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Distro 5 Syslinux</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Themes Default Posters</menunode> |
| <menutitle>Directories trunk Identity Models Themes Default Posters</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Palettes</menunode> |
| <menutitle>Directories trunk Identity Palettes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Patterns</menunode> |
| <menutitle>Directories trunk Identity Patterns</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Webenv</menunode> |
| <menutitle>Directories trunk Identity Webenv</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales</menunode> |
| <menutitle>Directories trunk Locales</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Manual</menunode> |
| <menutitle>Directories trunk Manual</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions</menunode> |
| <menutitle>Directories trunk Scripts Functions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Help</menunode> |
| <menutitle>Directories trunk Scripts Functions Help</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Locale</menunode> |
| <menutitle>Directories trunk Scripts Functions Locale</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Prepare</menunode> |
| <menutitle>Directories trunk Scripts Functions Prepare</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Render</menunode> |
| <menutitle>Directories trunk Scripts Functions Render</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Tuneup</menunode> |
| <menutitle>Directories trunk Scripts Functions Tuneup</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </chapter> |
| </node> |
| <node> |
| <nodename>Directories branches</nodename> |
| <nodenext>Directories tags</nodenext> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>branches</file> Directory</title> |
| <para><indexterm index="cp">Directories branches</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure.</para> |
| <subheading>Description</subheading> |
| <para>The <file>branches/</file> directory structure provides the intermediate space for creating several instances of <file>trunk/</file> directory structure for parallel development and later merging changes back to <file>trunk/</file> in the same parallel basis.</para> |
| <subheading>Usage</subheading> |
| <para>The <file>branches/</file> directory structure is unused, so far.</para> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories tags</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>The Subversion book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories tags</nodename> |
| <nodenext>Directories trunk</nodenext> |
| <nodeprev>Directories branches</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>tags</file> Directory</title> |
| <para><indexterm index="cp">Directories tags</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This directory implements the Subversion's tags concept in a trunk, branches, tags repository structure.</para> |
| <subheading>Description</subheading> |
| <para>The <file>tags/</file> directory structure provides frozen branches. Generally, we use frozen branches to make check-points in time for development lines under <file>branches/</file> or <file>trunk/</file> directory structure.</para> |
| <subheading>Usage</subheading> |
| <para>The <file>tags/</file> directory structure is unused, so far.</para> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories branches</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>The subversion book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk</nodename> |
| <nodenext>Directories trunk Identity</nodenext> |
| <nodeprev>Directories tags</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/</file> directory structure implements the Subversion's trunk concept in a trunk, branches, tags repository structure.</para> |
| <subheading>Description</subheading> |
| <para>The <file>trunk/</file> directory structure provides the main development line inside the CentOS Artwork Repository.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Manual</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Locales</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories branches</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories tags</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>The Subversion book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity</nodename> |
| <nodenext>Directories trunk Identity Brushes</nodenext> |
| <nodeprev>Directories trunk</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/Identity</file> describes what The CentOS Project Corporate Identity is and the components it is made of.</para> |
| <subheading>Description</subheading> |
| <para>The CentOS Project Corporate Identity is the “persona” of the organization known as The CentOS Project. The CentOS Project Corporate Identity plays a significant role in the way The CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, The CentOS Project Corporate Identity expresses the values and ambitions of The CentOS Project organization, its business, and its characteristics.</para> |
| <para>The CentOS Project Corporate Identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of <emph>Corporate Design</emph>, <emph>Corporate Communication</emph>, and <emph>Corporate Behaviour</emph>.</para> |
| <image width="450pt" height="" name="trunk/Identity/Images/Manual/Corporate/monolithic" extension="jpg"><alttext></alttext></image> |
| <subsubheading>Corporate Mission</subsubheading> |
| <para>The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively.</para> |
| <subsubheading>Corporate Design</subsubheading> |
| <para>Corporate design is focused on the effective communication of corporate visual messages. Corporate visual messages are all the information emitted by a corporation that can be perceived by the people through their visual sence (i.e., the human eye). In order for such visual communication to happen, it is required to put the visual message on medium available for people to see. These kind of media are know as corporate visual manifestations, since the corporate manifests its existence through them using corporate design.</para> |
| <para>The amount of visual manifestations a corporation uses to communicate its existence is very specific to each corporation itself. Inside The CentOS Project Corporate Identity, considering <emph>The CentOS Project Corporate Structure</emph>, <emph>The CentOS Project Corporate Mission</emph> and <emph>The CentOS Project Release Schema</emph>, the following visual manifestations were defined:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>The CentOS Distribution</strong></tableterm> |
| <item> |
| <para>The CentOS Distribution visual manifestation exists to cover all actions related to artwork production and rebranding required by the The CentOS Distribution (— <strong>Removed</strong>(pxref:Directories trunk Identity Images Themes Models Default Distro) —) in order to comply with its upstream redistribution guidelines.</para> |
| <para>The CentOS Distribution is made of software packages. Inside the distribution there are packages that make a remarkable use of images and there are packages that don't use images at all. The CentOS Distribution visual manifestation gets focused on software packages that do use images in a remarkable way (e.g., <file>anaconda</file>, <file>grub</file>, <file>syslinux</file>, <file>gdm</file>, <file>kdm</file>) and that way, through images, implements the corporate design in The CentOS Distribution (i.e., the operating system).</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>The CentOS Web</strong></tableterm> |
| <item> |
| <para>The CentOS Web visual manifestation exists to support The CentOS Distribution.</para> |
| <para>The CentOS Web covers web applications which let The CentOS Project to manifest its existence on the Internet. Through these web applications The CentOS Project provides Corporate Communication. These web applications are free software and come from different providers which distribute their work with predefined visual styles. Frequently, these predefined visual styles have no visual relation among themselves and introduce some visual contraditions when they all are put together. These visual contraditions need to be removed in order to comply with The CentOS Project Corporate Structure guidelines.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>The CentOS Showroom</strong></tableterm> |
| <item> |
| <para>The CentOS Showroom visual manifestation exists to promote The CentOS Distribution.</para> |
| <para>The CentOS Showroom covers industrial production of objects branded by The CentOS Project (e.g., clothes, stationery and installation media). These branded objects are for distribution on social events and/or shops. They provide a way of promotion and a route for commercialization that may help to aliviate The CentOS Project expenses (e.g., electrical power, hosting, servers, full-time-developers, etc.), in a similar way as donations may do.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>The visual manifestations above seem to cover all the media required by The CentOS Project, as organization, to show its existence. However, other visual manifestations could be added in the future, if needed, to cover different areas like building, offices, road transportation and whaterver visual manifestation The CentOS Project thouches to show its existence.</para> |
| <subsubheading>Corporate Communication</subsubheading> |
| <para>The CentOS Project Corporate Communication is based on <emph>Community Communication</emph> and takes place through the following avenues:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The CentOS Chat (<code>#centos</code>, <code>#centos-social</code>, <code>#centos-devel</code> on irc.freenode.net)</para> |
| </item> |
| <item> |
| <para>The CentOS Mailing Lists (<uref><urefurl>http://lists.centos.org/</urefurl></uref>).</para> |
| </item> |
| <item> |
| <para>The CentOS Forums (<uref><urefurl>http://forums.centos.org/</urefurl></uref>).</para> |
| </item> |
| <item> |
| <para>The CentOS Wiki (<uref><urefurl>http://wiki.centos.org/</urefurl></uref>).</para> |
| </item> |
| <item> |
| <para>Social events, interviews, conferences, etc.</para> |
| </item> |
| </itemize> |
| <subsubheading>Corporate Behaviour</subsubheading> |
| <para>The CentOS Project Corporate Behaviour is based on <emph>Community Behaviour</emph> which take place on <emph>Corporate Communication</emph>.</para> |
| <subsubheading>Corporate Structure</subsubheading> |
| <para>The CentOS Project Corporate Structure is based on a <emph>Monolithic Corporate Visual Identity Structure</emph>. In this configuration, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project.</para> |
| <para>In a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting web sites, using the distribution, or acting on social events, the one unique name and one unique visual style connects them all to say: <emph>Hey! we are all part of The CentOS Project</emph>.</para> |
| <para>Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major release of The CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project is made of.</para> |
| <para>The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Showroom. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. However, inside The CentOS Web visual manifestations, the content is produced for no specific release information (e.g., there is no a complete web site for each major release of The CentOS Distribution individually, but one web site to cover them all). Likewise, the content produced in The CentOS Showroom is created for no release-specific at all, but for The CentOS Project in general.</para> |
| <para>In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., The CentOS Web and The CentOS Showroom)?</para> |
| <para>Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain?</para> |
| <para>Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and, that, certainly, didn't come through swinging magical wands or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Corporate Structure must be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition.</para> |
| <para>Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem itself is in not propagating the brand new visual style created for the new release of The CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository.</para> |
| <subheading>Usage</subheading> |
| <para>The <file>trunk/Identity</file> directory structure organizes most files used to build and implement The CentOS Project Corporate Identity. In that sake, the following work lines are available:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Brushes</strong></tableterm> |
| <item> |
| <para>This work line provides brushes for GIMP. When you prepare the repository, brushes in this location are made available immediatly for you to use in the “Brushes” panel of GIMP.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Brushes</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Fonts</strong></tableterm> |
| <item> |
| <para>This work line provides the typography information required by all different visual manifestations of The CentOS Project. When you prepare the repository, fonts in this location are made available immediatly for you to use in GIMP and Inkscape.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Fonts</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Images</strong></tableterm> |
| <item> |
| <para>This work line provides output location for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.).</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Images</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Models</strong></tableterm> |
| <item> |
| <para>This work line provides design models for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.).</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Models</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Palettes</strong></tableterm> |
| <item> |
| <para>This work line provides palettes of colors for GIMP and Inkscape. When you prepare the repository, palettes of colors in this location are made available immediatly for you to use in the “Palettes” panel of GIMP and Inkscape.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Palettes</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Patterns</strong></tableterm> |
| <item> |
| <para>This work line provides patterns for GIMP. When you prepare the repository, patterns in this location are made available immediatly for you to use in the “Patterns” panel of GIMP.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Patterns</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Themes</strong></tableterm> |
| <item> |
| <para>This work line provides theme design models and theme artistic motifs for The CentOS Project. If you are interested in creating brand new visual styles for The CentOS Project this is the place for you.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Webenv</strong></tableterm> |
| <item> |
| <para>This work line provides the HTML/XHTML and CSS standard definitions used by The CentOS Web visual manifestation. If you are a web developer and plan to improve The CentOS Web visual manifestation, then the files in this location may result very useful to you.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Webenv</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subheading>See also</subheading> |
| <para>See <uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref> (and related links), for general information on Corporate Identity.</para> |
| <para>Specially useful has been, and still is, the book <emph>Corporate Identity</emph> by Wally Olins (1989). This book provides many of the conceptual ideas we've used as base to build The CentOS Artwork Repository.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Brushes</nodename> |
| <nodenext>Directories trunk Identity Fonts</nodenext> |
| <nodeprev>Directories trunk Identity</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Brushes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Brushes</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes how brushes are organized in the repository and how to make them available for you to use in <acronym><acronymword>GIMP</acronymword><acronymdesc>GNU Image Manipulation Program</acronymdesc></acronym>.</para> |
| <subheading>Description</subheading> |
| <para>A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've organized brushes in <emph>common brushes</emph> and <emph>theme-specific brushes</emph>. In both cases, brushes are initially created in <file>.xcf</file> format and later exported to any of the brush formats recognized by GIMP (e.g., <file>.gbr</file> or <file>.gih</file>) using the same name of its source file.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| 1. Common brushes 2. Theme-specific brushes |
| ---------------------- ----------------------------------------------------------- |
| trunk/Identity/Brushes trunk/Identity/Images/Themes/THEMENAME/THEMEVERSION/Brushes |
| |-- Xcf |-- Xcf |
| | |-- 1.xcf | |-- 1.xcf |
| | |-- 2.xcf | |-- 2.xcf |
| | `-- 3.xcf | `-- 3.xcf |
| |-- 1.gbr |-- 1.gbr |
| |-- 2.gih |-- 2.gih |
| `-- 3.gbr `-- 3.gbr |
| ]]></verbatim> |
| <para>In order for both common brushes and theme-specific brushes to be loaded by GIMP, related <file>.gbr</file> and <file>.gih</file> brush files need to be stored under <file>~/.gimp-2.2/brushes</file> directory. This location is out of CentOS Artwork Repository and provides no version control by itself. This way, brushes aren't exported to this location but into the repository directory structure which is versioned. Later, we create symbolic links in <file>~/.gimp-2.2/brushes</file> to connect file brushes inside the repository and, this way, provide the configuration needed by GIMP to use the brush files produced inside the repository.</para> |
| <quotation> |
| <para><strong>Warning</strong> When brushes are added to or removed from the repository, you need to update your working copy and all information related to brushes inside your workstation (e.g., brush links in <file>~/.gimp-2.2/brushes</file> and the Brushes panel in GIMP). Otherwise, you may end up with broken links or brushes in the repository that wouldn't be available for you to use in GIMP.</para> |
| </quotation> |
| <para>Inside the repository, common brushes and theme-specific brushes are created individually in different locations, but they all are linked from one unique location (i.e., <file>~/.gimp-2.2/brushes</file>). This configuration may provoke brush overlapping if a name convenction is not implemented correctly. In that sake, file names used for brushes inside the repository must be unique, no matter where they be.</para> |
| <para>As file name convenction inside the repository, brushes are named using lowercase letters, numbers, minus characters and dot characters, only. Additionally, when links are built, we use one suffix for those brushes retrived from <file>trunk/Identity/Brushes</file> and another suffix for those brushes retrivided from theme-specific directories. Using both the brush file name and the suffix information, it is possible to build unique names for links under <file>~/.gimp-2.2/brushes</file> directory, scalably.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Brushes |
| |-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-1.gbr (link) |
| |-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-2.gbr (link) |
| `-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-3.gbr (link) |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Images/Themes/THEMENAME/THEMEVERSION/Brushes |
| |-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-1.gbr (link) |
| |-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-2.gbr (link) |
| `-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION-3.gbr (link) |
| ]]></verbatim> |
| <para>Brushes produced with GIMP has a description field associated that is shown in the Brushes panel of GIMP. This description is set when the brush is created as <file>.xcf</file> file and can be updated when it is exported either to <file>.gbr</file> or <file>.gih</file> format. It wouldn't be too useful to have two or more brushes using the same description so, we also make description of brush files unique, too. In that sake, we use the same name schema used to name brush links as description but without including the file extension (e.g., if we have the <file>centos-flame-3.gbr</file> brush, its description would be <code>centos-flame-3</code>).</para> |
| <subheading>Usage</subheading> |
| <para>The way you use brushes is up to your creativeness. However, the way brushes are made available needs to be standardized. That's the reason of organizing brushes in common brushes and theme-specific brushes.</para> |
| <subheading>Common brushes</subheading> |
| <para>Common brushes exist to organize brushes that can be used anywhere inside the repository. Inside the repository, common brushes under <file>trunk/Identity/Brushes</file> are mainly used to hold brand information related to The CentOS Project (e.g., symbols, logos, trademarks, etc.).</para> |
| <para>Common brushes are always made available under <file>~/.gimp-2.2/brushes</file> directory after preparing the repository (see <xref><xrefnodename>Directories trunk Scripts Functions Prepare</xrefnodename></xref>).</para> |
| <subheading>Theme-specific brushes</subheading> |
| <para>Theme-specific brushes exist to organize brushes that can be used inside specific artistic motifs only. Inside the repository, theme-specific brushes are stored in a directory named <file>Brushes</file> which is stored in the first directory level under the artistic motif directory structure. Each artistic motif inside the repository has its own <file>Brushes</file> directory and uses it to store brushes that can be considered auxiliars to that artistic motif construction.</para> |
| <para>Theme-specific brushes aren't made available under <file>~/.gimp-2.2/brushes</file> directory after preparing the repository. In order to make theme-specific brushes available under <file>~/.gimp-2.2./brushes</file> it is required to activate/deactivate them using the <code>theme</code> functionality of <command>centos-art.sh</command> script. |
| </para> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><uref><urefurl>file:///usr/share/gimp/2.0/help/en/index.html</urefurl><urefdesc>The Gimp Manual</urefdesc></uref>, specifically the section related to <uref><urefurl>file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.html</urefurl><urefdesc>Brushes</urefdesc></uref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Fonts</nodename> |
| <nodenext>Directories trunk Identity Images</nodenext> |
| <nodeprev>Directories trunk Identity Brushes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Fonts</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Fonts</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes how typographies are organized in the repository and how to make them available for you to use in <acronym><acronymword>GIMP</acronymword><acronymdesc>GNU Image Manipulation Program</acronymdesc></acronym> and Inkscape.</para> |
| <subheading>Description</subheading> |
| <para>The CentOS Project Corporate Identity is attached to <samp>DejaVu LGC</samp> font-family and <samp>Denmark</samp> font-family.</para> |
| <image width="430pt" height="" name="trunk/Identity/Images/Manual/Fonts/dejavu-lgc" extension="jpg"><alttext></alttext></image> |
| <image width="430pt" height="" name="trunk/Identity/Images/Manual/Fonts/denmark" extension="jpg"><alttext></alttext></image> |
| <quotation> |
| <para><strong>Caution</strong> The copyright and license of <samp>Denmark</samp> typography aren't very specific and that issue may represent a threat to The CentOS Project Corporate Identity.</para> |
| </quotation> |
| <para>The <samp>Denmark</samp> typography is used as base to build The CentOS Logo (i.e., the main graphic design that connects/identifies all visual manifestations related to The CentOS Project). If the typography used to build The CentOS Logo is compromised somehow, the whole corporate visual identity it represents would be compromised, as well. To prevent such issues, it would be better for The CentOS Project to move on from <samp>Denmark</samp> typography to another typography (free, preferably) that retain the same visual style of <samp>Denmark</samp>, but intruce a clearer copyright and license notice.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity Models Brands</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images</nodename> |
| <nodenext>Directories trunk Identity Images Themes</nodenext> |
| <nodeprev>Directories trunk Identity Fonts</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes</nodename> |
| <nodenext>Directories trunk Identity Images Themes Motifs</nodenext> |
| <nodeprev>Directories trunk Identity Images</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/Identity/Themes/</file> directory exists to organize production of CentOS themes.</para> |
| <subheading>Description</subheading> |
| <para>Initially, we start working themes on their trunk development line (e.g., <file>trunk/Identity/Images/Themes/TreeFlower/</file>), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.).</para> |
| <para>Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., <file>branches/Identity/Images/Themes/TreeFlower/1/</file>). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up.</para> |
| <para>Once the branch has been tunned up, and considered “ready” for release, it is freezed under <file>tags/</file> directory (e.g., <file>tags/Identity/Images/Themes/TreeFower/1.0/</file>) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for.</para> |
| <para>Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., <samp>1</samp>) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., <samp>0</samp>) and increment one unit for each tag created from the same branch development line.</para> |
| <quotation> |
| <para><strong>Convenction</strong> Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead.</para> |
| </quotation> |
| <para>The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository.</para> |
| <para>If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit.</para> |
| <para>Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene.</para> |
| <para>Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under <file>tags/</file> directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project.</para> |
| <subheading>Usage</subheading> |
| <para>In this location themes are organized in “Models” —to store common information— and “Motifs”—to store unique information. At rendering time, both motifs and models are combined to produce the final CentOS themes. CentOS themes can be tagged as “Default” or “Alternative”. CentOS themes are maintained by CentOS community.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity Models Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Images Themes Motifs) —.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes Motifs</nodename> |
| <nodenext>Directories trunk Identity Images Themes Motifs Flame</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes/Motifs</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes Motifs</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/Identity/Images/Themes</file> directory exists to:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize CentOS themes' artistic motifs.</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <para>The artistic motif of theme is a graphic design component that provides the visual style of themes, it is used as pattern to connect all visual manifestations inside one unique theme.</para> |
| <para>Artistic motifs are based on conceptual ideas. Conceptual ideas bring the motivation, they are fuel for the engines of human imagination. Good conceptual ideas may produce good motivation to produce almost anything, and art works don't escape from it.</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>TreeFlower</samp></tableterm> |
| <item> |
| <para>CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Modern</samp></tableterm> |
| <item> |
| <para>Modern, squares and circles flowing up.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>If you have new conceptual ideas for CentOS, then you can say that you want to create a new artistic motif for CentOS. To create a new artistic motif you need to create a directory under <file>Identity/Images/Themes/</file> using a name coherent with your conceptual idea. That name will be the name of your artistic motif. If possible, when creating new conceptual ideas for CentOS, think about what CentOS means for you, what does it makes you feel, take your time, think deep, and share; you can improve the idea as time goes on.</para> |
| <para>Once you have defined a name for your theme, you need to create the motif structure of your theme. The motif structure is the basic direcotry structure you'll use to work your ideas. Here is where you organize your graphic design projects.</para> |
| <para>To add a new motif structure to CentOS Artwork Repository, you need to use the <command>centos-art</command> command line in the <file>Identity/Images/Themes/</file> directory as described below:</para> |
| <example xml:space="preserve">centos-art add --motif=ThemeName</example> |
| <para>The previous command will create the basic structure of themes for you. The basic structure produced by <command>centos-art</command> command is illustrated in the following figure:</para> |
| <example xml:space="preserve">trunk/Identity/Images/Themes/$ThemeName/ |
| |-- Backgrounds |
| | |-- Img |
| | `-- Tpl |
| |-- Info |
| | |-- Img |
| | `-- Tpl |
| |-- Palettes |
| `-- Screenshots</example> |
| <subheading>Usage</subheading> |
| <para>When designing artistic motifs for CentOS, consider the following recommendations:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Give a unique (case-sensitive) name to your Motif. This name is used as value wherever theme variable (<b>$THEME</b>) or translation marker (<b>=THEME=</b>) is. Optionally, you can add a description about inspiration and concepts behind your work.</para> |
| </item> |
| <item> |
| <para>Use the location <file>trunk/Identity/Images/Themes/$THEME/</file> to store your work. If it doesn't exist create it. Note that this require you to have previous commit access in CentOS Artwork Repository.</para> |
| </item> |
| <item> |
| <para>The CentOS Project is using the blue color (<b>#204c8d</b>) as base color for its corporate visual identity. Use such base corporate color information as much as possible in your artistic motif designs.</para> |
| </item> |
| <item> |
| <para>Try to make your design fit one of the theme models.</para> |
| </item> |
| <item> |
| <para>Feel free to make your art enterprise-level and beautiful.</para> |
| </item> |
| <item> |
| <para>Add the following information on your artwork (both in a visible design area and document metadata):</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The name (or logo) of your artistic motif.</para> |
| </item> |
| <item> |
| <para>The copyright sentence: <b>Copyright (C) YEAR YOURNAME</b></para> |
| </item> |
| <item> |
| <para>The license under which the work is released. All CentOS Art works are released under <uref><urefurl>http://creativecommons.org/licenses/by-sa/3.0/</urefurl><urefdesc>Creative Common Share-Alike License 3.0</urefdesc></uref> (<uref><urefurl>http://creativecommons.org/licenses/by-sa/3.0/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Images Themes</menunode> |
| <menutitle>Directories trunk Identity Images Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| <para>The <file>Backgrounds/</file> directory is used to organize artistic motif background images and the projects used to build those images.</para> |
| <para>Background images are linked (using the <b>import</b> feature of Inkscape) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas.</para> |
| <para>In this configuration you design background images for different screen resolutions based on the theme artistic motif.</para> |
| <para>You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea.</para> |
| <para>Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.).</para> |
| <para>Each artistic motif directory represents just one unique artistic motif.</para> |
| <para>The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes.</para> |
| <para>Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif.</para> |
| <para>Inside CentOS Artwork Repository, theme visual styles (a.k.a., artistic motifs) and theme visual structures (a.k.a., design models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the <command>centos-art</command> command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under <file>Motifs/</file> directory using the model name, and the model directory structure as reference.</para> |
| <para>The artistic motif base structure is used by <command>centos-art</command> to produce images automatically. This section describes each directory of CentOS artistic motif base structure.</para> |
| <para>The <file>Backgrounds/</file> directory is probably the core component, inside <file>Motifs/</file> directory structure. Inside <file>Backgrounds/</file> directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The <file>Backgrounds/</file> directory can contain subdirectories to help you organize the design process.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes Motifs Flame</nodename> |
| <nodenext>Directories trunk Identity Images Themes Motifs Modern</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes Motifs</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes/Motifs/Flame</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes Motifs Flame</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes the <emph>Flame</emph> artistic motif. This section may be useful for anyone interested in reproducing the <emph>Flame</emph> artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity.</para> |
| <subheading>Description</subheading> |
| <para>The <emph>Flame</emph> artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5.</para> |
| <para>The flame filter of Gimp can produce stunning, randomly generated fractal patterns. The flame filter of Gimp gives us a great oportunity to reduce the time used to produce new artistic motifs, because of its “randomly generated” nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the <file>centos-art.sh</file> script (see <xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref>) inside the CentOS Artwork Repository.</para> |
| <para>To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we could produce a new visual style, every two years, based on a new “randomly generated” flame pattern, and publish the whole corporate visual identity (i.e., distribution stuff, promotion stuff, websites stuff, etc.) with the new major release of CentOS distribution all together at once.</para> |
| <para>Producing a new visual style is not one day's task. Once we have defined the artistic motif, we need to propagate it through all visual manifestations of The CentOS Project corporate visual identity. When we say that we could produce one new visual style every two years we really mean: to work two years long in order to propagate a new visual style to all visual manifestations of The CentOS Project corporate visual identity.</para> |
| <para>Obviously, in order to propagate one visual style to all different visual manifestations of The CentOS Project corporate visual identity, we need first to know which the visual manifestations are. To define which visual manifestations are inside The CentOS Project corporate visual identity is one of the goals the CentOS Artwork Repository and this documentation manual are both aimed to satisfy.</para> |
| <para>Once we define which the visual manifestation are, it is possible to define how to produce them, and this way, organize the automation process. Such automation process is one of the goals of <file>centos-art.sh</file> script.</para> |
| <para>With the combination of both CentOS Artwork Repository and <file>centos-art.sh</file> scripts we define work lines where translators, programmers, and graphic designers work together to distribute and reduce the amount of time employed to produce The CentOS Project monolithic corporate identity.</para> |
| <para>From a monolithic corporate visual identity point of view, notice that we are producing a new visual style for the same theme (i.e., <emph>Flame</emph>). It would be another flame design but still a flame design. This idea is very important to be aware of, because we are somehow “refreshing” the theme, not changing it at all.</para> |
| <para>This way, as we are “refreshing” the theme, we still keep oursleves inside the monolithic conception we are trying to be attached to (i.e., one unique name, and one unique visual style for all visual manifestations).</para> |
| <para>Producing artistic motifs is a creative process that may consume long time, specially for people without experienced knowledge on graphic design land. Using “randomly generated” conception to produce artistic motifs could be, practically, a way for anyone to follow in order to produce maintainable artistic motifs in few steps.</para> |
| <para>Due to the “randomly generated” nature of Flame filter, we find that <emph>Flame</emph> pattern is not always the same when we use <emph>Flame</emph> filter interface.</para> |
| <para>Using the same pattern design for each visual manifestation is essential in order to maintain the visual connection among all visual manifestations inside the same theme. Occasionally, we may introduce pattern variations in opacity, size, or even position but never change the pattern design itself, nor the color information used by images considered part of the same theme.</para> |
| <quotation> |
| <para><strong>Important</strong> When we design background images, which are considered part of the same theme, it is essential to use the same design pattern always. This is what makes theme images to be visually connected among themeselves, and so, the reason we use to define the word “theme” as: a set of images visually connected among themeselves.</para> |
| </quotation> |
| <para>In order for us to reproduce the same flame pattern always, <emph>Flame</emph> filter interface provides the <samp>Save</samp> and <samp>Open</samp> options. The <samp>Save</samp> option brings up a file save dialog that allows you to save the current Flame settings for the plug-in, so that you can recreate them later. The <samp>Open</samp> option brings up a file selector that allows you to open a previously saved Flame settings file.</para> |
| <para>The Flame settings we used in our example are saved in the file named <file>800x600.xcf-flame.def</file>, inside the <file>Backgrounds/Xcf</file> directory structure.</para> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Images Themes Motifs) —.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes Motifs Modern</nodename> |
| <nodenext>Directories trunk Identity Images Themes Motifs Pipes</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes Motifs Flame</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes/Motifs/Modern</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes Motifs Modern</indexterm></para> |
| <subheading>Goals</subheading> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes Motifs Pipes</nodename> |
| <nodenext>Directories trunk Identity Images Themes Motifs TreeFlower</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes Motifs Modern</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes/Motifs/Pipes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes Motifs Pipes</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Images Themes Motifs TreeFlower</nodename> |
| <nodenext>Directories trunk Identity Models</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes Motifs Pipes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Images/Themes/Motifs/TreeFlower</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Images Themes Motifs TreeFlower</indexterm></para> |
| <subheading>Goals</subheading> |
| <subheading>Description</subheading> |
| <subheading>Usage</subheading> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models</nodename> |
| <nodenext>Directories trunk Identity Models Brands</nodenext> |
| <nodeprev>Directories trunk Identity Images Themes Motifs TreeFlower</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>&dots;</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Brands</nodename> |
| <nodenext>Directories trunk Identity Models Themes</nodenext> |
| <nodeprev>Directories trunk Identity Models</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Brands</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Brands</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes The CentOS Brand design models.</para> |
| <subheading>Description</subheading> |
| <para>The CentOS Brand provides the one unique name or trademark that connects the producer with their products. In this case, the producer is The CentOS Project and the products are The CentOS Project visual manifestations.</para> |
| <para>The CentOS Brand is the main visual representation of the CentOS project so the typography used in it must be the same always, no matter where it be shown. It also has to be clear enough to dismiss any confussion between similar typefaces (e.g., the number one (1) sometimes is confuesed with the letter <samp>el</samp> (l) or letter <samp>ai</samp> (i)).</para> |
| <para>As convenction, the word <samp>CentOS</samp> uses <samp>Denmark</samp> typography as base, both for the word <samp>CentOS</samp> and the phrase <samp>Community Enterprise Operating System</samp>. The phrase size of CentOS logo is half the size in poits the word <samp>CentOS</samp> has and it below <samp>CentOS</samp> word and aligned with it on the left. The distance between <samp>CentOS</samp> word and phrase <samp>Community Enterprise Operating System</samp> have the size in points the phrase has.</para> |
| <image width="" height="" name="trunk/Identity/Images/Manual/Brands/Logos/a" extension=""><alttext></alttext></image> |
| <para>When the CentOS release brand is built, use <samp>Denmark</samp> typography for the release number. The release number size is two times larger (in height) than default <samp>CentOS</samp> word. The separation between release number and <samp>CentOS</samp> word is twice the size in points of separation between <samp>CentOS</samp> word and phrase <samp>Community Enterprise Operating System</samp>.</para> |
| <para>Another component inside CentOS logo is the trademark symbol (TM). This symbol specifies that the CentOS logo must be consider a product brand, even it is not a registered one. The trademark symbol uses DejaVu LGC Sans Regular typography. The trademark symbol is aligned right-top on the outter side of <samp>CentOS</samp> word. The trademark symbol must not exceed haf the distance, in points, between <samp>CentOS</samp> word and the release number on its right.</para> |
| <para>It would be very convenient for the CentOS Project and its community to to make a registered trademark (®) of CentOS logo. To make a register trademark of CentOS Logo prevents legal complications in the market place of brands. It grants the consistency, through time, of CentOS project corporate visual identity.</para> |
| <quotation> |
| <para><strong>Note</strong> The information about trademarks and corporate identity is my personal interpretation of <uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref> and <uref><urefurl>http://en.wikipedia.org/Trademark</urefurl></uref> description. If you have practical experiences with these affairs, please serve yourself to improve this section with your reasons.</para> |
| </quotation> |
| <subheading>Usage</subheading> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default</nodenext> |
| <nodeprev>Directories trunk Identity Models Brands</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes design models from The CentOS Themes.</para> |
| <subheading>Description</subheading> |
| <para>Theme models let you modeling characteristics (e.g., dimensions, translation markers, position of each element on the display area, etc.) common to all themes. Theme models let you reduce the time needed when propagating artistic motifs to different visual manifestations.</para> |
| <para>Theme models serves as a central pool of design templates for themes to use. This way you can produce themes with different artistic motifs but same characteristics.</para> |
| <subsubheading>Default Design Model</subsubheading> |
| <para>Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the <command>centos-art</command> script uses to produce images when no other design model is specified.</para> |
| <subsubheading>Alternative Design Models</subsubheading> |
| <para>CentOS alternative theme models exist for people how want to use a different visual style on their installations of CentOS distribution. As the visual style is needed for a system already installed components like Anaconda are not required inside alternative themes. Inside alternative themes you find post-installation visual style only (i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative themes are maintained by CentOS Community.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default) —.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Concept</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes the default design model of The CentOS Themes.</para> |
| <subheading>Description</subheading> |
| <para>The <file>trunk/Identity/Themes/Models/Default</file> directory implements the concept of <emph>Default Design Model</emph> for The CentOS Themes. The CentOS Themes Default Design Model provides the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the <command>centos-art</command> script uses to produce images when no other design model is specified.</para> |
| <para>Deisgn models in this directory do use the <emph>CentOS Release Brand</emph>. The CentOS Release Brand is a combination of both The CentOS Type and The CentOS Release Schema used to illustrate the major release of The CentOS Distribution the image produced belongs to. — <strong>Removed</strong>(xref:Directories trunk Identity Models Tpl Brands) —, for more information.</para> |
| <para>The CentOS Project maintains near to four different major releases of CentOS Distribution. Each major release of CentOS Distribution has internal differences that make them unique and, at the same time, each CentOS Distribution individually is tagged into the one unique visual manifestation (i.e., Distribution). So, how could we implement the monolithic visual structure in one visual manifestation that has internal difference?</para> |
| <para>To answer this question we broke the question in two parts and later combined the resultant answers to build a possible solution.</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>How to remark the internal differences visually?</strong></tableterm> |
| <item> |
| <para>Merge both The CentOS Project Release Schema into The CentOS Project Trademark to build The CentOS Project Release Trademark. The CentOS Project Release Trademark remarks two things: first, it remarks the image is from The CentOS Project and second, it remarks which major release of CentOS Distribution does the image belongs to. — <strong>Removed</strong>(xref:Directories trunk Identity Models Tpl Brands) —, for more information on how to develop and improve The CentOS Project Brand.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>How to remark the visual resemblance?</strong></tableterm> |
| <item> |
| <para>Use a common artistic motifs as background for all CentOS Distribution images. — <strong>Removed</strong>(xref:Directories trunk Identity Images Themes Motifs) —, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>So, combining answers above, we could conclude that:</strong></tableterm> |
| <item> |
| <para>In order to implement the CentOS Monolithic Visual Structure on CentOS Distribution visual manifestations, a CentOS Release Trademark and a background information based on one unique artistic motif should be used in all remarkable images The CentOS Distribution visual manifestation is made of.</para> |
| </item> |
| </tableitem> |
| </table> |
| <quotation> |
| <para><strong>Important</strong> Remarking the CentOS Release Schema inside each major release of CentOS Distribution —or similar visual manifestations— takes <emph>high attention</emph> inside The CentOS Project corporate visual identity. It should be very clear for everyone which major release of CentOS Distribution is being used.</para> |
| </quotation> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Concept) —.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Models Themes</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(ref:Directories trunk Identity Images Themes Motifs) —</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Concept</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Concept</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Concept</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Concept</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section organizes default design models for different major releases of CentOS Distribution.</para> |
| <subheading>Description</subheading> |
| <para>In order to better understatand how this visual manifestation is organized, it is necessary to consider what The CentOS Distribution is and how it is released.</para> |
| <subsubheading>The CentOS Distribution</subsubheading> |
| <para>The CentOS Distribution is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. The CentOS Distribution conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. (The CentOS Project mainly changes packages to remove upstream vendor branding and artwork.)</para> |
| <para>The CentOS Distribution is developed by a small but growing team of core developers. In turn the core developers are supported by an active user community including system administrators, network administrators, enterprise users, managers, core Linux contributors and Linux enthusiasts from around the world.</para> |
| <subsubheading>The CentOS Distribution Release Schema</subsubheading> |
| <para>The upstream vendor has released 4 versions of their <acronym><acronymword>EL</acronymword><acronymdesc>Enterprise Linux</acronymdesc></acronym> product that The CentOS Project rebuilds the freely available SRPMS for. The upstream vendor releases security updates as required by circumstances. The CentOS Project releases rebuilds of security updates as soon as possible. Usually within 24 hours (our stated goal is with 72 hours, but we are usually much faster).</para> |
| <para>The upstream vendor also releases numbered update sets for major versions of their EL product from 2 to 4 times per year. There are new ISOs from the upstream vendor provided for these update sets. Update sets will be completed as soon as possible after the upstream vendor releases their version &dots; generally within 2 weeks. The CentOS Project follows these conventions as well, so CentOS-3.9 correlates with EL 3 update 9 and CentOS-4.6 correlates with EL 4 update 6, CentOS-5.1 correlates to EL 5 update 1, etc.</para> |
| <para>One thing some people have problems understanding is that if you have any CentOS-3 product and update it, you will be updated to the latest CentOS-3.x version.</para> |
| <para>The same is true for CentOS-4 and CentOS-5. If you update any CentOS-4 product, you will be updated to the latest CentOS-4.x version, or to the latest CentOS-5.x version if you are updating a CentOS-5 system. This is exactly the same behavior as the upstream product. Let's assume that the latest EL4 product is update 6. If you install the upstream original EL4 CDs (the ones before any update set) and upgrade via <command>yum</command>, you will have latest update set installed (EL4 update 6 in our example). Since all updates within a major release (CentOS-2, CentOS-3, CentOS-4, CentOS-5) always upgrade to the latest version when updates are performed (thus mimicking upstream behavior), only the latest version is maintained in each main tree on The CentOS Mirrors (<uref><urefurl>http://mirrors.centos.org/</urefurl></uref>).</para> |
| <para>There is a CentOS Vault (<uref><urefurl>http://vault.centos.org/</urefurl></uref>) containing old CentOS trees. This vault is a picture of the older tree when it was removed from the main tree, and does not receive updates. It should only be used for reference.</para> |
| <para>The CentOS Distribution visual style is controlled by image files. These image files are packaged inside The CentOS Distribution and made visible once such packages are installed and executed. The way to go for changing The CentOS Distribution visual style is changing all those image files to add the desired visual style first and later, repackage them to make them available inside the final iso files of CentOS Distribution.</para> |
| <subheading>Usage</subheading> |
| <para>Sometimes, between major releases, image files inside packages can be added, removed or just get the name changed. In order to describe such variations, the design models directory structure is organized in the same way the variations are introduced (i.e., through The CentOS Distribution Release Schema). So, each major release of The CentOS Distribution has its own design model directory structure.</para> |
| <para>When a new package/component is added to one or all the major releases of The CentOS Distribution, a design model directory structure for that component needs to be created. Later, it is filled up with related design models. Design models are created for each image file inside the component that need to be rebuilt in order to set the visual style and brand information correctly.</para> |
| <para>When a package is removed from one or all major releases of The CentOS Distribution, the design model directory structure releated to that package/component is no longer used. However, it could be very useful for historical reasons. Also, someone could feel motivation enough to keep himself documenting it or supporting it for whatever reason.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5) —.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(ref:Directories trunk Identity Models Themes Default) —.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Models Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Anaconda</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Syslinux) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Anaconda) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Rhgb) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Gdm) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Kdm) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Grub) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Gsplash) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(xref:Directories trunk Identity Models Themes Default Distro 5 Ksplash) —.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>— <strong>Removed</strong>(ref:Directories trunk Identity Models Themes Default Distro) —.</para> |
| </item> |
| <item> |
| <para>— <strong>Removed</strong>(ref:Directories trunk Identity Models Themes Default) —.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Models Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Images Themes</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Anaconda</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Firstboot</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Anaconda</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Anaconda</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <subheading>Usage</subheading> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Firstboot</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Gdm</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Anaconda</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Firstboot</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Firstboot</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Gdm</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Grub</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Firstboot</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Gdm</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Gdm</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Grub</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Gsplash</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Gdm</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Grub</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Grub</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Gsplash</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Kdm</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Grub</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Gsplash</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Gsplash</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Kdm</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Ksplash</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Gsplash</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Kdm</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Kdm</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Ksplash</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Rhgb</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Kdm</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Ksplash</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Ksplash</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Rhgb</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Distro 5 Syslinux</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Ksplash</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Rhgb</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Rhgb</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Distro 5 Syslinux</nodename> |
| <nodenext>Directories trunk Identity Models Themes Default Posters</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Rhgb</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Distro/5/Syslinux</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Distro 5 Syslinux</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Themes Default Posters</nodename> |
| <nodenext>Directories trunk Identity Palettes</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Distro 5 Syslinux</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Themes/Default/Posters</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Themes Default Posters</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Palettes</nodename> |
| <nodenext>Directories trunk Identity Patterns</nodenext> |
| <nodeprev>Directories trunk Identity Models Themes Default Posters</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Palettes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Palettes</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Patterns</nodename> |
| <nodenext>Directories trunk Identity Webenv</nodenext> |
| <nodeprev>Directories trunk Identity Palettes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Patterns</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Patterns</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Webenv</nodename> |
| <nodenext>Directories trunk Locales</nodenext> |
| <nodeprev>Directories trunk Identity Patterns</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Webenv</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Webenv</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <para>The CentOS web environment is formed by a central web application —to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)— and many different free web applications —to cover specific needs (e.g., wiki, mailing lists, etc.)—.</para> |
| <para>The CentOS web environment is addressed to solve the following issues:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>One unique name and one unique visual style to all web applications used inside the web environment.</para> |
| </item> |
| <item> |
| <para>One-step navigation to web applications inside the environment.</para> |
| </item> |
| <item> |
| <para>High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions).</para> |
| </item> |
| </itemize> |
| <para>The CentOS project is attached to a monolithic corporate visual identity (see <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case.</para> |
| <para>Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (<uref><urefurl>http://wiki.centos.org/</urefurl></uref>) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't support<footnote><para>The theme support of Mailman may be introduced in mailman-3.x.x release.</para></footnote> a customization system that separates presentation from logic, similar to that used by MoinMoin.</para> |
| <para>This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic).</para> |
| <para>To solve the “one unique visual style” issue, installation and actualization of web applications —used inside CentOS web environment— need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes.</para> |
| <para>At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications.</para> |
| <subsubheading>Design model (without ads)</subsubheading> |
| <subsubheading>Design model (with ads)</subsubheading> |
| <subsubheading>HTML definitions</subsubheading> |
| <subsubheading>Controlling visual style</subsubheading> |
| <para>Inside CentOS web environment, the visual style is controlled by the following compenents:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Webenv header background</strong></tableterm> |
| <item> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Images/Themes/$THEME/Backgrounds/Img/1024x250.png |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>CSS definitions</strong></tableterm> |
| <item> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| </table> |
| <subsubheading>Producing visual style</subsubheading> |
| <para>The visual style of CentOS web environment is defined in the following files:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Images/Themes/$THEME/Backgrounds/Xcf/1024x250.xcf |
| trunk/Identity/Images/Themes/$THEME/Backgrounds/Img/1024x250.png |
| trunk/Identity/Images/Themes/$THEME/Backgrounds/Img/1024x250-bg.png |
| trunk/Identity/Images/Themes/$THEME/Backgrounds/Tpl/1024x250.svg |
| ]]></verbatim> |
| <para>As graphic designer you use <file>1024x250.xcf</file> file to produce <file>1024x250-bg.png</file> file. Later, inside <file>1024x250.svg</file> file, you use the <file>1024x250-bg.png</file> file as background layer to draw your vectorial design. When you consider you artwork ready, use the <command>centos-art.sh</command> script, as described below, to produce the visual style controller images of CentOS web environment.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render --entry=trunk/Identity/Images/Themes/$THEME/Backgrounds --filter='1024x250' |
| ]]></verbatim> |
| <para>Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories.</para> |
| <subsubheading>Navigation</subsubheading> |
| <para>Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment.</para> |
| <subsubheading>Development and release cycle</subsubheading> |
| <para>The CentOS web environment development and relase cycle is described below:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Download</strong></tableterm> |
| <item> |
| <para>The first action is download the source code of web applications we want to use inside CentOS web environment.</para> |
| <quotation> |
| <para><strong>Important</strong> The source location from which web application are downloaded is very important. Use SRPMs from CentOS <strong>[base]</strong> and <strong>[updates]</strong> repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Prepare</strong></tableterm> |
| <item> |
| <para>Once web application source code has been downloaded, our duty is organize its files inside <samp>webenv</samp> version controlled repository.</para> |
| <para>When preparing the structure keep in mind that different web applications have different visual styles, and also different ways to implement it. A convenient way to organize the file system structure would be create one development line for each web application we use inside CentOS web environment. For example, consider the following file system structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | `-- webapp1-0.0.1/ |
| | |-- Rpms/ |
| | | `-- webapp1-0.0.1.rpm |
| | |-- Srpms/ |
| | | `-- webapp1-0.0.1.srpm |
| | `-- Specs/ |
| | `-- webapp1-0.0.1.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Customize</strong></tableterm> |
| <item> |
| <para>Once web applications have been organized inside the version controlled repository file system, use subversion to create the CentOS customization development line of web applications source code. For example, using the above file system structure, you can create the customization development line of <file>webapp1-0.0.1/</file> with the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv |
| ]]></verbatim> |
| <para>The command above creates the following structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | |-- webapp1-0.0.1/ |
| | | `-- webapp1-0.0.1-webenv/ |
| | |-- Rpms/ |
| | | `-- webapp1-0.0.1.rpm |
| | |-- Srpms/ |
| | | `-- webapp1-0.0.1.srpm |
| | `-- Specs/ |
| | `-- webapp1-0.0.1.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| <para>In the above structure, the <file>webapp1-0.0.1-webenv/</file> directory is the place where you customize the visual style of <file>webapp1-0.0.1/</file> web application.</para> |
| <quotation> |
| <para><strong>Tip</strong> Use the <command>diff</command> command of Subversion between CentOS customization and upstream development lines to know what you are changing exactly.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Build packages</strong></tableterm> |
| <item> |
| <para>When web application has been customized, build the web application RPM and SRPM using the source location with <samp>-webenv</samp> prefix.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | |-- webapp1-0.0.1/ |
| | | `-- webapp1-0.0.1-webenv/ |
| | |-- Rpms/ |
| | | |-- webapp1-0.0.1.rpm |
| | | `-- webapp1-0.0.1-webenv.rpm |
| | |-- Srpms/ |
| | | |-- webapp1-0.0.1.srpm |
| | | `-- webapp1-0.0.1-webenv.srpm |
| | `-- Specs/ |
| | |-- webapp1-0.0.1.spec |
| | `-- webapp1-0.0.1-webenv.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Release for testing</strong></tableterm> |
| <item> |
| <para>When the customized web application has been packaged, make packages available for testing and quality assurance. This can be achives using a [webenv-test] yum repository.</para> |
| <quotation> |
| <para><strong>Note</strong> The [webenv-test] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv-test] repository you need to configure it first.</para> |
| </quotation> |
| <para>If some problem is found to install/update/use the customized version of web application, the problem is notified somewhere (a bugtracker maybe) and the customization face is repated in order to fix the problem. To release the new package add a number after <samp>-webenv</samp> prefix. For example, if some problem is found in <file>webapp1-0.0.1-webenv.rpm</file>, when it be fixed the new package will be named <file>webapp1-0.0.1-webenv-1.rpm</file>. If a problem is found in <file>webapp1-0.0.1-webenv-1.rpm</file>, when it be fixed the new package will be named <file>webapp1-0.0.1-webenv-2.rpm</file>, and so on.</para> |
| <para>The “customization — release for testing” process is repeated until CentOS quality assurance team considers the package is ready for production.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Release for production</strong></tableterm> |
| <item> |
| <para>When customized web application packages are considered ready for production they are moved from [webenv-test] to [webenv] repository. This action is commited by CentOS quality assurance team.</para> |
| <quotation> |
| <para><strong>Note</strong> The [webenv] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv] repository you need to configure it first.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| </table> |
| <subsubheading>The [webenv-test] repository</subsubheading> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /etc/yum.repos.d/CentOS-Webenv-test.repo |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [webenv-test] |
| name=CentOS-$releasever - Webenv-test |
| mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test |
| #baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/ |
| gpgcheck=1 |
| gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever |
| enabled=1 |
| priority=10 |
| ]]></verbatim> |
| <subsubheading>The [webenv] repository</subsubheading> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /etc/yum.repos.d/CentOS-Webenv.repo |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [webenv] |
| name=CentOS-$releasever - Webenv |
| mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv |
| #baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/ |
| gpgcheck=1 |
| gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever |
| enabled=1 |
| priority=10 |
| ]]></verbatim> |
| <subsubheading>Priority configuration</subsubheading> |
| <para>Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales</nodename> |
| <nodenext>Directories trunk Manual</nodenext> |
| <nodeprev>Directories trunk Identity Webenv</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/Locales</file> directory structure provides the localization work line and its main goal is provide the translation messages required to produce content in different languages.</para> |
| <subheading>Description</subheading> |
| <para>Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under <file>trunk/Locales</file> directory structure.</para> |
| <para>Translation messages are organized using the directory structure of the component being translated. For example, if we want to provide translation messages for <file>trunk/Manuals/Repository</file>, then the <file>trunk/Locales/Manuals/Repository</file> directory needs to be created.</para> |
| <para>Once the locale directory exists for the component we want to provide translation messages for, it is necessary to create the translation files where translation messages are. The translation files follows the concepts of <command>xml2po</command> and GNU <command>gettext</command> tools.</para> |
| <para>The basic translation process is as follow: first, translatable strings are extracted from files and a portable object template (.pot) is created or updated with the information. Using the portable object template, a portable object (.po) is created or updated for translator to locale the messages retrived. Finally, a machine object (.mo) is created from portable object to sotore the translated messages.</para> |
| <para>Inside the repository there are two ways to retrive translatable strings from files. The first one is through <command>xml2po</command> command and the second through <command>xgettext</command> command. The <command>xml2po</command> is used to retrive translatable strings from XML files (e.g., Scalable Vector Graphics, DocBook, etc.) and the <command>xgettext</command> command is used to retrive translatable strings from shell scripts files (e.g., the files that make the <command>centos-art.sh</command> command-line interface).</para> |
| <para>When translatable strings are retrived from XML files, using the <command>xml2po</command> command, there is no need to create the machine object as we do when translatable strings ar retrived from shell files, using the <command>xgettext</command> command. The <command>xml2po</command> produces a temporal machine object in order to create a translated XML file. Once the translated XML file has been created the machine object is no longer needed. On the other hand, the machine object produced by the <command>xgettext</command> command is required by the system in order for the show shell script localized messages.</para> |
| <para>Another difference between <command>xml2po</command> and <command>xgettext</command> we need to be aware of is the directory structure used to store machine objects. In <command>xml2po</command>, the machine object is created in the current working directory as <file>.xml2po.mo</file> and can be safetly removed once the translated XML file has been created. In the case of <command>xgettext</command>, the machine object needs to be stored in the <file>$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo</file> file in order for the system to interpret it and should not be removed since it is the file that contain the translation messages themselves.</para> |
| <para>Automation of localization tasks is achived through the <code>locale</code> functionality of command-line interface.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction><xref><xrefnodename>Directories trunk Scripts Functions Locale</xrefnodename></xref> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Manual</nodename> |
| <nodenext>Directories trunk Scripts</nodenext> |
| <nodeprev>Directories trunk Locales</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Manual</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Manual</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This <file>trunk/Manual</file> directory structure provides the documentation work line. The main goal of documentation work line is 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.</para> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts</nodename> |
| <nodenext>Directories trunk Scripts Functions</nodenext> |
| <nodeprev>Directories trunk Manual</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section provides the automation work line. The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script.</para> |
| <para>In this section you'll find how to organize and extend the <command>centos-art.sh</command> script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here.</para> |
| <subheading>Description</subheading> |
| <para>The best way to understand the <command>centos-art.sh</command> script is studying and improving its source code. However, as start point, you may prefer to read an introductory resume before diving into the source code details. In this section we identify the different parts the <command>centos-art.sh</command> script is made of and how these parts interact one another.</para> |
| <subsubheading>Execution environments</subsubheading> |
| <para>The <command>centos-art.sh</command> script is basically made of four execution environments which are named <emph>script</emph>, <emph>global</emph>, <emph>specific</emph> and <emph>action</emph>. These execution environments are nested one into another and provide different definition levels for variables and functions. In this design, variables and functions defined in higher execution environments are available on lower execution environments, but variables and functions defined in lower execution environments are not available for higher execution enviroments.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| +----------------------------------------------------------------------+ |
| | [centos@host]$ centos-art function path/to/dir --option='value' | |
| +----------------------------------------------------------------------+ |
| | ~/bin/centos-art --> ~/artwork/trunk/Scripts/centos-art.sh | |
| +---v--------------------------------------------------------------v---+ |
| | centos-art.sh | |
| +---v------------------------------------------------------v---+ |
| . | cli $@ | . |
| . +---v----------------------------------------------v---+ . |
| . . | cli_getFunctions | . . |
| . . +---v--------------------------------------v---+ . . |
| . . . | function | . . . |
| . . . +---v------------------------------v---+ . . . |
| . . . . | function_getOptions | . . . . |
| . . . . | function_doSomething | . . . . |
| . . . . +------------------------------+ . . . . |
| . . . . . . . . |
| . . . . Execution environment (action) . . . . |
| . . . ........................................ . . . |
| . . . . . . |
| . . . Execution environment (specific) . . . |
| . . ................................................ . . |
| . . . . |
| . . Execution environment (global) . . |
| . ........................................................ . |
| . . |
| . Execution environment (script) . |
| ................................................................ |
| ]]></verbatim> |
| <para>The script execution environment exists to provide script definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of internationalization through <command>gettext</command> program, script personal information and initialization of global functionalities.</para> |
| <para>The global execution environment exists to provide definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of functionalities (e.g., <code>cli_printMessage</code>, <code>cli_getCurrentLocale</code>, <code>cli_checkFiles</code>, etc.) and variables (e.g., <var>FUNCNAM</var>, <var>FUNCDIR</var>, <var>FUNCDIRNAM</var>, <var>ARGUMENTS</var>, etc.) that can be both used on specific and action execution environments, only.</para> |
| <para>The specific execution environment exists to provide definitions that can't be set anywhere else inside the script. Example of such definitions include initialization of specifc functionalities (e.g., <code>render</code>, <code>help</code>, <code>locale</code>, etc.) and specific variables (<var>ACTIONNAM</var>, <var>ACTIONVAL</var>, etc.) that can be used on action execution environment only.</para> |
| <para>The action execution environment exists to perform the script actions themselves. It is here where we perform content rendition, content documentation, content localization and whatever action you plan for the <command>centos-art.sh</command> script to perform. For example, if you passed the <code>render</code> value as first argument to <command>centos-art.sh</command> command-line, the script performs the content rendition action through the <code>render</code> function which is defined in the <file>render.sh</file> file under <file>trunk/Scripts/Functions/Render</file> directory. Is there, inside <code>render</code> functionality were the action execution environment takes place exactly.</para> |
| <subsubheading>Command-line interface</subsubheading> |
| <para>When the <command>centos-art</command> command is executed in a bash terminal, the bash interpreter uses the <env>PATH</env> environment variable to find where such command is. In order to run the <command>centos-art</command>, it must exist either as a link to an executable file or an executable file by its own, in any of the paths provided by <env>PATH</env> environment variable. Otherwise, the bash interpreter will print an error message and prompt you back to type a valid command.</para> |
| <para>By default, after installing The CentOS Distribution, there is no <command>centos-art</command> command available in the <env>PATH</env> environment variable for you to execute. The <command>centos-art</command> command is made available in your workstation as result of executing the <code>prepare</code> functionality of <command>centos-art.sh</command> script (see <xref><xrefnodename>Directories trunk Scripts Functions Prepare</xrefnodename></xref>) which requires you had previously downloaded a working copy of CentOS Artwork Repository in your workstation.</para> |
| <para>When the <command>centos-art</command> is executed, the first positional parameter passed is required and represents the name of the function you want to perform (e.g., <code>render</code> for content rendition, <code>locale</code> for content localization, etc.). Beyond the first positional parameter you can provide either option or non-option parameters in no specific order. There are also, option parameters with arguments and without arguments. Frequently, non-option paramters are used to specify the path location inside the repository where the function will be performed in (e.g., the directory structure do you want to produce content for) and option parameters to specify how such functionality is performed (e.g., do you want to go quietly? do you want to do filtering? etc.).</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| A B C D E |
| ---------- ------- ----------- ---------------- ------- |
| centos-art funcnam path/to/dir --filter='regex' --quiet |
| ---------- ------- ----------- ---------------- ------- |
| |
| A = The centos-art.sh script command-line. |
| B = The centos-art.sh function name. |
| C = Non-option parameter. |
| D = Option parameter (with argument). |
| E = Option parameter (without argument). |
| ]]></verbatim> |
| <subsubheading>Parsing command-line options</subsubheading> |
| <para>The action of parsing options is performed through <command>getopt</command> and results particularly interesting. <command>getopt</command> breaks up (parse) options in command lines and checks for legal options using the GNU <code>getopt</code> routines to do this. One important consideration on <command>centos-art.sh</command> script design is that positional parameters are retrived in the <code>cli</code> function but parsed on each specific function, individually. There isn't a big parsing definition to cover all specific functions, but one parsing definitions for each specific functions.</para> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions</nodename> |
| <nodenext>Directories trunk Scripts Functions Help</nodenext> |
| <nodeprev>Directories trunk Scripts</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>The <file>trunk/Scripts/Functions</file> directory exists to organize <file>centos-art.sh</file> specific functionalities.</para> |
| <subheading>Description</subheading> |
| <para>The specific functions of <file>centos-art.sh</file> script are designed with the “Software Toolbox” philosophy (<inforef><inforefnodename>Toolbox introduction</inforefnodename><inforefinfoname>coreutils.info</inforefinfoname></inforef>) in mind: each program “should do one thing well”. Inside <file>centos-art.sh</file> script, each specific functionality is considered a program that should do one thing well. Of course, if you find that they still don't do it, feel free to improve them in order for them to do so.</para> |
| <para>The specific functions of <file>centos-art.sh</file> script are organized inside specific directories under <file>trunk/Scripts/Functions</file> location. Each specific function directory should be named as the function it represents, with the first letter in uppercase. For example, if the function name is <code>render</code>, the specific function directory for it would be <samp>trunk/Scripts/Functions/Render</samp>.</para> |
| <subsubheading>Creating the <code>greet</code> functionality</subsubheading> |
| <para>To better understand how to design specific functions for <file>centos-art.sh</file> script, let's create the <code>greet</code> functionality which only goal is to print out different kind of greetings to your screen. The <code>greet</code> functionality will be set using the follwiing directory structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Scripts/Functions/Greet <-- The source location of greet function. |
| |-- greet_getOptions.sh <-- Defines command-line interface. |
| |-- greet_sayGoodbye.sh <-- Defines specific action. |
| |-- greet_sayHello.sh <-- Defines specific action. |
| `-- greet.sh <-- Defines function initialization. |
| ]]></verbatim> |
| <para>The <file>greet.sh</file> file contains the initialization script of <code>greet</code> functionality. It is the first file loaded from function source location by <command>centos-art.sh</command> script when it is executed using the <code>greet</code> functionality as first argument.</para> |
| <para>Inside <file>centos-art.sh</file> script, as convenction, each function script has one top commentary, followed by one blank line, and then one function defintion below it only. The top commentary has the function description, one-line for copyright notice with your personal information, the license under which the function source code is released —the <file>centos-art.sh</file> script is released as GPL, so do all its functions— and the <code>$Id$</code> keyword of Subversion which is later expanded by <command>svn propset</command> command. In our example, the top comment of <code>greet.sh</code> function script would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #!/bin/bash |
| # |
| # greet.sh -- This function outputs different kind of greetings to |
| # your screen. Use this function to understand how centos-art.sh |
| # script specific functionalities work. |
| # |
| # Copyright (C) YEAR YOURFULLNAME |
| # |
| # This program is free software; you can redistribute it and/or modify |
| # it under the terms of the GNU General Public License as published by |
| # the Free Software Foundation; either version 2 of the License, or (at |
| # your option) any later version. |
| # |
| # This program is distributed in the hope that it will be useful, but |
| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| # General Public License for more details. |
| # |
| # You should have received a copy of the GNU General Public License |
| # along with this program; if not, write to the Free Software |
| # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| # ---------------------------------------------------------------------- |
| # $Id$ |
| # ---------------------------------------------------------------------- |
| |
| function greet { |
| |
| # Define command-line interface. |
| greet_getOptions |
| |
| # Execute action name. |
| if [[ $ACTIONNAM =~ "^${FUNCNAM}_[A-Za-z]+$" ]];then |
| eval $ACTIONNAM |
| else |
| cli_printMessage "`gettext "A valid action is required."`" 'AsErrorLine' |
| cli_printMessage "${FUNCDIRNAM}" 'AsToKnowMoreLine' |
| fi |
| |
| } |
| ]]></verbatim> |
| <para>The first definition inside <code>greet</code> function is for variables that will be available along the whole execution environment of <code>greet</code> function. This time we didn't define any variable here so, we continued with definition of command-line interface, through <code>greet_getOptions</code> function.</para> |
| <para>The command-line interface of <code>greet</code> functionality defines how to interpret arguments passed from <command>centos-art.sh</command> script command-line. Inside <command>centos-art.sh</command> script, the interpretation of arguments passed through its command-line takes place by mean of <command>getopt</command> command and is written as the following code example describes:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_getOptions { |
| |
| # Define short options we want to support. |
| local ARGSS="" |
| |
| # Define long options we want to support. |
| local ARGSL="hello:,bye:,quiet" |
| |
| # Redefine ARGUMENTS variable using getopt output. |
| cli_doParseArguments |
| |
| # Redefine positional parameters using ARGUMENTS variable. |
| eval set -- "$ARGUMENTS" |
| |
| # Look for options passed through command-line. |
| while true; do |
| |
| case "$1" in |
| |
| --hello ) |
| ACTIONNAM="${FUNCNAM}_sayHello" |
| ACTIONVAL="$2" |
| shift 2 |
| ;; |
| |
| --bye ) |
| ACTIONNAM="${FUNCNAM}_sayGoodbye" |
| ACTIONVAL="$2" |
| shift 2 |
| ;; |
| |
| --quiet ) |
| FLAG_QUIET='true' |
| shift 1 |
| ;; |
| |
| -- ) |
| # Remove the `--' argument from the list of arguments |
| # in order for processing non-option arguments |
| # correctly. At this point all option arguments have |
| # been processed already but the `--' argument still |
| # remains to mark ending of option arguments and |
| # begining of non-option arguments. The `--' argument |
| # needs to be removed here in order to avoid |
| # centos-art.sh script to process it as a path inside |
| # the repository, which obviously is not. |
| shift 1 |
| break |
| ;; |
| esac |
| done |
| |
| # Redefine ARGUMENTS variable using current positional parameters. |
| cli_doParseArgumentsReDef "$@" |
| |
| } |
| ]]></verbatim> |
| <para>The <code>greet_sayHello</code> and <code>greet_sayGoodbye</code> function definitions are the core of <code>greet</code> specific functionality. In such function definitions we set what our <code>greet</code> function really does: to output different kinds of greetings.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_sayHello { |
| |
| cli_printMessage "`gettext "Hello"`, $ACTIONVAL" |
| |
| } |
| ]]></verbatim> |
| <para>The <code>greet_sayHello</code> function definition is stored in <file>greet_sayHello.sh</file> function script.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_sayGoodbye { |
| |
| cli_printMessage "`gettext "Goodbye"`, $ACTIONVAL" |
| |
| } |
| ]]></verbatim> |
| <para>The <code>greet_sayGoodbye</code> function definition is stored in the <file>greet_sayGoodbye.sh</file> function script.</para> |
| <subsubheading>Executing the <code>greet</code> functionality</subsubheading> |
| <para>To execute the <code>greet</code> specific functionality we've just created, pass the function name (i.e., <code>greet</code>) as first argument to <file>centos-art.sh</file> script and any of the valid options after it. Some examples are illustrated below:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [centos@projects ~]$ centos-art greet --hello='World' |
| Hello, World |
| [centos@projects ~]$ centos-art greet --bye='World' |
| Goodbye, World |
| [centos@projects ~]$ centos-art greet --bye='World' --quiet |
| [centos@projects ~]$ |
| ]]></verbatim> |
| <para>The word <samp>World</samp> in the examples above can be anything. Likewise, if you need to change the way either the hello or goodbye messages are printed out, you can modifie the functions <code>greet_sayHello</code> and <code>greet_sayGoodbye</code>, respectively.</para> |
| <subsubheading>Documenting the <command>greet</command> functionality</subsubheading> |
| <para>Now that <code>greet</code> functionality works as we expect, it is time to document it. To document functionalities inside <command>centos-art.sh</command> script we use the function directory path as argument to the <code>help</code> functionality (see <xref><xrefnodename>Directories trunk Scripts Functions Help</xrefnodename></xref>) of <file>centos-art.sh</file> script, just as the following command illustrates:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art help --edit trunk/Scripts/Functions/Greet |
| ]]></verbatim> |
| <para>The function documentation helps to understand how the function really works and how it should be used. Also, when <command>centos-art.sh</command> script ends because an error, the documentation entry related to the functionality being currently executed is used as vehicle to communicate the user what is the correct way of using the functionality.</para> |
| <subsubheading>Localizing the <command>greet</command> functionality</subsubheading> |
| <para>Now that <code>greet</code> functionality has been documented, it is time to localize its output messages. Localizing specific functionalities of <command>centos-art.sh</command> script takes place as part of <command>centos-art.sh</command> script localization itself which is performed by applying the path <file>trunk/Scripts</file> to the <code>locale</code> functionality of <command>centos-art.sh</command> script.</para> |
| <para>As the <code>greet</code> functionality added new translatable strings to the <command>centos-art.sh</command> script, it is required to update the translation messages firstly, to add the new translatable strings from <code>greet</code> functionality to <command>centos-art.sh</command> script translation messages and then, edit the translation messages of <command>centos-art.sh</command> script to localize the new translatable strings that have been added. To achieve this, execute the following two commands:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art locale --update trunk/Scripts |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art locale --edit trunk/Scripts |
| ]]></verbatim> |
| <quotation> |
| <para><strong>Warning</strong> To translate output messages in different languages, your system locale information —as in <env>LANG</env> environment variable— must be set to that locale you want to produce translated messages for. For example, if you want to produce translated messages for Spanish language, your system locale information must be set to <samp>es_ES.UTF-8</samp>, or similar, before executing the <code>locale</code> functionality of <command>centos-art.sh</command> script.</para> |
| </quotation> |
| <para>Well, it seems that our example is rather complete by now.</para> |
| <subsubheading>Extending the <code>greet</code> functionality</subsubheading> |
| <para>In the <code>greet</code> functionality we've described so far, we only use <code>cli_printMessage</code> function in action specific function definitions in order to print messages, but more interesting things can be achieved inside action specific function definitions. For example, if you pass a directory path as argument, you could use it to retrive a list of files from therein and process them. If the list of files turns too long or you just want to control which files to process, so you could add another argument in the form <option>--filter='regex'</option> and reduce the list of files to process using a regular expression pattern.</para> |
| <para>In case you consider to extend the <code>greet</code> functionality to do something different but print out grettings, consider changing the function name from <code>greet</code> to something more appropriate, as well. The name change must be coherent with the actions the new function is designed to perform.</para> |
| <para>If you doubt what name is better for your functionality, write to <email><emailaddress>centos-devel@centos.org</emailaddress></email> mailing list, explain what your functionality intends to do and request suggestion about what name would be more appropriate for it. That would be also very convenient for you, in order to evaluate the purposes of your function and what the community thinks about it. It is a way for you to gather ideas that help you to write using the community feeling as base.</para> |
| <para>If your function passes the community evaluation, that is a good sign for you to start/keep writing it. However, if it doesn't, it is time for you to rethink what you are doing and ask again until it passes the community evaluation. You can considered you've passed the community evaluation when after proposing your idea, you get a considerable amount of possitve responses for what you are doing, specially if those responses come from community leaders.</para> |
| <para>It is very hard to do something useful for a community of people without any point of contact with that community you are trying to do things for. How could you know you are doing something that is needed if you don't know what the needs are? So, explore the community needs first, define them, work them out and repeat the process time after time, even when you might think the need has been already satisfied. At that point, surely, you'll find smaller needs that need to be satisfied, as well.</para> |
| <subsubheading>Conclusions</subsubheading> |
| <para>The <code>greet</code> functionality described in this section may serve as introduction for you to understand how specific functionalities are created inside <file>centos-art.sh</file> script. With some of luck this introduction will also serve you as motivation to create your own specific functionalities for <file>centos-art.sh</file> script.</para> |
| <para>By the way, the <code>greet</code> functionality doesn't exist inside <file>centos-art.sh</file> script yet. Would you like to create it?</para> |
| <subheading>Usage</subheading> |
| <para>The following specific functions of <file>centos-art.sh</file> script, are available for you to use:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Help</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Locale</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Prepare</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Render</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Tuneup</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Help</nodename> |
| <nodenext>Directories trunk Scripts Functions Locale</nodenext> |
| <nodeprev>Directories trunk Scripts Functions</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Help</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Help</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Locale</nodename> |
| <nodenext>Directories trunk Scripts Functions Prepare</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Help</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Locale</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Locale</indexterm></para> |
| <subheading>Goals</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Description</subheading> |
| <para>This command looks for <samp>.sh</samp> files inside Bash directory and extracts translatable strings from files, using <command>xgettext</command> command, in order to create a portable object template (<file>centos-art.sh.pot</file>) file for them.</para> |
| <para>With the <file>centos-art.sh.pot</file> file up to date, the <command>centos-art</command> command removes the temporal list of files sotred inside <file>/tmp</file> directory and checks the current language of your user's session to create a portable object file for it, in the location <file>$CLI_LANG/$CLI_LANG.po</file>.</para> |
| <para>The <var>CLI_LANG</var> variable discribes the locale language used to output messages inside <command>centos-art</command> command. The locale language used inside <command>centos-art</command> command is taken from the <env>LANG</env> environment variable. The <var>CLI_LANG</var> variable has the <samp>LL_CC</samp> format, where <samp>LL</samp> is a language code from the ISO-639 standard, and <samp>CC</samp> a country code from the ISO-3166 standard.</para> |
| <para>The <env>LANG</env> environment variable is set when you do log in to your system. If you are using a graphical session, change language to your native language and do login. That would set and exoprt the <env>LANG</env> environment variable to the correct value. On the other side, if you are using a text session edit your <file>~/.bash_profile</file> file to set and export the <env>LANG</env> environment variable to your native locale as defines the <command>locale -a</command> command output; do logout, and do login again.</para> |
| <para>At this point, the <env>LANG</env> environment variable has the appropriate value you need, in order to translate <command>centos-art.sh</command> messages to your native language (the one set in <env>LANG</env> environment variable).</para> |
| <para>With the <file>$CLI_LANG/$CLI_LANG.po</file> file up to date, the <command>centos-art</command> opens it for you to update translation strings. The <command>centos-art</command> command uses the value of <var>EDITOR</var> environment variable to determine your favorite text editor. If no value is defined on <var>EDITOR</var>, the <file>/usr/bin/vim</file> text editor is used as default.</para> |
| <para>When you finishd PO file edition and quit text editor, the <command>centos-art</command> command creates the related machine object in the location <file>$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo</file>.</para> |
| <para>At this point, all translations you made in the PO file should be available to your language when runing <command>centos-art.sh</command> script.</para> |
| <para>In order to make the <command>centos-art.sh</command> internationalization, the <command>centos-art.sh</command> script was modified as described in the <command>gettext</command> info documentation (<command>info gettext</command>). You can find such modifications in the following files:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><file>trunk/Scripts/Bash/initFunctions.sh</file></para> |
| </item> |
| <item> |
| <para><file>trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh</file></para> |
| </item> |
| <item> |
| <para><file>trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh</file></para> |
| </item> |
| </itemize> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| <subheading>Usage</subheading> |
| <table> |
| <tableitem> |
| <tableterm><samp>centos-art locale --edit</samp></tableterm> |
| <item> |
| <para>Use this command to translate command-line interface output messages in the current system locale you are using (as specified in <env>LANG</env> environment variable).</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>centos-art locale --list</samp></tableterm> |
| <item> |
| <para>Use this command to see the command-line interface locale report.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subheading>See also</subheading> |
| <menu> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Prepare</nodename> |
| <nodenext>Directories trunk Scripts Functions Render</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Locale</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Prepare</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Prepare</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes the <code>prepare</code> functionality of <command>centos-art.sh</command> script and the preliminar steps you need to follow in order to get your workstation ready for using a working copy of CentOS Artwork Repository.</para> |
| <subheading>Description</subheading> |
| <para>The <code>prepare</code> functionality of <command>centos-art.sh</command> script provides the standard way of configuring the workstation you plan to use for storing the working copy of CentOS Artwork Repository.</para> |
| <para>The <code>prepare</code> functionality of <command>centos-art.sh</command> script is part of the CentOS Artwork Repository. So, in order to execute the <code>prepare</code> functionality of <command>centos-art.sh</command> script you need to have access to a working copy of CentOS Artwork Repository, first. Working copies of CentOS Artwork Repository are downloaded from the source repository and made available to you by mean of workstations. A workstation is a computer that you install and configure (prepare) to do something. In this case, you pick up a computer and prepare it for working on the CentOS Artwork Repository.</para> |
| <subsubheading>Installing the workstation</subsubheading> |
| <para>Installing the workstation is the first step you need to do. In this step you make your computer functional through an operating system. In this case, The Community Enterprise Operating System; which is also know as The CentOS Distribution or just CentOS, for short.</para> |
| <para>To install The CentOS Distribution you need to have the installation media somehow (e.g., CDs, DVDs, Pendrives, etc.). There are several different ways to perform the installation process of CentOS distribution, but generally, you put the installation media in your media reader, boot the computer from it, and follow the installer intructions. That simple.</para> |
| <para>If you don't have the installation media of CentOS distribution, you need to download the ISO files related to the media you plan to use (e.g., CD or DVD) and then create the installation media by yourself. The CentOS Distribution ISO files can be downloaded from <uref><urefurl>http://mirrors.centos.org/</urefurl></uref> and, if you chosen CD or DVD as your prefered installation medium, you can burn the ISO files using the <command>K3B</command> application to create the installation media you'll use. Of course, in order to download the ISO files and create the installation media, you need to have an already installed CentOS workstation where you can realized all the work.</para> |
| <subsubheading>Configuring the workstation</subsubheading> |
| <para>Once you've installed the workstation and it is up and running, login as <samp>root</samp> user, create a username (e.g., <samp>centos</samp>) and set a password for it. This is the username you must use for everyday work inside your working copy of the CentOS Artwork Repository.</para> |
| <quotation> |
| <para><strong>Caution</strong> Do not use the <samp>root</samp> username for your everyday work inside the working copy of CentOS Artwork Repository. It is dangerous and might provoke unreversable damages on your workstation.</para> |
| </quotation> |
| <para>Once you've created the username for your everyday work, there are some environment variables that you can customize to fit your personal needs (e.g., default text editor, default locale information, default time zone representation, etc.). To customize these variables you need to edit your profile file (i.e., <file>~/.bash_profile</file>) and set the redefinition there. Notice that you may need to logout and then do login again in order for the new variable values to take effect.</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Default text editor:</strong></tableterm> |
| <item> |
| <para>The default text editor information is contrlled by the <env>EDITOR</env> environment variable. The <file>centos-art.sh</file> script uses the default text editor to edit subversion pre-commit messages, translation files, documentation files, script files, and similar text-based files.</para> |
| <para>If <env>EDITOR</env> environment variable is not set, <file>centos-art.sh</file> script uses <file>/usr/bin/vim</file> as default text editor. Otherwise, the following values are recognized by <file>centos-art.sh</file> script:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><file>/usr/bin/vim</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/emacs</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/nano</file></para> |
| </item> |
| </itemize> |
| <para>If no one of these values is set in the <env>EDITOR</env> environment variable, the <file>centos-art.sh</file> script uses <file>/usr/bin/vim</file> text editor, the one installed by default in The CentOS Distribution.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Default locale information:</strong></tableterm> |
| <item> |
| <para>The default locale information is controlled by the <env>LANG</env> environment variable. This variable is initially set in the configuration process of CentOS distribution installer, specifically in the <samp>Language</samp> step; or once installed using the <command>system-config-language</command> tool.</para> |
| <para>The <command>centos-art.sh</command> script uses the <env>LANG</env> environment variable to determine what language to use for printing output messages. Moreover, the <code>locale</code> functionality uses the <env>LANG</env> to determine what translation messages to udpate or edit.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Default time zone representation:</strong></tableterm> |
| <item> |
| <para>The time zone representation is a time correction applied to the system time (stored in the BIOS clock) based on your country location. This correction is specially useful to distributed computers around the world that work together and need to be syncronized in time to know when things happened.</para> |
| <para>The CentOS Artwork Repository is made of one server and several workstations spread around the world. In order for all these workstations to know when changes in the server took place, it is required that all the workstations set their system clocks to use the same time information (i.e., <acronym><acronymword>UTC</acronymword><acronymdesc>Coordinated Universal Time</acronymdesc></acronym>) and set the time correction for their countries in the operating system. Otherwise, it'd be hard to know when something exactly happened.</para> |
| <para>Generally, setting the time information is a straight-forward task and configuration tools provided by The CentOS Distribution do cover time correction for most of the countries around the world. However, if you need a time precision not provided by any of the date and time configuration tools provided by The CentOS Distribution then, you need to use the <env>TZ</env> environment variable to correct the time information by yourself. The format of <env>TZ</env> environment variable is described in <file>tzset(3)</file> manual page.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subsubheading>Downloading the working copy</subsubheading> |
| <para>Once you've configured the workstation, it is time to download the working copy of CentOS Artwork Repository.</para> |
| <para>To download the working copy of CentOS Artwork Repository you need to login as your everyday work username (e.g., <samp>centos</samp>) and use the Subversion client to bring all the files you need to work with down from the source location of CentOS Artwork Repository (<uref><urefurl>https://projects.centos.org/svn/artwork/</urefurl></uref>) to your workstation, just as the following command describes:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| svn co https://projects.centos.org/svn/artwork ~/ |
| ]]></verbatim> |
| <para>This command will create the working copy of CentOS Artwork Repository in your workstation, specifically in the <file>/home/centos/artwork</file> directory. Note that you only need to execute this command once. After that, to keep your working copy up to date, you use the Subversion <command>update</command> command instead.</para> |
| <quotation> |
| <para><strong>Tip</strong> In the condition that you don't have Subversion client installed in the workstation, then you can install it using the command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| sudo yum install subversion |
| ]]></verbatim> |
| </quotation> |
| <subsubheading>Configuring the working copy</subsubheading> |
| <para>Once you have a working copy of CentOS Artwork Repository in your workstation, you can go and run the <code>prepare</code> functionality of <command>centos-art.sh</command> script to realize the remaining configuration stuff.</para> |
| <para>Assuming this is the very first time you run the <command>centos-art.sh</command> script, you'll find that there is no <command>centos-art</command> command-line interface for it in your workstation. This is correct. In order to have the <command>centos-art</command> command-line in your workstation, you need to run the <command>centos-art.sh</command> script using its absolute path:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS] |
| ]]></verbatim> |
| <para>Assuming you've already run the <code>prepare</code> functionality before, there is no need for you to use the absolute path again. Instead, you can use the <command>centos-art</command> command-line interface directly, as the following example describes:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art.sh prepare [OPTIONS] |
| ]]></verbatim> |
| <para>Notice that you can execute the <code>prepare</code> functionality more than once. This is specially useful to keep the link information syncronized. For example, considering you've added new brushes to or removed old brushes from your working copy of CentOS Artwork Repository, the link information related to those files need to be updated in the <file>~/.gimp-2.2/brushes</file> directory too, in a way the addition/deletion change that took place in your working copy can be reflected there, as well. The same is true for other similar components like fonts, patterns and palettes components.</para> |
| <subheading>Usage</subheading> |
| <subsubheading>Synopsis</subsubheading> |
| <para><command>centos-art prepare [OPTIONS]</command></para> |
| <subsubheading>Options</subsubheading> |
| <table> |
| <tableitem> |
| <tableterm><option>--packages</option></tableterm> |
| <item> |
| <para>Install/update software packages required by the working copy of CentOS Artwork Repository.</para> |
| <para>The process of software installation takes place through <command>sudo yum</command> and the repository configuration currently set in your workstation.</para> |
| <para>Most of the software packages required by the working copy of CentOS Artwork Repository are available on The CentOS Distribution and can be installed using The CentOS Distribution installation media. The only exception is Inkscape, the program used to manipulate <acronym><acronymword>SVG</acronymword><acronymdesc>Scalable Vector Graphics</acronymdesc></acronym> files in the working copy.</para> |
| <para>The <file>inkscape</file> package isn't inside The CentOS Distribution or any of The CentOS Project repositories neither, so you need to install it from a third party repository like <samp>RPMForge</samp> or <samp>EPEL</samp>. See page <uref><urefurl>http://wiki.centos.org/AdditionalResources/Repositories/</urefurl><urefdesc>The CentOS Repositories</urefdesc></uref>, to know how to configure third party repositories in The CentOS Distribution.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--link</option></tableterm> |
| <item> |
| <para>Install/update connection between working copy and workstation through symbolic links.</para> |
| <para>This option creates the <command>centos-art</command> command-line interface of <command>centos-art.sh</command> script through a symbolic link. There is no need for you to type the full path to <command>centos-art.sh</command> script each time you need to execute it. Instead, you use the <command>centos-art</command> command which is much shorter and faster to type.</para> |
| <para>This option connects design compenents like fonts, brushes, patterns and palettes inside your working copy of CentOS Artwork Repository with programs like <acronym><acronymword>GIMP</acronymword><acronymdesc>GNU Image Manipulation Program</acronymdesc></acronym> and Inkscape outside it. This way, all your modifications on these components will take place inside the repository and will be shared to all other working copies the next time you commit the changes up to source repository.</para> |
| <para>This option standardizes width, tabulation, indentation, and line numbering for text editors in your workstation. The configuration file where these definitions are set, is versioned inside your working copy and linked from the appropriate place in the workstation to make it valid to your default text editor.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--environment</option></tableterm> |
| <item> |
| <para>Print the name and value of some of the environment variables used by <command>centos-art.sh</command> scripts.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--quiet</option></tableterm> |
| <item> |
| <para>Supress all output messages, including confirmation question. Use this option with care.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--answer-yes</option></tableterm> |
| <item> |
| <para>Assume <samp>yes</samp> to all confirmation questions.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subsubheading>Examples</subsubheading> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art prepare --packages --link</command></tableterm> |
| <item> |
| <para>Preapare both links and packages required to use the working copy of CentOS Artwork Repository in the workstation. If required packages are already installed this command looks for updates instead.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art prepare --link --quiet</command></tableterm> |
| <item> |
| <para>Update connection between the workstation and the working copy of CentOS Artwork Repository, using no output.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts Functions</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Render</nodename> |
| <nodenext>Directories trunk Scripts Functions Tuneup</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Prepare</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Render</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Render</indexterm></para> |
| <subheading>Name</subheading> |
| <para>The <strong><code>render</code></strong> functionlity is part of <command>centos-art.sh</command> script and standardizes rendition tasks inside the working copy of CentOS Artwork Repository.</para> |
| <subheading>Synopsis</subheading> |
| <para><command>centos-art</command> <code><strong>render</strong></code> <code>[OPTION] path/to/dir</code></para> |
| <para>The <file>path/to/dir</file> parameter refers the path information related to the directory structure inside the working copy of CentOS Artwork Repository you'r going to produce. This path information defines whether to perform direct or theme-specific rendition.</para> |
| <para>You can use the <file>path/to/dir</file> information to control the amount of components you'll produce inside a specific renderable location. The more deep you go inside the path the more specific you are when producing theme components. Sometimes, you can also combine the use of <file>path/to/dir</file> with the <option>--filter</option> option to have a finer control over the files you produce.</para> |
| <para>The <code>render</code> functionality of <command>centos-art.sh</command> script accepts the following options:</para> |
| <table> |
| <tableitem> |
| <tableterm><option>--quiet</option></tableterm> |
| <item> |
| <para>Supress all output messages, including confirmation question. Use this option with care.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--filter="REGEX"</option></tableterm> |
| <item> |
| <para>Reduce the list of files to process using <samp>REGEX</samp> as pattern.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--answer-yes</option></tableterm> |
| <item> |
| <para>Assume `yes' to all confirmation questions.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--dont-commit-changes</option></tableterm> |
| <item> |
| <para>Supress all commit and update actions realized over files already processed, before and after the action itself had took place in the working copy.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--releasever="STRING"</option></tableterm> |
| <item> |
| <para>Produce content for the release version specified in <samp>STRING</samp>. This option is generaly used in direct rendition, where design models aren't organized using release versions and architectures as reference.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--basearch="STRING"</option></tableterm> |
| <item> |
| <para>Produce content for the architecture specified in <samp>STRING</samp>. This option is generaly used in direct rendition, where design models aren't organized using release versions and architectures as reference.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--convert="STRING"</option></tableterm> |
| <item> |
| <para>Uses post-rendition to convert output produced by base-rendition to any image format specified in <samp>STRING</samp>. This option is an interface for the <command>convert</command> command of ImageMagick tool set, so it is applicable to images output only.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--rotate="STRING"</option></tableterm> |
| <item> |
| <para>Uses post-rendition to rotate output produced by base-rendition to any angle specified in <samp>STRING</samp>. This option is an interface for the <command>convert</command> command of ImageMagick tool set, so it is applicable to images output only.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--resize="STRING"</option></tableterm> |
| <item> |
| <para>Uses post-rendition to resize the base-rendition output to any angle specified in <samp>STRING</samp>. This option is an interface for the <command>convert</command> command of ImageMagick tool set, so it is applicable to images output only.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--group-by="STRING"</option></tableterm> |
| <item> |
| <para>Group base output files inside directories. Directories used to stored base output files are named using the file extension of base output files. For example: if the base output file is a <file>.png</file> file, it is moved inside a <file>Png/</file> directory; if the current file is a <file>.jpg</file> file, it is stored inside a <file>Jpg/</file> directory, and so on.</para> |
| <para>Directories used to group files are created in the same location that base output files would normaly do.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--theme-model="STRING"</option></tableterm> |
| <item> |
| <para>Specify, in the <samp>STRING</samp>, the name of the theme model you want to use to produce theme motifs. By default, if this option is not passed, the <samp>Default</samp> theme model is used as reference to produce theme motifs.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subheading>Description</subheading> |
| <para>Inside the working copy of CentOS Artwork Repository, rendition tasks take place inside renderable directories. Inside the <code>render</code> functionality of <command>centos-art.sh</command> script, you can control rendition tasks through different flows of rendition named base-rendition, post-rendition, last-rendition and directory-specific rendition.</para> |
| <subsubheading>Renderable directories</subsubheading> |
| <para>In order for a directory structure to be considered renderable, it should have one directory structure for input files and one directory structure for output files. Optionally, a third directory structure might be available for storing translation files.</para> |
| <para>Renderable directories are very tied to the way content is produced inside the working copy of CentOS Artwork Repository. Presently, content is produced through the following organizations:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Direct rendition</strong></tableterm> |
| <item> |
| <para>In direct rendition, there is one directory structure for input files (<file>trunk/Identity/Models</file>) and one directory structure for output files (e.g., <file>trunk/Identity/Images</file>). Optionally, a third directory structure is available to store the input related translation files (e.g., <file>trunk/Locales/Identity/Models</file>).</para> |
| <para>In direct rendition, when the <code>render</code> functionality of <command>centos-art.sh</command> script is executed, it uses the input directory structure to build a list of files to process, which is used as reference to determine the location of the translation file and the location of the output file, as well.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Theme-specific rendition</strong></tableterm> |
| <item> |
| <para>In theme-specific rendition, there is one directory structure to store input files <file>trunk/Identity/Themes/Models</file>, one directory structure to store translation files (<file>trunk/Locales/Identity/Themes/Models/</file>), one directory structure to store artistic motifs (<file>trunk/Identity/Images/Themes</file>) and one directory structure to store output files (<file>trunk/Identity/Images/Themes</file>).</para> |
| <para>In theme-specific rendition, when the <code>render</code> functionality of <command>centos-art.sh</command> script is executed, it uses the input directory structure to build a list of files to process, which is used as reference to determine the location of the translation file and the location of the output file, as well.</para> |
| <para>In contrast with direct rendition, when we use theme-specific rendition, it is possible to combine both design models and artistic motifs to produce output in an arbitrary way. This configuration is specially interesting because it is possible to create different artistic motifs and one unique design model in order to produce one unique theme structure with different visual styles. Or the opposite, to create different theme structures and apply one unique visual style to produce different visual styles with the same theme structure. Or even push a bit farther and experiment with arbitrary combinations among them all.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>In both direct and theme-specific rendition, if the location where the output file should be stored doesn't exist, the <code>render</code> functionality of <command>centos-art.sh</command> script will create it for you.</para> |
| <para>In both direct and theme-specific rendition, if the input related translation file doesn't exist, the <code>render</code> functionality of <command>centos-art.sh</command> script will produce the output in the same language of its input file.</para> |
| <subsubheading>The base-rendition flow</subsubheading> |
| <para>The base-rendition flow is the first rendition flow of all rendition flows available and takes place immediatly after executing the <code>render</code> functionality of <command>centos-art.sh</command> script.</para> |
| <para>The base-rendition consist on producing different output formats in different languages from one single input format. This is, one input file produces one output file. Inside the <code>render</code> functionality of <command>centos-art.sh</command> script, the input format is always an XML file (e.g., SVG, XHTML, Docbook) and the output format depends on the input file provided.</para> |
| <para>For example, when the input format is a SVG file, the base output is a PNG file; when the input format is XHTML the base output is an XHTML file; when the input format is a Docbook file the base output is an XHTML file.</para> |
| <subsubheading>The post-rendition flow</subsubheading> |
| <para>The post-rendition flow takes place after base-rendition and is applied to create modified copies of the file produced by base-rendition in the same directory structure.</para> |
| <para>For example, when the input format is a SVG file and the output is a PNG file, we can use post-rendition to extend the base output to other image formats. In fact, it is possible to do anything permitted by the ImageMagick and Netpbm programs (e.g., resize, rotate, reduce color, etc.) over the base output.</para> |
| <subsubheading>The last-rendition flow</subsubheading> |
| <para>The last-rendition flow takes place after post-rendition and is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure.</para> |
| <para>For example, consider the <file>Preview.png</file> image of Ksplash which is made of three different images. In order to build the <file>Preview.png</file> image, we need to create the three images the <file>Preview.png</file> image is made of first (e.g., through base-rendition) and then, combine them all together into one new image, the <file>Preview.png</file> image in this case.</para> |
| <para>Another example of using last-rendition flow is that related to GDM and KDM <file>tar.gz</file> file construction. Each <file>tar.gz</file> file is made of several files that need to be put together in order to make them installable. In the very specific case of GDM and KDM some of the required files are retrived from design models directory structure and others from artistic motifs directory structure after had been produced through base-rendition. In this case, the action of grouping files and packing them is realized through last-rendition action. This couldn't be possible through post-rendition because we need to wait to have two images first (produced through base-rendition) before we could grouping them all into the <file>tar.gz</file> package.</para> |
| <subsubheading>The directory-specific rendition flow</subsubheading> |
| <para>The directory-specific rendition flow isn't a rendition flow by itself but a combination of rendition flows that are applied to specific directories at rendition time.</para> |
| <para>Inside the working copy of CentOS Artwork Repository there are some directories structures that exist to achieve specific tasks every time they are produced. The directory-specific rendition flow provides a way for the <code>render</code> functionality of <command>centos-art.sh</command> script to know what actions to apply to what directory structure when producing them.</para> |
| <para>The directory-specific rendition flow combines the base-rendition, post-rendition and last-rendition flows in specific ways and applies them to specific directory structures when they are detected. Using this configuration can speed up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created.</para> |
| <subsubheading>Translations</subsubheading> |
| <para>To translate output files, the <code>render</code> functionality of <command>centos-art.sh</command> script creates a translated instance of the input file and uses it then to create the base output file. The translated instance is created using the related translation messages of the input file. Translation messages are stored under <file>trunk/Locales</file> and are created using the <code>locale</code> functionality of <command>centos-art.sh</command> script (see <xref><xrefnodename>Directories trunk Scripts Functions Locale</xrefnodename></xref>).</para> |
| <subheading>Examples</subheading> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render trunk/Identity/Images/Brands |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render trunk/Identity/Images/Brands --filter="symbol" |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render trunk/Identity/Images/Themes/Flame/2 |
| ]]></verbatim> |
| <subheading>Author</subheading> |
| <para>Written by Alain Reguera Delgado.</para> |
| <subheading>Reporting bugs</subheading> |
| <para>Report bugs to <email><emailaddress>centos-artwork@centos.org</emailaddress></email> mailing list.</para> |
| <subheading>Copyright</subheading> |
| <para>Copyright ©right; 2009, 2010, 2011 The CentOS Project.</para> |
| <para>This is free software. You may redistribute copies of it under the terms of the GNU General Public License (see <xref><xrefnodename>GNU General Public License</xrefnodename></xref>). There is NO WARRANTY, to the extent permitted by law.</para> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts Functions</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Tuneup</nodename> |
| <nodeprev>Directories trunk Scripts Functions Render</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Tuneup</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Tuneup</indexterm></para> |
| <subheading>Goals</subheading> |
| <para>This section describes the <code>tuneup</code> functionality of <command>centos-art.sh</command> script and general examples about file maintainance inside a working copy of CentOS Artwork Repository.</para> |
| <subheading>Description</subheading> |
| <para>The <code>tuneup</code> functionality of <command>centos-art.sh</command> script provides the standard way of maintaining files inside the working copy of CentOS Artwork Repository.</para> |
| <para>Tasks related to file maintainance are repetitive. You might find yourself doing them time after time inside the working copy of CentOS Artwork Repository. Some of these maintainance tasks do update top comments on shell scripts, create table of contents for web pages, update metadata related to design models and remove unused definitions from design models.</para> |
| <para>When you execute the <code>tuneup</code> functionality of <command>centos-art.sh</command> script, it looks for all files that match the supported extensions (e.g., <file>.sh</file>, <file>.svg</file> and <file>.xhtml</file>) in the directory specified, builds a list with them and applies the maintainance tasks using file extensions as reference.</para> |
| <subsubheading>Maintaining <file>.sh</file> files</subsubheading> |
| <para>If shell scripts are found, the <code>tuneup</code> functionality of <command>centos-art.sh</command> script reads a comment template from <file>trunk/Scripts/Functions/Prepare/Config/shell_topcomment.sed</file> and applies it to shell scripts found, one by one. As result, all shell scripts will end up having the same copyright and license information the comment template does.</para> |
| <para>In order for the shell script top comment template to be applied correctly, the shell scripts you write must have the following structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| 1| #!/bin/bash |
| 2| # |
| 3| # doSomething.sh -- The function description goes here. |
| 4| # |
| 5| # Copyright |
| 6| # |
| 7| # ... |
| 8| # |
| 9| # ---------------------------------------------------------------------- |
| 10| # $Id$ |
| 11| # ---------------------------------------------------------------------- |
| 12| |
| 13| function doSomething { |
| 14| |
| 15| } |
| ]]></verbatim> |
| <para>The <code>tuneup</code> functionality of <command>centos-art.sh</command> script replaces all lines between the <samp>Copyright</samp> line (e.g., line 5) and the first separator line (e.g., line 9), inclusively. Everything else in the file will remain immutable.</para> |
| <subsubheading>Maintaining <file>.svg</file> files</subsubheading> |
| <para>If scalable vector graphics are found, the <code>tuneup</code> functionality reads a metadata template (<file>trunk/Scripts/Functions/Tuneup/Config/svg_metadata.sed</file>) and applies it to all files found, one by one. Immediatly after the metadata template has been applied and, before passing to next file, all unused definition are removed from file, too.</para> |
| <para>The metadata we apply from the metadata template is created dynamicaly combining the file absolute path, the workstation time information and the <command>centos-art.sh</command> script copyright holder information as reference. Additionally, the <emph>Creative Common Distribution-ShareAlike 3.0 License</emph> is also set in the metadata.</para> |
| <para>The elimination of unused definitions inside SVG files takes place through the <option>--vacuum-defs</option> option of <command>inkscape</command> command-line interface which is described in its man page (<command>man inkscape</command>).</para> |
| <subsubheading>Maintaining <file>.xhtml</file> files</subsubheading> |
| <para>If web pages are found, the <code>tuneup</code> functionality of <command>centos-art.sh</command> script transforms web page headings to make them accessible through a table of contents. The table of contents is expanded in place, wherever the <code><div class="toc"></div></code> piece of code be in the page.</para> |
| <para>Once the <code><div class="toc"></div></code> piece of code has be expanded, there is no need to put anything else in the page. You can run the <code>tuneup</code> functionality everytime you update the heading information so as to update the table of contents, too.</para> |
| <para>In order for the <code>tuneup</code> functionality of <command>centos-art.sh</command> script to transform headings, you need to put headings in just one line using one of the following forms:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| <h1><a name="">Title</a></h1> |
| <h1><a href="">Title</a></h1> |
| <h1><a name="" href="">Title</a></h1> |
| ]]></verbatim> |
| <para>In the example above, h1 can vary from h1 to h6. Closing tag must be present and also match the openning tag. The value of <option>name</option> and <option>href</option> options from the anchor element are set dynamically using the md5sum output of combining the page location, the <code>head-</code> string and the heading string. If any of the components used to build the heading reference changes, you need to run the the <code>tuneup</code> functionality of <command>centos-art.sh</command> script in order for the anchor elements to use the correct information.</para> |
| <subheading>Usage</subheading> |
| <subsubheading>Synopsis</subsubheading> |
| <para><command>centos-art tuneup [OPTIONS] path/to/dir</command></para> |
| <subsubheading>Options</subsubheading> |
| <table> |
| <tableitem> |
| <tableterm><option>--quiet</option></tableterm> |
| <item> |
| <para>Supress all output messages, including confirmation question. Use this option with care.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--filter='regex'</option></tableterm> |
| <item> |
| <para>Reduce the amount of files to process using <samp>regex</samp> as pattern.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--answer-yes</option></tableterm> |
| <item> |
| <para>Assume `yes' to all confirmation questions.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>--dont-commit-changes</option></tableterm> |
| <item> |
| <para>Supress all <code>commit</code> and <code>update</code> actions realized over files already processed, before and after the action itself had took place in the working copy.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subsubheading>Examples</subsubheading> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art tuneup trunk/Scripts</command></tableterm> |
| <item> |
| <para>Update the copyright and license notice of all the shell scripts we have in <file>trunk/Scripts</file> directory structure.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art tuneup trunk/Identity/Models/Brands --filter="symbol"</command></tableterm> |
| <item> |
| <para>Update metadata and remove unused definitions from all design models in <file>trunk/Identity/Models/Brands</file> which have the word <samp>symbol</samp> in the file name.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art tuneup trunk/Identity/Webenv/App/Home</command></tableterm> |
| <item> |
| <para>Update headings and the related table of contents to all web pages inside <file>trunk/Identity/Webenv/App/Home</file>, recusively.</para> |
| </item> |
| </tableitem> |
| </table> |
| <subheading>See also</subheading> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts Functions</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </section> |
| </node> |
| <node> |
| <nodename>Licenses</nodename> |
| <nodenext>Index</nodenext> |
| <nodeprev>Directories</nodeprev> |
| <nodeup>Top</nodeup> |
| <chapter> |
| <title>Licenses</title> |
| <para><indexterm index="cp">Licenses</indexterm></para> |
| <menu> |
| <menuentry> |
| <menunode>GNU General Public License</menunode> |
| <menutitle>GNU General Public License</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>GNU Free Documentation License</menunode> |
| <menutitle>GNU Free Documentation License</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </chapter> |
| </node> |
| <node> |
| <nodename>GNU General Public License</nodename> |
| <nodenext>GNU Free Documentation License</nodenext> |
| <nodeup>Licenses</nodeup> |
| <section> |
| <title>GNU General Public License</title> |
| <para><indexterm index="cp">GNU General Public License</indexterm>Version 2, June 1991</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Copyright (C) 1989, 1991 Free Software Foundation, Inc. |
| 675 Mass Ave, Cambridge, MA 02139, USA |
| ]]></verbatim> |
| <para>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.</para> |
| <subheading>Preamble</subheading> |
| <para>The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.</para> |
| <para>When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.</para> |
| <para>To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.</para> |
| <para>For example, if you distribute copies of such a program, whether gratis or for a fee, 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 show them these terms so they know their rights.</para> |
| <para>We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.</para> |
| <para>Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.</para> |
| <para>Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.</para> |
| <para>The precise terms and conditions for copying, distribution and modification follow.</para> |
| <subheading>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</subheading> |
| <para>0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is addressed as “you”.</para> |
| <para>Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.</para> |
| <para>1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.</para> |
| <para>You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.</para> |
| <para>2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:</para> |
| <para>a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.</para> |
| <para>b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.</para> |
| <para>c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)</para> |
| <para>These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.</para> |
| <para>Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.</para> |
| <para>In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.</para> |
| <para>3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:</para> |
| <para>a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,</para> |
| <para>b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,</para> |
| <para>c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)</para> |
| <para>The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.</para> |
| <para>If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.</para> |
| <para>4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.</para> |
| <para>5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.</para> |
| <para>6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.</para> |
| <para>7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.</para> |
| <para>If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.</para> |
| <para>It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.</para> |
| <para>This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.</para> |
| <para>8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.</para> |
| <para>9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.</para> |
| <para>Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.</para> |
| <para>10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.</para> |
| <para><strong>NO WARRANTY</strong></para> |
| <para>11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.</para> |
| <para>12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</para> |
| <para><strong>END OF TERMS AND CONDITIONS</strong></para> |
| <subheading>Appendix: How to Apply These Terms to Your New Programs</subheading> |
| <para>If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.</para> |
| <para>To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| <one line to give the program's name and a brief idea of what it does.> |
| Copyright (C) 19yy <name of author> |
| |
| This program is free software; you can redistribute it and/or modify |
| it under the terms of the GNU General Public License as published by |
| the Free Software Foundation; either version 2 of the License, or |
| (at your option) any later version. |
| |
| This program is distributed in the hope that it will be useful, |
| but WITHOUT ANY WARRANTY; without even the implied warranty of |
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| GNU General Public License for more details. |
| |
| You should have received a copy of the GNU General Public License |
| along with this program; if not, write to the Free Software |
| Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| ]]></verbatim> |
| <para>Also add information on how to contact you by electronic and paper mail.</para> |
| <para>If the program is interactive, make it output a short notice like this when it starts in an interactive mode:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Gnomovision version 69, Copyright (C) 19yy name of author |
| Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. |
| This is free software, and you are welcome to redistribute it |
| under certain conditions; type `show c' for details. |
| ]]></verbatim> |
| <para>The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items–whatever suits your program.</para> |
| <para>You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Yoyodyne, Inc., hereby disclaims all copyright interest in the program |
| `Gnomovision' (which makes passes at compilers) written by James Hacker. |
| |
| <signature of Ty Coon>, 1 April 1989 |
| Ty Coon, President of Vice |
| ]]></verbatim> |
| <para>This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>GNU Free Documentation License</nodename> |
| <nodeprev>GNU General Public License</nodeprev> |
| <nodeup>Licenses</nodeup> |
| <section> |
| <title>GNU Free Documentation License</title> |
| <para><indexterm index="cp">GNU Free Documentation License</indexterm>Version 1.2, November 2002</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. |
| 675 Mass Ave, Cambridge, MA 02139, USA |
| ]]></verbatim> |
| <para>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.</para> |
| <subheading>Preamble</subheading> |
| <para>The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.</para> |
| <para>This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.</para> |
| <para>We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.</para> |
| <subheading>1. APPLICABILITY AND DEFINITIONS</subheading> |
| <para>This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.</para> |
| <para>A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.</para> |
| <para>A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.</para> |
| <para>The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.</para> |
| <para>The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.</para> |
| <para>A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.</para> |
| <para>Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.</para> |
| <para>The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.</para> |
| <para>A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.</para> |
| <para>The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.</para> |
| <subheading>2. VERBATIM COPYING</subheading> |
| <para>You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section <emph>3. COPYING IN QUANTITY</emph>.</para> |
| <para>You may also lend copies, under the same conditions stated above, and you may publicly display copies.</para> |
| <subheading>3. COPYING IN QUANTITY</subheading> |
| <para>If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.</para> |
| <para>If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.</para> |
| <para>If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.</para> |
| <para>It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.</para> |
| <subheading>4. MODIFICATIONS</subheading> |
| <para>You may copy and distribute a Modified Version of the Document under the conditions of sections <emph>2. VERBATIM COPYING</emph> and <emph>3. COPYING IN QUANTITY</emph> above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:</para> |
| <para>A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.</para> |
| <para>B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.</para> |
| <para>C. State on the Title page the name of the publisher of the Modified Version, as the publisher.</para> |
| <para>D. Preserve all the copyright notices of the Document.</para> |
| <para>E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.</para> |
| <para>F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.</para> |
| <para>G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.</para> |
| <para>H. Include an unaltered copy of this License.</para> |
| <para>I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.</para> |
| <para>J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.</para> |
| <para>K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.</para> |
| <para>L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.</para> |
| <para>M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.</para> |
| <para>N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.</para> |
| <para>O. Preserve any Warranty Disclaimers.</para> |
| <para>If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.</para> |
| <para>You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.</para> |
| <para>You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.</para> |
| <para>The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.</para> |
| <subheading>5. COMBINING DOCUMENTS</subheading> |
| <para>You may combine the Document with other documents released under this License, under the terms defined in section <emph>4. MODIFICATIONS</emph> above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.</para> |
| <para>The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.</para> |
| <para>In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements”.</para> |
| <subheading>6. COLLECTIONS OF DOCUMENTS</subheading> |
| <para>You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.</para> |
| <para>You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.</para> |
| <subheading>7. AGGREGATION WITH IDENPENDENT WORKS</subheading> |
| <para>A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.</para> |
| <para>If the Cover Text requirement of section <emph>3. COPYING IN QUANTITY</emph> is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.</para> |
| <subheading>8. TRANSLATIONS</subheading> |
| <para>Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section <emph>4. MODIFICATIONS</emph>. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.</para> |
| <para>If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section <emph>4. MODIFICATIONS</emph>) to Preserve its Title (section <emph>1. APPLICABILITY AND DEFINITIONS</emph>) will typically require changing the actual title.</para> |
| <subheading>9. TERMINATION</subheading> |
| <para>You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.</para> |
| <subheading>Appendix 1. Future Revisions of this License</subheading> |
| <para>The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See <uref><urefurl>http://www.gnu.org/copyleft/</urefurl></uref>.</para> |
| <para>Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.</para> |
| <subheading>Appendix 2. How to use this License for your documents</subheading> |
| <para>To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Copyright (C) YEAR YOUR NAME. |
| |
| Permission is granted to copy, distribute and/or modify this |
| document under the terms of the GNU Free Documentation License, |
| Version 1.2 or any later version published by the Free Software |
| Foundation; with no Invariant Sections, no Front-Cover Texts, |
| and no Back-Cover Texts. A copy of the license is included in |
| the section entitled ``GNU Free Documentation License''. |
| ]]></verbatim> |
| <para>If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts”. line with this:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| with the Invariant Sections being LIST THEIR TITLES, with the |
| Front-Cover Texts being LIST, and with the Back-Cover Texts |
| being LIST. |
| ]]></verbatim> |
| <para>If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.</para> |
| <para>If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.</para> |
| |
| </section> |
| </node> |
| <node> |
| <nodename>Index</nodename> |
| <nodenext>List of Figures</nodenext> |
| <nodeprev>Licenses</nodeprev> |
| <nodeup>Top</nodeup> |
| <unnumbered> |
| <title>Index</title> |
| <printindex>cp</printindex> |
| </unnumbered> |
| </node> |
| <node> |
| <nodename>List of Figures</nodename> |
| <nodeprev>Index</nodeprev> |
| <nodeup>Top</nodeup> |
| <unnumbered> |
| <title>List of Figures</title> |
| <listoffloats type="Figure"></listoffloats> |
| </unnumbered> |
| </node> |
| </texinfo> |
| |
| |
| |
| |
| |
| |
| |