diff --git a/Manual/Directories/trunk/Identity.texi b/Manual/Directories/trunk/Identity.texi index 3d1f0a5..315f560 100644 --- a/Manual/Directories/trunk/Identity.texi +++ b/Manual/Directories/trunk/Identity.texi @@ -18,115 +18,108 @@ recognizability, reputation, structure and identification to The CentOS Project organization by means of @emph{Corporate Design}, @emph{Corporate Communication}, and @emph{Corporate Behaviour}. -@subsubsection Corporate Design - -The CentOS Project Corporate Design is applied to visual -manifestations of The CentOS Project organization. As visual -manifestation we understand any medium, digital or printed, used by -The CentOS Project to communicate its existence (e.g., @emph{The -CentOS Distribution}, @emph{The CentOS Web} and @emph{The CentOS -Stationery}) and is very tied to @emph{The CentOS Project Corporate -Structure} which in turn is based on @emph{The CentOS Project Mission} -and @emph{The CentOS Project Release Schema}. - -In The CentOS Project Corporate Design most of the work is about -graphic design, everything that people can perceive through the visual -sence (i.e., the human eye), it is about effective visual -communication of messages. - -The CentOS Project Corporate Design is organized in the following work -lines: - -@table @strong - -@item Brushes - -This work line provides brushes for GIMP. When you prepare the -repository, brushes in this location are made available immediatly for -you to use in the ``Brushes'' panel of GIMP. - -@xref{Directories trunk Identity Brushes}, for more -information. - -@item Fonts - -This work line provides the typography information required by all -different visual manifestations of The CentOS Project. - -@xref{Directories trunk Identity Fonts}, for more information. +@float Figure, The CentOS Project Corporate Identity +@image{trunk/Identity/Images/Manual/Corporate/monolithic,450pt,,,jpg} +@caption{The CentOS Project - Corporate Identity.} +@end float -@item Images - -This work line provides output location for images that don't need to -use background images (e.g., brands, icons, illustrations, etc.). +@subsubsection Corporate Mission -@xref{Directories trunk Identity Images}, for more information. +The CentOS Project exists to provide The CentOS Distribution. +Additionally, The CentOS Project provides The CentOS Web and The +CentOS Showroom to support and promote the existence of The CentOS +Distribution, respectively. -@item Models - -This work line provides design models for images that don't need to -use background images (e.g., brands, icons, illustrations, etc.). - -@xref{Directories trunk Identity Models}, for more information. - -@item Palettes - -This work line provides palettes of colors for GIMP and Inkscape. When -you prepare the repository, palettes of colors in this location are -made available immediatly for you to use in the ``Palettes'' panel of -GIMP. - -@xref{Directories trunk Identity Palettes}, for more information. - -@item Patterns - -This work line provides patterns for GIMP. When you prepare the -repository, patterns in this location are made available immediatly -for you to use in the ``Patterns'' panel of GIMP. - -@xref{Directories trunk Identity Patterns}, for more information. - -@item Themes - -This work line provides theme design models and theme artistic motifs -for The CentOS Project. If you are interesting in create a brand new -visual style for The CentOS Project this is the place for you. - -@xref{Directories trunk Identity Themes}, for more information. - -@item Web environment +@subsubsection Corporate Design -This work line provides the HTML/XHTML and CSS standard definitions -used by The CentOS Websites. If you are a web developer and plan to -improve The CentOS Websites, then the files in this location may -result very useful to you. +The CentOS Project Corporate Design is focused on the effective +communication of visual messages through graphic design. Visual +messages can be considered any information that people can perceive +through the visual sence (i.e., the human eye). The CentOS Project +Corporate Design is very tied to @emph{The CentOS Project Corporate +Structure} which, in turn, is based on @emph{The CentOS Project +Corporate Mission} and @emph{The CentOS Project Release Schema}. + +The CentOS Project Corporate Design is applied to The CentOS Project +Visual Manifestations. A visual manifestation is any medium, digital +or printed, used by The CentOS Project to communicate its existence +(e.g., @emph{The CentOS Distribution}, @emph{The CentOS Web} and +@emph{The CentOS Showroom}). + +@table @strong +@item The CentOS Distribution + +The CentOS Distribution is an Enterprise-class Linux Distribution +derived from sources freely provided to the public by a prominent +North American Enterprise Linux vendor. The CentOS Distribution +conforms fully with the upstream vendors redistribution policy and +aims to be 100% binary compatible. (The CentOS Project mainly changes +packages to remove upstream vendor branding and artwork.) + +The CentOS Distribution is developed by a small but growing team of +core developers. In turn the core developers are supported by an +active user community including system administrators, network +administrators, enterprise users, managers, core Linux contributors +and Linux enthusiasts from around the world. + +@item The CentOS Web + +The CentOS Web exists to support The CentOS Distribution. + +The CentOS Web covers web applications which let The CentOS Project to +manifest its existence on the Internet. Through these web applications +The CentOS Project provides Corporate Communication. These web +applications are free software and come from different providers which +distribute their work with predefined visual styles. Frequently, +these predefined visual styles have no visual relation among +themselves and introduce some visual contraditions when they all are +put together. These visual contraditions need to be removed in order +to comply with The CentOS Project Corporate Structure guidelines. + +@item The CentOS Showroom + +The CentOS Showroom exists to promote The CentOS Distribution. + +The CentOS Showroom covers industrial production of objects branded by +The CentOS Project (e.g., clothes, stationery and installation media). +These branded objects are for distribution on social events and/or +shops. They provide a way of both promotion and monetary incomming to +aliviate The CentOS Project expenses (e.g., electrical power, hosting, +servers, full-time-developers, etc.), in a similar way as donations +do. -@xref{Directories trunk Identity Webenv}, for more information. @end table +The visual manifestation described above seems to be enough for what +The CentOS Project is, by now. However, other visual manifestations +could be added in the future, if needed, to cover different areas like +building, offices, road transportation and whaterver visual +manifestation The CentOS Project thouches to show its existence. + @subsubsection Corporate Communication The CentOS Project Corporate Communication is based on @emph{Community -Communication}. In that sake, the following media are available: +Communication} and takes place through the following avenues: @itemize @item The CentOS Chat (@code{#centos}, @code{#centos-social}, @code{#centos-devel} on irc.freenode.net) @item The CentOS Mailing Lists (@url{http://lists.centos.org/}). @item The CentOS Forums (@url{http://forums.centos.org/}). +@item The CentOS Wiki (@url{http://wiki.centos.org/}). @end itemize @subsubsection Corporate Behaviour The CentOS Project Corporate Behaviour is based on @emph{Community -Behaviour}. +Behaviour} which take place on @emph{Corporate Communication}. @subsubsection Corporate Structure The CentOS Project Corporate Structure is based on a @emph{Monolithic -Corporate Visual Identity Structure}. In this structure, one unique -name and one unique visual style is used in all visual manifestation -of The CentOS Project. +Corporate Visual Identity Structure}. In this configuration, one +unique name and one unique visual style is used in all visual +manifestation of The CentOS Project. In a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, @@ -138,23 +131,23 @@ Project}. Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for -each major releasae of CentOS Distribution. This structure isn't +each major release of The CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of -it. To apply it correctly, we need to know what The CentOS Project and -which are the visual manifestations it is made of. +it. To apply it correctly, we need to know what The CentOS Project is +made of. The CentOS Project, as organization, is mainly made of (but not -limited to) three visual manifestions: Distribution, Web and -Stationery. Inside the Distribution visual manifestations, The CentOS -Project maintains near to four different major releases of CentOS -Distribution, parallely in time. Inside Web and Stationery visual -manifestations content is visually produced to fit non-release-specifc -content but treat it as a visual manifestation properly. For example, -consider that there is no a complete web site for each major release -of CentOS distribution, but one web site to cover the information -related to all release-specific visual manifestations like CentOS -distribution. +limited to) three visual manifestions: Distribution, Web and Showroom. +Inside the Distribution visual manifestations, The CentOS Project +maintains near to four different major releases of CentOS +Distribution, parallely in time. However, inside The CentOS Web +visual manifestations, the content is produced for no specific release +information (e.g., there is no a complete web site for each major +release of The CentOS Distribution individually, but one web site to +cover them all). Likewise, the content produced in The CentOS Showroom +is created for no release-specific at all, but for The CentOS Project +in general. In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS @@ -162,7 +155,7 @@ Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., -web sites and stationery)? +The CentOS Web and The CentOS Showroom)? Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same @@ -170,10 +163,10 @@ 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 The CentOS Project has proven stability and consistency -through time and that, certainly, didn't come through swinging magical -wangs or something but hardly working out to automate tasks and -providing maintainance through time. Said that, we consider that The -CentOS Project Visual Structure should be consequent with such +through time and, that, certainly, didn't come through swinging +magical wands or something but hardly working out to automate tasks +and providing maintainance through time. Said that, we consider that +The CentOS Project Corporate Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. @@ -187,8 +180,8 @@ visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new -release of CentOS Distribution to all other visual manifestations The -CentOS Project is made of, in a way The CentOS Project could be +release of The CentOS Distribution to all other visual manifestations +The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS @@ -196,82 +189,79 @@ Artwork Repository. @subsection Usage -The @file{trunk/Identity/} directory structure is organized in -@emph{renderable} and @emph{non-renderable} directories. Generally, -renderable directories are stored under @file{trunk/Identity/Images} -and @file{trunk/Identity/Themes/Motifs} directories. These directories -contain the image files used to implemente The CentOS Project -Corporate Identity. - -@subsubsection Rendition - -In order to produce content inside rendereble directories, you can use -the following command: - -@verbatim -centos-art render trunk/Identity/Path/To/Dir -@end verbatim - -@quotation -@strong{Warning} If the @command{centos-art} command-line -is not found in your workstation, it is probably because you haven't -prepared your workstation for using The CentOS Artwork Repository yet. -@xref{Directories trunk Scripts Functions Prepare}, for more -information. -@end quotation - -This command takes one design template (a.k.a., design model) from the -template directory and creates an instance of it in order to apply -translation messages, if any. Later, using the translated design -template instance, the command renders the final content based on -whether the design template instance is a SVG file or XHTML. If the -design template instace is a SVG file, the final content produced is a -PNG image. On the other hand, if the design template instance is a -XHTML file, the final content produced is a XHTML file. The rendition -flow described so far is known as the @command{centos-art.sh} script -@emph{base-rendition} flow. - -Besides the base-rendition flow, the @command{centos-art} provides -@emph{post-rendition} and @emph{last-rendition} flows. The -post-rendition flow is applied to files produced as result of -base-rendition flow under the same directory structure. For example, -you can use post-rendition action to convert the PNG base output into -different outputs formats (e.g., JPG, PDF, etc.) before passing to -process the next file in the same directory structure. The -last-rendition flow, on the other hand, is applied to all files -produced as result of both base-rendition and post-rendition flows in -the same directory structure, just before passing to process a -different directory structure. For example, the @file{Preview.png} -image from Ksplash component is made of three images. In order to -build the @file{Preview.png} image through @command{centos-art.sh} we -need to wait for all the three images the @file{Preview.png} image is -made of to be rendered in order to combine them all together into just -one image (i.e., the @file{Preview.png} image). This is something we -can't do using post-rendition flow. - -Inside @file{trunk/Identity} directory structure, you can find that -base-rendition, post-rendition and last-rendition flows can be -combined to build @emph{directory-specific} rendition. The -directory-specific rendition exists to automatically process specific -renderable directories in very specific ways. Using directory-specific -rendition speeds up production of different components like Syslinux, -Grub, Gdm, Kdm and Ksplash that require intermediate formats or even -several independent files, in order to reach the final content -construction. Directory-specific rendition is a way to -programmatically describe how specific art works are built in and -organized inside The CentOS Artwork Repository. Such descriptions -have been added to @command{centos-art.sh} command-line to let you -produce them all with just one single command, as fast as your machine -can be able to handle it. - -@xref{Directories trunk Scripts Functions Render}, for more -information about the @command{render} functionality of -@command{centos-art.sh} script. - -@subsubsection Documentation - -@subsubsection Localization +The @file{trunk/Identity} directory structure organizes most files +used to build and implement The CentOS Project Corporate Identity. In +that sake, the following work lines are available: +@table @strong + +@item Brushes + +This work line provides brushes for GIMP. When you prepare the +repository, brushes in this location are made available immediatly for +you to use in the ``Brushes'' panel of GIMP. + +@xref{Directories trunk Identity Brushes}, for more +information. + +@item Fonts + +This work line provides the typography information required by all +different visual manifestations of The CentOS Project. When you +prepare the repository, fonts in this location are made available +immediatly for you to use in GIMP and Inkscape. + +@xref{Directories trunk Identity Fonts}, for more information. + +@item Images + +This work line provides output location for final images that don't +need to use background images (e.g., brands, icons, illustrations, +etc.). + +@xref{Directories trunk Identity Images}, for more information. + +@item Models + +This work line provides design models for final images that don't need +to use background images (e.g., brands, icons, illustrations, etc.). + +@xref{Directories trunk Identity Models}, for more information. + +@item Palettes + +This work line provides palettes of colors for GIMP and Inkscape. When +you prepare the repository, palettes of colors in this location are +made available immediatly for you to use in the ``Palettes'' panel of +GIMP and Inkscape. + +@xref{Directories trunk Identity Palettes}, for more information. + +@item Patterns + +This work line provides patterns for GIMP. When you prepare the +repository, patterns in this location are made available immediatly +for you to use in the ``Patterns'' panel of GIMP. + +@xref{Directories trunk Identity Patterns}, for more information. + +@item Themes + +This work line provides theme design models and theme artistic motifs +for The CentOS Project. If you are interested in creating brand new +visual styles for The CentOS Project this is the place for you. + +@xref{Directories trunk Identity Themes}, for more information. + +@item Webenv + +This work line provides the HTML/XHTML and CSS standard definitions +used by The CentOS Web visual manifestation. If you are a web +developer and plan to improve The CentOS Web visual manifestation, +then the files in this location may result very useful to you. + +@xref{Directories trunk Identity Webenv}, for more information. +@end table @subsection See also diff --git a/Manual/Directories/trunk/Identity/Brushes.texi b/Manual/Directories/trunk/Identity/Brushes.texi index fb39647..c415a67 100755 --- a/Manual/Directories/trunk/Identity/Brushes.texi +++ b/Manual/Directories/trunk/Identity/Brushes.texi @@ -1,22 +1,143 @@ @subsection Goals -@itemize -@item ... -@end itemize +This section describes how brushes are organized in the repository and +how to make them available for you to use in @acronym{GIMP,GNU Image +Manipulation Program}. @subsection Description -@itemize -@item ... -@end itemize +A brush is a pixmap or set of pixmaps used for painting through an +image manipulation program like GIMP. Inside the repository, we've +organized brushes in @emph{common brushes} and @emph{theme-specific +brushes}. In both cases, brushes are created under a @file{Xcf} +directory as @file{.xcf} files first and later exported to @file{.gbr} +or @file{.gih} format in the same level of @file{Xcf} directory. + +@float Figure, Brush file format and directory structure +@verbatim +1. Common brushes 2. Theme-specific brushes +---------------------- ----------------------------------------------------------- +trunk/Identity/Brushes trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes +|-- Xcf |-- Xcf +| |-- 1.xcf | |-- 1.xcf +| |-- 2.xcf | |-- 2.xcf +| `-- 3.xcf | `-- 3.xcf +|-- 1.gbr |-- 1.gbr +|-- 2.gih |-- 2.gih +`-- 3.gbr `-- 3.gbr +@end verbatim +@caption{Brush file format and directory structure.} +@end float + +In order for both common brushes and theme-specific brushes to be +loaded by GIMP, they need to be stored under +@file{~/.gimp-2.2/brushes} directory. Since files related to brushes +already exist in the repository, there is no need to duplicate them in +@file{~/.gimp-2.2/brushes} directory, too. Instead, we make use of +symbolic links and file name convenctions to ``connect'' brushes +created in the repository with the standard location they need to be +stored in for GIMP to recognize them. In this configuration, when +links to brushes are created, if someone commits a change for a brush +you are using, that change will be immediatly available for you the +next time you update your working copy and refresh the Brushes panel +of GIMP. + +When new brushes are added to or removed from the repository, it is +required to update the connection between the brushes inside the +repository working copy and the links created in the predifined +location that GIMP uses to retrive them. Otherwise you may end up +with broken links or brushes in the repository which are not linked. + +Inside the repository, common brushes and theme-specific brushes are +created individually in different locations. However, they all are +linked from one unique directory (i.e., @file{~/.gimp-2.2/brushes}). +This configuration may provoke overlapping of brushes if a name +convenction is not implemented correctly. In that sake, file names +used for brushes inside the repository must be unique, no matter where +they be. + +As convenction inside the repository, brush files are named using a +numerical value that start at 1 and increment one unit when a new +brush is added to the same directory. Later, when links are built, we +use one suffix for those brushes retrived from +@file{trunk/Identity/Brushes} and another suffix for those brushes +retrivided from theme-specific directories. Using both the numerical +value and the suffix information, it is possible to build unique +names for links under @file{~/.gimp-2.2/brushes} directory, scalably. + +@float Figure, Common brushes path relation +@verbatim +trunk/Identity/Brushes +|-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-1.gbr (link) +|-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-2.gbr (link) +`-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-3.gbr (link) +@end verbatim +@caption{Common brushes path relation.} +@end float + +@float Figure, Theme-specific brushes path relation +@verbatim +trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes +|-- 1.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION.1.gbr (link) +|-- 2.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION.2.gbr (link) +`-- 3.gbr (file) <-- ~/.gimp-2.2/brushes/centos-THEMENAME-THEMEVERSION.3.gbr (link) +@end verbatim +@caption{Theme-specific brushes path relation.} +@end float + +Each brush produced with GIMP has a description field associated which +is shown in the Brushes panel of GIMP. This description is set when +the brush is created as @file{.xcf} file and can be updated when it is +exported either to @file{.gbr} or @file{.gih} format. It wouldn't be +too useful to have two or more brushes using the same description. So, +in order to have unique descriptions in brushes it is required to +provide them that way. In that sake, we use the same name schema used +to name brush files as description but without including the file +extension. This way, if we have the @file{centos-flame-3.gbr} brush, +its description would be @code{centos-flame-3}. @subsection Usage -@itemize -@item ... -@end itemize +How to use brushes is up to your creativeness. You can use brushes as +you consider them more appropriate for your graphical compositions. +However, adding and removing them from the repository is something we +need to standardize. It would be terribly sad being using one brush +and suddenly find out that it no longer exists, the next time you +update your working copy. + +@subsection Common brushes + +Common brushes exist to organize brushes that can be used anywhere +inside the repository. Inside the repository, common brushes under +@file{trunk/Identity/Brushes} are mainly used to hold brand +information related to The CentOS Project (e.g., symbols, logos, +trademarks, etc.). + +Common brushes are always made available under +@file{~/.gimp-2.2/brushes} directory after preparing the repository +(@pxref{Directories trunk Scripts Functions Prepare}). + +@subsection Theme-specific brushes + +Theme-specific brushes exist to organize brushes that can be used +inside specific artistic motifs only. Inside the repository, +theme-specific brushes are stored in a directory named @file{Brushes} +which is stored in the first directory level under the artistic motif +directory structure. Each artistic motif inside the repository has the +@file{Brushes} directory and uses it to store brushes that can be +considered auxiliars to that artistic motif construction. + +Theme-specific brushes aren't made available under +@file{~/.gimp-2.2/brushes} directory after preparing the repository. +In order to make theme-specific brushes available under +@file{~/.gimp-2.2./brushes} it is required to activate/deactivate them +using the @code{brush} functionality of @command{centos-art.sh} script +(). @subsection See also -@menu -@end menu +@itemize +@item +@url{file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.html,Brushes} +(from GIMP's manual) +@end itemize diff --git a/Manual/Directories/trunk/Scripts/Functions/Render.texi b/Manual/Directories/trunk/Scripts/Functions/Render.texi index 3e915e2..90b7bd3 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render.texi @@ -1,11 +1,52 @@ -The @code{render} functionality exists to produce both identity and -translation files on different levels of information (i.e., different -languages, release numbers, architectures, etc.). - -The @code{render} functionality relies on ``renderable directory -structures'' to produce files. Renderable directory structures can be -either ``identity directory structures'' or ``translation directory -structures'' with special directories inside. +Rendition is the action through we produce content (images specially) +inside The CentOS Artwork Repository. In order to produce content +through rendition, the directory structure where that content is +stored in must be renderable (i.e., the rendition action must be +applied to a directory structure considered renderable). Presently, +renderable directories are stored under @file{trunk/Identity/Images} +and @file{trunk/Identity/Themes/Motifs} directories only. + +In order to render content inside renderable directory structures you +can use the @code{render} functionality of @command{centos-art.sh} +script. The @code{render} functionality takes one design template +(a.k.a., design model) from the template directory related and creates +an instance of it in order to apply translation messages, if any. +Later, using the translated design template instance, the command +renders the final content based on whether the design template +instance is a SVG file or XHTML file. If the design template instace +is a SVG file, the final content produced is a PNG image. On the other +hand, if the design template instance is a XHTML file, the final +content produced is a XHTML file. The rendition flow described so far +is known as the @command{centos-art.sh} script @emph{base-rendition} +flow and take place both in @emph{direct rendition} and @emph{theme +rendition}. + +Besides the base-rendition flow, the @command{centos-art} provides +@emph{post-rendition} and @emph{last-rendition} flows. The +post-rendition flow is applied to files produced as result of +base-rendition flow under the same directory structure. For example, +you can use post-rendition action to convert the PNG base output into +different outputs formats (e.g., JPG, PDF, etc.) before passing to +process the next file in the same directory structure. The +last-rendition flow, on the other hand, is applied to all files +produced as result of both base-rendition and post-rendition flows in +the same directory structure, just before passing to process a +different directory structure. For example, the @file{Preview.png} +image from Ksplash component is made of three images. In order to +build the @file{Preview.png} image through @command{centos-art.sh} we +need to wait for all the three images the @file{Preview.png} image is +made of to be rendered in order to combine them all together into just +one image (i.e., the @file{Preview.png} image). This is something we +can't do using post-rendition flow. + +Inside @file{trunk/Identity} directory structure, you can find that +base-rendition, post-rendition and last-rendition flows can be +combined to build @emph{directory-specific} rendition. The +directory-specific rendition exists to process specific renderable +directories in very specific ways. Using directory-specific rendition +speeds up production of different components like Syslinux, Grub, Gdm, +Kdm and Ksplash that require intermediate formats or even several +independent files, in order for the final content to be created. @subsection Renderable identity directory structures diff --git a/Manual/Introduction/authors.texi b/Manual/Introduction/authors.texi index d1565b3..87f6878 100755 --- a/Manual/Introduction/authors.texi +++ b/Manual/Introduction/authors.texi @@ -1,28 +1,39 @@ This section records authoring information of CentOS Artwork Repository: -@table @strong - -@item Karanbirn Singh - -Infrastructure, Packaging. - -@item Ralph Angenendt - -Infrastructure, Packaging, Documentation. - -@item Alain Reguera Delgado - -Implementation of a monolithic corporate visual identity for The -CentOS Project that can be maintained by The CentOS Community through -the CentOS Artwork Repository and the @command{centos-art.sh} script. - -@item Marcus Moeller - -Theme Design. +@subsection Graphic Design +@itemize @item Guideon de Kok - -Theme Design. - -@end table +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{marcus@@moeller.org,Marcus Moeller} +@end itemize + +@subsection Documentation +@itemize +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{ralph@@centos.org,Ralph Angenendt} +@end itemize + +@subsection Localization +@itemize +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} (Spanish) +@end itemize + +@subsection Automation +@itemize +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@end itemize + +@subsection Infrastructure +@itemize +@item @email{karan@@centos.org,Karanbirn Singh} +@item @email{ralph@@centos.org,Ralph Angenendt} +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@end itemize + +@subsection Packaging +@itemize +@item @email{karan@@centos.org,Karanbirn Singh} +@item @email{ralph@@centos.org,Ralph Angenendt} +@end itemize diff --git a/Manual/repository.info.bz2 b/Manual/repository.info.bz2 index 416d874..dfdce9e 100644 Binary files a/Manual/repository.info.bz2 and b/Manual/repository.info.bz2 differ diff --git a/Manual/repository.pdf b/Manual/repository.pdf index ff46b33..8ee8915 100644 Binary files a/Manual/repository.pdf and b/Manual/repository.pdf differ diff --git a/Manual/repository.txt.bz2 b/Manual/repository.txt.bz2 index 4b254e2..7dd7ef6 100644 Binary files a/Manual/repository.txt.bz2 and b/Manual/repository.txt.bz2 differ diff --git a/Manual/repository.xhtml.tar.bz2 b/Manual/repository.xhtml.tar.bz2 index ea58b8b..300f945 100644 Binary files a/Manual/repository.xhtml.tar.bz2 and b/Manual/repository.xhtml.tar.bz2 differ diff --git a/Manual/repository.xml b/Manual/repository.xml index cc40765..bd7d081 100644 --- a/Manual/repository.xml +++ b/Manual/repository.xml @@ -156,38 +156,84 @@
Authors AuthorsThis section records authoring information of CentOS Artwork Repository: - - - Karanbirn Singh <karan@centos.org> + + + Graphic Design + + • - Infrastructure, Packaging. + Guideon de Kok - - - Ralph Angenendt <ralph@centos.org> - Infrastructure, Packaging, Documentation. + alain.reguera@gmail.comAlain Reguera Delgado - - - Alain Reguera Delgado - Implementation of a monolithic corporate visual identity for The CentOS Project that can be maintained by The CentOS Community through the CentOS Artwork Repository and the centos-art.sh script. + marcus@moeller.orgMarcus Moeller - - - Marcus Moeller <marcus@moeller.org> + + + + + Documentation + + • - Theme Design. + alain.reguera@gmail.comAlain Reguera Delgado - - - Guideon de Kok - Theme Design. + ralph@centos.orgRalph Angenendt - -
+ + + + + Localization + + • + + alain.reguera@gmail.comAlain Reguera Delgado (Spanish) + + + + + + Automation + + • + + alain.reguera@gmail.comAlain Reguera Delgado + + + + + + Infrastructure + + • + + karan@centos.orgKaranbirn Singh + + + ralph@centos.orgRalph Angenendt + + + alain.reguera@gmail.comAlain Reguera Delgado + + + + + + Packaging + + • + + karan@centos.orgKaranbirn Singh + + + ralph@centos.orgRalph Angenendt + + +
@@ -813,39 +859,43 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 Directories trunk Goals - This directory implements the Subversion's trunk concept in a trunk, branches, tags repository structure. + The trunk/ directory structure implements the Subversion's trunk concept in a trunk, branches, tags repository structure. Description - The trunk/ directory structure is the main development line inside the CentOS Artwork Repository and organizes the following sections: + The trunk/ directory structure is the main development line inside the CentOS Artwork Repository and organizes the following work lines: - Identity + Graphic design - This section describes the implementation of The CentOS Project Corporate Identity. This place is perfect to consolidate The CentOS Artwork SIG. If you are interested in producing art works for The CentOS Project, this place is for you. + The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. + In this section you'll find how to organize and produce gaphic designs in the repository. The graphic design work line is the perfect place to consolidate The CentOS Artwork SIG. If you are interested in producing graphic designs for The CentOS Project, this place is for you. See Directories trunk Identity, for more information. - Scripts + Documentation - This section describes the implementation of centos-art.sh script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. - See Directories trunk Scripts, for more information. + The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas behind them and, if possible, how automation scripts make use of them. + In this section you'll find how to organize and produce the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested in producing documentation for the repository, this place is for you. + See Directories trunk Manual, for more information. - Manual + Localization - This section organizes the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested on improving The CentOS Artwork Repository Manual, in this place you'll find the Texinfo documentation structure you need to work with. - See Directories trunk Manual, for more information. + The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under trunk/Locales directory structure. + In this section you'll find how to organize and produce translation messages for graphic designs, documentation and automation scripts in the repository. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. + See Directories trunk Locales, for more information. - Locales + Automation - This section organizes production of translation messages for Identity, Documentation and Scripts. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. - See Directories trunk Locales, for more information. + The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. + In this section you'll find how to organize and extend the centos-art.sh script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. + See Directories trunk Scripts, for more information.
@@ -883,76 +933,58 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 Directories trunk Identity Goals - This section descirbes the implementation of The CentOS Project Corporate Identity. + The trunk/Identity describes what The CentOS Project Corporate Identity is and the components it is made of. Description - The CentOS Project Corporate Identity is the “persona” of the organization known as The CentOS Project. The CentOS Project Corporate Identity plays a significant role in the way the CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, the CentOS Project Corporate Identity expresses the values and ambitions of the CentOS Project organization, its business, and its characteristics. + 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. + + Figure + + + The CentOS Project - Corporate Identity. + + + + Corporate Mission + The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively. + Corporate Design - The CentOS Project Corporate Design is applied to every single visual manifestations The CentOS Project as organization wants to express its existence. Examples of the most relevant visual manifestations inside The CentOS Project are The CentOS Distribution, The CentOS Web and The CentOS Stationery. - The CentOS Project Corporate Design is organized in the following work-lines: + The CentOS Project Corporate Design is focused on the effective communication of visual messages through graphic design. Visual messages can be considered any information that people can perceive through the visual sence (i.e., the human eye). The CentOS Project Corporate Design is very tied to The CentOS Project Corporate Structure which, in turn, is based on The CentOS Project Corporate Mission and The CentOS Project Release Schema. + The CentOS Project Corporate Design is applied to The CentOS Project Visual Manifestations. A visual manifestation is any medium, digital or printed, used by The CentOS Project to communicate its existence (e.g., The CentOS Distribution, The CentOS Web and The CentOS Showroom). - Brushes - - See Directories trunk Identity Brushes, for more information. - - - - Fonts - - The CentOS Fonts provide the Corporate Typography information used along The CentOS Project visual manifestations. - See Directories trunk Identity Fonts, for more information. - - - - Images - - See Directories trunk Identity Images, for more information. - - - - Models - - See Directories trunk Identity Models, for more information. - - - - Palettes - - The CentOS Palettes provide the Corporate Color information used along The CentOS Project visual manifestations. - See Directories trunk Identity Palettes, for more information. - - - - Patterns + The CentOS Distribution - See Directories trunk Identity Patterns, for more information. + The CentOS Distribution is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. The CentOS Distribution conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. (The CentOS Project mainly changes packages to remove upstream vendor branding and artwork.) + The CentOS Distribution is developed by a small but growing team of core developers. In turn the core developers are supported by an active user community including system administrators, network administrators, enterprise users, managers, core Linux contributors and Linux enthusiasts from around the world. - Themes + The CentOS Web - The CentOS Themes provide the Corporate Structure and the Corporate Visual Style used along The CentOS Project visual manifestations. - See Directories trunk Identity Themes, for more information. + The CentOS Web exists to support The CentOS Distribution. + The CentOS Web covers web applications which let The CentOS Project to manifest its existence on the Internet. Through these web applications The CentOS Project provides Corporate Communication. These web applications are free software and come from different providers which distribute their work with predefined visual styles. Frequently, these predefined visual styles have no visual relation among themselves and introduce some visual contraditions when they all are put together. These visual contraditions need to be removed in order to comply with The CentOS Project Corporate Structure guidelines. - Webenv + The CentOS Showroom - See Directories trunk Identity Webenv, for more information. + The CentOS Showroom exists to promote The CentOS Distribution. + The CentOS Showroom covers industrial production of objects branded by The CentOS Project (e.g., clothes, stationery and installation media). These branded objects are for distribution on social events and/or shops. They provide a way of both promotion and monetary incomming to aliviate The CentOS Project expenses (e.g., electrical power, hosting, servers, full-time-developers, etc.), in a similar way as donations do.
+ The visual manifestation described above seems to be enough for what The CentOS Project is, by now. However, other visual manifestations could be added in the future, if needed, to cover different areas like building, offices, road transportation and whaterver visual manifestation The CentOS Project thouches to show its existence. Corporate Communication - The CentOS Project Corporate Communication is based on Community Communication. In that sake, the following media are available: + The CentOS Project Corporate Communication is based on Community Communication and takes place through the following avenues: • @@ -964,53 +996,91 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3 The CentOS Forums (http://forums.centos.org/). + + The CentOS Wiki (http://wiki.centos.org/). + Corporate Behaviour - The CentOS Project Corporate Behaviour is based on Community Behaviour. + The CentOS Project Corporate Behaviour is based on Community Behaviour which take place on Corporate Communication. Corporate Structure - The CentOS Project Corporate Structure is based on a Monolithic Corporate Visual Identity Structure. In this structure, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project. + The CentOS Project Corporate Structure is based on a Monolithic Corporate Visual Identity Structure. In this configuration, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project. 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 The CentOS Project. - Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major releasae of CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project and which are the visual manifestations it is made of. - The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Stationery. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. Inside Web and Stationery visual manifestations content is visually produced to fit non-release-specifc content but treat it as a visual manifestation properly. For example, consider that there is no a complete web site for each major release of CentOS distribution, but one web site to cover the information related to all release-specific visual manifestations like CentOS distribution. - In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., web sites and stationery)? + Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major release of The CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project is made of. + The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Showroom. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. However, inside The CentOS Web visual manifestations, the content is produced for no specific release information (e.g., there is no a complete web site for each major release of The CentOS Distribution individually, but one web site to cover them all). Likewise, the content produced in The CentOS Showroom is created for no release-specific at all, but for The CentOS Project in general. + In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., The CentOS Web and The CentOS Showroom)? Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain? - Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and that, certainly, didn't come through swinging magical wangs or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Visual Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. - Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new release of CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. + Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and, that, certainly, didn't come through swinging magical wands or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Corporate Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. + Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new release of The CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. Usage - The trunk/Identity/ directory structure is organized in renderable and non-renderable directories. Generally, renderable directories are stored under trunk/Identity/Images and trunk/Identity/Themes/Motifs directories. These directories contain the image files used to implemente The CentOS Project Corporate Identity. - - - Rendition - In order to produce content inside rendereble directories, you can use the following command: - - - Warning If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared your workstation for using The CentOS Artwork Repository yet. See Directories trunk Scripts Functions Prepare, for more information. - - This command takes one design template (a.k.a., design model) from the template directory and creates an instance of it in order to apply translation messages, if any. Later, using the translated design template instance, the command renders the final content based on whether the design template instance is a SVG file or XHTML. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a XHTML file, the final content produced is a XHTML file. The rendition flow described so far is known as the centos-art.sh script base-rendition flow. - Besides the base-rendition flow, the centos-art provides post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs formats (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow, on the other hand, is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art.sh we need to wait for all the three images the Preview.png image is made of to be rendered in order to combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. - Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to automatically process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order to reach the final content construction. Directory-specific rendition is a way to programmatically describe how specific art works are built in and organized inside The CentOS Artwork Repository. Such descriptions have been added to centos-art.sh command-line to let you produce them all with just one single command, as fast as your machine can be able to handle it. - See Directories trunk Scripts Functions Render, for more information about the render functionality of centos-art.sh script. - - - - Documentation - - - - Localization - + The trunk/Identity directory structure organizes most files used to build and implement The CentOS Project Corporate Identity. In that sake, the following work lines are available: + + + Brushes + + This work line provides brushes for GIMP. When you prepare the repository, brushes in this location are made available immediatly for you to use in the “Brushes” panel of GIMP. + See Directories trunk Identity Brushes, for more information. + + + + Fonts + + This work line provides the typography information required by all different visual manifestations of The CentOS Project. When you prepare the repository, fonts in this location are made available immediatly for you to use in GIMP and Inkscape. + See Directories trunk Identity Fonts, for more information. + + + + Images + + This work line provides output location for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). + See Directories trunk Identity Images, for more information. + + + + Models + + This work line provides design models for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). + See Directories trunk Identity Models, for more information. + + + + Palettes + + This work line provides palettes of colors for GIMP and Inkscape. When you prepare the repository, palettes of colors in this location are made available immediatly for you to use in the “Palettes” panel of GIMP and Inkscape. + See Directories trunk Identity Palettes, for more information. + + + + Patterns + + This work line provides patterns for GIMP. When you prepare the repository, patterns in this location are made available immediatly for you to use in the “Patterns” panel of GIMP. + See Directories trunk Identity Patterns, for more information. + + + + Themes + + This work line provides theme design models and theme artistic motifs for The CentOS Project. If you are interested in creating brand new visual styles for The CentOS Project this is the place for you. + See Directories trunk Identity Themes, for more information. + + + + Webenv + + This work line provides the HTML/XHTML and CSS standard definitions used by The CentOS Web visual manifestation. If you are a web developer and plan to improve The CentOS Web visual manifestation, then the files in this location may result very useful to you. + See Directories trunk Identity Webenv, for more information. + + +
@@ -1030,39 +1100,84 @@ centos-art render trunk/Identity/Path/To/Dir Directories trunk Identity Brushes Goals - - • - - ... - - + This section describes how brushes are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program. Description - - • - - ... - - + A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've organized brushes in common brushes and theme-specific brushes. In both cases, brushes are created under a Xcf directory as .xcf files first and later exported to .gbr or .gih format in the same level of Xcf directory. + + Figure + + + Brush file format and directory structure. + + In order for both common brushes and theme-specific brushes to be loaded by GIMP, they need to be stored under ~/.gimp-2.2/brushes directory. Since files related to brushes already exist in the repository, there is no need to duplicate them in ~/.gimp-2.2/brushes directory, too. Instead, we make use of symbolic links and file name convenctions to “connect” brushes created in the repository with the standard location they need to be stored in for GIMP to recognize them. In this configuration, when links to brushes are created, if someone commits a change for a brush you are using, that change will be immediatly available for you the next time you update your working copy and refresh the Brushes panel of GIMP. + When new brushes are added to or removed from the repository, it is required to update the connection between the brushes inside the repository working copy and the links created in the predifined location that GIMP uses to retrive them. Otherwise you may end up with broken links or brushes in the repository which are not linked. + Inside the repository, common brushes and theme-specific brushes are created individually in different locations. However, they all are linked from one unique directory (i.e., ~/.gimp-2.2/brushes). This configuration may provoke overlapping of brushes if a name convenction is not implemented correctly. In that sake, file names used for brushes inside the repository must be unique, no matter where they be. + As convenction inside the repository, brush files are named using a numerical value that start at 1 and increment one unit when a new brush is added to the same directory. Later, when links are built, we use one suffix for those brushes retrived from trunk/Identity/Brushes and another suffix for those brushes retrivided from theme-specific directories. Using both the numerical value and the suffix information, it is possible to build unique names for links under ~/.gimp-2.2/brushes directory, scalably. + + Figure + + + Common brushes path relation. + + + Figure + + + Theme-specific brushes path relation. + + Each brush produced with GIMP has a description field associated which is shown in the Brushes panel of GIMP. This description is set when the brush is created as .xcf file and can be updated when it is exported either to .gbr or .gih format. It wouldn't be too useful to have two or more brushes using the same description. So, in order to have unique descriptions in brushes it is required to provide them that way. In that sake, we use the same name schema used to name brush files as description but without including the file extension. This way, if we have the centos-flame-3.gbr brush, its description would be centos-flame-3. Usage + How to use brushes is up to your creativeness. You can use brushes as you consider them more appropriate for your graphical compositions. However, adding and removing them from the repository is something we need to standardize. It would be terribly sad being using one brush and suddenly find out that it no longer exists, the next time you update your working copy. + + + + Common brushes + Common brushes exist to organize brushes that can be used anywhere inside the repository. Inside the repository, common brushes under trunk/Identity/Brushes are mainly used to hold brand information related to The CentOS Project (e.g., symbols, logos, trademarks, etc.). + Common brushes are always made available under ~/.gimp-2.2/brushes directory after preparing the repository (see Directories trunk Scripts Functions Prepare). + + + + Theme-specific brushes + Theme-specific brushes exist to organize brushes that can be used inside specific artistic motifs only. Inside the repository, theme-specific brushes are stored in a directory named Brushes which is stored in the first directory level under the artistic motif directory structure. Each artistic motif inside the repository has the Brushes directory and uses it to store brushes that can be considered auxiliars to that artistic motif construction. + Theme-specific brushes aren't made available under ~/.gimp-2.2/brushes directory after preparing the repository. In order to make theme-specific brushes available under ~/.gimp-2.2./brushes it is required to activate/deactivate them using the brush functionality of centos-art.sh script (). + + + + See also • - ... + file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.htmlBrushes (from GIMP's manual) - - - See also - - - @@ -4344,8 +4459,10 @@ Copyright (C) 1989, 1991 Free Software Foundation, Inc. Directories
The <file>trunk/Scripts/Functions/Render</file> Directory - Directories trunk Scripts Functions RenderThe render functionality exists to produce both identity and translation files on different levels of information (i.e., different languages, release numbers, architectures, etc.). - The render functionality relies on “renderable directory structures” to produce files. Renderable directory structures can be either “identity directory structures” or “translation directory structures” with special directories inside. + Directories trunk Scripts Functions RenderRendition is the action through we produce content (images specially) inside The CentOS Artwork Repository. In order to produce content through rendition, the directory structure where that content is stored in must be renderable (i.e., the rendition action must be applied to a directory structure considered renderable). Presently, renderable directories are stored under trunk/Identity/Images and trunk/Identity/Themes/Motifs directories only. + In order to render content inside renderable directory structures you can use the render functionality of centos-art.sh script. The render functionality takes one design template (a.k.a., design model) from the template directory related and creates an instance of it in order to apply translation messages, if any. Later, using the translated design template instance, the command renders the final content based on whether the design template instance is a SVG file or XHTML file. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a XHTML file, the final content produced is a XHTML file. The rendition flow described so far is known as the centos-art.sh script base-rendition flow and take place both in direct rendition and theme rendition. + Besides the base-rendition flow, the centos-art provides post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs formats (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow, on the other hand, is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art.sh we need to wait for all the three images the Preview.png image is made of to be rendered in order to combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. + Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created. Renderable identity directory structures