@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{Directories 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{Directories 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{Directories 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{Directories 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 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{Directories trunk Scripts 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{Directories trunk Scripts 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.