diff --git a/Manuals/TCAR-UG/Commons.ent b/Manuals/TCAR-UG/Commons.ent deleted file mode 100644 index dede723..0000000 --- a/Manuals/TCAR-UG/Commons.ent +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - - - - - - - - - -&TC; Project"> - - - -&TC; Mirrors"> - - - - - - - -&TCA; Repository"> -&TCA; SIG"> - -&TCAR; User's Guide"> - -centos-artwork@centos.org mailing list"> -centos-devel@centos.org mailing list"> -centos-info@centos.org mailing list"> - - - - -&TC; Documentation"> diff --git a/Manuals/TCAR-UG/Identity.docbook b/Manuals/TCAR-UG/Identity.docbook deleted file mode 100644 index e4b3488..0000000 --- a/Manuals/TCAR-UG/Identity.docbook +++ /dev/null @@ -1,17 +0,0 @@ - - - Corporate Identity - - - - ... - - - - &identity-project; - &identity-brand; - &identity-distro; - &identity-web; - &identity-showroom; - - diff --git a/Manuals/TCAR-UG/Identity.ent b/Manuals/TCAR-UG/Identity.ent deleted file mode 100644 index 21d5de9..0000000 --- a/Manuals/TCAR-UG/Identity.ent +++ /dev/null @@ -1,12 +0,0 @@ - - - - - - - - - - - - diff --git a/Manuals/TCAR-UG/Identity/Brand.docbook b/Manuals/TCAR-UG/Identity/Brand.docbook deleted file mode 100644 index 4640ff8..0000000 --- a/Manuals/TCAR-UG/Identity/Brand.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - The CentOS Brand - ... - - - Introduction - - - The CentOS Brands is the main visual manifestaion of The CentOS - Project. The CentOS Project uses The CentOS Logo to connect - all its visual manifestions (e.g., GNU/Linux Distributions, - Websites, Stationery, etc.) and, this way, it provides - recognition among other similar projects available on the - Internet. - - - - Both The CentOS Brand and all the visual manifestations that - derivate from it are available for you to study and propose - improvement around a good citizen's will at The CentOS - Community environment, but you are not allowed to redistribute - them elsewhere, without the given permission of The CentOS - Project. - - - - If you need to redistribute either The CentOS Logo or any - visual manifestation derived from it, write your intentions to - the The CentOS Developers mailing list (centos-devel@centos.org). - - - - - - ... - ... - - - diff --git a/Manuals/TCAR-UG/Identity/Distribution.docbook b/Manuals/TCAR-UG/Identity/Distribution.docbook deleted file mode 100644 index 0236910..0000000 --- a/Manuals/TCAR-UG/Identity/Distribution.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - The CentOS Distribution - ... - - - Release Schema - ... - - - - ... - ... - - - diff --git a/Manuals/TCAR-UG/Identity/Project.docbook b/Manuals/TCAR-UG/Identity/Project.docbook deleted file mode 100644 index 2a4d6b4..0000000 --- a/Manuals/TCAR-UG/Identity/Project.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - The CentOS Project - - - The CentOS Project Corporate Identity is the - persona of the organization known as The CentOS - Project. The CentOS Project Corporate Identity plays a - significant role in the way The CentOS Project, as - organization, presents itself to both internal and external - stakeholders. In general terms, The CentOS Project Corporate - Identity expresses the values and ambitions of The CentOS - Project organization, its business, and its characteristics. - - - - The CentOS Project Corporate Identity provides visibility, - recognizability, reputation, structure and identification to - The CentOS Project organization by means of Corporate Design, - Corporate Communication, and Corporate Behaviour. - - -
- The CentOS Project Corporate Identity. - - The CentOS Project Corporate Identity. - - - - - - -
- - &identity-project-mission; - &identity-project-design; - &identity-project-communication; - &identity-project-behaviour; - &identity-project-structure; - - diff --git a/Manuals/TCAR-UG/Identity/Project/behaviour.docbook b/Manuals/TCAR-UG/Identity/Project/behaviour.docbook deleted file mode 100755 index bd22f04..0000000 --- a/Manuals/TCAR-UG/Identity/Project/behaviour.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Corporate Behaviour - - - &TCP; corporate behaviour is focused on the effective - interaction of each member involved in the organization (e.g., - core developers, community members, etc.). It is related to - ethics and politics used to do the things inside the - organization. It is related to the sense of direction chosen - by the organization and they way the organization projects - itself to achieve it. - - - - &TCP; corporate behaviour takes place through &TCP; corporate - communication, as described in . - - - diff --git a/Manuals/TCAR-UG/Identity/Project/communication.docbook b/Manuals/TCAR-UG/Identity/Project/communication.docbook deleted file mode 100755 index b87dd32..0000000 --- a/Manuals/TCAR-UG/Identity/Project/communication.docbook +++ /dev/null @@ -1,141 +0,0 @@ - - - Corporate Communication - - - &TCP; corporate communication is focused on the effective - propagation of corporate messages. Propagation of corporate - messages is closely related to the media the organization uses - as vehicle to distribute its corporate messages. - - - - &TCP; corporate communication takes place through the - following visual manifestations: - - - - - &TCD; - - - This visual manifestation communicates its existence - through software packages. There are packages that make a - remarkable use of images, packages that make a moderate - use of images, and packages that don't use images at all. - This visual manifestation is focused on providing &TCP; - images required by software packages that do use images in - a remarkable way, specially those holding the upstream - brand (e.g., anaconda, - grub, syslinux, - gdm, kdebase). - - - - - The Community Enterprise Operating System itself - (communicates the essense of &TCP; existence.). - - - - - Release Schema (Lifetime) and all the stuff related (e.g., - Release Notes, Documentation, Erratas, etc.). - - - - - - - - &TCW; - - - This visual manifestation communicates its existence - through web applications. 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. Removing - these visual contraditions is object of work for this - visual manifestation. - - - - - The CentOS Chat. - - - - - The CentOS Mailing Lists. - - - - - The CentOS Forums. - - - - - The CentOS Wiki. - - - - - Special Interest Groups (SIGs). - - - - - Social Events, Interviews, Conferences, etc. - - - - - The extensive network of mirrors available for downloading - ISO files as well as RPMs and SRPMs used to build them up - in different architectures. - - - - - - - - &TCS; - - - This visual manifestation communicates its existence - through production of industrial objects carrying &TCB;. - These branded objects are directed to be distributed on - social events and/or shops. They provide a way of - promotion and commercialization that may help to reduce - &TCP; expenses (e.g., electrical power, hosting, servers, - full-time-developers, etc.), in a similar way as donations - may do. - - - - - Stationery (e.g., Posters, Stickers, CD Lables and Sleeves). - - - - - Clothes (e.g., Shirts, T-shirts, Pullovers, Caps). - - - - - Installation media (e.g., CDs, DVD, Pendrives). - - - - - - - - - diff --git a/Manuals/TCAR-UG/Identity/Project/design.docbook b/Manuals/TCAR-UG/Identity/Project/design.docbook deleted file mode 100755 index c1df9af..0000000 --- a/Manuals/TCAR-UG/Identity/Project/design.docbook +++ /dev/null @@ -1,96 +0,0 @@ - - - Corporate Design - - - The corporate design is focused on the effective presentation - of corporate messages. As corporate messages we understand all - the information emitted from the organization; and when we say - all we mean everything that can be - perceived through the human senses. The corporate design takes - care of defining what this information is and controlling the - way it goes out the organization producing it. - - - - When the organization doesn't take control over the corporate - messages it produces, the organization is letting that area of - its identity to the unknown and the results might be good or - not so good, it is hard to know. The issue to see here is - that even the organization doesn't take control over its - corporate messages, they are always talking about the - organization. Taking control of corporate messages is a - decition the organization needs to take by itself, based on - its need of better describe what it is. - - - - In the very specific case of &TCP;, we'll concentrate our - attention on corporate messages that reach us through the - visual sense. This is, all the visual manifestations &TCP; is - made of. As visual manifestaions we understand all the visible - media &TCP; uses to manifest its existence on. At this point - it is necessary to consider what &TCP; is, what its mission is - and what it is producing. This, in order to identify which - visual manifestations the organization is demanding attention - of corporate design for. - - - - Inside &TCP; we identify and apply corporate design to the - following visual manifestations: - - - - - &TCD; — This visual manifestation exists to cover - all actions related to artwork production and rebranding, - required by &TCD; in order to comply with upstream's - redistribution guidelines. This visual manifestation is - described in . - - - - - - &TCW; — This visual manifestation exists to cover - all actions related to artwork production required by - &TCP; to manifest its existence in the World Wide Web - medium. This visual manifestation is described in . - - - - - - &TCS; — This visual manifestation exists to cover - all actions related to artwork production required by - &TCP; to manifest its existence through media produced - industrially (e.g., stationery, clothes, CDs, DVDs, etc.). - This visual manifestation is described in . - - - - - - - - The visual manifestations identified above seem to cover most - media required by &TCP;, as organization, to show its - existence. However, other visual manifestations could be - added in the future, as long as they be needed, to cover - different areas like stands, buildings, offices, road - transportation or whaterver visual manifestation &TCP; - thouches to show its existence. - - - - Once all visual manifestations have been identified and - defined through design models, it is time to visually remark - their connection with &TCP;. This kind of connection is - realized by applying &TCB; to design models inside visual - manifestations supported through corporate design. - - - diff --git a/Manuals/TCAR-UG/Identity/Project/mission.docbook b/Manuals/TCAR-UG/Identity/Project/mission.docbook deleted file mode 100644 index 507873d..0000000 --- a/Manuals/TCAR-UG/Identity/Project/mission.docbook +++ /dev/null @@ -1,40 +0,0 @@ - - - Corporate Mission - - - &TCP; exists to produce &TCD;, an Enterprise-class Linux - Distribution derived from sources freely provided to the - public by a prominent North American Enterprise Linux vendor. - &TCD; conforms fully with the upstream vendors redistribution - policy and aims to be 100% binary compatible. (&TCD; mainly - changes packages to remove upstream vendor branding and - artwork.). - - - - &TCD; 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. - - - - &TCD; has numerous advantages including: an active and growing - user community, quickly rebuilt, tested, and QA'ed errata - packages, an extensive mirror network, developers who are - contactable and responsive of a reliable Enterprise-class - Linux Distribution, multiple free support avenues including a - Wiki, - IRC - Chat, Email Lists, Forums, and - a dynamic FAQ. - - - diff --git a/Manuals/TCAR-UG/Identity/Project/structure.docbook b/Manuals/TCAR-UG/Identity/Project/structure.docbook deleted file mode 100755 index b1042d7..0000000 --- a/Manuals/TCAR-UG/Identity/Project/structure.docbook +++ /dev/null @@ -1,91 +0,0 @@ - - - Corporate Structure - - - &TCP; corporate structure is based on a &MCVIS;. In this - configuration, one unique name and one unique visual style is - used in all visual manifestation &TCP; is made of. - - - - 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: - Hey! we are all part of &TCP;. - - - - Other corporate structures for &TCP; have been considered as - well. Such is the case of producing one different visual style - for each major release of &TCD;. 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 &TCP; - is made of. - - - - &TCP;, as organization, is mainly made of (but not limited to) - three visual manifestions: &TCD;, &TCW; and &TCS;. Inside - &TCD; visual manifestations, &TCP; maintains near to four - different major releases of &TCD;, parallely in time. - However, inside &TCW; 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 &TCD; - individually, but one web site to cover them all). Likewise, - the content produced in &TCS; is industrially created for no - specific release, but &TCP; in general. - - - - In order to produce the &TCPMCVIS; correctly, we need to - concider all the visual manifestations &TCP; is made of, not - just one of them. If one different visual style is - implemented for each major release of &TCD;, which one of - those different visual styles would be used to cover the - remaining visual manifestations &TCP; is made of (e.g., &TCW; - and &TCS;)? - - - - Probably you are thinking: yes, I see your point, but &TCB; - 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? - - - - Harder to maintain, more work to do, probably. Specially when - you consider that &TCP; 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. With - that in mind, we consider &TCPCVIS; must be consequent with - such stability and consistency tradition. It is true that - &TCB; does connect all the visual manifestations it is present - on, but that connection is strengthened if one unique visual - style backups it. In fact, whatever thing you do to strength - the visual connection among &TCP; visual manifestations would - be very good in favor of &TCP; recognition. - - - - 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 &TCD;, in order to refresh &TCD; visual - style; the problem itself is in not propagating the brand new - visual style created for the new release of &TCD; to all other - visual manifestations &TCP; is made of, in a way &TCP; 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 &TCAR;. - - - diff --git a/Manuals/TCAR-UG/Identity/Showroom.docbook b/Manuals/TCAR-UG/Identity/Showroom.docbook deleted file mode 100644 index db87232..0000000 --- a/Manuals/TCAR-UG/Identity/Showroom.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - The CentOS Showroom - ... - - - ... - ... - - - diff --git a/Manuals/TCAR-UG/Identity/Web.docbook b/Manuals/TCAR-UG/Identity/Web.docbook deleted file mode 100644 index 98780b2..0000000 --- a/Manuals/TCAR-UG/Identity/Web.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - The CentOS Web - ... - - - ... - ... - - - diff --git a/Manuals/TCAR-UG/Introduction.docbook b/Manuals/TCAR-UG/Introduction.docbook deleted file mode 100644 index 82ff07e..0000000 --- a/Manuals/TCAR-UG/Introduction.docbook +++ /dev/null @@ -1,84 +0,0 @@ - - - Introduction - - - Welcome to &TCARUG;. - - - - &TCAR; User's Guide describes how &TCPCVI; is organized and - produced inside &TCAR;. If you are looking for a - comprehensive, task-oriented guide for understanding how - &TCPCI; is produced, this is the manual for you. - - - - This manual is divided in the following categories: - - - - - - Repository - - - - - - Corporate Identity - - - - - - Localization - - - - - - Documentation - - - - - - Automation - - - - - - This manual discusses the following topics: - - - - - - &TCAR;, what it is, how it is organized, the things you can - achieve inside it and how you can do such things. - - - - - - &TCP; as organization and the components that define its - visual identity. Here we dig in the ground and climb up to - the sky, looking for the roots, flowers and thorns &TCP; is - made of. - - - - - - This manual assumes you have a basic understanding of &TCD;. - If you need help with it, refer to the help page on The CentOS Wiki for - a list of different places you can find help. - - - &intro-docconvs; - &intro-feedback; - - diff --git a/Manuals/TCAR-UG/Introduction.ent b/Manuals/TCAR-UG/Introduction.ent deleted file mode 100644 index 86feba0..0000000 --- a/Manuals/TCAR-UG/Introduction.ent +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/Manuals/TCAR-UG/Introduction/Docconvs.docbook b/Manuals/TCAR-UG/Introduction/Docconvs.docbook deleted file mode 100644 index 0f522c7..0000000 --- a/Manuals/TCAR-UG/Introduction/Docconvs.docbook +++ /dev/null @@ -1,225 +0,0 @@ -
- - Document Convenctions - - - In this manual, certain words are represented in different - fonts, typefaces, sizes, and weights. This highlighting is - systematic; different words are represented in the same style - to indicate their inclusion in a specific category. The types - of words that are represented this way include the - following: - - - - - command - - - Linux commands (and other operating system commands, when - used) are represented this way. This style should - indicate to you that you can type the word or phrase on - the command line and press Enter to - invoke a command. Sometimes a command contains words that - would be displayed in a different style on their own (such - as file names). In these cases, they are considered to be - part of the command, so the entire phrase is displayed as - a command. For example: - - - - Use the centos-art render - trunk/Identity/Images/Themes/TreeFlower/4/Distro/5/Anaconda - --filter="01-welcome" command to produce the first - slide image used by Anaconda in the branch 5 of &TCD; - using the version 4 of TreeFlower artistic motif. - - - - - - file name - - - File names, directory names, paths, and RPM package names - are represented this way. This style indicates that a - particular file or directory exists with that name on your - system. Examples: - - - - The init.sh file in trunk/Scripts/Bash/Cli/ - directory is the initialization script, written in Bash, - used to automate most of tasks in the repository. - - - - The centos-art command uses the - ImageMagick RPM package to convert - images from PNG format to other formats. - - - - - - key - - - A key on the keyboard is shown in this style. For - example: - - - - To use Tab completion to list particular - files in a directory, type ls, then a - character, and finally the Tab key. Your - terminal displays the list of files in the working - directory that begin with that character. - - - - - - keycombination - - - A combination of keystrokes is represented in this way. - For example: - - - - The CtrlAltBackspace - key combination exits your graphical session and returns - you to the graphical login screen or the console. - - - - - - computer output - - - Text in this style indicates text displayed to a shell - prompt such as error messages and responses to commands. - For example, the ls command displays - the contents of a directory using this style: - - - -render_doTranslation.sh render_getDirTemplate.sh render_doBaseActions.sh -render_getConfigOption.sh render_getOptions.sh render_doThemeActions.sh -render_getDirOutput.sh render.sh - - - - The output returned in response to the command (in this - case, the contents of the directory) is shown in this - style. - - - - - - prompt - - - A prompt, which is a computer's way of signifying that it - is ready for you to input something, is shown in this - style. Examples: - - - - - - $ - - - - - # - - - - - [centos@projects centos]$ - - - - - projects login: - - - - - - - - user input - - - Text that the user types, either on the command line or - into a text box on a GUI screen, is displayed in this - style. In the following example, - text is displayed in this style: To - boot your system into the text based installation program, - you must type in the text command - at the boot: prompt. - - - - - - replaceable - - - Text used in examples that is meant to be replaced with - data provided by the user is displayed in this style. In - the following example, - version-number is displayed in - this style: The directory for the kernel source is - /usr/src/kernels/version-number/, - where version-number is the - version and type of kernel installed on this system. - - - - - - Additionally, we use several different strategies to draw - your attention to certain pieces of information. In order of - urgency, these items are marked as a note, tip, important, - caution, or warning. For example: - - - Remember that Linux is case sensitive. In other words, a - rose is not a ROSE is not a rOsE. - - - - The directory /usr/share/doc/ contains - additional documentation for packages installed on your - system. - - - - If you modify the DHCP configuration file, the changes - do not take effect until you restart the DHCP daemon. - - - - Do not perform routine tasks as root — use a - regular user account unless you need to use the root account - for system administration tasks. - - - - Be careful to remove only the necessary partitions. - Removing other partitions could result in data loss or a - corrupted system environment. - - -
diff --git a/Manuals/TCAR-UG/Introduction/Feedback.docbook b/Manuals/TCAR-UG/Introduction/Feedback.docbook deleted file mode 100644 index f690b2a..0000000 --- a/Manuals/TCAR-UG/Introduction/Feedback.docbook +++ /dev/null @@ -1,18 +0,0 @@ -
- - Send in Your Feedback - - - If you find an error in the &TCAR;, or if you have thought of - a way to make this manual better, we would like to hear from - you! Share your suggestions in &TCAML;. - - - - When you make suggestion, try to be as specific as possible. - For example, if you have found an error in the manual, include - the section number and some of the surrounding text so we can - find it easily. - - -
diff --git a/Manuals/TCAR-UG/Licenses.docbook b/Manuals/TCAR-UG/Licenses.docbook deleted file mode 100644 index dfc86ce..0000000 --- a/Manuals/TCAR-UG/Licenses.docbook +++ /dev/null @@ -1,6 +0,0 @@ - - Licenses - &licenses-gpl; - &licenses-gfdl; - - diff --git a/Manuals/TCAR-UG/Licenses.ent b/Manuals/TCAR-UG/Licenses.ent deleted file mode 100644 index 29e0b56..0000000 --- a/Manuals/TCAR-UG/Licenses.ent +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/Manuals/TCAR-UG/Licenses/gfdl.docbook b/Manuals/TCAR-UG/Licenses/gfdl.docbook deleted file mode 100644 index 57d1e0a..0000000 --- a/Manuals/TCAR-UG/Licenses/gfdl.docbook +++ /dev/null @@ -1,591 +0,0 @@ - - - GNU Free Documentation License - - Version 1.2, November 2002 - - Copyright © 2000, 2001, 2002 Free Software Foundation, - Inc. 675 Mass Ave, Cambridge, MA 02139, USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - 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. - - 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 , which is a copyleft license - designed for free software. - - 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. - - - - - - Applicability and definitions - - 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. - - 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. - - 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 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. - - The Invariant Sections are certain - 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 Section then - there are none. - - 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. - - 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 file format whose - markup, or absence of markup, has been arranged to thwart or - discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of - text. A copy that is not is called Opaque. - - Examples of suitable formats for 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. - - 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. - - 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. - - 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. - - - - - - Verbatim copying - - 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 . - - You may also lend copies, under the same conditions - stated above, and you may publicly display copies. - - - - - - Copying in quantity - - 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 : - 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. - - 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. - - If you publish or distribute Opaque copies of the - Document numbering more than 100, you must either include a - machine-readable 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 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 - 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. - - 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. - - - - - - Modifications - - You may copy and distribute a of the Document under the - conditions of sections and above, - provided that you release the under precisely this License, with the filling the role of the - Document, thus licensing distribution and modification of the - to whoever possesses a - copy of it. In addition, you must do these things in the - : - - - - - Use in the (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. - - - List on the , as - authors, one or more persons or entities responsible - for authorship of the modifications in the , 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. - - - - State on the the - name of the publisher of the , as the - publisher. - - - - Preserve all the copyright notices of the - Document. - - - - Add an appropriate copyright notice for your - modifications adjacent to the other copyright - notices. - - - - Include, immediately after the copyright - notices, a license notice giving the public permission - to use the under the terms of this - License, in the form shown in the Addendum - below. - - - - Preserve in that license notice the full lists - of and required - given in the Document's - license notice. - - - - Include an unaltered copy of this License. - - - - 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 as given on the . 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 , then add an item describing the as stated in the previous - sentence. - - - - Preserve the network location, if any, given in - the Document for public access to a 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. - - - - 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. - - - - Preserve all the of the Document, - unaltered in their text and in their titles. Section - numbers or the equivalent are not considered part of - the section titles. - - - - Delete any section Entitled - Endorsements. Such a section may not - be included in the . - - - - Do not retitle any existing section to be - Entitled Endorsements or to conflict in - title with any . - - - Preserve any Warranty Disclaimers. - - - - - If the includes new - front-matter sections or appendices that qualify as 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 in the 's license notice. These titles - must be distinct from any other section titles. - - You may add a section Entitled - Endorsements, provided it contains nothing but - endorsements of your 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. - - 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 in the . 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. - - 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 . - - - - - - Combining documents - - You may combine the Document with other documents - released under this License, under the terms defined in - section above for - modified versions, provided that you include in the - combination all of the of - all of the original documents, unmodified, and list them all - as of your combined work - in its license notice, and that you preserve all their - Warranty Disclaimers. - - The combined work need only contain one copy of this - License, and multiple identical may be replaced with a single - copy. If there are multiple 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 in - the license notice of the combined work. - - 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. - - - - - - Collection of documents - - 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. - - 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. - - - - - - Aggregation with independent works - - 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. - - If the Cover Text requirement of section is applicable to these - copies of the Document, then if the Document is less than one - half of the entire aggregate, the Document's 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. - - - - - - Translations - - Translation is considered a kind of modification, so you - may distribute translations of the Document under the terms of - section . Replacing - with translations - requires special permission from their copyright holders, but - you may include translations of some or all in addition to the original - versions of these . 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. - - If a section in the Document is Entitled - Acknowledgements, Dedications, - or History, the requirement (section ) to Preserve its Title - (section ) will - typically require changing the actual title. - - - - - - Termination - - 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. - - - - - - Future Revisions of this License - - 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 . - - 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. - - - - - - How to use this License for your documents - - 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: - - -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. - - - If you have , - Front-Cover Texts and Back-Cover Texts, replace the - with...Texts. line with this: - - -with the Invariant Sections being LIST THEIR TITLES, with the -Front-Cover Texts being LIST, and with the Back-Cover Texts being -LIST. - - - If you have - without , or some other - combination of the three, merge those two alternatives to suit - the situation. - - 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. - - - - diff --git a/Manuals/TCAR-UG/Licenses/gpl.docbook b/Manuals/TCAR-UG/Licenses/gpl.docbook deleted file mode 100644 index 0990730..0000000 --- a/Manuals/TCAR-UG/Licenses/gpl.docbook +++ /dev/null @@ -1,497 +0,0 @@ - - - GNU General Public License - - Version 2, June 1991 - - Copyright © 1989, 1991 Free Software Foundation, Inc. - 675 Mass Ave, Cambridge, MA 02139, USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - 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. - - 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. - - 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. - - 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. - - We protect your rights with two steps: - - - - copyright the software, and - - - offer you this license which gives you legal - permission to copy, distribute and/or modify the - software. - - - - - 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. - - 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. - - The precise terms and conditions for copying, distribution - and modification follow. - - - - - - Terms and Conditions for Copying, Distribution and Modification - - - - Section 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. - - 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. - - - - - - Section 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 above, provided that you also meet all of these - conditions: - - - - You must cause the modified files to carry prominent - notices stating that you changed the files and the date of - any change. - - - 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. - - - 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. - - - - - - - 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. - - 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. - - 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. - - - - - - Section 3 - - You may copy and distribute the Program (or a work - based on it, under ) in - object code or executable form under the terms of and above provided that you also - do one of the following: - - - - - - Accompany it with the complete corresponding - machine-readable source code, which must be - distributed under the terms of and above on a medium - customarily used for software interchange; - or, - - - - - - 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 and above on a medium - customarily used for software interchange; - or, - - - - - - 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.) - - - - - - - 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. - - 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. - - - - - - Section 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. - - - - - - Section 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. - - - - - - Section 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. - - - - - - Section 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. - - 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. - - 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. - - This section is intended to make thoroughly clear what is - believed to be a consequence of the rest of this License. - - - - - - Section 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. - - - - - - Section 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. - - 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. - - - - - - Section 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. - - - - - - NO WARRANTY - Section 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. - - - - - - Section 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. - - End of Terms and Conditions. - - - - - - - - How to Apply These Terms to Your New Programs - - 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. - - 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. - - -<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. - - - Also add information on how to contact you by electronic - and paper mail. - - If the program is interactive, make it output a short - notice like this when it starts in an interactive mode: - - -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. - - - 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. - - 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: - - -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 - - - 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. - - - - diff --git a/Manuals/TCAR-UG/Locales.docbook b/Manuals/TCAR-UG/Locales.docbook deleted file mode 100644 index f33f6e9..0000000 --- a/Manuals/TCAR-UG/Locales.docbook +++ /dev/null @@ -1,21 +0,0 @@ - - - Localization - - - ... - - - - ... - ... - - - ... - ... - - - - - - diff --git a/Manuals/TCAR-UG/Locales.ent b/Manuals/TCAR-UG/Locales.ent deleted file mode 100644 index 48245e8..0000000 --- a/Manuals/TCAR-UG/Locales.ent +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/Manuals/TCAR-UG/Manuals.docbook b/Manuals/TCAR-UG/Manuals.docbook deleted file mode 100644 index 80d9424..0000000 --- a/Manuals/TCAR-UG/Manuals.docbook +++ /dev/null @@ -1,20 +0,0 @@ - - - Documentation - - - - This part describes the repository's documentation work - line. Here you'll find how documentation backends inside - The CentOS Distribution are used to produce documentation - manuals inside The CentOS - Artwork Repository. - - - - - &manuals-texinfo; - &manuals-docbook; - - - diff --git a/Manuals/TCAR-UG/Manuals.ent b/Manuals/TCAR-UG/Manuals.ent deleted file mode 100644 index 8bb6cd7..0000000 --- a/Manuals/TCAR-UG/Manuals.ent +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/Manuals/TCAR-UG/Manuals/Docbook.docbook b/Manuals/TCAR-UG/Manuals/Docbook.docbook deleted file mode 100644 index 24c369a..0000000 --- a/Manuals/TCAR-UG/Manuals/Docbook.docbook +++ /dev/null @@ -1,7 +0,0 @@ - - - DocBook Backend - - &manuals-docbook-intro; - - diff --git a/Manuals/TCAR-UG/Manuals/Docbook/intro.docbook b/Manuals/TCAR-UG/Manuals/Docbook/intro.docbook deleted file mode 100644 index 4645113..0000000 --- a/Manuals/TCAR-UG/Manuals/Docbook/intro.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Introduction - - - ... - - - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo.docbook b/Manuals/TCAR-UG/Manuals/Texinfo.docbook deleted file mode 100644 index 3f0523f..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo.docbook +++ /dev/null @@ -1,11 +0,0 @@ - - - Texinfo Backend - - &manuals-texinfo-intro; - &manuals-texinfo-structure; - &manuals-texinfo-templates; - &manuals-texinfo-localizing; - &manuals-texinfo-encoding; - - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo/encoding.docbook b/Manuals/TCAR-UG/Manuals/Texinfo/encoding.docbook deleted file mode 100644 index a9ac2a7..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo/encoding.docbook +++ /dev/null @@ -1,5 +0,0 @@ - - Document Encoding - ... - - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo/intro.docbook b/Manuals/TCAR-UG/Manuals/Texinfo/intro.docbook deleted file mode 100644 index f9c99b0..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo/intro.docbook +++ /dev/null @@ -1,38 +0,0 @@ - - - Introduction - - - Documentation manuals that use - Texinfo as documentation backend - are conceived 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. They provides a documentation entry for each directory - inside the repository and, this way, a place to document it. - - - - Most actions related to Texinfo documentation backend (e.g., - editing, reading, copying, renaming, etc.) are controlled by - the help functionality as described in - . Through this - functionality you can manipulate documentation entries in a - way that you don't need to take care of updating menus, nodes - and cross reference information inside the manual source files - because 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 by your own, there - is no functionality to help you doing such things, yet. - - - - The Texinfo documentation backend could result useful to you - if your only need is to document directory structures in a - manual that follows, exactly, the same organization of the - structure it documents (e.g., one directory one documentation - entry for it). - - - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo/localizing.docbook b/Manuals/TCAR-UG/Manuals/Texinfo/localizing.docbook deleted file mode 100644 index 0661a4c..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo/localizing.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - Document Localization - ... - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo/structure.docbook b/Manuals/TCAR-UG/Manuals/Texinfo/structure.docbook deleted file mode 100644 index 7fc3abf..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo/structure.docbook +++ /dev/null @@ -1,131 +0,0 @@ - - - Document Structure - - - The document structure provides the organization needed to - make the documentation scalable and maintainable through time - which, in turn, involves document sectioning and file - organization inside specific locations of the working copy. - The document structure is also a convenction we adopt in order - to automate frequent tasks related to the document structure - itself. Without a well defined document structure convenction, - it would be very difficult for automation script to guess - where the documentation files are. - - - - The file organization of Texinfo documentation backend takes - place in trunk/Manuals/Repository/Texinfo/ - directory. Inside this location there is one documentation - structure for each language you want to support and the - repository-init.pl and - repository.sed files which let you - control common characteristics of final XHTML output (e.g., - texi2html initialization, and markup - transformations). - - - - The document sectioning follows the idea of an upside-down - tree to organize chapters, sections, subsections, and the - like. The document initiates with a Top node where we placed - document's title, copyright note, abstract, and a list of - available chapters to start browsing. Inside each chapter the - information is logically organized in sections which in turn - are subdivided in subsections and subsubsections. - - - - The Texinfo document structure produced by - help functionality organizes information - in two chapters only, which are: - - - - - - Directories — This chapter organizes documentation - entries related to repository directories. In the normal - work flow, you don't need to touch the files of this - chapter by your own. For that purpose, the - centos-art.sh script porovides the - help functionality. To manipulate - documentation entries in this chapter, you use the - help functionality as described in - . - - - - - - Licenses — This chapter includes licenses from - trunk/Scripts/Functions/Help/Texinfo/Templates/language/Licenses/ - directory. In the normal work flow, you don't need to - touch this chapter. It is created when the document - structure is created and should ramain that way. If you - need to improve the markup, update the template files for - your language, not the content of this chapter. - - - - - - - - - At the same level of chapter directories, the - repository.texinfo, - repository-index.texinfo, - repository-menu.texinfo and - repository-nodes.texinfo files exist to - set manual's main definitions (e.g., title, copyright notice, - chapters, appendixes, indexes and all the similar stuff a - documentation manual should have). - - - Inside each chapter directory, the - chapter.texinfo, - chapter-menu.texinfo and - chapter-nodes.texinfo files exist to - control definition of sections. In addition to these files, - there are documentation entries to store the document's content - itself, using arbitrary file names prefixed with the texinfo extension, just as it is - illustrated in . - - - - Texinfo backend's document structure. - - Texinfo backend's document structure. - - - trunk/Manuals/Repository/Texinfo -|-- en_US -| |-- Directories -| | |-- chapter-menu.texinfo -| | |-- chapter-nodes.texinfo -| | |-- chapter.texinfo -| | |-- trunk/Identity.texinfo -| | `-- trunk.texinfo -| |-- Licenses -| | |-- chapter-menu.texinfo -| | |-- chapter-nodes.texinfo -| | `-- chapter.texinfo -| |-- repository-index.texinfo -| |-- repository-menu.texinfo -| |-- repository-nodes.texinfo -| `-- repository.texinfo -|-- repository-init.pl -|-- repository.css -`-- repository.sed - - - - - - diff --git a/Manuals/TCAR-UG/Manuals/Texinfo/templates.docbook b/Manuals/TCAR-UG/Manuals/Texinfo/templates.docbook deleted file mode 100644 index e459647..0000000 --- a/Manuals/TCAR-UG/Manuals/Texinfo/templates.docbook +++ /dev/null @@ -1,6 +0,0 @@ - - Document Templates - ... - - - diff --git a/Manuals/TCAR-UG/Repository.docbook b/Manuals/TCAR-UG/Repository.docbook deleted file mode 100644 index ea8dd86..0000000 --- a/Manuals/TCAR-UG/Repository.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Repository - - &repo-convs; - &repo-ws; - &repo-history; - - diff --git a/Manuals/TCAR-UG/Repository.ent b/Manuals/TCAR-UG/Repository.ent deleted file mode 100644 index f934105..0000000 --- a/Manuals/TCAR-UG/Repository.ent +++ /dev/null @@ -1,23 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions.docbook b/Manuals/TCAR-UG/Repository/Convenctions.docbook deleted file mode 100644 index 71f68f8..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - Repository Convenctions - - &repo-convs-mission; - &repo-convs-layout; - &repo-convs-worklines; - &repo-convs-filenames; - &repo-convs-relbdirs; - &repo-convs-syncpaths; - &repo-convs-extending; - &repo-convs-publishing; - &repo-convs-authoring; - &repo-convs-copying; - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/authoring.docbook b/Manuals/TCAR-UG/Repository/Convenctions/authoring.docbook deleted file mode 100755 index fdbd8e8..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/authoring.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - Repository Authoring - - - The content produced inside &TCAR; is copyright of &TCAS; and - this is something you, as author, need to be aware of because - you are giving part of your creation's rights to someone else; - &TCAS; for this matter. In this case, your work is - distributed using &TCAS; as copyright holder not your name. - Because &TCAS; is the copyright holder, is the license chosen - by &TCAS; the one applied to your work, so it is the one you - need to agree with before making a creation inside &TCAR;. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/copying.docbook b/Manuals/TCAR-UG/Repository/Convenctions/copying.docbook deleted file mode 100755 index 04a3957..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/copying.docbook +++ /dev/null @@ -1,68 +0,0 @@ - - - Repository Copying Conditions - - - &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation - itself is controlled by the centos-art.sh - script. - - - - Both the centos-art.sh script and &TCAR;, - 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 work - that they might get from you. - - - - Specifically, we want to make sure that you have the right to - give away copies of centos-art.sh script - and the organization of files it needs to work, that you - receive source code or else can get it if you want it, that - you can change this work or use pieces of it in new free - works, and that you know you can do these things. - - - - To make sure that everyone has such rights, we have to forbid - you to deprive anyone else of these rights. For example, if - you distribute copies of the centos-art.sh - script, you must give the recipients all the rights that you - have. You must make sure that they, too, receive or can get - the source code. And you must tell them their rights. - - - - Also, for our own protection, we must make certain that - everyone finds out that there is no warranty for the - centos-art.sh script. If this work is - modified by someone else and passed on, we want their - recipients to know that what they have is not what we - distributed, so that any problems introduced by others will - not reflect on our reputation. - - - - The centos-art.sh script is released as a - GPL work. Individual packages used by - centos-art.sh script include their own - licenses and the centos-art.sh script - license applies to all packages that it does not clash with. - If there is a clash between the - centos-art.sh script license and individual - package licenses, the individual package license applies - instead. - - - - The precise conditions of the license for the - centos-art.sh script are found in the . This manual specifically is covered - by the . - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/extending.docbook b/Manuals/TCAR-UG/Repository/Convenctions/extending.docbook deleted file mode 100644 index 6e0d153..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/extending.docbook +++ /dev/null @@ -1,40 +0,0 @@ - - - Extending Repository Layout - - - Occasionly, you may find that new components of &TCPCVI; 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 starting to create directories blindly all over, is: - What is the right place to store it? - - - - When the repository structure is extended, it is very useful - to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a - matter of choosing appropriate names. It is also worth to - know that each directory in the repository responds to one or - more concepts that justify its existence. - - - - To build a directory structure inside the repository, you need - to define the concept behind it first and later create the - directory, remembering that there are locations inside the - repository that define concepts you probably would prefer to - reuse. For example, the trunk/Identity/Images/Themes - directory stores artistic motifs of different themes, the - trunk/Identity/Models/Themes - directory stores design models for themes, the trunk/Manuals directory stores - documentation, the trunk/L10n stores translation - messages, and the trunk/Scripts stores automation - scripts. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/filenames.docbook b/Manuals/TCAR-UG/Repository/Convenctions/filenames.docbook deleted file mode 100644 index d47dbf4..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/filenames.docbook +++ /dev/null @@ -1,27 +0,0 @@ - - - Repository File Names - - - Inside &TCAR;, file names are all written in lowercase (e.g., - 01-welcome.png, - splash.png, - anaconda_header.png, etc.) and directory - names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel - case (e.g., TreeFlower, - etc.). - - - - In the very specific case of repository documentation entries, - file names follow the directory naming convenction. This is - because they are documenting directories and that is something - we want to remark. So, to better describe what we are - documenting, documentation entries follow the name convenction - used by the item they document. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/layout.docbook b/Manuals/TCAR-UG/Repository/Convenctions/layout.docbook deleted file mode 100644 index a62d4fd..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/layout.docbook +++ /dev/null @@ -1,58 +0,0 @@ - - - Repository Layout - - - &TCAR; is supported by Subversion, 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. - - - - &TCAR; is made of one source repository and - many working copies of that source repository. - The working copies are independent one another, can be - distributed all around the world and provide a local place for - designers, documentors, translators and programmers to perform - their work in a descentralized way. The source repository, on - the other hand, provides a central place for all independent - working copies to interchange data and provides the - information required to permit extracting previous versions of - files at any time. - - - - The first level of directories in the repository provides - organization through a convenctional trunk, - branches and tags layout. In - this configuration the trunk directory is where main - changes take place, the tags directory is where frozen - copies of trunk changes - are placed in for releasing, and the branches directory is an - intermediate place between trunk and tags states where changes take - place before being merged into trunk and finally released into - tags. - - - - The second level of directories in the repository provides - organization for repository work lines, as described in . - - - - All other subsequent levels of directories in the repository, - from third level on, are created to organize specific concepts - related to the work line they are in. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/mission.docbook b/Manuals/TCAR-UG/Repository/Convenctions/mission.docbook deleted file mode 100755 index 76a2e7c..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/mission.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Repository Mission - - - &TCAR; exists to oraganize the files related to &TCPCVI;. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/publishing.docbook b/Manuals/TCAR-UG/Repository/Convenctions/publishing.docbook deleted file mode 100755 index dd8d7e4..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/publishing.docbook +++ /dev/null @@ -1,54 +0,0 @@ - - - Repository Publishing - - - When you perform changes inside your working copy, those - changes are local to your working copy only. In order for you - to share your changes with others, you need to commit them up - to the central repository the working copy you are using was - initially downloaded from. To commit your changes up to the - central repository you use the commit - command of Subversion's client installed in your workstation. - - - - - Initially, when you get registered inside &TCAR;, you won't be - able to publish your changes to &TCAR; immediatly. It is - necessary that you prove your interest in contributing first, - preferably in conjunction with a description of the changes - you pretend to commit. This restriction is necessary in order - to protect the source repository from spammers. - - - - Once you've received access to publish your changes, they will - remain valid to you and there is no need for you to request - permission to publish new changes as long as you behave as a - good cooperating citizen. - - - - As a good cooperating citizen one understand of a person who - respects the work already done by others and share ideas with - authors before changing relevant parts of their work, - specially in situations when the access required to realize - the changes has been granted already. Of course, there is a - time when conversation has taken place, the paths has been - traced and changing the work is so obvious that there is no - need for you to talk about it; that's because you already did, - you already built the trust to keep going. As complement, the - mailing list mentioned above is available for sharing ideas in - a way that good relationship between community citizens could - be constantly balanced. - - - - The relationship between community citizens is monitored by - repository administrators. Repository administrators are - responsible of granting that everything goes the way it needs - to go in order for &TCAR; to accomplish its mission. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/relbdirs.docbook b/Manuals/TCAR-UG/Repository/Convenctions/relbdirs.docbook deleted file mode 100644 index 1abadfd..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/relbdirs.docbook +++ /dev/null @@ -1,123 +0,0 @@ - - - Repository Path Types - - - In order for automation scripts to produce content inside a - working copy of &TCAR;, it is required that all work lines be - related somehow. The relation between work lines is used by - automation scripts to know where to retrive the information - they need to work with (e.g., input files, translation - messages, output locations, etc.). This kind of relation is - built using two path constructions known as master - paths and auxiliar paths. - - - - - Master Paths - - - A master path refers to a directory inside the repository that - contain input files required to produce output files through - automation scripts. Examples of master paths inside the - repository include: - - - - - trunk/Identity/Models/Brands - - - - - trunk/Manuals/Repository/Docbook - - - - - trunk/Identity/Models/Themes/Default/Distro/5/Anaconda - - - - - - - - - Auxiliar paths - - - An auxiliar path refers a directory inside the repository - considered auxiliar for the master path. Auxiliar path can be - either for output or localization. Assuming the master path - provides the input information, the auxiliar paths provide the - auxiliar information which describes how and where that input - information is rendered by automation scripts. Examples of - auxiliar paths inside the repository include: - - - - - trunk/Identity/Images/Brands - - - - - trunk/Manuals/Repository/Docbook/es_ES - - - - - trunk/Locales/Manuals/Repository/Docbook/es_ES - - - - - trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES - - - - - trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES - - - - - - - - - - - The relationship between master and auxiliar paths is built by - combining the second directory level of master paths with - directories in the second directory level of repository - layout. In the second directory level of repository layout, - the Identity, Manuals and Scripts directories are always - used to create the master paths and the output auxiliar paths. - The Locales directory, - on the other hand, is always used to create localization - auxiliar paths for all the master paths available under - Identity, Manuals and Scripts directories. - - - - For example, if the LANG environment variable - is set to es_ES.UTF-8 and you execute the - render functionality of - centos-art.sh script with the trunk/Manuals/Repository/Docbook - master path as argument, it will produce &TCARUG; in Spanish - language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES - auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES - auxiliar path. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/syncpaths.docbook b/Manuals/TCAR-UG/Repository/Convenctions/syncpaths.docbook deleted file mode 100644 index 23ad317..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/syncpaths.docbook +++ /dev/null @@ -1,96 +0,0 @@ - - - Syncronizing Repository Paths - - - Once both master and auxiliar paths have been related in the - repository, they shouldn't be changed except you absolutly - need to do so. In this cases, when you need to change master - or auxiliar paths, it is required that you also change the - relation between them so as to retain their bond. This - process of keeping master and auxiliar paths - connected between themselves is known as - path syncronization. - - - - Path syncronization is required for automation scripts to know - where to store final output, where to retrive translation - messages from, and whatever information you might need to - count with. If the 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 to work with or - where to store the output information produced from it. Path - syncronization is the way we use through to organize and - extend the information stored in the repository. - - - - Path syncronization involves both movement of files and - replacement of content inside files. Movement of files is - related to actions like renaming files and directories inside - the repository. Replacement of content inside files is - related to actions like replacing information (e.g., paths - information) inside files in order to keep file contents and - file locations consistent one another after a file movement. - - - - The order followed to syncronize path information is very - important because the versioned nature of the files we are - working with. When a renaming action needs to be performed - inside the repository, we avoid making replacements inside - files first and file movements later. This would demand two - commit actions: one for the files' internal changes and - another for the file movement itself. Otherwise, we prefer to - perform file movements first and files' internal replacements - later. This way it is possible to commit both changes as if - they were just one. - - - - - There is no support for URLs actions inside - centos-art.sh script. The - centos-art.sh script is designed to work - with local files inside the working copy only. If you need to - perform URL actions directly, use Subversion's commands - instead. - - - - - At this moment there is no full implementation of path - syncronization process inside centos-art.sh - script and it is somthing we need to do oursleves. However, - the texinfo backend of help - functionality which provides a restricted implementation of - path syncronization to this specific area of documentation - through the , - and options you can take as - reference to implement it in other areas. - - - - The plan for a full implementation of path syncronization - would be to create individual restricted implementations like - the one in texinfo backend for other areas that - demand it and then, create a higher implmentation that - combines them all as needed. This way, if we try to rename a - repository directory the higher action will define which are - all the restricted actions that should be performed in order - to make the full path syncronization. - - - - For example, if the directory we are renaming is a master - path, it is required to syncronize the related output and - localization auxiliar paths. On the other hand, if the - directory we are renaming through full path syncronization is - an auxiliar path, it is required to determine first what is - the related master path and later, perform the syncronization - from master path to auxiliar paths as if the path provided - would be the master path not the auxiliar path. - - - diff --git a/Manuals/TCAR-UG/Repository/Convenctions/worklines.docbook b/Manuals/TCAR-UG/Repository/Convenctions/worklines.docbook deleted file mode 100644 index a49257e..0000000 --- a/Manuals/TCAR-UG/Repository/Convenctions/worklines.docbook +++ /dev/null @@ -1,112 +0,0 @@ - - - Repository Work Lines - - - To organize content production inside &TCAR;, production has - been divided into individual work lines that relate one - another based on the idea of doing one thing well. Later, the - results produced individually by each work line are combined - to achieve a higher purpose. Work lines, as conceived here, - provide the relayable output components the production cycle - inside &TCAR; needs to let everyone to work syncronized in a - descentralized environment. - - - - - Visual Identity - - - In the production cycle, the first step takes place through - graphic design. It is focused on preparing design models for - all the visual manifestation &TCP; is made of. Here, graphic - designers describe the visual characteristics of each visual - manifestation (e.g., image dimensions, position of text in the - visible area, translation markers, etc.). - Later, once design models have been defined, graphic designers - take care of artistic motifs to define the visual style of - those design models already created (e.g., how they look and - feel). - - - - Finally, graphic designers use the - render functionality of - centos-art.sh script to combine both design - models and artistic motifs in order to produce the final - images required by each visual manifestaions. - - - - - - - Localization - - - The second step in the production cycle is to localize - source files (e.g., SVG, DocBook, Shell scripts). This step - makes possible to produce localized images, localized - documentation and localized automation scripts. - - - - The localization tasks are carried on by translators using the - locale functionality of the - centos-art.sh script which take care of - retriving translatable strings from source files and provide a - consistent localization interface based on GNU - gettext multi-lingual message - production tool set and xml2po command. - - - - - - - Documentation - - - The third step in the production cycle is to document &TCAR;, - what it is and how to use it. This step provides the - conceptual ideas used as base to edificate &TCPCVI; and is - implemented through &TCARUG;. - - - - To write documentation, documentors use the - help functionality of - centos-art.sh script which provide an - consistent interface for building documentation through - different documentation backends (e.g., Texinfo and DocBook). - - - - - - - Automation - - - The fourth step in the production cycle is to automate - frequent tasks inside &TCAR;. This step closes the production - cycle and provides the production standards needed by all - different work lines to coexist together. Here is where - the centos-art.sh script and all - its functionalities (e.g., render for - rendition, help for documentation, - locale for localization, etc.) are - developed. - - - - At this point it should be obvious, but we consider worth to - remember that: there is no need to type several tasks, time - after time, if they can be programmed into just one executable - script. - - - - - diff --git a/Manuals/TCAR-UG/Repository/History.docbook b/Manuals/TCAR-UG/Repository/History.docbook deleted file mode 100644 index 6292d08..0000000 --- a/Manuals/TCAR-UG/Repository/History.docbook +++ /dev/null @@ -1,41 +0,0 @@ - - - Repository History - - - &TCAR; started at The CentOS Developers - Mailing List around 2008, on a discussion about how to - automate slide images used by Anaconda. In such discussion, - Ralph Angenendt rose up his hand to ask —Do you have - something to show?—. - - - - To answer the question, Alain Reguera Delgado suggested a bash - script which combined SVG and SED files in order to produce - PNG images in different languages —in conjunction with - the proposition of creating a Subversion repository where - translations and image production could be distributed inside - &TCC;—. - - - - Karanbirn Sighn considered the idea intresting and provided - the infrastructure necessary to support the effort. This way, - &TCAS; and &TCAR; were officially created and world wide - available. - - - - Once &TCAR; was available, Alain Reguera Delgado uploaded the - bash script Anaconda slides; Ralph Angenendt documented it - very well; and people started to download working copies of - the repository to produce slide images in their own languages. - - - &repo-history-2009; - &repo-history-2010; - &repo-history-2011; - - diff --git a/Manuals/TCAR-UG/Repository/History/2009.docbook b/Manuals/TCAR-UG/Repository/History/2009.docbook deleted file mode 100644 index 5e10ea5..0000000 --- a/Manuals/TCAR-UG/Repository/History/2009.docbook +++ /dev/null @@ -1,55 +0,0 @@ - - - 2009's - - - Around 2009, the rendition script was at a very rustic state - where only slide images could be produced, so it was - redesigned to extend the image production to other areas, - different from slide images. In this configuration, one SVG - file was used as input to produce a translated instance of it - which, in turn, was used to produce one translated PNG image - as output. The SVG translated instance was created through SED - replacement commands. The translated PNG image was created - from the SVG translated instance using Inkscape command-line - interface. - - - - The repository directory structure was prepared to receive the - rendition script using design templates and translation files - in the same location. There was one directory structure for - each artwork that needed to be produced. In this - configuration, if you would want to produce the same artwork - with a different visual style or structure, it was needed to - create a new directory structure for it because both the image - structure and the image visual style were together in the - design template. - - - - The rendition script was moved to a common place and linked - from different directory structures. There was no need to have - the same code in different directory structures if it could be - in just one place and then be linked from different locations. - - - - Corporate identity concepts began to be considered. As - referece, it was used the book "Corporate Identity" by Wally - Olins (1989) and Wikipedia - related links. This way, the rendition script main's goal - becomes to: automate the production process of a - monolithic corporate visual identity structure, based on the - mission and the release schema of The CentOS - Project. - - - - The repository directory structures began to be documented by - mean of flat text files. Later, documentation in flat text - files was moved onto LaTeX format and this way &TCARUG; was - initiated. - - diff --git a/Manuals/TCAR-UG/Repository/History/2010.docbook b/Manuals/TCAR-UG/Repository/History/2010.docbook deleted file mode 100644 index 6949b7e..0000000 --- a/Manuals/TCAR-UG/Repository/History/2010.docbook +++ /dev/null @@ -1,79 +0,0 @@ - - - 2010's - - - Around 2010, the rendition script changed its name from - render.sh to - centos-art.sh and became a collection of - functionalities where rendition was just one among others - (e.g., documentation and localization). - - - - The centos-art.sh was initially conceived - to automate frequent tasks inside the repository based in the - idea of Unix toolbox: to create small and specialized tools - that do one thing well. This way, functionalities inside - centos-art.sh began to be identified and - separated one another. For example, when images were rendered, - there was no need to load functionalities related to - documentation manual. This layout moved us onto common - functionalities and specific - functionalities inside - centos-art.sh script. Common - functionalities are loaded when - centos-art.sh script is initiated and are - available to specific functionalities. - - - - Suddenly, no need was found to keep all the links spreaded - around the repository in order to execute the - centos-art.sh script from different - locations. The centos-art command-line interface was used - instead. The centos-art command-line interface is a symbolic - link stored inside the ~/bin directory that point to - centos-art.sh script. As default - configuration, inside The CentOS Distribution, the path to - ~/bin is included in - the search path for commands (see PATH - environment variable). This way, using the centos-art - command-line interface, it is possible for us to execute the - centos-art.sh script from virtually - anywhere inside the workstation, just as we frequently do with - regular commands. - - - - Start using GNU getopt as default option parser inside the - centos-art.sh script. - - - - The repository directory structure was updated to improve the - implementation of corporate visual identity concepts. - Specially in the area related to themes. Having both structure - and style in the same file introduced content duplication when - producing art works. Because of this reason, they were - divided out to separate directory structures: the design - models and artistic motifs directory structures. From this - point on, the centos-art.sh is able to - produce themes as result of arbitrary combinations between - design models (structures) and artistic motifs (visual - styles). - - - - In the documentation area, the documents in LaTeX format were - migrated to Texinfo format. In this configuration, each - directory structure in the repository has a documentation - entry associated in a Texinfo structure which can be read, - edited and administered (e.g., renamed, deleted and copied) - interactively through centos-art.sh script. - Additionally, the texi2html program was used to produced - customized XHTML output in conjunction with CSS from &TCW;. - - - diff --git a/Manuals/TCAR-UG/Repository/History/2011.docbook b/Manuals/TCAR-UG/Repository/History/2011.docbook deleted file mode 100644 index 867d75e..0000000 --- a/Manuals/TCAR-UG/Repository/History/2011.docbook +++ /dev/null @@ -1,57 +0,0 @@ - - - 2011's - - - Around 2011, the centos-art.sh script was - redesigned to start translating XML-based files (e.g., SVG and - Docbook files) through xml2po program and - shell scripts (e.g., Bash scripts) through GNU gettext tools. - This configuration provided a stronger localization interface - for graphic designers, translators and programmers. The SED - replacement files are no longer used to handle localization. - - - - The render, help and - locale functionalities were consolidated - as the most frequent tasks performed inside the repository. - Additionally, the prepare and tuneup functionalities are also - maintained as useful tasks. - - - - In the documentation area, support for producing localized - transformations of DocBook XML DTD instances was added through - the render and locale functionalities. - The render functionality uses the - xsltproc command-line XSLT parser in - conjunction with the styles provided by the - docbook-style-xsl package, both of them - included inside The CentOS Distribution. The locale - functionality creates the localized portable object - (PO) the render - functionality needs to produce localized transformations of - DocBook XML DTD instances. - - - - To build DocBook documentation, it was considered the idea of - using concepts behind repository directory structure as base, - not the opposite (as I've been doing with Texinfo backend, so - far). - - - - Producing documentation through DocBook XML as default - documentation backend consolidates render - and locale even more. In this - configuration, once the DocBook files are written, you use - locale functionality to localize the - DocBook files in your prefered language and later, using - render functionality, you produce the - XTHML and PDF outputs as specified in a XSLT or DSL - customization layer. - - - diff --git a/Manuals/TCAR-UG/Repository/Workstation.docbook b/Manuals/TCAR-UG/Repository/Workstation.docbook deleted file mode 100644 index 66b07de..0000000 --- a/Manuals/TCAR-UG/Repository/Workstation.docbook +++ /dev/null @@ -1,9 +0,0 @@ - - - Preparing Your Workstation - - &repo-ws-overview; - &repo-ws-install; - &repo-ws-config; - - diff --git a/Manuals/TCAR-UG/Repository/Workstation/config.docbook b/Manuals/TCAR-UG/Repository/Workstation/config.docbook deleted file mode 100644 index dd07957..0000000 --- a/Manuals/TCAR-UG/Repository/Workstation/config.docbook +++ /dev/null @@ -1,396 +0,0 @@ - - - Configuring Your Workstation - - - Once your worstation is installed, it is time for you to - configure it. At this point you create a user for everyday's - work, configure third party repositories, fix environment - variables to fit your personal needs, download the working - copy of &TCAR; and prepare it for start using it. - - - - - Workplace - - - Once you've installed the workstation and it is up and - running, you need to create the user name you'll use for your - everyday's work. In this task you need to use the commands - useradd and passwd to - create the user name and set a password for it, respectively. - These commands require administrative privileges to be - executed, so you need to login as root - superuser for doing so. - - - - - Do not use the root username for your - everyday's work inside your working copy of &TCAR;. This is - dangerous and might provoke unreversable damages on your - workstation. - - - - - When user names are created inside the workstation, it doesn't - create only a user identifier for you to login, but a place - for you to store your information, as well. This place is - known as your home directory and is unique for each user - inside the workstation. At the moment, we face the following - design problems related to handling absolute paths inside the - working copies of &TCAR;: - - - - - Case 1: Different home directories - - - Assuming you store your working copy under /home/john/artwork/ and I store - mine under /home/al/artwork/, we'll end up - refering the same files inside our working copies through - different absolute paths. This generates a contradiction when - files, holding path information inside, are committed up to - the central repository. The contradiction comes from the - question: which is the correct absolute path to use inside - such files, yours or mine? — No one of them is, of - course. - - - - - - Case 2: One unique home directory - - - Another case would be that you and I ourselves use one unique - home directory (e.g., /home/centos/artwork/) to store - the working copy of &TCAR; in our own workstations, but - configure the subversion client to use different user names to - commit changes up from the working copy to the central - repository. This configuration might be not so good for - situations where you and I have to share the same workstation. - In such case, it would be required that we both share the - password information of the same system user (the - centos user in our example) which, in - addition, gives access to that user's subversion client - configuration and this way provokes the whole sense of using - different subversion credentials for committing changes to be - lost. - - - - - - Case 3: Different home directories through dynamic expansion - - - Most of the absolute paths we use inside the working copy are - made of two parts, one dynamic and one fixed. The dynamic part - is the home directory of the current user and its value can be - retrived from the $HOME environment variable. - The fixed part of the path is the one we set inside the - repositroy structure itself as organization matter. What we - need here is to find a way to expand variables inside files - that don't support variable expansion. So far we've been - doing this through creation template instances which are - temporal files with translation markers expanded inside. This - work rather fine with template files that are one-time-pass - (e.g., when we produce produce PNG files from SVG files and - XTHML from DocBook files), but the same is not true for - absolute paths inside files that are used as in their - permanent state inside the repository (e.g., CSS files and - other files similar in purpose). - - - - - - - From the three cases discussed above, the second one (i.e., - One unique home directory) seems to be the best candidate. It - limits us from using more than one working copy in the same - workstation, but gives us the chance of standardizing the use - of absolute paths inside all the working copies of &TCAR;. - Using absolute paths is very convenient because it is possible - to reuse information from different locations inside the - working copy, something that would be almost imposible to - maintain if relative paths were used instead. Thus, lets - assume the second case of handling home directories as default - solution to relatively solve the problem of where to store - working copies of &TCAR; until a better one shows itself up. - - - - The action of providing working copies of &TCAR; that permit - to reuse files inside them unifies the way content is produced - inside the working copy and provides a convenction for people - working on different areas to get attached to in order to - syncronize their works and still keep doing it decentralized - one another. - - - - - - Environment Variables - - - Once you've created the centos user name - for your everyday's work and you had done login with it, 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 personal - profile (i.e., ~/.bash_profile) and set the - redefinition there. Notice that you may need to logout and - then do login again in order for the new variable values to - take effect. - - - - - Default text editor - - - The default text editor information is controlled by the - EDITOR environment variable. The - centos-art.sh script uses the default text - editor to edit subversion pre-commit messages, translation - files, documentation files, script files, and similar - text-based files. - - - - If EDITOR environment variable is not set, - centos-art.sh script uses /usr/bin/vim as default text - editor. Otherwise, the following values are recognized by - centos-art.sh script: - - - - - /usr/bin/vim - - - - - - /usr/bin/emacs - - - - - - /usr/bin/nano - - - - - - - - If no one of these values is set in the EDITOR - environment variable, the centos-art.sh - script uses /usr/bin/vim text editor, the one - installed by default in &TCD;. - - - - - - Default locale information - - - The default locale information is controlled by the - LANG environment variable. This variable is - initially set in the installation process of &TCD;, - specifically in the Language step. - Generally, there is no need to customize this variable in your - personal profile. If you need to change the value of this - environment variable do it through the login screen of GNOME - Desktop Environment or the - system-config-language command. - - - - The centos-art.sh script uses the - LANG environment variable to determine what - language to use for printing output messages from the script - itself, as well as the portable objects locations that need to - be updated or edited when you localize directory structures - inside the working copy of &TCAR;. - - - - - - Default time zone representation - - - The time zone representation is a time correction applied to - the system time (stored in the BIOS clock) based on your - country location. This correction is specially useful to - distributed computers around the world that work together and - need to be syncronized in time to know when things happened. - - - &TCAR; 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 - they all set their system clocks to use the same time - information (e.g., through UTC (Coordinated Universal Time)) - and set the time correction for their specific countries in - the operating system. Otherwise, it would be difficult to - know when something exactly happened. - - - Generally, setting the time information is a straight-forward - task and configuration tools provided by &TCD; 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 &TCD; then, - you need to customize the TZ environment - variable in your personal profile to correct the time - information by yourself. The format of TZ - environment variable is described in tzset(3) - manual page. - - - - - - - - Administrative Tasks - - - Sometimes it is necessary that you perform administrative - tasks inside the workstation the working copy of &TCAR; is - stored in. These tasks might demand you to type many commands - (e.g., for configuring a third party repository) or just a - one-line command (e.g., for installing a new package). In - both cases this kind of tasks require permissions that your - user for everyday's work must not have under no mean. - - - - To perform administrative tasks in your workstation, you need - to login as root or configure the - sudo program to temporarily granting the - permissions your regular user needs to perform the - administrative tasks. The configuration of - sudo program is at - /etc/sudoers file and you need to add the - centos user to the list of privileged - user as described in the section below: - - - -## Next comes the main part: which users can run what software on -## which machines (the sudoers file can be shared between multiple -## systems). -## Syntax: -## -## user MACHINE=COMMANDS -## -## The COMMANDS section may have other options added to it. -## -## Allow root to run any commands anywhere -root ALL=(ALL) ALL -centos ALL=(ALL) ALL - - - - This configuration is required in order for automation scripts - to realize administrative tasks that otherwise you would need - to type one by one. It is worth to mention that all these - tasks are organized in the prepare - functionality of the centos-art.sh script - in the sake of reducing work and standardize the procedure of - performing them. It is also worth to mention that, the - centos-art.sh script is available for you - to run, study, improve and share your changes as described in - . - - - - - - Working Copy - - - Once you've installed and configured the workstation, it is - ready to receive the working copy of &TCAR;. In this step, you - use Subversion's client to communicate the source repository - of &TCAR; and download all the files that make a working copy - of it. - - - - To download the working copy of &TCAR; you need to login as - your everyday's work user (i.e., the - centos user) and use the Subversion - client installed in your workstation to bring all the files - you need to work with from the source repository down to your - workstation, just as the following command describes: - - - svn co https://projects.centos.org/svn/artwork ~/ - - - This command will create your working copy of &TCAR; in your - workstation, specifically in the /home/centos/artwork directory. - - - - - If the Subversion's client wasn't installed by default, you - need to install it using the following command: - - sudo yum install subversion - - - - - Once your working copy of &TCAR; has been downloaded, you - should notice that there is no image files, nor documentation, - or localized content inside it. This is because all the files - provided in the working copy are source files (e.g., the files - needed to produce other files) and it is up to you the action - of render them to produce the final files (e.g., images and - documentation) used to implement &TCPCVI;. - - - - Another consideration to be aware of at this point, is the - need of verifying the software installed in the workstation, - as well as the creation of symbolic links to connect the - content produced inside the working copy to applications - outside it (e.g., to make available patterns, brushes, and - palettes produced inside the working copy in GIMP, the - application used to manipulate images). - - - - This final preparation stuff is automated by the - prepare functionality of the - centos-art.sh script, as described in . Execute it right now, - to be sure your workstation and your working copy are both - ready to be used. - - - - - diff --git a/Manuals/TCAR-UG/Repository/Workstation/install.docbook b/Manuals/TCAR-UG/Repository/Workstation/install.docbook deleted file mode 100644 index fdb8f4a..0000000 --- a/Manuals/TCAR-UG/Repository/Workstation/install.docbook +++ /dev/null @@ -1,221 +0,0 @@ - - - Installing Your Workstation - - - In order to have a working copy of &TCAR; in your workstation, - the first step you need to follow is pick up a computer and - install an operating system in it. This computer will be named - the workstation from now on. - - - - At the moment of chosing which operating system to install in - your workstation, consider that &TCAR; is completly built on - &TCD; and realies on it to achieve most automation tasks. At - time of this writing the major release 5 update 5 of &TCD; was - used as platform to support all work line development inside - &TCAR;. To get the best of &TCAR;, it is necessary that you - too, use the same operating system we did to develop it. - - - - To install &TCD; you need to have access to the installation - media somehow (e.g., CDs, DVDs, Pendrives, etc.). If you - don't have the installation media of &TCD;, you need to - download the ISO files related to the installation media you - plan to use (e.g., CD or DVD) and then create the installation - media by yourself. &TCD; ISO files can be downloaded from - &TCM;. - - - - Assuming you downloaded the DVD ISO of &TCD;, you can burn it - using the K3B application and, this - way, you are creating the installation media you are in need - of. Of course, in order to download the ISO files and create - the installation media, you need to have a workstation already - functionality where you can realized such tasks. If this is - the first time for you and see yourself into much troubles - here, talk to the guys in your nearest LUG, or simply send a - mail to &TCML; where you'll surely have the answer you need. - - - - Once you have the installation media on your hands, the - installation process of &TCD; is rather straightforward. To - begin, you put the installation media in your media reader, - boot the computer from it, and follow the installer - intructions till it completes all the steps. That simple. - - - - - Partition Information - - - The partition information you set in your workstation is very - specific to your personal needs and the technical - characteristics of your machine. This information will also - set the bases of all deployment you reach to achieve inside - the workstation. A well partitioned workstation is crucial to - garantee a well distribution of space inside the worstation. - In order to provide an idea of this installation step, I'll - describe the specific partitioning of the machine I use to - develop &TCAR; right now. Remember that your needs might be - differents and so the partition layout you should implement. - - - - The machine of our example is isolated from Internet or any - other network. It has two hard drives of 256GB each, 2GB of - RAM and a 2.80GHz Core 2 Duo processor. The main goal of this - machine is producing &TCAR;. To represent the real production - environment of &TCAR;, this machine was conceived to have two - roles, one as server —to store the source repository of - &TCAR;— and one as client —to store a working copy - of the source repository—. From both hard drives - available, one is used as primary - (/dev/sda) and the other one as secondary - (/dev/sdb) where the secondary is used - only to backup the information produced in the primary by mean - of backup scripts. - - - The partition distribution of this machine implements the - default partinioning schema provided by &TCD; in the primary - hard drive to store partitions needed by the operating system - (e.g., /, /boot and swap partition) where - the working copy is placed in. The second hard drive is an - entire partition mounted in /mnt/backups automatically on - boot which only purpose is to duplicate the information - produced in the workplace. - - - -Filesystem Type Size Mounted on -/dev/mapper/VolGroup00-LogVol00 ext3 239G / -/dev/sda1 ext3 104M /boot -tmpfs tmpfs 1.1G /dev/shm -/dev/sdb ext3 247G /mnt/backups - - - - The detailed steps followed to prepare the partinioning layout - described above are described in the Deployment - Guide provided by - Deployment_Guide-en-US-5.2-11.el5.centos - package. - - - - - - - Packages Selection - - - The packages selection lets you to specify which software does - your workstation will have once it be installed. In this step, - you need to select the following groups of packages: - - - - - Desktop Environments - - - - GNOME Desktop Environment - - - - - KDE (K Desktop Environment) - - - - - - - Applications - - - - Authoring and Publishing - - - - - Editors - - - - - Graphical Internet - - - - - Graphics - - - - - Office/Productivity - - - - - Text-based Internet - - - - - - - Development - - - - Development Libraries - - - - - Development Tools - - - - - GNOME Software Development - - - - - KDE Software Development - - - - - - - - Packages selected in this step provide a base selection of all - the packages you need in order to have a functional working - copy of &TCAR;. The only exception for this, is the - inkscape package and some of its - dependencies which doesn't come with &TCD; and need to be - installed from third party repositroies like EPEL and - RPMForge. The configuration of third party repository is done - later, once the workstation has been installed; just as - described in the Repositories - page. - - - - - diff --git a/Manuals/TCAR-UG/Repository/Workstation/overview.docbook b/Manuals/TCAR-UG/Repository/Workstation/overview.docbook deleted file mode 100644 index b410d20..0000000 --- a/Manuals/TCAR-UG/Repository/Workstation/overview.docbook +++ /dev/null @@ -1,27 +0,0 @@ - - - Overview - - - The workstation is the machine you use to store your working - copy of &TCAR;. The working copy is an ordinary directory - tree on your workstation, containing a collection of files - that you can edit however you wish. The working copy is your - own private work area related to &TCAR; where you perform - changes and receive changes from others. - - - - In order to make your workstation completely functional, it is - necessary that you install it and configure it to satisfy the - needs demanded by the working copy of &TCAR; you lately - download in it. - - - - This chapter describes the steps you need to follow in order - to install and configure a workstation for using a working - copy of &TCAR; in all its extention. - - - diff --git a/Manuals/TCAR-UG/Scripts.docbook b/Manuals/TCAR-UG/Scripts.docbook deleted file mode 100644 index 3645deb..0000000 --- a/Manuals/TCAR-UG/Scripts.docbook +++ /dev/null @@ -1,12 +0,0 @@ - - - Automation - - - ... - - - &scripts-bash; - - - diff --git a/Manuals/TCAR-UG/Scripts.ent b/Manuals/TCAR-UG/Scripts.ent deleted file mode 100644 index a0e60e5..0000000 --- a/Manuals/TCAR-UG/Scripts.ent +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/Manuals/TCAR-UG/Scripts/Bash.docbook b/Manuals/TCAR-UG/Scripts/Bash.docbook deleted file mode 100644 index 52df4f4..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash.docbook +++ /dev/null @@ -1,13 +0,0 @@ - - - The <command>centos-art.sh</command> script - - &scripts-bash-intro; - &scripts-bash-design; - &scripts-bash-render; - &scripts-bash-locale; - &scripts-bash-help; - &scripts-bash-prepare; - &scripts-bash-tuneup; - - diff --git a/Manuals/TCAR-UG/Scripts/Bash/design.docbook b/Manuals/TCAR-UG/Scripts/Bash/design.docbook deleted file mode 100644 index 1521d7d..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/design.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - The script design - ... - diff --git a/Manuals/TCAR-UG/Scripts/Bash/help.docbook b/Manuals/TCAR-UG/Scripts/Bash/help.docbook deleted file mode 100644 index c40870b..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/help.docbook +++ /dev/null @@ -1,197 +0,0 @@ - - - <function>help</function> — Standardize Documentation - Tasks - - - The help functionality is the interface - the centos-art.sh script provides to - control frequent documentation tasks (e.g., reading, editing, - update output files, etc.) requied by specific documentation - backends. Documentation backends supported by - help functionality are described in . - - - centos-art help [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process the related documentation entry for. - This paramter can be provided more than once in order to - process more than one directory path in a single command - execution or not provided at all. When this parameter is not - provided, the current directory path where the command was - called from is used instead. - - - - The help functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the action itself had took place over files - in the working copy. - - - - - - - - - The NAME argument in this option specifies - what backend to use when processing documentation. Possible - arguments to this options are: texinfo or - docbook. If this option is not provided, - texinfo is used as default documentation - backend. - - - - - - - - - Go to node pointed by ID argument. When - texinfo backend is used, this arguments refers the node you - want to read documentation for. When docbook backend is used, - this argument refers the section id you want to read - documentation for. - - - - - - - - - Edit documentation entry related to path specified by - DIRECTORY parameter. - - - The DIRECTORY parameter must point to any - directory inside the working copy. When more than one - DIRECTORY are passed as non-option - arguments to the centos-art.sh script - command-line, they are queued for further edition. The - edition itself takes place through your default text editor - (e.g., the one you specified in the EDITOR - environment variable) and the text editor opens one file at - time (i.e., the queue of files to edit is not loaded in the - text editor.). - - - - - - - - - Read documentation entry specified by - DIRECTORY path. This option is used - internally by centos-art.sh script to print - out the reference you can follow to know more about an error - message. - - - - - - - - - Update output files rexporting them from the specified backend - source files. - - - - - - - - - Duplicate documentation entries inside the working copy. - - - When documentation entries are copied, it is required to pass - two non-option parameters in the command-line. The first - non-option parameter is considered the source location and the - second one the target location. Both source location and - target location must point to a directory under the working - copy. - - - - - - - - - Delete documentation entries specified by - DIRECTORY inside the working copy. It is - possible to delete more than one documentation entry by - specifying more DIRECTORY parameters in the - command-line. - - - - - - - - - Rename documentation entries inside the working copy. - - - When documentation entries are renamed, it is required to pass - only two non-option parameters to the command-line. The first - non-option parameter is considered the source location and the - second one the target location. Both source location and - target location must point to a directory under the working - copy. - - - - - - - - When documentation entries are removed (e.g., through - or - options), the help functionality takes - care of updating nodes, menus and cross references related to - documentation entries in order to keep the manual structure in - a consistent state. - - - diff --git a/Manuals/TCAR-UG/Scripts/Bash/intro.docbook b/Manuals/TCAR-UG/Scripts/Bash/intro.docbook deleted file mode 100644 index 00ee91e..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/intro.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - Introduction - ... - diff --git a/Manuals/TCAR-UG/Scripts/Bash/locale.docbook b/Manuals/TCAR-UG/Scripts/Bash/locale.docbook deleted file mode 100644 index 676a5e4..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/locale.docbook +++ /dev/null @@ -1,230 +0,0 @@ - - - <function>locale</function> — Standardize Localization Tasks - - - The locale functionality is the - interface the centos-art.sh script provides - to standardize localization tasks inside the working copy. - - - centos-art locale [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - The locale functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Reduce the list of files to process inside - DIRECTORY using REGEX as - pattern. You can use this option to control the amount of - files you want to locale. The deeper you go into the - directory structure the more specific you'll be about the - files you want to locale. When you cannot go deeper into the - directory structure through DIRECTORY - specification, use this option to reduce the list of files - therein. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the actions themselves had took place over - files in the working copy. - - - - - - - - - This option updates both POT and PO files related to source - files. Use this option everytime you change translatable - strings inside the source files. - - - - - - - - - This option edits the portable object related to source files. - When you provide this option, your default text editor is used - to open the portable object you, as translator, need to change - in order to keep source file messages consistent with their - localized versions. In the very specific case of shell - scripts localization, this option takes care of updating the - machine object (MO) file the shell script requires to - displayed translation messages correctly when it is executed. - - - - - - - - - This option unlocalizes source files. When you provide this - option, the localization directory related to source files is - removed from the working copy in conjunction with all portable - objects and machine objects inside it. - - - - - - - - - This option suppresses machine objects creation when shell - scripts are localized. - - - - - - - - The localization process is very tied to the source files we - want to provide localized messages for. Inside the working - copy of &TCAR; it is possible to localize XML-based files - (e.g., SVG and Docbook) and programs written in most popular - programming languages (e.g., C, C++, C#, Shell Scripts, - Python, Java, GNU awk, PHP, etc.). - - - - The localization process initiates by retriving translatable - strings from source files. When source files are XML-based - files, the only requisite to retrive translatable strings - correctly is that they be well-formed. Beyond that, the - xml2po command takes care of everything - else. When source files are Shell script files, it is - necessary that you previously define what strings inside the - script are considered as translatable strings in order for - xgettext command to retrive them correctly. - To define translatable strings inside shell scripts, you need - to use either gettext, - ngettext, eval_gettext - or eval_ngettext command as it is following - described: - - - - - - Use the gettext command to display the - native language translation of a textual message. - - MESSAGE="`gettext "There is no entry to create."`" - - - - - Use the ngettext command to display the - native language translation of a textual message whose - grammatical form depends on a number. - - MESSAGE="`ngettext "The following entry will be created" \ - "The following entries will be created" \ - $COUNT`:" - - - - - Use the eval_gettext command to display the - native language translation of a textual message, performing - dollar-substitution on the result. Note that only shell - variables mentioned in the message will be dollar-substituted - in the result. - - MESSAGE="`eval_gettext "The location \\\"\\\$LOCATION\\\" is not valid."`" - - - - - Use the eval_ngettext command to display - the native language translation of a textual message whose - grammatical form depends on a number, performing - dollar-substitution on the result. Note that only shell - variables mentioned in messages will be dollar-substituted in - the result. - - MESSAGE="`eval_ngettext "The following entry will be created in \\\$LOCATION" \ - "The following entries will be created in \\\$LOCATION" \ - $COUNT`:" - - - - - Once translatable strings are retrived, a portable object - template (POT) file is created for storing them. Later, the - POT file is used to create a portable object (PO). The - portable object is the place where localization itself takes - place, it is the file translators edit to localize messages. - When translatable strings change inside source files, it is - necessary that you update these POT and PO files in order to - keep consistency between source file messages and their - localized versions. - - - - Inside source files, translatable strings are always written - in English language. In order to localize translatable strings - from English language to another language, you need to be sure - the LANG environment variable has been already - set to the locale code you want to localize message for or see - them printed out before running the - locale functionality of - centos-art.sh script. Localizing English - language to itself is not supported. - - - - To have a list of all locale codes you can have localized - messages for, run the following command: locale -a | - less. - - - diff --git a/Manuals/TCAR-UG/Scripts/Bash/prepare.docbook b/Manuals/TCAR-UG/Scripts/Bash/prepare.docbook deleted file mode 100644 index 5748e53..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/prepare.docbook +++ /dev/null @@ -1,173 +0,0 @@ - - - <function>prepare</function> — Standardize Configuration Tasks - - - The prepare functionality is the - interface the centos-art.sh script provides - to standardize the final configuration stuff your workstation - needs, once the working copy of &TCAR; has been downloaded - inside it already. - - - - Assuming this is the very first time you run the - centos-art.sh script, you'll find that - it isn't found in your workstation. This is correct because - you haven't created the symbolic link that make it available - in the execution path, yet. In order to make the - centos-art.sh script available in the - execution path of your workstation, you need to run it using - its absolute path first: - - - ~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS] - - - Later, once the centos-art.sh script is - available in the execution path of your system, there is no - need for you to use the absolute path again. From this time - on, you can use the centos-art command-line - interface directly, as the following example describes: - - - centos-art prepare [OPTIONS] - - - The prepare functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option whould have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - This option verifies packeges required by - centos-art.sh script. installs or updates - required packages. When required packages aren't installed, - this option uses sudo yum install - command to perform the installation task. When required - packages are installed, this option uses sudo yum - update to update them, if there is any related - actualization to be applied on. In both cases, it is required - that you configure the sudo command first, - as described in . - - - - - - - - - This option maintains the file relation between your working - copy and configuration files inside your workstation through - symbolic links. When you provide this option, the - centos-art.sh puts itself into your - system's execution path through its command line interface - centos-art and makes common brushes, - patterns, palettes and fonts inside the working copy, - available to applications like GIMP in order for you to make - use of them without loosing version control over them. - - - - This option removes all common fonts, brushes, patterns, and - palettes currently installed in your home directory, in order - to create a fresh installation of them all again, using the - working copy as reference. - - - - - - - - - - This option initializes image files inside the working copy. - When you provide this option, the - centos-art.sh scripts renders image files - from all design models available in the working copy. This - step is required in order to satisfy file dependencies among - different components inside the working copy. - - - - - - - - - This option initializes documentation files inside the working - copy. When you provide this option, the - centos-art.sh script renders all - documentation manuals from their related source files to - different output formats, so you can read them nicely. - - - - - - - - - Print the name and value of some of the environment variables - used by centos-art.sh scripts as described - in . - - - - - - - When no option is provided to prepare - functionality, the centos-art.sh script - uses the , - , and - options as default behaviour. - Otherwise, if you provide any option, the - centos-art.sh script avoids its default - behaviour and executes the prepare - functionality as specified by the options you provides. - - - - Notice that it is possible for you to execute the - prepare functionality as much times as - you need to. This is specially useful when you need to keep - syncronized the relation between content produced inside your - working copy and the applications you use outside it. For - example, considering you've added new brushes to or removed - old brushes from your working copy of &TCAR;, the link - information related to those files need to be updated in the - ~/.gimp-2.2/brushes - 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. - - - diff --git a/Manuals/TCAR-UG/Scripts/Bash/render.docbook b/Manuals/TCAR-UG/Scripts/Bash/render.docbook deleted file mode 100644 index fe12217..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/render.docbook +++ /dev/null @@ -1,240 +0,0 @@ - - - <function>render</function> — Standardize Content Production - - - The render functionality is the interface - the centos-art.sh script provides to - standardize the content production tasks inside the working - copy. - - - centos-art render [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - The render functionality accepts the - following options: - - - - - - - - This option supresses all output messages except error - messages. When this option is passed, all confirmation - requests are supressed and a possitive answer is assumed for - them, just as if the option - would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - This option reduces the list of files to process inside - DIRECTORY using REGEX as - pattern. You can use this option to control the amount of - files you want to render. The deeper you go into the - directory structure the more specific you'll be about the - files you want to render. When you cannot go deeper into the - directory structure through DIRECTORY - specification, use this option to reduce the list of files - therein. - - - - - - - - - This option supresses all commit and update actions realized - over files, before and after the action itself had took place - over files in the working copy. - - - - - - - - - This option expands the =\RELEASE=, - =\MAJOR_RELEASE=, and - =\MINOR_RELEASE= translation makers based on - NUMBER value. Notice that translation - markers here were escaped using a backslash (\) - in order to prevent their expansion. Use this option when you - need to produce release-specific contents, but no release - information can be retrived from the directory path you are - currently rendering. - - - - - - - - - This option expands the =\ARCHITECTURE=, - translation makers based on ARHC value. - Notice that translation markers here were escaped using a - backslash (\) in order to prevent their - expansion. Use this option when you need to produce - architecture-sepecific contents but no architecture - information can be retrived from the directory path you are - currently rendering. - - - - - - - - - This option specifies the name of theme model you want to use - when producing theme artistic motifs. By default, if this - option is not provided, the Default theme - model is used as reference to produce theme artistic motifs. - To know what values does the NAME variable - can have, run ls - ~/artwork/trunk/Identity/Models/Themes command. - - - - - - - - - This option lets you apply a command as post-rendition action. - In this case, the COMMAND represents the - command-line you want to execute in order to perform in-place - modifications to base-rendition output. - - - - - - - - - This option lets you apply a command as last-rendition action. - In this case, the COMMAND argument - represents the command string you want to execute in order to - perform in-place modifications to base-rendition, - post-rendition and directory-specific rendition outputs. - - - - - - - Inside the working copy of &TCAR;, rendition tasks take place - inside renderable directories. The rendition itself is - performed through a serie of rendition flows named - base-rendition, post-rendition, last-rendition and - directory-specific rendition. - - - - Renderable Directories - - Renderable directories are convenctional locations inside the - working copy where you can find source files, output files and - auxiliar files. Source files are used to produce output files. - Auxiliar files are used to modify the way output files are - produced from source files (e.g., to produce localized - output). Auxiliar files are optionals. - - - Renderable directories are made of several directories but - only the output dirctory path is passed to - render functionality as - DIRECTORY parameter in the command-line. - The directories related to source and auxiliar files are - automatically constructed based on a directory organization - convenction. This way, the render - functionality collects all the information it needs to work - with. - - - Inside the working copy, renderable directories are divided in - two categories in a way differences between them can be - preserved. These categories are named direct - production and theme production. These - categories provide the file organization convenction the - render functionality needs, to produce - content based on rendition flows. - - - - Direct Production - - ... - - - - - Theme Production - - ... - - - - - - - Rendition Flows - - - Base-Rendition - - ... - - - - - Post-Rendition - - ... - - - - - Last-Rendition - - ... - - - - - Directory-Specific Rendition - - ... - - - - - diff --git a/Manuals/TCAR-UG/Scripts/Bash/tuneup.docbook b/Manuals/TCAR-UG/Scripts/Bash/tuneup.docbook deleted file mode 100644 index aefc6cf..0000000 --- a/Manuals/TCAR-UG/Scripts/Bash/tuneup.docbook +++ /dev/null @@ -1,240 +0,0 @@ - - - <function>tuneup</function> — Standardize File Maintainance - - - The tuneup functionality is the - interface the centos-art.sh script provides - to standardize the maintainance tasks related to individual - files inside the working copy. - - - centos-art tuneup [OPTIONS] [DIRECTORY] - - - The DIRECTORY parameter specifies the - directory path, inside the working copy of &TCAR;, where the - files you want to process are stored in. This paramter can be - provided more than once in order to process more than one - directory path in a single command execution. When this - parameter is not provided, the current directory path where - the command was called from is used instead. - - - The tuneup functionality accepts the - following options: - - - - - - - - Supress all output messages except error messages. When this - option is passed, all confirmation requests are supressed and - a possitive answer is assumed for them, just as if the - option would have been provided. - - - - - - - - - Assume yes to all confirmation requests. - - - - - - - - - Reduce the list of files to process inside - path/to/dir using - REGEX as pattern. You can use this - option to control the amount of files you want to tuneup. The - deeper you go into the directory structure the more specific - you'll be about the files you want to tuneup. When you cannot - go deeper into the directory structure through - path/to/dir specification, use this - option to reduce the list of files therein. - - - - - - - - - Supress all commit and update actions realized over files, - before and after the action itself had took place over files - in the working copy. - - - - - - - Tasks related to file maintainance are repetitive. You might - find yourself doing them time after time inside the working - copy of &TCAR;. 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. - - - - When you execute the tuneup functionality of centos-art.sh - script, it looks for all files that match the supported - extensions (e.g., .sh, - .svg and .xhtml) in the directory - specified, builds a list with them and applies the - maintainance tasks using file extensions as reference. - - - - When shell scripts are found, the tuneup - functionality of centos-art.sh script reads a comment template - from - trunk/Scripts/Functions/Tuneup/Shell/Config/topcomment.sed - and applies it to all 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. - - - In order for the shell script top comment template to be - applied correctly, the shell scripts you write must have the - structure described in . - - - - Shell script top-comment template. - - Shell script top-comment template. - - - - 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| } - - - - - - - - The tuneup functionality of - centos-art.sh script replaces all lines - between the Copyright line (e.g., line 5) - and the first separator line (e.g., line 9), inclusively. - Everything else will remain immutable in the file. - - - - When scalable vector graphics are found, the tuneup - functionality reads a SVG metadata template from - trunk/Scripts/Functions/Tuneup/Svg/Config/metadata.sed - 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 - the file, too. - - - The metadata applied by the SVG metadata template is created - dynamicaly combining the absolute path of the file being - currently modified, the workstation's date information, the - centos-art.sh script copyright holder - (e.g., =COPYRIGHT_HOLDER=) as reference and the Creative - Common Distribution-ShareAlike 3.0 License as default license - to release SVG files. - - - The elimination of unused definitions inside SVG files takes - place through Inkscape's - option, as described in its man page (e.g., man - inkscape). - - - - When HTML files are found, the tuneup - functionality of centos-art.sh script - transforms web page headings to make them accessible through a - table of contents. The table of contents is expanded in - place, wherever the <div - class="toc"></div> piece of code be in the - file. Once the table of contents has been expanded, there is - no need to put anything else in the page. You can run the - tuneup functionality everytime you update - the heading information so as to update the table of contents, - too. - - - In order for this functionality to build the table of contents - from headings, you need to put headings in just one line. The - headin level can vary from h1 to h6 - with attribute definitions accepted. Closing tag must be - present and also match the openning tag. Inside the heading - definition an anchor definition must be present with attribute - definitions accepted. The value of name - and href attributes from the anchor - element are set dynamically using the md5sum output of - combining the page location, the head- - string and the heading content itself. If any of the - components used to build the heading reference changes, you - need to run the the tuneup functionality of - centos-art.sh script in order for the - anchor elements to use the correct information. - - - For example, the headings shown in produces the table of - contents shown in . - - - - HTML heading definition. - - HTML heading definition. - - - -<h1 class="title"><a name="head-8a23b56a28dfa7277d176576f217054a">Forms</a></h1> -<h2 class="title"><a name="head-629f38bc607f2a270177106b450aeae3">Elements</a></h2> -<h2 class="title"><a name="head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a></h2> - - - - - - - - HTML table of contents definition. - - HTML table of contents definition. - - - -<div class="toc"> <p>Table of contents</p> <dl><dt><a href="#head-8a23b56a28dfa7277d176576f217054a">Forms</a> <dl><dt><a href="#head-629f38bc607f2a270177106b450aeae3">Elements</a> </dt><dt><a href="#head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a> </dt></dl> </dt></dl> </div> - - - - - - - diff --git a/Manuals/TCAR-UG/tcar-ug.docbook b/Manuals/TCAR-UG/tcar-ug.docbook deleted file mode 100644 index 32a4ba3..0000000 --- a/Manuals/TCAR-UG/tcar-ug.docbook +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - - - -%Commons.ent; -%Introduction.ent; -%Repository.ent; -%Identity.ent; -%Locales.ent; -%Manuals.ent; -%Scripts.ent; -%Licenses.ent; -]> - - - - - The CentOS Artwork Repository - User's Guide - - - - - - Alain - Reguera Delgado - - - - - - 2009 - 2010 - 2011 - &TCAS; - - - - - 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 . - - - - - - 5.5-1 - Fri Jun 24, 2011 - - - ... - - - - - - - - This manuals documents relevant information regarding - the deployment, organization, and administration of - &TCAR; - - - - - - - &intro; - - - &repo; - &identity; - &locales; - &manuals; - &scripts; - &licenses; - - diff --git a/Manuals/Tcar-ug/Commons.ent b/Manuals/Tcar-ug/Commons.ent new file mode 100644 index 0000000..dede723 --- /dev/null +++ b/Manuals/Tcar-ug/Commons.ent @@ -0,0 +1,45 @@ + + + + + + + + + + + + + + +&TC; Project"> + + + +&TC; Mirrors"> + + + + + + + +&TCA; Repository"> +&TCA; SIG"> + +&TCAR; User's Guide"> + +centos-artwork@centos.org mailing list"> +centos-devel@centos.org mailing list"> +centos-info@centos.org mailing list"> + + + + +&TC; Documentation"> diff --git a/Manuals/Tcar-ug/Identity.docbook b/Manuals/Tcar-ug/Identity.docbook new file mode 100644 index 0000000..e4b3488 --- /dev/null +++ b/Manuals/Tcar-ug/Identity.docbook @@ -0,0 +1,17 @@ + + + Corporate Identity + + + + ... + + + + &identity-project; + &identity-brand; + &identity-distro; + &identity-web; + &identity-showroom; + + diff --git a/Manuals/Tcar-ug/Identity.ent b/Manuals/Tcar-ug/Identity.ent new file mode 100644 index 0000000..21d5de9 --- /dev/null +++ b/Manuals/Tcar-ug/Identity.ent @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/Manuals/Tcar-ug/Identity/Brand.docbook b/Manuals/Tcar-ug/Identity/Brand.docbook new file mode 100644 index 0000000..4640ff8 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Brand.docbook @@ -0,0 +1,41 @@ + + + The CentOS Brand + ... + + + Introduction + + + The CentOS Brands is the main visual manifestaion of The CentOS + Project. The CentOS Project uses The CentOS Logo to connect + all its visual manifestions (e.g., GNU/Linux Distributions, + Websites, Stationery, etc.) and, this way, it provides + recognition among other similar projects available on the + Internet. + + + + Both The CentOS Brand and all the visual manifestations that + derivate from it are available for you to study and propose + improvement around a good citizen's will at The CentOS + Community environment, but you are not allowed to redistribute + them elsewhere, without the given permission of The CentOS + Project. + + + + If you need to redistribute either The CentOS Logo or any + visual manifestation derived from it, write your intentions to + the The CentOS Developers mailing list (centos-devel@centos.org). + + + + + + ... + ... + + + diff --git a/Manuals/Tcar-ug/Identity/Distribution.docbook b/Manuals/Tcar-ug/Identity/Distribution.docbook new file mode 100644 index 0000000..0236910 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Distribution.docbook @@ -0,0 +1,16 @@ + + + The CentOS Distribution + ... + + + Release Schema + ... + + + + ... + ... + + + diff --git a/Manuals/Tcar-ug/Identity/Project.docbook b/Manuals/Tcar-ug/Identity/Project.docbook new file mode 100644 index 0000000..2a4d6b4 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project.docbook @@ -0,0 +1,41 @@ + + + The CentOS Project + + + The CentOS Project Corporate Identity is the + persona of the organization known as The CentOS + Project. The CentOS Project Corporate Identity plays a + significant role in the way The CentOS Project, as + organization, presents itself to both internal and external + stakeholders. In general terms, The CentOS Project Corporate + Identity expresses the values and ambitions of The CentOS + Project organization, its business, and its characteristics. + + + + The CentOS Project Corporate Identity provides visibility, + recognizability, reputation, structure and identification to + The CentOS Project organization by means of Corporate Design, + Corporate Communication, and Corporate Behaviour. + + +
+ The CentOS Project Corporate Identity. + + The CentOS Project Corporate Identity. + + + + + + +
+ + &identity-project-mission; + &identity-project-design; + &identity-project-communication; + &identity-project-behaviour; + &identity-project-structure; + + diff --git a/Manuals/Tcar-ug/Identity/Project/behaviour.docbook b/Manuals/Tcar-ug/Identity/Project/behaviour.docbook new file mode 100755 index 0000000..bd22f04 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project/behaviour.docbook @@ -0,0 +1,21 @@ + + + Corporate Behaviour + + + &TCP; corporate behaviour is focused on the effective + interaction of each member involved in the organization (e.g., + core developers, community members, etc.). It is related to + ethics and politics used to do the things inside the + organization. It is related to the sense of direction chosen + by the organization and they way the organization projects + itself to achieve it. + + + + &TCP; corporate behaviour takes place through &TCP; corporate + communication, as described in . + + + diff --git a/Manuals/Tcar-ug/Identity/Project/communication.docbook b/Manuals/Tcar-ug/Identity/Project/communication.docbook new file mode 100755 index 0000000..b87dd32 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project/communication.docbook @@ -0,0 +1,141 @@ + + + Corporate Communication + + + &TCP; corporate communication is focused on the effective + propagation of corporate messages. Propagation of corporate + messages is closely related to the media the organization uses + as vehicle to distribute its corporate messages. + + + + &TCP; corporate communication takes place through the + following visual manifestations: + + + + + &TCD; + + + This visual manifestation communicates its existence + through software packages. There are packages that make a + remarkable use of images, packages that make a moderate + use of images, and packages that don't use images at all. + This visual manifestation is focused on providing &TCP; + images required by software packages that do use images in + a remarkable way, specially those holding the upstream + brand (e.g., anaconda, + grub, syslinux, + gdm, kdebase). + + + + + The Community Enterprise Operating System itself + (communicates the essense of &TCP; existence.). + + + + + Release Schema (Lifetime) and all the stuff related (e.g., + Release Notes, Documentation, Erratas, etc.). + + + + + + + + &TCW; + + + This visual manifestation communicates its existence + through web applications. 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. Removing + these visual contraditions is object of work for this + visual manifestation. + + + + + The CentOS Chat. + + + + + The CentOS Mailing Lists. + + + + + The CentOS Forums. + + + + + The CentOS Wiki. + + + + + Special Interest Groups (SIGs). + + + + + Social Events, Interviews, Conferences, etc. + + + + + The extensive network of mirrors available for downloading + ISO files as well as RPMs and SRPMs used to build them up + in different architectures. + + + + + + + + &TCS; + + + This visual manifestation communicates its existence + through production of industrial objects carrying &TCB;. + These branded objects are directed to be distributed on + social events and/or shops. They provide a way of + promotion and commercialization that may help to reduce + &TCP; expenses (e.g., electrical power, hosting, servers, + full-time-developers, etc.), in a similar way as donations + may do. + + + + + Stationery (e.g., Posters, Stickers, CD Lables and Sleeves). + + + + + Clothes (e.g., Shirts, T-shirts, Pullovers, Caps). + + + + + Installation media (e.g., CDs, DVD, Pendrives). + + + + + + + + + diff --git a/Manuals/Tcar-ug/Identity/Project/design.docbook b/Manuals/Tcar-ug/Identity/Project/design.docbook new file mode 100755 index 0000000..c1df9af --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project/design.docbook @@ -0,0 +1,96 @@ + + + Corporate Design + + + The corporate design is focused on the effective presentation + of corporate messages. As corporate messages we understand all + the information emitted from the organization; and when we say + all we mean everything that can be + perceived through the human senses. The corporate design takes + care of defining what this information is and controlling the + way it goes out the organization producing it. + + + + When the organization doesn't take control over the corporate + messages it produces, the organization is letting that area of + its identity to the unknown and the results might be good or + not so good, it is hard to know. The issue to see here is + that even the organization doesn't take control over its + corporate messages, they are always talking about the + organization. Taking control of corporate messages is a + decition the organization needs to take by itself, based on + its need of better describe what it is. + + + + In the very specific case of &TCP;, we'll concentrate our + attention on corporate messages that reach us through the + visual sense. This is, all the visual manifestations &TCP; is + made of. As visual manifestaions we understand all the visible + media &TCP; uses to manifest its existence on. At this point + it is necessary to consider what &TCP; is, what its mission is + and what it is producing. This, in order to identify which + visual manifestations the organization is demanding attention + of corporate design for. + + + + Inside &TCP; we identify and apply corporate design to the + following visual manifestations: + + + + + &TCD; — This visual manifestation exists to cover + all actions related to artwork production and rebranding, + required by &TCD; in order to comply with upstream's + redistribution guidelines. This visual manifestation is + described in . + + + + + + &TCW; — This visual manifestation exists to cover + all actions related to artwork production required by + &TCP; to manifest its existence in the World Wide Web + medium. This visual manifestation is described in . + + + + + + &TCS; — This visual manifestation exists to cover + all actions related to artwork production required by + &TCP; to manifest its existence through media produced + industrially (e.g., stationery, clothes, CDs, DVDs, etc.). + This visual manifestation is described in . + + + + + + + + The visual manifestations identified above seem to cover most + media required by &TCP;, as organization, to show its + existence. However, other visual manifestations could be + added in the future, as long as they be needed, to cover + different areas like stands, buildings, offices, road + transportation or whaterver visual manifestation &TCP; + thouches to show its existence. + + + + Once all visual manifestations have been identified and + defined through design models, it is time to visually remark + their connection with &TCP;. This kind of connection is + realized by applying &TCB; to design models inside visual + manifestations supported through corporate design. + + + diff --git a/Manuals/Tcar-ug/Identity/Project/mission.docbook b/Manuals/Tcar-ug/Identity/Project/mission.docbook new file mode 100644 index 0000000..507873d --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project/mission.docbook @@ -0,0 +1,40 @@ + + + Corporate Mission + + + &TCP; exists to produce &TCD;, an Enterprise-class Linux + Distribution derived from sources freely provided to the + public by a prominent North American Enterprise Linux vendor. + &TCD; conforms fully with the upstream vendors redistribution + policy and aims to be 100% binary compatible. (&TCD; mainly + changes packages to remove upstream vendor branding and + artwork.). + + + + &TCD; 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. + + + + &TCD; has numerous advantages including: an active and growing + user community, quickly rebuilt, tested, and QA'ed errata + packages, an extensive mirror network, developers who are + contactable and responsive of a reliable Enterprise-class + Linux Distribution, multiple free support avenues including a + Wiki, + IRC + Chat, Email Lists, Forums, and + a dynamic FAQ. + + + diff --git a/Manuals/Tcar-ug/Identity/Project/structure.docbook b/Manuals/Tcar-ug/Identity/Project/structure.docbook new file mode 100755 index 0000000..b1042d7 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Project/structure.docbook @@ -0,0 +1,91 @@ + + + Corporate Structure + + + &TCP; corporate structure is based on a &MCVIS;. In this + configuration, one unique name and one unique visual style is + used in all visual manifestation &TCP; is made of. + + + + 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: + Hey! we are all part of &TCP;. + + + + Other corporate structures for &TCP; have been considered as + well. Such is the case of producing one different visual style + for each major release of &TCD;. 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 &TCP; + is made of. + + + + &TCP;, as organization, is mainly made of (but not limited to) + three visual manifestions: &TCD;, &TCW; and &TCS;. Inside + &TCD; visual manifestations, &TCP; maintains near to four + different major releases of &TCD;, parallely in time. + However, inside &TCW; 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 &TCD; + individually, but one web site to cover them all). Likewise, + the content produced in &TCS; is industrially created for no + specific release, but &TCP; in general. + + + + In order to produce the &TCPMCVIS; correctly, we need to + concider all the visual manifestations &TCP; is made of, not + just one of them. If one different visual style is + implemented for each major release of &TCD;, which one of + those different visual styles would be used to cover the + remaining visual manifestations &TCP; is made of (e.g., &TCW; + and &TCS;)? + + + + Probably you are thinking: yes, I see your point, but &TCB; + 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? + + + + Harder to maintain, more work to do, probably. Specially when + you consider that &TCP; 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. With + that in mind, we consider &TCPCVIS; must be consequent with + such stability and consistency tradition. It is true that + &TCB; does connect all the visual manifestations it is present + on, but that connection is strengthened if one unique visual + style backups it. In fact, whatever thing you do to strength + the visual connection among &TCP; visual manifestations would + be very good in favor of &TCP; recognition. + + + + 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 &TCD;, in order to refresh &TCD; visual + style; the problem itself is in not propagating the brand new + visual style created for the new release of &TCD; to all other + visual manifestations &TCP; is made of, in a way &TCP; 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 &TCAR;. + + + diff --git a/Manuals/Tcar-ug/Identity/Showroom.docbook b/Manuals/Tcar-ug/Identity/Showroom.docbook new file mode 100644 index 0000000..db87232 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Showroom.docbook @@ -0,0 +1,11 @@ + + + The CentOS Showroom + ... + + + ... + ... + + + diff --git a/Manuals/Tcar-ug/Identity/Web.docbook b/Manuals/Tcar-ug/Identity/Web.docbook new file mode 100644 index 0000000..98780b2 --- /dev/null +++ b/Manuals/Tcar-ug/Identity/Web.docbook @@ -0,0 +1,11 @@ + + + The CentOS Web + ... + + + ... + ... + + + diff --git a/Manuals/Tcar-ug/Introduction.docbook b/Manuals/Tcar-ug/Introduction.docbook new file mode 100644 index 0000000..82ff07e --- /dev/null +++ b/Manuals/Tcar-ug/Introduction.docbook @@ -0,0 +1,84 @@ + + + Introduction + + + Welcome to &TCARUG;. + + + + &TCAR; User's Guide describes how &TCPCVI; is organized and + produced inside &TCAR;. If you are looking for a + comprehensive, task-oriented guide for understanding how + &TCPCI; is produced, this is the manual for you. + + + + This manual is divided in the following categories: + + + + + + Repository + + + + + + Corporate Identity + + + + + + Localization + + + + + + Documentation + + + + + + Automation + + + + + + This manual discusses the following topics: + + + + + + &TCAR;, what it is, how it is organized, the things you can + achieve inside it and how you can do such things. + + + + + + &TCP; as organization and the components that define its + visual identity. Here we dig in the ground and climb up to + the sky, looking for the roots, flowers and thorns &TCP; is + made of. + + + + + + This manual assumes you have a basic understanding of &TCD;. + If you need help with it, refer to the help page on The CentOS Wiki for + a list of different places you can find help. + + + &intro-docconvs; + &intro-feedback; + + diff --git a/Manuals/Tcar-ug/Introduction.ent b/Manuals/Tcar-ug/Introduction.ent new file mode 100644 index 0000000..86feba0 --- /dev/null +++ b/Manuals/Tcar-ug/Introduction.ent @@ -0,0 +1,3 @@ + + + diff --git a/Manuals/Tcar-ug/Introduction/Docconvs.docbook b/Manuals/Tcar-ug/Introduction/Docconvs.docbook new file mode 100644 index 0000000..0f522c7 --- /dev/null +++ b/Manuals/Tcar-ug/Introduction/Docconvs.docbook @@ -0,0 +1,225 @@ +
+ + Document Convenctions + + + In this manual, certain words are represented in different + fonts, typefaces, sizes, and weights. This highlighting is + systematic; different words are represented in the same style + to indicate their inclusion in a specific category. The types + of words that are represented this way include the + following: + + + + + command + + + Linux commands (and other operating system commands, when + used) are represented this way. This style should + indicate to you that you can type the word or phrase on + the command line and press Enter to + invoke a command. Sometimes a command contains words that + would be displayed in a different style on their own (such + as file names). In these cases, they are considered to be + part of the command, so the entire phrase is displayed as + a command. For example: + + + + Use the centos-art render + trunk/Identity/Images/Themes/TreeFlower/4/Distro/5/Anaconda + --filter="01-welcome" command to produce the first + slide image used by Anaconda in the branch 5 of &TCD; + using the version 4 of TreeFlower artistic motif. + + + + + + file name + + + File names, directory names, paths, and RPM package names + are represented this way. This style indicates that a + particular file or directory exists with that name on your + system. Examples: + + + + The init.sh file in trunk/Scripts/Bash/Cli/ + directory is the initialization script, written in Bash, + used to automate most of tasks in the repository. + + + + The centos-art command uses the + ImageMagick RPM package to convert + images from PNG format to other formats. + + + + + + key + + + A key on the keyboard is shown in this style. For + example: + + + + To use Tab completion to list particular + files in a directory, type ls, then a + character, and finally the Tab key. Your + terminal displays the list of files in the working + directory that begin with that character. + + + + + + keycombination + + + A combination of keystrokes is represented in this way. + For example: + + + + The CtrlAltBackspace + key combination exits your graphical session and returns + you to the graphical login screen or the console. + + + + + + computer output + + + Text in this style indicates text displayed to a shell + prompt such as error messages and responses to commands. + For example, the ls command displays + the contents of a directory using this style: + + + +render_doTranslation.sh render_getDirTemplate.sh render_doBaseActions.sh +render_getConfigOption.sh render_getOptions.sh render_doThemeActions.sh +render_getDirOutput.sh render.sh + + + + The output returned in response to the command (in this + case, the contents of the directory) is shown in this + style. + + + + + + prompt + + + A prompt, which is a computer's way of signifying that it + is ready for you to input something, is shown in this + style. Examples: + + + + + + $ + + + + + # + + + + + [centos@projects centos]$ + + + + + projects login: + + + + + + + + user input + + + Text that the user types, either on the command line or + into a text box on a GUI screen, is displayed in this + style. In the following example, + text is displayed in this style: To + boot your system into the text based installation program, + you must type in the text command + at the boot: prompt. + + + + + + replaceable + + + Text used in examples that is meant to be replaced with + data provided by the user is displayed in this style. In + the following example, + version-number is displayed in + this style: The directory for the kernel source is + /usr/src/kernels/version-number/, + where version-number is the + version and type of kernel installed on this system. + + + + + + Additionally, we use several different strategies to draw + your attention to certain pieces of information. In order of + urgency, these items are marked as a note, tip, important, + caution, or warning. For example: + + + Remember that Linux is case sensitive. In other words, a + rose is not a ROSE is not a rOsE. + + + + The directory /usr/share/doc/ contains + additional documentation for packages installed on your + system. + + + + If you modify the DHCP configuration file, the changes + do not take effect until you restart the DHCP daemon. + + + + Do not perform routine tasks as root — use a + regular user account unless you need to use the root account + for system administration tasks. + + + + Be careful to remove only the necessary partitions. + Removing other partitions could result in data loss or a + corrupted system environment. + + +
diff --git a/Manuals/Tcar-ug/Introduction/Feedback.docbook b/Manuals/Tcar-ug/Introduction/Feedback.docbook new file mode 100644 index 0000000..f690b2a --- /dev/null +++ b/Manuals/Tcar-ug/Introduction/Feedback.docbook @@ -0,0 +1,18 @@ +
+ + Send in Your Feedback + + + If you find an error in the &TCAR;, or if you have thought of + a way to make this manual better, we would like to hear from + you! Share your suggestions in &TCAML;. + + + + When you make suggestion, try to be as specific as possible. + For example, if you have found an error in the manual, include + the section number and some of the surrounding text so we can + find it easily. + + +
diff --git a/Manuals/Tcar-ug/Licenses.docbook b/Manuals/Tcar-ug/Licenses.docbook new file mode 100644 index 0000000..dfc86ce --- /dev/null +++ b/Manuals/Tcar-ug/Licenses.docbook @@ -0,0 +1,6 @@ + + Licenses + &licenses-gpl; + &licenses-gfdl; + + diff --git a/Manuals/Tcar-ug/Licenses.ent b/Manuals/Tcar-ug/Licenses.ent new file mode 100644 index 0000000..29e0b56 --- /dev/null +++ b/Manuals/Tcar-ug/Licenses.ent @@ -0,0 +1,3 @@ + + + diff --git a/Manuals/Tcar-ug/Licenses/gfdl.docbook b/Manuals/Tcar-ug/Licenses/gfdl.docbook new file mode 100644 index 0000000..57d1e0a --- /dev/null +++ b/Manuals/Tcar-ug/Licenses/gfdl.docbook @@ -0,0 +1,591 @@ + + + GNU Free Documentation License + + Version 1.2, November 2002 + + Copyright © 2000, 2001, 2002 Free Software Foundation, + Inc. 675 Mass Ave, Cambridge, MA 02139, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + 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. + + 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 , which is a copyleft license + designed for free software. + + 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. + + + + + + Applicability and definitions + + 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. + + 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. + + 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 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. + + The Invariant Sections are certain + 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 Section then + there are none. + + 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. + + 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 file format whose + markup, or absence of markup, has been arranged to thwart or + discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of + text. A copy that is not is called Opaque. + + Examples of suitable formats for 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. + + 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. + + 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. + + 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. + + + + + + Verbatim copying + + 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 . + + You may also lend copies, under the same conditions + stated above, and you may publicly display copies. + + + + + + Copying in quantity + + 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 : + 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. + + 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. + + If you publish or distribute Opaque copies of the + Document numbering more than 100, you must either include a + machine-readable 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 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 + 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. + + 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. + + + + + + Modifications + + You may copy and distribute a of the Document under the + conditions of sections and above, + provided that you release the under precisely this License, with the filling the role of the + Document, thus licensing distribution and modification of the + to whoever possesses a + copy of it. In addition, you must do these things in the + : + + + + + Use in the (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. + + + List on the , as + authors, one or more persons or entities responsible + for authorship of the modifications in the , 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. + + + + State on the the + name of the publisher of the , as the + publisher. + + + + Preserve all the copyright notices of the + Document. + + + + Add an appropriate copyright notice for your + modifications adjacent to the other copyright + notices. + + + + Include, immediately after the copyright + notices, a license notice giving the public permission + to use the under the terms of this + License, in the form shown in the Addendum + below. + + + + Preserve in that license notice the full lists + of and required + given in the Document's + license notice. + + + + Include an unaltered copy of this License. + + + + 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 as given on the . 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 , then add an item describing the as stated in the previous + sentence. + + + + Preserve the network location, if any, given in + the Document for public access to a 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. + + + + 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. + + + + Preserve all the of the Document, + unaltered in their text and in their titles. Section + numbers or the equivalent are not considered part of + the section titles. + + + + Delete any section Entitled + Endorsements. Such a section may not + be included in the . + + + + Do not retitle any existing section to be + Entitled Endorsements or to conflict in + title with any . + + + Preserve any Warranty Disclaimers. + + + + + If the includes new + front-matter sections or appendices that qualify as 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 in the 's license notice. These titles + must be distinct from any other section titles. + + You may add a section Entitled + Endorsements, provided it contains nothing but + endorsements of your 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. + + 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 in the . 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. + + 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 . + + + + + + Combining documents + + You may combine the Document with other documents + released under this License, under the terms defined in + section above for + modified versions, provided that you include in the + combination all of the of + all of the original documents, unmodified, and list them all + as of your combined work + in its license notice, and that you preserve all their + Warranty Disclaimers. + + The combined work need only contain one copy of this + License, and multiple identical may be replaced with a single + copy. If there are multiple 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 in + the license notice of the combined work. + + 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. + + + + + + Collection of documents + + 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. + + 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. + + + + + + Aggregation with independent works + + 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. + + If the Cover Text requirement of section is applicable to these + copies of the Document, then if the Document is less than one + half of the entire aggregate, the Document's 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. + + + + + + Translations + + Translation is considered a kind of modification, so you + may distribute translations of the Document under the terms of + section . Replacing + with translations + requires special permission from their copyright holders, but + you may include translations of some or all in addition to the original + versions of these . 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. + + If a section in the Document is Entitled + Acknowledgements, Dedications, + or History, the requirement (section ) to Preserve its Title + (section ) will + typically require changing the actual title. + + + + + + Termination + + 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. + + + + + + Future Revisions of this License + + 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 . + + 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. + + + + + + How to use this License for your documents + + 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: + + +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. + + + If you have , + Front-Cover Texts and Back-Cover Texts, replace the + with...Texts. line with this: + + +with the Invariant Sections being LIST THEIR TITLES, with the +Front-Cover Texts being LIST, and with the Back-Cover Texts being +LIST. + + + If you have + without , or some other + combination of the three, merge those two alternatives to suit + the situation. + + 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. + + + + diff --git a/Manuals/Tcar-ug/Licenses/gpl.docbook b/Manuals/Tcar-ug/Licenses/gpl.docbook new file mode 100644 index 0000000..0990730 --- /dev/null +++ b/Manuals/Tcar-ug/Licenses/gpl.docbook @@ -0,0 +1,497 @@ + + + GNU General Public License + + Version 2, June 1991 + + Copyright © 1989, 1991 Free Software Foundation, Inc. + 675 Mass Ave, Cambridge, MA 02139, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + 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. + + 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. + + 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. + + 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. + + We protect your rights with two steps: + + + + copyright the software, and + + + offer you this license which gives you legal + permission to copy, distribute and/or modify the + software. + + + + + 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. + + 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. + + The precise terms and conditions for copying, distribution + and modification follow. + + + + + + Terms and Conditions for Copying, Distribution and Modification + + + + Section 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. + + 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. + + + + + + Section 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 above, provided that you also meet all of these + conditions: + + + + You must cause the modified files to carry prominent + notices stating that you changed the files and the date of + any change. + + + 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. + + + 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. + + + + + + + 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. + + 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. + + 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. + + + + + + Section 3 + + You may copy and distribute the Program (or a work + based on it, under ) in + object code or executable form under the terms of and above provided that you also + do one of the following: + + + + + + Accompany it with the complete corresponding + machine-readable source code, which must be + distributed under the terms of and above on a medium + customarily used for software interchange; + or, + + + + + + 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 and above on a medium + customarily used for software interchange; + or, + + + + + + 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.) + + + + + + + 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. + + 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. + + + + + + Section 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. + + + + + + Section 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. + + + + + + Section 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. + + + + + + Section 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. + + 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. + + 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. + + This section is intended to make thoroughly clear what is + believed to be a consequence of the rest of this License. + + + + + + Section 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. + + + + + + Section 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. + + 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. + + + + + + Section 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. + + + + + + NO WARRANTY + Section 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. + + + + + + Section 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. + + End of Terms and Conditions. + + + + + + + + How to Apply These Terms to Your New Programs + + 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. + + 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. + + +<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. + + + Also add information on how to contact you by electronic + and paper mail. + + If the program is interactive, make it output a short + notice like this when it starts in an interactive mode: + + +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. + + + 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. + + 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: + + +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 + + + 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. + + + + diff --git a/Manuals/Tcar-ug/Locales.docbook b/Manuals/Tcar-ug/Locales.docbook new file mode 100644 index 0000000..f33f6e9 --- /dev/null +++ b/Manuals/Tcar-ug/Locales.docbook @@ -0,0 +1,21 @@ + + + Localization + + + ... + + + + ... + ... + + + ... + ... + + + + + + diff --git a/Manuals/Tcar-ug/Locales.ent b/Manuals/Tcar-ug/Locales.ent new file mode 100644 index 0000000..48245e8 --- /dev/null +++ b/Manuals/Tcar-ug/Locales.ent @@ -0,0 +1,2 @@ + + diff --git a/Manuals/Tcar-ug/Manuals.docbook b/Manuals/Tcar-ug/Manuals.docbook new file mode 100644 index 0000000..80d9424 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals.docbook @@ -0,0 +1,20 @@ + + + Documentation + + + + This part describes the repository's documentation work + line. Here you'll find how documentation backends inside + The CentOS Distribution are used to produce documentation + manuals inside The CentOS + Artwork Repository. + + + + + &manuals-texinfo; + &manuals-docbook; + + + diff --git a/Manuals/Tcar-ug/Manuals.ent b/Manuals/Tcar-ug/Manuals.ent new file mode 100644 index 0000000..8bb6cd7 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals.ent @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/Manuals/Tcar-ug/Manuals/Docbook.docbook b/Manuals/Tcar-ug/Manuals/Docbook.docbook new file mode 100644 index 0000000..24c369a --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Docbook.docbook @@ -0,0 +1,7 @@ + + + DocBook Backend + + &manuals-docbook-intro; + + diff --git a/Manuals/Tcar-ug/Manuals/Docbook/intro.docbook b/Manuals/Tcar-ug/Manuals/Docbook/intro.docbook new file mode 100644 index 0000000..4645113 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Docbook/intro.docbook @@ -0,0 +1,9 @@ + + + Introduction + + + ... + + + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo.docbook b/Manuals/Tcar-ug/Manuals/Texinfo.docbook new file mode 100644 index 0000000..3f0523f --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo.docbook @@ -0,0 +1,11 @@ + + + Texinfo Backend + + &manuals-texinfo-intro; + &manuals-texinfo-structure; + &manuals-texinfo-templates; + &manuals-texinfo-localizing; + &manuals-texinfo-encoding; + + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo/encoding.docbook b/Manuals/Tcar-ug/Manuals/Texinfo/encoding.docbook new file mode 100644 index 0000000..a9ac2a7 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo/encoding.docbook @@ -0,0 +1,5 @@ + + Document Encoding + ... + + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo/intro.docbook b/Manuals/Tcar-ug/Manuals/Texinfo/intro.docbook new file mode 100644 index 0000000..f9c99b0 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo/intro.docbook @@ -0,0 +1,38 @@ + + + Introduction + + + Documentation manuals that use + Texinfo as documentation backend + are conceived 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. They provides a documentation entry for each directory + inside the repository and, this way, a place to document it. + + + + Most actions related to Texinfo documentation backend (e.g., + editing, reading, copying, renaming, etc.) are controlled by + the help functionality as described in + . Through this + functionality you can manipulate documentation entries in a + way that you don't need to take care of updating menus, nodes + and cross reference information inside the manual source files + because 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 by your own, there + is no functionality to help you doing such things, yet. + + + + The Texinfo documentation backend could result useful to you + if your only need is to document directory structures in a + manual that follows, exactly, the same organization of the + structure it documents (e.g., one directory one documentation + entry for it). + + + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo/localizing.docbook b/Manuals/Tcar-ug/Manuals/Texinfo/localizing.docbook new file mode 100644 index 0000000..0661a4c --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo/localizing.docbook @@ -0,0 +1,4 @@ + + Document Localization + ... + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo/structure.docbook b/Manuals/Tcar-ug/Manuals/Texinfo/structure.docbook new file mode 100644 index 0000000..7fc3abf --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo/structure.docbook @@ -0,0 +1,131 @@ + + + Document Structure + + + The document structure provides the organization needed to + make the documentation scalable and maintainable through time + which, in turn, involves document sectioning and file + organization inside specific locations of the working copy. + The document structure is also a convenction we adopt in order + to automate frequent tasks related to the document structure + itself. Without a well defined document structure convenction, + it would be very difficult for automation script to guess + where the documentation files are. + + + + The file organization of Texinfo documentation backend takes + place in trunk/Manuals/Repository/Texinfo/ + directory. Inside this location there is one documentation + structure for each language you want to support and the + repository-init.pl and + repository.sed files which let you + control common characteristics of final XHTML output (e.g., + texi2html initialization, and markup + transformations). + + + + The document sectioning follows the idea of an upside-down + tree to organize chapters, sections, subsections, and the + like. The document initiates with a Top node where we placed + document's title, copyright note, abstract, and a list of + available chapters to start browsing. Inside each chapter the + information is logically organized in sections which in turn + are subdivided in subsections and subsubsections. + + + + The Texinfo document structure produced by + help functionality organizes information + in two chapters only, which are: + + + + + + Directories — This chapter organizes documentation + entries related to repository directories. In the normal + work flow, you don't need to touch the files of this + chapter by your own. For that purpose, the + centos-art.sh script porovides the + help functionality. To manipulate + documentation entries in this chapter, you use the + help functionality as described in + . + + + + + + Licenses — This chapter includes licenses from + trunk/Scripts/Functions/Help/Texinfo/Templates/language/Licenses/ + directory. In the normal work flow, you don't need to + touch this chapter. It is created when the document + structure is created and should ramain that way. If you + need to improve the markup, update the template files for + your language, not the content of this chapter. + + + + + + + + + At the same level of chapter directories, the + repository.texinfo, + repository-index.texinfo, + repository-menu.texinfo and + repository-nodes.texinfo files exist to + set manual's main definitions (e.g., title, copyright notice, + chapters, appendixes, indexes and all the similar stuff a + documentation manual should have). + + + Inside each chapter directory, the + chapter.texinfo, + chapter-menu.texinfo and + chapter-nodes.texinfo files exist to + control definition of sections. In addition to these files, + there are documentation entries to store the document's content + itself, using arbitrary file names prefixed with the texinfo extension, just as it is + illustrated in . + + + + Texinfo backend's document structure. + + Texinfo backend's document structure. + + + trunk/Manuals/Repository/Texinfo +|-- en_US +| |-- Directories +| | |-- chapter-menu.texinfo +| | |-- chapter-nodes.texinfo +| | |-- chapter.texinfo +| | |-- trunk/Identity.texinfo +| | `-- trunk.texinfo +| |-- Licenses +| | |-- chapter-menu.texinfo +| | |-- chapter-nodes.texinfo +| | `-- chapter.texinfo +| |-- repository-index.texinfo +| |-- repository-menu.texinfo +| |-- repository-nodes.texinfo +| `-- repository.texinfo +|-- repository-init.pl +|-- repository.css +`-- repository.sed + + + + + + diff --git a/Manuals/Tcar-ug/Manuals/Texinfo/templates.docbook b/Manuals/Tcar-ug/Manuals/Texinfo/templates.docbook new file mode 100644 index 0000000..e459647 --- /dev/null +++ b/Manuals/Tcar-ug/Manuals/Texinfo/templates.docbook @@ -0,0 +1,6 @@ + + Document Templates + ... + + + diff --git a/Manuals/Tcar-ug/Repository.docbook b/Manuals/Tcar-ug/Repository.docbook new file mode 100644 index 0000000..ea8dd86 --- /dev/null +++ b/Manuals/Tcar-ug/Repository.docbook @@ -0,0 +1,9 @@ + + + Repository + + &repo-convs; + &repo-ws; + &repo-history; + + diff --git a/Manuals/Tcar-ug/Repository.ent b/Manuals/Tcar-ug/Repository.ent new file mode 100644 index 0000000..f934105 --- /dev/null +++ b/Manuals/Tcar-ug/Repository.ent @@ -0,0 +1,23 @@ + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions.docbook b/Manuals/Tcar-ug/Repository/Convenctions.docbook new file mode 100644 index 0000000..71f68f8 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions.docbook @@ -0,0 +1,16 @@ + + + Repository Convenctions + + &repo-convs-mission; + &repo-convs-layout; + &repo-convs-worklines; + &repo-convs-filenames; + &repo-convs-relbdirs; + &repo-convs-syncpaths; + &repo-convs-extending; + &repo-convs-publishing; + &repo-convs-authoring; + &repo-convs-copying; + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook b/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook new file mode 100755 index 0000000..fdbd8e8 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/authoring.docbook @@ -0,0 +1,16 @@ + + + Repository Authoring + + + The content produced inside &TCAR; is copyright of &TCAS; and + this is something you, as author, need to be aware of because + you are giving part of your creation's rights to someone else; + &TCAS; for this matter. In this case, your work is + distributed using &TCAS; as copyright holder not your name. + Because &TCAS; is the copyright holder, is the license chosen + by &TCAS; the one applied to your work, so it is the one you + need to agree with before making a creation inside &TCAR;. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook b/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook new file mode 100755 index 0000000..04a3957 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/copying.docbook @@ -0,0 +1,68 @@ + + + Repository Copying Conditions + + + &TCAS; uses &TCAR; to implement &TCPCVI;. The implementation + itself is controlled by the centos-art.sh + script. + + + + Both the centos-art.sh script and &TCAR;, + 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 work + that they might get from you. + + + + Specifically, we want to make sure that you have the right to + give away copies of centos-art.sh script + and the organization of files it needs to work, that you + receive source code or else can get it if you want it, that + you can change this work or use pieces of it in new free + works, and that you know you can do these things. + + + + To make sure that everyone has such rights, we have to forbid + you to deprive anyone else of these rights. For example, if + you distribute copies of the centos-art.sh + script, you must give the recipients all the rights that you + have. You must make sure that they, too, receive or can get + the source code. And you must tell them their rights. + + + + Also, for our own protection, we must make certain that + everyone finds out that there is no warranty for the + centos-art.sh script. If this work is + modified by someone else and passed on, we want their + recipients to know that what they have is not what we + distributed, so that any problems introduced by others will + not reflect on our reputation. + + + + The centos-art.sh script is released as a + GPL work. Individual packages used by + centos-art.sh script include their own + licenses and the centos-art.sh script + license applies to all packages that it does not clash with. + If there is a clash between the + centos-art.sh script license and individual + package licenses, the individual package license applies + instead. + + + + The precise conditions of the license for the + centos-art.sh script are found in the . This manual specifically is covered + by the . + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook b/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook new file mode 100644 index 0000000..6e0d153 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/extending.docbook @@ -0,0 +1,40 @@ + + + Extending Repository Layout + + + Occasionly, you may find that new components of &TCPCVI; 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 starting to create directories blindly all over, is: + What is the right place to store it? + + + + When the repository structure is extended, it is very useful + to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a + matter of choosing appropriate names. It is also worth to + know that each directory in the repository responds to one or + more concepts that justify its existence. + + + + To build a directory structure inside the repository, you need + to define the concept behind it first and later create the + directory, remembering that there are locations inside the + repository that define concepts you probably would prefer to + reuse. For example, the trunk/Identity/Images/Themes + directory stores artistic motifs of different themes, the + trunk/Identity/Models/Themes + directory stores design models for themes, the trunk/Manuals directory stores + documentation, the trunk/L10n stores translation + messages, and the trunk/Scripts stores automation + scripts. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook b/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook new file mode 100644 index 0000000..d47dbf4 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/filenames.docbook @@ -0,0 +1,27 @@ + + + Repository File Names + + + Inside &TCAR;, file names are all written in lowercase (e.g., + 01-welcome.png, + splash.png, + anaconda_header.png, etc.) and directory + names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel + case (e.g., TreeFlower, + etc.). + + + + In the very specific case of repository documentation entries, + file names follow the directory naming convenction. This is + because they are documenting directories and that is something + we want to remark. So, to better describe what we are + documenting, documentation entries follow the name convenction + used by the item they document. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook b/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook new file mode 100644 index 0000000..a62d4fd --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/layout.docbook @@ -0,0 +1,58 @@ + + + Repository Layout + + + &TCAR; is supported by Subversion, 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. + + + + &TCAR; is made of one source repository and + many working copies of that source repository. + The working copies are independent one another, can be + distributed all around the world and provide a local place for + designers, documentors, translators and programmers to perform + their work in a descentralized way. The source repository, on + the other hand, provides a central place for all independent + working copies to interchange data and provides the + information required to permit extracting previous versions of + files at any time. + + + + The first level of directories in the repository provides + organization through a convenctional trunk, + branches and tags layout. In + this configuration the trunk directory is where main + changes take place, the tags directory is where frozen + copies of trunk changes + are placed in for releasing, and the branches directory is an + intermediate place between trunk and tags states where changes take + place before being merged into trunk and finally released into + tags. + + + + The second level of directories in the repository provides + organization for repository work lines, as described in . + + + + All other subsequent levels of directories in the repository, + from third level on, are created to organize specific concepts + related to the work line they are in. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook b/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook new file mode 100755 index 0000000..76a2e7c --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/mission.docbook @@ -0,0 +1,9 @@ + + + Repository Mission + + + &TCAR; exists to oraganize the files related to &TCPCVI;. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook b/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook new file mode 100755 index 0000000..dd8d7e4 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/publishing.docbook @@ -0,0 +1,54 @@ + + + Repository Publishing + + + When you perform changes inside your working copy, those + changes are local to your working copy only. In order for you + to share your changes with others, you need to commit them up + to the central repository the working copy you are using was + initially downloaded from. To commit your changes up to the + central repository you use the commit + command of Subversion's client installed in your workstation. + + + + + Initially, when you get registered inside &TCAR;, you won't be + able to publish your changes to &TCAR; immediatly. It is + necessary that you prove your interest in contributing first, + preferably in conjunction with a description of the changes + you pretend to commit. This restriction is necessary in order + to protect the source repository from spammers. + + + + Once you've received access to publish your changes, they will + remain valid to you and there is no need for you to request + permission to publish new changes as long as you behave as a + good cooperating citizen. + + + + As a good cooperating citizen one understand of a person who + respects the work already done by others and share ideas with + authors before changing relevant parts of their work, + specially in situations when the access required to realize + the changes has been granted already. Of course, there is a + time when conversation has taken place, the paths has been + traced and changing the work is so obvious that there is no + need for you to talk about it; that's because you already did, + you already built the trust to keep going. As complement, the + mailing list mentioned above is available for sharing ideas in + a way that good relationship between community citizens could + be constantly balanced. + + + + The relationship between community citizens is monitored by + repository administrators. Repository administrators are + responsible of granting that everything goes the way it needs + to go in order for &TCAR; to accomplish its mission. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook b/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook new file mode 100644 index 0000000..1abadfd --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/relbdirs.docbook @@ -0,0 +1,123 @@ + + + Repository Path Types + + + In order for automation scripts to produce content inside a + working copy of &TCAR;, it is required that all work lines be + related somehow. The relation between work lines is used by + automation scripts to know where to retrive the information + they need to work with (e.g., input files, translation + messages, output locations, etc.). This kind of relation is + built using two path constructions known as master + paths and auxiliar paths. + + + + + Master Paths + + + A master path refers to a directory inside the repository that + contain input files required to produce output files through + automation scripts. Examples of master paths inside the + repository include: + + + + + trunk/Identity/Models/Brands + + + + + trunk/Manuals/Repository/Docbook + + + + + trunk/Identity/Models/Themes/Default/Distro/5/Anaconda + + + + + + + + + Auxiliar paths + + + An auxiliar path refers a directory inside the repository + considered auxiliar for the master path. Auxiliar path can be + either for output or localization. Assuming the master path + provides the input information, the auxiliar paths provide the + auxiliar information which describes how and where that input + information is rendered by automation scripts. Examples of + auxiliar paths inside the repository include: + + + + + trunk/Identity/Images/Brands + + + + + trunk/Manuals/Repository/Docbook/es_ES + + + + + trunk/Locales/Manuals/Repository/Docbook/es_ES + + + + + trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES + + + + + trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES + + + + + + + + + + + The relationship between master and auxiliar paths is built by + combining the second directory level of master paths with + directories in the second directory level of repository + layout. In the second directory level of repository layout, + the Identity, Manuals and Scripts directories are always + used to create the master paths and the output auxiliar paths. + The Locales directory, + on the other hand, is always used to create localization + auxiliar paths for all the master paths available under + Identity, Manuals and Scripts directories. + + + + For example, if the LANG environment variable + is set to es_ES.UTF-8 and you execute the + render functionality of + centos-art.sh script with the trunk/Manuals/Repository/Docbook + master path as argument, it will produce &TCARUG; in Spanish + language using translation messages from trunk/Locales/Manuals/Repository/Docbook/es_ES + auxiliar path and saving output files inside trunk/Manuals/Repository/Docbook/es_ES + auxiliar path. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook b/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook new file mode 100644 index 0000000..23ad317 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/syncpaths.docbook @@ -0,0 +1,96 @@ + + + Syncronizing Repository Paths + + + Once both master and auxiliar paths have been related in the + repository, they shouldn't be changed except you absolutly + need to do so. In this cases, when you need to change master + or auxiliar paths, it is required that you also change the + relation between them so as to retain their bond. This + process of keeping master and auxiliar paths + connected between themselves is known as + path syncronization. + + + + Path syncronization is required for automation scripts to know + where to store final output, where to retrive translation + messages from, and whatever information you might need to + count with. If the 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 to work with or + where to store the output information produced from it. Path + syncronization is the way we use through to organize and + extend the information stored in the repository. + + + + Path syncronization involves both movement of files and + replacement of content inside files. Movement of files is + related to actions like renaming files and directories inside + the repository. Replacement of content inside files is + related to actions like replacing information (e.g., paths + information) inside files in order to keep file contents and + file locations consistent one another after a file movement. + + + + The order followed to syncronize path information is very + important because the versioned nature of the files we are + working with. When a renaming action needs to be performed + inside the repository, we avoid making replacements inside + files first and file movements later. This would demand two + commit actions: one for the files' internal changes and + another for the file movement itself. Otherwise, we prefer to + perform file movements first and files' internal replacements + later. This way it is possible to commit both changes as if + they were just one. + + + + + There is no support for URLs actions inside + centos-art.sh script. The + centos-art.sh script is designed to work + with local files inside the working copy only. If you need to + perform URL actions directly, use Subversion's commands + instead. + + + + + At this moment there is no full implementation of path + syncronization process inside centos-art.sh + script and it is somthing we need to do oursleves. However, + the texinfo backend of help + functionality which provides a restricted implementation of + path syncronization to this specific area of documentation + through the , + and options you can take as + reference to implement it in other areas. + + + + The plan for a full implementation of path syncronization + would be to create individual restricted implementations like + the one in texinfo backend for other areas that + demand it and then, create a higher implmentation that + combines them all as needed. This way, if we try to rename a + repository directory the higher action will define which are + all the restricted actions that should be performed in order + to make the full path syncronization. + + + + For example, if the directory we are renaming is a master + path, it is required to syncronize the related output and + localization auxiliar paths. On the other hand, if the + directory we are renaming through full path syncronization is + an auxiliar path, it is required to determine first what is + the related master path and later, perform the syncronization + from master path to auxiliar paths as if the path provided + would be the master path not the auxiliar path. + + + diff --git a/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook b/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook new file mode 100644 index 0000000..a49257e --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Convenctions/worklines.docbook @@ -0,0 +1,112 @@ + + + Repository Work Lines + + + To organize content production inside &TCAR;, production has + been divided into individual work lines that relate one + another based on the idea of doing one thing well. Later, the + results produced individually by each work line are combined + to achieve a higher purpose. Work lines, as conceived here, + provide the relayable output components the production cycle + inside &TCAR; needs to let everyone to work syncronized in a + descentralized environment. + + + + + Visual Identity + + + In the production cycle, the first step takes place through + graphic design. It is focused on preparing design models for + all the visual manifestation &TCP; is made of. Here, graphic + designers describe the visual characteristics of each visual + manifestation (e.g., image dimensions, position of text in the + visible area, translation markers, etc.). + Later, once design models have been defined, graphic designers + take care of artistic motifs to define the visual style of + those design models already created (e.g., how they look and + feel). + + + + Finally, graphic designers use the + render functionality of + centos-art.sh script to combine both design + models and artistic motifs in order to produce the final + images required by each visual manifestaions. + + + + + + + Localization + + + The second step in the production cycle is to localize + source files (e.g., SVG, DocBook, Shell scripts). This step + makes possible to produce localized images, localized + documentation and localized automation scripts. + + + + The localization tasks are carried on by translators using the + locale functionality of the + centos-art.sh script which take care of + retriving translatable strings from source files and provide a + consistent localization interface based on GNU + gettext multi-lingual message + production tool set and xml2po command. + + + + + + + Documentation + + + The third step in the production cycle is to document &TCAR;, + what it is and how to use it. This step provides the + conceptual ideas used as base to edificate &TCPCVI; and is + implemented through &TCARUG;. + + + + To write documentation, documentors use the + help functionality of + centos-art.sh script which provide an + consistent interface for building documentation through + different documentation backends (e.g., Texinfo and DocBook). + + + + + + + Automation + + + The fourth step in the production cycle is to automate + frequent tasks inside &TCAR;. This step closes the production + cycle and provides the production standards needed by all + different work lines to coexist together. Here is where + the centos-art.sh script and all + its functionalities (e.g., render for + rendition, help for documentation, + locale for localization, etc.) are + developed. + + + + At this point it should be obvious, but we consider worth to + remember that: there is no need to type several tasks, time + after time, if they can be programmed into just one executable + script. + + + + + diff --git a/Manuals/Tcar-ug/Repository/History.docbook b/Manuals/Tcar-ug/Repository/History.docbook new file mode 100644 index 0000000..6292d08 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/History.docbook @@ -0,0 +1,41 @@ + + + Repository History + + + &TCAR; started at The CentOS Developers + Mailing List around 2008, on a discussion about how to + automate slide images used by Anaconda. In such discussion, + Ralph Angenendt rose up his hand to ask —Do you have + something to show?—. + + + + To answer the question, Alain Reguera Delgado suggested a bash + script which combined SVG and SED files in order to produce + PNG images in different languages —in conjunction with + the proposition of creating a Subversion repository where + translations and image production could be distributed inside + &TCC;—. + + + + Karanbirn Sighn considered the idea intresting and provided + the infrastructure necessary to support the effort. This way, + &TCAS; and &TCAR; were officially created and world wide + available. + + + + Once &TCAR; was available, Alain Reguera Delgado uploaded the + bash script Anaconda slides; Ralph Angenendt documented it + very well; and people started to download working copies of + the repository to produce slide images in their own languages. + + + &repo-history-2009; + &repo-history-2010; + &repo-history-2011; + + diff --git a/Manuals/Tcar-ug/Repository/History/2009.docbook b/Manuals/Tcar-ug/Repository/History/2009.docbook new file mode 100644 index 0000000..5e10ea5 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/History/2009.docbook @@ -0,0 +1,55 @@ + + + 2009's + + + Around 2009, the rendition script was at a very rustic state + where only slide images could be produced, so it was + redesigned to extend the image production to other areas, + different from slide images. In this configuration, one SVG + file was used as input to produce a translated instance of it + which, in turn, was used to produce one translated PNG image + as output. The SVG translated instance was created through SED + replacement commands. The translated PNG image was created + from the SVG translated instance using Inkscape command-line + interface. + + + + The repository directory structure was prepared to receive the + rendition script using design templates and translation files + in the same location. There was one directory structure for + each artwork that needed to be produced. In this + configuration, if you would want to produce the same artwork + with a different visual style or structure, it was needed to + create a new directory structure for it because both the image + structure and the image visual style were together in the + design template. + + + + The rendition script was moved to a common place and linked + from different directory structures. There was no need to have + the same code in different directory structures if it could be + in just one place and then be linked from different locations. + + + + Corporate identity concepts began to be considered. As + referece, it was used the book "Corporate Identity" by Wally + Olins (1989) and Wikipedia + related links. This way, the rendition script main's goal + becomes to: automate the production process of a + monolithic corporate visual identity structure, based on the + mission and the release schema of The CentOS + Project. + + + + The repository directory structures began to be documented by + mean of flat text files. Later, documentation in flat text + files was moved onto LaTeX format and this way &TCARUG; was + initiated. + + diff --git a/Manuals/Tcar-ug/Repository/History/2010.docbook b/Manuals/Tcar-ug/Repository/History/2010.docbook new file mode 100644 index 0000000..6949b7e --- /dev/null +++ b/Manuals/Tcar-ug/Repository/History/2010.docbook @@ -0,0 +1,79 @@ + + + 2010's + + + Around 2010, the rendition script changed its name from + render.sh to + centos-art.sh and became a collection of + functionalities where rendition was just one among others + (e.g., documentation and localization). + + + + The centos-art.sh was initially conceived + to automate frequent tasks inside the repository based in the + idea of Unix toolbox: to create small and specialized tools + that do one thing well. This way, functionalities inside + centos-art.sh began to be identified and + separated one another. For example, when images were rendered, + there was no need to load functionalities related to + documentation manual. This layout moved us onto common + functionalities and specific + functionalities inside + centos-art.sh script. Common + functionalities are loaded when + centos-art.sh script is initiated and are + available to specific functionalities. + + + + Suddenly, no need was found to keep all the links spreaded + around the repository in order to execute the + centos-art.sh script from different + locations. The centos-art command-line interface was used + instead. The centos-art command-line interface is a symbolic + link stored inside the ~/bin directory that point to + centos-art.sh script. As default + configuration, inside The CentOS Distribution, the path to + ~/bin is included in + the search path for commands (see PATH + environment variable). This way, using the centos-art + command-line interface, it is possible for us to execute the + centos-art.sh script from virtually + anywhere inside the workstation, just as we frequently do with + regular commands. + + + + Start using GNU getopt as default option parser inside the + centos-art.sh script. + + + + The repository directory structure was updated to improve the + implementation of corporate visual identity concepts. + Specially in the area related to themes. Having both structure + and style in the same file introduced content duplication when + producing art works. Because of this reason, they were + divided out to separate directory structures: the design + models and artistic motifs directory structures. From this + point on, the centos-art.sh is able to + produce themes as result of arbitrary combinations between + design models (structures) and artistic motifs (visual + styles). + + + + In the documentation area, the documents in LaTeX format were + migrated to Texinfo format. In this configuration, each + directory structure in the repository has a documentation + entry associated in a Texinfo structure which can be read, + edited and administered (e.g., renamed, deleted and copied) + interactively through centos-art.sh script. + Additionally, the texi2html program was used to produced + customized XHTML output in conjunction with CSS from &TCW;. + + + diff --git a/Manuals/Tcar-ug/Repository/History/2011.docbook b/Manuals/Tcar-ug/Repository/History/2011.docbook new file mode 100644 index 0000000..867d75e --- /dev/null +++ b/Manuals/Tcar-ug/Repository/History/2011.docbook @@ -0,0 +1,57 @@ + + + 2011's + + + Around 2011, the centos-art.sh script was + redesigned to start translating XML-based files (e.g., SVG and + Docbook files) through xml2po program and + shell scripts (e.g., Bash scripts) through GNU gettext tools. + This configuration provided a stronger localization interface + for graphic designers, translators and programmers. The SED + replacement files are no longer used to handle localization. + + + + The render, help and + locale functionalities were consolidated + as the most frequent tasks performed inside the repository. + Additionally, the prepare and tuneup functionalities are also + maintained as useful tasks. + + + + In the documentation area, support for producing localized + transformations of DocBook XML DTD instances was added through + the render and locale functionalities. + The render functionality uses the + xsltproc command-line XSLT parser in + conjunction with the styles provided by the + docbook-style-xsl package, both of them + included inside The CentOS Distribution. The locale + functionality creates the localized portable object + (PO) the render + functionality needs to produce localized transformations of + DocBook XML DTD instances. + + + + To build DocBook documentation, it was considered the idea of + using concepts behind repository directory structure as base, + not the opposite (as I've been doing with Texinfo backend, so + far). + + + + Producing documentation through DocBook XML as default + documentation backend consolidates render + and locale even more. In this + configuration, once the DocBook files are written, you use + locale functionality to localize the + DocBook files in your prefered language and later, using + render functionality, you produce the + XTHML and PDF outputs as specified in a XSLT or DSL + customization layer. + + + diff --git a/Manuals/Tcar-ug/Repository/Workstation.docbook b/Manuals/Tcar-ug/Repository/Workstation.docbook new file mode 100644 index 0000000..66b07de --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Workstation.docbook @@ -0,0 +1,9 @@ + + + Preparing Your Workstation + + &repo-ws-overview; + &repo-ws-install; + &repo-ws-config; + + diff --git a/Manuals/Tcar-ug/Repository/Workstation/config.docbook b/Manuals/Tcar-ug/Repository/Workstation/config.docbook new file mode 100644 index 0000000..dd07957 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Workstation/config.docbook @@ -0,0 +1,396 @@ + + + Configuring Your Workstation + + + Once your worstation is installed, it is time for you to + configure it. At this point you create a user for everyday's + work, configure third party repositories, fix environment + variables to fit your personal needs, download the working + copy of &TCAR; and prepare it for start using it. + + + + + Workplace + + + Once you've installed the workstation and it is up and + running, you need to create the user name you'll use for your + everyday's work. In this task you need to use the commands + useradd and passwd to + create the user name and set a password for it, respectively. + These commands require administrative privileges to be + executed, so you need to login as root + superuser for doing so. + + + + + Do not use the root username for your + everyday's work inside your working copy of &TCAR;. This is + dangerous and might provoke unreversable damages on your + workstation. + + + + + When user names are created inside the workstation, it doesn't + create only a user identifier for you to login, but a place + for you to store your information, as well. This place is + known as your home directory and is unique for each user + inside the workstation. At the moment, we face the following + design problems related to handling absolute paths inside the + working copies of &TCAR;: + + + + + Case 1: Different home directories + + + Assuming you store your working copy under /home/john/artwork/ and I store + mine under /home/al/artwork/, we'll end up + refering the same files inside our working copies through + different absolute paths. This generates a contradiction when + files, holding path information inside, are committed up to + the central repository. The contradiction comes from the + question: which is the correct absolute path to use inside + such files, yours or mine? — No one of them is, of + course. + + + + + + Case 2: One unique home directory + + + Another case would be that you and I ourselves use one unique + home directory (e.g., /home/centos/artwork/) to store + the working copy of &TCAR; in our own workstations, but + configure the subversion client to use different user names to + commit changes up from the working copy to the central + repository. This configuration might be not so good for + situations where you and I have to share the same workstation. + In such case, it would be required that we both share the + password information of the same system user (the + centos user in our example) which, in + addition, gives access to that user's subversion client + configuration and this way provokes the whole sense of using + different subversion credentials for committing changes to be + lost. + + + + + + Case 3: Different home directories through dynamic expansion + + + Most of the absolute paths we use inside the working copy are + made of two parts, one dynamic and one fixed. The dynamic part + is the home directory of the current user and its value can be + retrived from the $HOME environment variable. + The fixed part of the path is the one we set inside the + repositroy structure itself as organization matter. What we + need here is to find a way to expand variables inside files + that don't support variable expansion. So far we've been + doing this through creation template instances which are + temporal files with translation markers expanded inside. This + work rather fine with template files that are one-time-pass + (e.g., when we produce produce PNG files from SVG files and + XTHML from DocBook files), but the same is not true for + absolute paths inside files that are used as in their + permanent state inside the repository (e.g., CSS files and + other files similar in purpose). + + + + + + + From the three cases discussed above, the second one (i.e., + One unique home directory) seems to be the best candidate. It + limits us from using more than one working copy in the same + workstation, but gives us the chance of standardizing the use + of absolute paths inside all the working copies of &TCAR;. + Using absolute paths is very convenient because it is possible + to reuse information from different locations inside the + working copy, something that would be almost imposible to + maintain if relative paths were used instead. Thus, lets + assume the second case of handling home directories as default + solution to relatively solve the problem of where to store + working copies of &TCAR; until a better one shows itself up. + + + + The action of providing working copies of &TCAR; that permit + to reuse files inside them unifies the way content is produced + inside the working copy and provides a convenction for people + working on different areas to get attached to in order to + syncronize their works and still keep doing it decentralized + one another. + + + + + + Environment Variables + + + Once you've created the centos user name + for your everyday's work and you had done login with it, 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 personal + profile (i.e., ~/.bash_profile) and set the + redefinition there. Notice that you may need to logout and + then do login again in order for the new variable values to + take effect. + + + + + Default text editor + + + The default text editor information is controlled by the + EDITOR environment variable. The + centos-art.sh script uses the default text + editor to edit subversion pre-commit messages, translation + files, documentation files, script files, and similar + text-based files. + + + + If EDITOR environment variable is not set, + centos-art.sh script uses /usr/bin/vim as default text + editor. Otherwise, the following values are recognized by + centos-art.sh script: + + + + + /usr/bin/vim + + + + + + /usr/bin/emacs + + + + + + /usr/bin/nano + + + + + + + + If no one of these values is set in the EDITOR + environment variable, the centos-art.sh + script uses /usr/bin/vim text editor, the one + installed by default in &TCD;. + + + + + + Default locale information + + + The default locale information is controlled by the + LANG environment variable. This variable is + initially set in the installation process of &TCD;, + specifically in the Language step. + Generally, there is no need to customize this variable in your + personal profile. If you need to change the value of this + environment variable do it through the login screen of GNOME + Desktop Environment or the + system-config-language command. + + + + The centos-art.sh script uses the + LANG environment variable to determine what + language to use for printing output messages from the script + itself, as well as the portable objects locations that need to + be updated or edited when you localize directory structures + inside the working copy of &TCAR;. + + + + + + Default time zone representation + + + The time zone representation is a time correction applied to + the system time (stored in the BIOS clock) based on your + country location. This correction is specially useful to + distributed computers around the world that work together and + need to be syncronized in time to know when things happened. + + + &TCAR; 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 + they all set their system clocks to use the same time + information (e.g., through UTC (Coordinated Universal Time)) + and set the time correction for their specific countries in + the operating system. Otherwise, it would be difficult to + know when something exactly happened. + + + Generally, setting the time information is a straight-forward + task and configuration tools provided by &TCD; 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 &TCD; then, + you need to customize the TZ environment + variable in your personal profile to correct the time + information by yourself. The format of TZ + environment variable is described in tzset(3) + manual page. + + + + + + + + Administrative Tasks + + + Sometimes it is necessary that you perform administrative + tasks inside the workstation the working copy of &TCAR; is + stored in. These tasks might demand you to type many commands + (e.g., for configuring a third party repository) or just a + one-line command (e.g., for installing a new package). In + both cases this kind of tasks require permissions that your + user for everyday's work must not have under no mean. + + + + To perform administrative tasks in your workstation, you need + to login as root or configure the + sudo program to temporarily granting the + permissions your regular user needs to perform the + administrative tasks. The configuration of + sudo program is at + /etc/sudoers file and you need to add the + centos user to the list of privileged + user as described in the section below: + + + +## Next comes the main part: which users can run what software on +## which machines (the sudoers file can be shared between multiple +## systems). +## Syntax: +## +## user MACHINE=COMMANDS +## +## The COMMANDS section may have other options added to it. +## +## Allow root to run any commands anywhere +root ALL=(ALL) ALL +centos ALL=(ALL) ALL + + + + This configuration is required in order for automation scripts + to realize administrative tasks that otherwise you would need + to type one by one. It is worth to mention that all these + tasks are organized in the prepare + functionality of the centos-art.sh script + in the sake of reducing work and standardize the procedure of + performing them. It is also worth to mention that, the + centos-art.sh script is available for you + to run, study, improve and share your changes as described in + . + + + + + + Working Copy + + + Once you've installed and configured the workstation, it is + ready to receive the working copy of &TCAR;. In this step, you + use Subversion's client to communicate the source repository + of &TCAR; and download all the files that make a working copy + of it. + + + + To download the working copy of &TCAR; you need to login as + your everyday's work user (i.e., the + centos user) and use the Subversion + client installed in your workstation to bring all the files + you need to work with from the source repository down to your + workstation, just as the following command describes: + + + svn co https://projects.centos.org/svn/artwork ~/ + + + This command will create your working copy of &TCAR; in your + workstation, specifically in the /home/centos/artwork directory. + + + + + If the Subversion's client wasn't installed by default, you + need to install it using the following command: + + sudo yum install subversion + + + + + Once your working copy of &TCAR; has been downloaded, you + should notice that there is no image files, nor documentation, + or localized content inside it. This is because all the files + provided in the working copy are source files (e.g., the files + needed to produce other files) and it is up to you the action + of render them to produce the final files (e.g., images and + documentation) used to implement &TCPCVI;. + + + + Another consideration to be aware of at this point, is the + need of verifying the software installed in the workstation, + as well as the creation of symbolic links to connect the + content produced inside the working copy to applications + outside it (e.g., to make available patterns, brushes, and + palettes produced inside the working copy in GIMP, the + application used to manipulate images). + + + + This final preparation stuff is automated by the + prepare functionality of the + centos-art.sh script, as described in . Execute it right now, + to be sure your workstation and your working copy are both + ready to be used. + + + + + diff --git a/Manuals/Tcar-ug/Repository/Workstation/install.docbook b/Manuals/Tcar-ug/Repository/Workstation/install.docbook new file mode 100644 index 0000000..fdb8f4a --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Workstation/install.docbook @@ -0,0 +1,221 @@ + + + Installing Your Workstation + + + In order to have a working copy of &TCAR; in your workstation, + the first step you need to follow is pick up a computer and + install an operating system in it. This computer will be named + the workstation from now on. + + + + At the moment of chosing which operating system to install in + your workstation, consider that &TCAR; is completly built on + &TCD; and realies on it to achieve most automation tasks. At + time of this writing the major release 5 update 5 of &TCD; was + used as platform to support all work line development inside + &TCAR;. To get the best of &TCAR;, it is necessary that you + too, use the same operating system we did to develop it. + + + + To install &TCD; you need to have access to the installation + media somehow (e.g., CDs, DVDs, Pendrives, etc.). If you + don't have the installation media of &TCD;, you need to + download the ISO files related to the installation media you + plan to use (e.g., CD or DVD) and then create the installation + media by yourself. &TCD; ISO files can be downloaded from + &TCM;. + + + + Assuming you downloaded the DVD ISO of &TCD;, you can burn it + using the K3B application and, this + way, you are creating the installation media you are in need + of. Of course, in order to download the ISO files and create + the installation media, you need to have a workstation already + functionality where you can realized such tasks. If this is + the first time for you and see yourself into much troubles + here, talk to the guys in your nearest LUG, or simply send a + mail to &TCML; where you'll surely have the answer you need. + + + + Once you have the installation media on your hands, the + installation process of &TCD; is rather straightforward. To + begin, you put the installation media in your media reader, + boot the computer from it, and follow the installer + intructions till it completes all the steps. That simple. + + + + + Partition Information + + + The partition information you set in your workstation is very + specific to your personal needs and the technical + characteristics of your machine. This information will also + set the bases of all deployment you reach to achieve inside + the workstation. A well partitioned workstation is crucial to + garantee a well distribution of space inside the worstation. + In order to provide an idea of this installation step, I'll + describe the specific partitioning of the machine I use to + develop &TCAR; right now. Remember that your needs might be + differents and so the partition layout you should implement. + + + + The machine of our example is isolated from Internet or any + other network. It has two hard drives of 256GB each, 2GB of + RAM and a 2.80GHz Core 2 Duo processor. The main goal of this + machine is producing &TCAR;. To represent the real production + environment of &TCAR;, this machine was conceived to have two + roles, one as server —to store the source repository of + &TCAR;— and one as client —to store a working copy + of the source repository—. From both hard drives + available, one is used as primary + (/dev/sda) and the other one as secondary + (/dev/sdb) where the secondary is used + only to backup the information produced in the primary by mean + of backup scripts. + + + The partition distribution of this machine implements the + default partinioning schema provided by &TCD; in the primary + hard drive to store partitions needed by the operating system + (e.g., /, /boot and swap partition) where + the working copy is placed in. The second hard drive is an + entire partition mounted in /mnt/backups automatically on + boot which only purpose is to duplicate the information + produced in the workplace. + + + +Filesystem Type Size Mounted on +/dev/mapper/VolGroup00-LogVol00 ext3 239G / +/dev/sda1 ext3 104M /boot +tmpfs tmpfs 1.1G /dev/shm +/dev/sdb ext3 247G /mnt/backups + + + + The detailed steps followed to prepare the partinioning layout + described above are described in the Deployment + Guide provided by + Deployment_Guide-en-US-5.2-11.el5.centos + package. + + + + + + + Packages Selection + + + The packages selection lets you to specify which software does + your workstation will have once it be installed. In this step, + you need to select the following groups of packages: + + + + + Desktop Environments + + + + GNOME Desktop Environment + + + + + KDE (K Desktop Environment) + + + + + + + Applications + + + + Authoring and Publishing + + + + + Editors + + + + + Graphical Internet + + + + + Graphics + + + + + Office/Productivity + + + + + Text-based Internet + + + + + + + Development + + + + Development Libraries + + + + + Development Tools + + + + + GNOME Software Development + + + + + KDE Software Development + + + + + + + + Packages selected in this step provide a base selection of all + the packages you need in order to have a functional working + copy of &TCAR;. The only exception for this, is the + inkscape package and some of its + dependencies which doesn't come with &TCD; and need to be + installed from third party repositroies like EPEL and + RPMForge. The configuration of third party repository is done + later, once the workstation has been installed; just as + described in the Repositories + page. + + + + + diff --git a/Manuals/Tcar-ug/Repository/Workstation/overview.docbook b/Manuals/Tcar-ug/Repository/Workstation/overview.docbook new file mode 100644 index 0000000..b410d20 --- /dev/null +++ b/Manuals/Tcar-ug/Repository/Workstation/overview.docbook @@ -0,0 +1,27 @@ + + + Overview + + + The workstation is the machine you use to store your working + copy of &TCAR;. The working copy is an ordinary directory + tree on your workstation, containing a collection of files + that you can edit however you wish. The working copy is your + own private work area related to &TCAR; where you perform + changes and receive changes from others. + + + + In order to make your workstation completely functional, it is + necessary that you install it and configure it to satisfy the + needs demanded by the working copy of &TCAR; you lately + download in it. + + + + This chapter describes the steps you need to follow in order + to install and configure a workstation for using a working + copy of &TCAR; in all its extention. + + + diff --git a/Manuals/Tcar-ug/Scripts.docbook b/Manuals/Tcar-ug/Scripts.docbook new file mode 100644 index 0000000..3645deb --- /dev/null +++ b/Manuals/Tcar-ug/Scripts.docbook @@ -0,0 +1,12 @@ + + + Automation + + + ... + + + &scripts-bash; + + + diff --git a/Manuals/Tcar-ug/Scripts.ent b/Manuals/Tcar-ug/Scripts.ent new file mode 100644 index 0000000..a0e60e5 --- /dev/null +++ b/Manuals/Tcar-ug/Scripts.ent @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/Manuals/Tcar-ug/Scripts/Bash.docbook b/Manuals/Tcar-ug/Scripts/Bash.docbook new file mode 100644 index 0000000..52df4f4 --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash.docbook @@ -0,0 +1,13 @@ + + + The <command>centos-art.sh</command> script + + &scripts-bash-intro; + &scripts-bash-design; + &scripts-bash-render; + &scripts-bash-locale; + &scripts-bash-help; + &scripts-bash-prepare; + &scripts-bash-tuneup; + + diff --git a/Manuals/Tcar-ug/Scripts/Bash/design.docbook b/Manuals/Tcar-ug/Scripts/Bash/design.docbook new file mode 100644 index 0000000..1521d7d --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/design.docbook @@ -0,0 +1,4 @@ + + The script design + ... + diff --git a/Manuals/Tcar-ug/Scripts/Bash/help.docbook b/Manuals/Tcar-ug/Scripts/Bash/help.docbook new file mode 100644 index 0000000..c40870b --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/help.docbook @@ -0,0 +1,197 @@ + + + <function>help</function> — Standardize Documentation + Tasks + + + The help functionality is the interface + the centos-art.sh script provides to + control frequent documentation tasks (e.g., reading, editing, + update output files, etc.) requied by specific documentation + backends. Documentation backends supported by + help functionality are described in . + + + centos-art help [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process the related documentation entry for. + This paramter can be provided more than once in order to + process more than one directory path in a single command + execution or not provided at all. When this parameter is not + provided, the current directory path where the command was + called from is used instead. + + + + The help functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the action itself had took place over files + in the working copy. + + + + + + + + + The NAME argument in this option specifies + what backend to use when processing documentation. Possible + arguments to this options are: texinfo or + docbook. If this option is not provided, + texinfo is used as default documentation + backend. + + + + + + + + + Go to node pointed by ID argument. When + texinfo backend is used, this arguments refers the node you + want to read documentation for. When docbook backend is used, + this argument refers the section id you want to read + documentation for. + + + + + + + + + Edit documentation entry related to path specified by + DIRECTORY parameter. + + + The DIRECTORY parameter must point to any + directory inside the working copy. When more than one + DIRECTORY are passed as non-option + arguments to the centos-art.sh script + command-line, they are queued for further edition. The + edition itself takes place through your default text editor + (e.g., the one you specified in the EDITOR + environment variable) and the text editor opens one file at + time (i.e., the queue of files to edit is not loaded in the + text editor.). + + + + + + + + + Read documentation entry specified by + DIRECTORY path. This option is used + internally by centos-art.sh script to print + out the reference you can follow to know more about an error + message. + + + + + + + + + Update output files rexporting them from the specified backend + source files. + + + + + + + + + Duplicate documentation entries inside the working copy. + + + When documentation entries are copied, it is required to pass + two non-option parameters in the command-line. The first + non-option parameter is considered the source location and the + second one the target location. Both source location and + target location must point to a directory under the working + copy. + + + + + + + + + Delete documentation entries specified by + DIRECTORY inside the working copy. It is + possible to delete more than one documentation entry by + specifying more DIRECTORY parameters in the + command-line. + + + + + + + + + Rename documentation entries inside the working copy. + + + When documentation entries are renamed, it is required to pass + only two non-option parameters to the command-line. The first + non-option parameter is considered the source location and the + second one the target location. Both source location and + target location must point to a directory under the working + copy. + + + + + + + + When documentation entries are removed (e.g., through + or + options), the help functionality takes + care of updating nodes, menus and cross references related to + documentation entries in order to keep the manual structure in + a consistent state. + + + diff --git a/Manuals/Tcar-ug/Scripts/Bash/intro.docbook b/Manuals/Tcar-ug/Scripts/Bash/intro.docbook new file mode 100644 index 0000000..00ee91e --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/intro.docbook @@ -0,0 +1,4 @@ + + Introduction + ... + diff --git a/Manuals/Tcar-ug/Scripts/Bash/locale.docbook b/Manuals/Tcar-ug/Scripts/Bash/locale.docbook new file mode 100644 index 0000000..676a5e4 --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/locale.docbook @@ -0,0 +1,230 @@ + + + <function>locale</function> — Standardize Localization Tasks + + + The locale functionality is the + interface the centos-art.sh script provides + to standardize localization tasks inside the working copy. + + + centos-art locale [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + The locale functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Reduce the list of files to process inside + DIRECTORY using REGEX as + pattern. You can use this option to control the amount of + files you want to locale. The deeper you go into the + directory structure the more specific you'll be about the + files you want to locale. When you cannot go deeper into the + directory structure through DIRECTORY + specification, use this option to reduce the list of files + therein. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the actions themselves had took place over + files in the working copy. + + + + + + + + + This option updates both POT and PO files related to source + files. Use this option everytime you change translatable + strings inside the source files. + + + + + + + + + This option edits the portable object related to source files. + When you provide this option, your default text editor is used + to open the portable object you, as translator, need to change + in order to keep source file messages consistent with their + localized versions. In the very specific case of shell + scripts localization, this option takes care of updating the + machine object (MO) file the shell script requires to + displayed translation messages correctly when it is executed. + + + + + + + + + This option unlocalizes source files. When you provide this + option, the localization directory related to source files is + removed from the working copy in conjunction with all portable + objects and machine objects inside it. + + + + + + + + + This option suppresses machine objects creation when shell + scripts are localized. + + + + + + + + The localization process is very tied to the source files we + want to provide localized messages for. Inside the working + copy of &TCAR; it is possible to localize XML-based files + (e.g., SVG and Docbook) and programs written in most popular + programming languages (e.g., C, C++, C#, Shell Scripts, + Python, Java, GNU awk, PHP, etc.). + + + + The localization process initiates by retriving translatable + strings from source files. When source files are XML-based + files, the only requisite to retrive translatable strings + correctly is that they be well-formed. Beyond that, the + xml2po command takes care of everything + else. When source files are Shell script files, it is + necessary that you previously define what strings inside the + script are considered as translatable strings in order for + xgettext command to retrive them correctly. + To define translatable strings inside shell scripts, you need + to use either gettext, + ngettext, eval_gettext + or eval_ngettext command as it is following + described: + + + + + + Use the gettext command to display the + native language translation of a textual message. + + MESSAGE="`gettext "There is no entry to create."`" + + + + + Use the ngettext command to display the + native language translation of a textual message whose + grammatical form depends on a number. + + MESSAGE="`ngettext "The following entry will be created" \ + "The following entries will be created" \ + $COUNT`:" + + + + + Use the eval_gettext command to display the + native language translation of a textual message, performing + dollar-substitution on the result. Note that only shell + variables mentioned in the message will be dollar-substituted + in the result. + + MESSAGE="`eval_gettext "The location \\\"\\\$LOCATION\\\" is not valid."`" + + + + + Use the eval_ngettext command to display + the native language translation of a textual message whose + grammatical form depends on a number, performing + dollar-substitution on the result. Note that only shell + variables mentioned in messages will be dollar-substituted in + the result. + + MESSAGE="`eval_ngettext "The following entry will be created in \\\$LOCATION" \ + "The following entries will be created in \\\$LOCATION" \ + $COUNT`:" + + + + + Once translatable strings are retrived, a portable object + template (POT) file is created for storing them. Later, the + POT file is used to create a portable object (PO). The + portable object is the place where localization itself takes + place, it is the file translators edit to localize messages. + When translatable strings change inside source files, it is + necessary that you update these POT and PO files in order to + keep consistency between source file messages and their + localized versions. + + + + Inside source files, translatable strings are always written + in English language. In order to localize translatable strings + from English language to another language, you need to be sure + the LANG environment variable has been already + set to the locale code you want to localize message for or see + them printed out before running the + locale functionality of + centos-art.sh script. Localizing English + language to itself is not supported. + + + + To have a list of all locale codes you can have localized + messages for, run the following command: locale -a | + less. + + + diff --git a/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook b/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook new file mode 100644 index 0000000..5748e53 --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/prepare.docbook @@ -0,0 +1,173 @@ + + + <function>prepare</function> — Standardize Configuration Tasks + + + The prepare functionality is the + interface the centos-art.sh script provides + to standardize the final configuration stuff your workstation + needs, once the working copy of &TCAR; has been downloaded + inside it already. + + + + Assuming this is the very first time you run the + centos-art.sh script, you'll find that + it isn't found in your workstation. This is correct because + you haven't created the symbolic link that make it available + in the execution path, yet. In order to make the + centos-art.sh script available in the + execution path of your workstation, you need to run it using + its absolute path first: + + + ~/artwork/trunk/Scripts/centos-art.sh prepare [OPTIONS] + + + Later, once the centos-art.sh script is + available in the execution path of your system, there is no + need for you to use the absolute path again. From this time + on, you can use the centos-art command-line + interface directly, as the following example describes: + + + centos-art prepare [OPTIONS] + + + The prepare functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option whould have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + This option verifies packeges required by + centos-art.sh script. installs or updates + required packages. When required packages aren't installed, + this option uses sudo yum install + command to perform the installation task. When required + packages are installed, this option uses sudo yum + update to update them, if there is any related + actualization to be applied on. In both cases, it is required + that you configure the sudo command first, + as described in . + + + + + + + + + This option maintains the file relation between your working + copy and configuration files inside your workstation through + symbolic links. When you provide this option, the + centos-art.sh puts itself into your + system's execution path through its command line interface + centos-art and makes common brushes, + patterns, palettes and fonts inside the working copy, + available to applications like GIMP in order for you to make + use of them without loosing version control over them. + + + + This option removes all common fonts, brushes, patterns, and + palettes currently installed in your home directory, in order + to create a fresh installation of them all again, using the + working copy as reference. + + + + + + + + + + This option initializes image files inside the working copy. + When you provide this option, the + centos-art.sh scripts renders image files + from all design models available in the working copy. This + step is required in order to satisfy file dependencies among + different components inside the working copy. + + + + + + + + + This option initializes documentation files inside the working + copy. When you provide this option, the + centos-art.sh script renders all + documentation manuals from their related source files to + different output formats, so you can read them nicely. + + + + + + + + + Print the name and value of some of the environment variables + used by centos-art.sh scripts as described + in . + + + + + + + When no option is provided to prepare + functionality, the centos-art.sh script + uses the , + , and + options as default behaviour. + Otherwise, if you provide any option, the + centos-art.sh script avoids its default + behaviour and executes the prepare + functionality as specified by the options you provides. + + + + Notice that it is possible for you to execute the + prepare functionality as much times as + you need to. This is specially useful when you need to keep + syncronized the relation between content produced inside your + working copy and the applications you use outside it. For + example, considering you've added new brushes to or removed + old brushes from your working copy of &TCAR;, the link + information related to those files need to be updated in the + ~/.gimp-2.2/brushes + 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. + + + diff --git a/Manuals/Tcar-ug/Scripts/Bash/render.docbook b/Manuals/Tcar-ug/Scripts/Bash/render.docbook new file mode 100644 index 0000000..fe12217 --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/render.docbook @@ -0,0 +1,240 @@ + + + <function>render</function> — Standardize Content Production + + + The render functionality is the interface + the centos-art.sh script provides to + standardize the content production tasks inside the working + copy. + + + centos-art render [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + The render functionality accepts the + following options: + + + + + + + + This option supresses all output messages except error + messages. When this option is passed, all confirmation + requests are supressed and a possitive answer is assumed for + them, just as if the option + would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + This option reduces the list of files to process inside + DIRECTORY using REGEX as + pattern. You can use this option to control the amount of + files you want to render. The deeper you go into the + directory structure the more specific you'll be about the + files you want to render. When you cannot go deeper into the + directory structure through DIRECTORY + specification, use this option to reduce the list of files + therein. + + + + + + + + + This option supresses all commit and update actions realized + over files, before and after the action itself had took place + over files in the working copy. + + + + + + + + + This option expands the =\RELEASE=, + =\MAJOR_RELEASE=, and + =\MINOR_RELEASE= translation makers based on + NUMBER value. Notice that translation + markers here were escaped using a backslash (\) + in order to prevent their expansion. Use this option when you + need to produce release-specific contents, but no release + information can be retrived from the directory path you are + currently rendering. + + + + + + + + + This option expands the =\ARCHITECTURE=, + translation makers based on ARHC value. + Notice that translation markers here were escaped using a + backslash (\) in order to prevent their + expansion. Use this option when you need to produce + architecture-sepecific contents but no architecture + information can be retrived from the directory path you are + currently rendering. + + + + + + + + + This option specifies the name of theme model you want to use + when producing theme artistic motifs. By default, if this + option is not provided, the Default theme + model is used as reference to produce theme artistic motifs. + To know what values does the NAME variable + can have, run ls + ~/artwork/trunk/Identity/Models/Themes command. + + + + + + + + + This option lets you apply a command as post-rendition action. + In this case, the COMMAND represents the + command-line you want to execute in order to perform in-place + modifications to base-rendition output. + + + + + + + + + This option lets you apply a command as last-rendition action. + In this case, the COMMAND argument + represents the command string you want to execute in order to + perform in-place modifications to base-rendition, + post-rendition and directory-specific rendition outputs. + + + + + + + Inside the working copy of &TCAR;, rendition tasks take place + inside renderable directories. The rendition itself is + performed through a serie of rendition flows named + base-rendition, post-rendition, last-rendition and + directory-specific rendition. + + + + Renderable Directories + + Renderable directories are convenctional locations inside the + working copy where you can find source files, output files and + auxiliar files. Source files are used to produce output files. + Auxiliar files are used to modify the way output files are + produced from source files (e.g., to produce localized + output). Auxiliar files are optionals. + + + Renderable directories are made of several directories but + only the output dirctory path is passed to + render functionality as + DIRECTORY parameter in the command-line. + The directories related to source and auxiliar files are + automatically constructed based on a directory organization + convenction. This way, the render + functionality collects all the information it needs to work + with. + + + Inside the working copy, renderable directories are divided in + two categories in a way differences between them can be + preserved. These categories are named direct + production and theme production. These + categories provide the file organization convenction the + render functionality needs, to produce + content based on rendition flows. + + + + Direct Production + + ... + + + + + Theme Production + + ... + + + + + + + Rendition Flows + + + Base-Rendition + + ... + + + + + Post-Rendition + + ... + + + + + Last-Rendition + + ... + + + + + Directory-Specific Rendition + + ... + + + + + diff --git a/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook b/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook new file mode 100644 index 0000000..aefc6cf --- /dev/null +++ b/Manuals/Tcar-ug/Scripts/Bash/tuneup.docbook @@ -0,0 +1,240 @@ + + + <function>tuneup</function> — Standardize File Maintainance + + + The tuneup functionality is the + interface the centos-art.sh script provides + to standardize the maintainance tasks related to individual + files inside the working copy. + + + centos-art tuneup [OPTIONS] [DIRECTORY] + + + The DIRECTORY parameter specifies the + directory path, inside the working copy of &TCAR;, where the + files you want to process are stored in. This paramter can be + provided more than once in order to process more than one + directory path in a single command execution. When this + parameter is not provided, the current directory path where + the command was called from is used instead. + + + The tuneup functionality accepts the + following options: + + + + + + + + Supress all output messages except error messages. When this + option is passed, all confirmation requests are supressed and + a possitive answer is assumed for them, just as if the + option would have been provided. + + + + + + + + + Assume yes to all confirmation requests. + + + + + + + + + Reduce the list of files to process inside + path/to/dir using + REGEX as pattern. You can use this + option to control the amount of files you want to tuneup. The + deeper you go into the directory structure the more specific + you'll be about the files you want to tuneup. When you cannot + go deeper into the directory structure through + path/to/dir specification, use this + option to reduce the list of files therein. + + + + + + + + + Supress all commit and update actions realized over files, + before and after the action itself had took place over files + in the working copy. + + + + + + + Tasks related to file maintainance are repetitive. You might + find yourself doing them time after time inside the working + copy of &TCAR;. 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. + + + + When you execute the tuneup functionality of centos-art.sh + script, it looks for all files that match the supported + extensions (e.g., .sh, + .svg and .xhtml) in the directory + specified, builds a list with them and applies the + maintainance tasks using file extensions as reference. + + + + When shell scripts are found, the tuneup + functionality of centos-art.sh script reads a comment template + from + trunk/Scripts/Functions/Tuneup/Shell/Config/topcomment.sed + and applies it to all 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. + + + In order for the shell script top comment template to be + applied correctly, the shell scripts you write must have the + structure described in . + + + + Shell script top-comment template. + + Shell script top-comment template. + + + + 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| } + + + + + + + + The tuneup functionality of + centos-art.sh script replaces all lines + between the Copyright line (e.g., line 5) + and the first separator line (e.g., line 9), inclusively. + Everything else will remain immutable in the file. + + + + When scalable vector graphics are found, the tuneup + functionality reads a SVG metadata template from + trunk/Scripts/Functions/Tuneup/Svg/Config/metadata.sed + 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 + the file, too. + + + The metadata applied by the SVG metadata template is created + dynamicaly combining the absolute path of the file being + currently modified, the workstation's date information, the + centos-art.sh script copyright holder + (e.g., =COPYRIGHT_HOLDER=) as reference and the Creative + Common Distribution-ShareAlike 3.0 License as default license + to release SVG files. + + + The elimination of unused definitions inside SVG files takes + place through Inkscape's + option, as described in its man page (e.g., man + inkscape). + + + + When HTML files are found, the tuneup + functionality of centos-art.sh script + transforms web page headings to make them accessible through a + table of contents. The table of contents is expanded in + place, wherever the <div + class="toc"></div> piece of code be in the + file. Once the table of contents has been expanded, there is + no need to put anything else in the page. You can run the + tuneup functionality everytime you update + the heading information so as to update the table of contents, + too. + + + In order for this functionality to build the table of contents + from headings, you need to put headings in just one line. The + headin level can vary from h1 to h6 + with attribute definitions accepted. Closing tag must be + present and also match the openning tag. Inside the heading + definition an anchor definition must be present with attribute + definitions accepted. The value of name + and href attributes from the anchor + element are set dynamically using the md5sum output of + combining the page location, the head- + string and the heading content itself. If any of the + components used to build the heading reference changes, you + need to run the the tuneup functionality of + centos-art.sh script in order for the + anchor elements to use the correct information. + + + For example, the headings shown in produces the table of + contents shown in . + + + + HTML heading definition. + + HTML heading definition. + + + +<h1 class="title"><a name="head-8a23b56a28dfa7277d176576f217054a">Forms</a></h1> +<h2 class="title"><a name="head-629f38bc607f2a270177106b450aeae3">Elements</a></h2> +<h2 class="title"><a name="head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a></h2> + + + + + + + + HTML table of contents definition. + + HTML table of contents definition. + + + +<div class="toc"> <p>Table of contents</p> <dl><dt><a href="#head-8a23b56a28dfa7277d176576f217054a">Forms</a> <dl><dt><a href="#head-629f38bc607f2a270177106b450aeae3">Elements</a> </dt><dt><a href="#head-f49cae1d73592c984bbb0bffb1d5699a">Recommendations</a> </dt></dl> </dt></dl> </div> + + + + + + + diff --git a/Manuals/Tcar-ug/tcar-ug.docbook b/Manuals/Tcar-ug/tcar-ug.docbook new file mode 100644 index 0000000..32a4ba3 --- /dev/null +++ b/Manuals/Tcar-ug/tcar-ug.docbook @@ -0,0 +1,96 @@ + + + + + + + + + + +%Commons.ent; +%Introduction.ent; +%Repository.ent; +%Identity.ent; +%Locales.ent; +%Manuals.ent; +%Scripts.ent; +%Licenses.ent; +]> + + + + + The CentOS Artwork Repository + User's Guide + + + + + + Alain + Reguera Delgado + + + + + + 2009 + 2010 + 2011 + &TCAS; + + + + + 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 . + + + + + + 5.5-1 + Fri Jun 24, 2011 + + + ... + + + + + + + + This manuals documents relevant information regarding + the deployment, organization, and administration of + &TCAR; + + + + + + + &intro; + + + &repo; + &identity; + &locales; + &manuals; + &scripts; + &licenses; + +