| @subsection Goals |
| |
| The @file{trunk/Identity} directory structure implements @emph{The |
| CentOS Project Corporate Identity}. |
| |
| @subsection 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 |
| visual 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 @emph{Corporate Design}, |
| @emph{Corporate Communication}, and @emph{Corporate Behaviour}. |
| |
| @subsubsection 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 @emph{The CentOS Distribution}, @emph{The |
| CentOS Web} and @emph{The CentOS Stationery}. |
| |
| The CentOS Project corporate design is organized in the following |
| work-lines: |
| |
| @table @strong |
| @item The CentOS Brand |
| The CentOS Brand is the name or trademark that connects the producer |
| with their products. In this case, the producer is The CentOS Project |
| and the products are The CentOS Project visual manifestations. |
| |
| @xref{Filesystem trunk Identity Brands}, for more information. |
| |
| @item The CentOS Colors |
| |
| The CentOS Fonts provides the color information used along The CentOS |
| Project visual manifestations. |
| |
| @xref{Filesystem trunk Identity Colors}, for more information. |
| @item The CentOS Fonts |
| |
| The CentOS Fonts provides the typography information used along The |
| CentOS Project visual manifestations. |
| |
| @xref{Filesystem trunk Identity Fonts}, for more information. |
| @item The CentOS Themes |
| |
| The CentOS Themes provides structural information and visual style |
| information, as well, used along The CentOS Project visual |
| manifestations. |
| |
| @xref{Filesystem trunk Identity Themes}, for more information. |
| @end table |
| |
| @subsubsection Corporate Communication |
| |
| The CentOS Project corporate communication is based on community |
| communication. In that sake, the following media are available for |
| corporate communication: |
| |
| @itemize |
| @item The CentOS Mailing Lists (@url{http://lists.centos.org/}). |
| @item The CentOS Forums (@url{http://forums.centos.org/}). |
| @end itemize |
| |
| @subsubsection Corporate Behaviour |
| |
| The CentOS Project corporate behaviour is based on community |
| behaviour. |
| |
| @subsubsection Corporate Structure |
| |
| The CentOS Project corporate structure is based on a @emph{monolithic} |
| corporate visual identity structure. In this structure, we use one |
| unique name (The CentOS Brand) and one unique visual style (The CentOS |
| Theme) in all The CentOS Project visual manifestations. |
| |
| Inside a monolithic corporate visual identity structure, internal and |
| external stakeholders use to feel a strong sensation of uniformity, |
| orientation, and identification with the organization. No matter if |
| you are visiting web sites, using the distribution, or acting on |
| social events, the one unique name and one unique visual style |
| connects them all to say: @emph{Hey! we are all part of The CentOS |
| Project}. |
| |
| Other corporate structures have been considered as well, but they |
| introduce visual contradictions we need to be aware of. In that sake, |
| lets describe the idea of: @emph{Producing one different visual style |
| for each major release of The CentOS Distribution}. |
| |
| The CentOS Project maintains near to four different major releases of |
| The CentOS Distribution parallely in time and that fact makes one part |
| of The CentOS Project structural design, but just one part, not the |
| complete structural design. 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. Would we end up with four different visual styles, |
| one for each distribution? In that case, why The CentOS Distribution |
| we use shows one visual style, The CentOS Web sites another and The |
| CentOS Stationery even another completly different one? Isn't them |
| all part of the same project? |
| |
| Probably you be 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, it is 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 so 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 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 |
| does 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. |
| |
| @subsection Usage |
| |
| The @file{trunk/} directory structure is organized in |
| @emph{renderable} and @emph{non-renderable} directories. Generally, |
| renderable directories contain two non-renderable directories inside, |
| one to store design templates (the @file{Tpl/} directory), and other |
| to store the content produced (the @file{Img/} directory). |
| |
| In order to produce content inside rendereble directories, you can use |
| the following command: |
| |
| @verbatim |
| centos-art identity --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 it for using The CentOS Artwork Repository yet. |
| @xref{Filesystem trunk Scripts Bash Cli Functions Verify}, for more |
| information. |
| @end quotation |
| |
| This command takes one design template from the template directory and |
| creates an instance of it in order to apply translation messages on |
| it, if any. Later, using the design template instance, the command |
| renders the final content based on whether the design template |
| instance is a SVG file or a Docbook 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 Docbook file, the |
| final content produced is a XHTML file. Final content is stored in the |
| image directory using the design template directory paths as referece. |
| The rendition flow described so far is known as the |
| @emph{base-rendition} flow. |
| |
| Besides the base-rendition flow, the @command{centos-art} provides the |
| @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 (e.g., JPG, PDF, etc.) before passing to process the |
| next file in the same directory structure. The last-rendition flow 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} we need to wait for all the three images the |
| @file{Preview.png} image is made of to be rendered, so we can 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 its final 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} 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{Filesystem trunk Scripts Bash Cli Functions Identity}, for more |
| information about the @command{identity} functionality of |
| @command{centos-art} command-line interface. |
| |
| @subsection See also |
| |
| See @url{http://en.wikipedia.org/Corporate_identity} (and related |
| links), for general information on corporate identity. |
| |
| Specially useful has been, and still be, the book @emph{Corporate |
| Identity} by Wally Olins (1989). This book provides many conceptual |
| ideas we've used as base to build The CentOS Artwork Repository. |
| |