<section id="repository-history-2012">
<title>2012's</title>
<para>
&TCAR; development was eventually stopped at November 2011
until July 2012 when we needed to make the
<command>centos-art.sh</command> script a bit more
customizable than it presently was. For example, it was
considered as a need that functionalities inside the
<command>centos-art.sh</command> script must be not just
conceived independent one another but reusable in different
contexts as well.
</para>
<simplesect id="repository-history-2012-UpdateLocales">
<title>Make Localization Of <command>centos-art.sh</command>
Script Specific To Different Contexts</title>
<para>
The procedure used to locale messages inside the
<command>centos-art.sh</command> script had to be re-designed
in order to accept such pluggable behavior into the script. We
couldn't publish unique <filename>centos-art.sh.po</filename>
and <filename>centos-art.sh.mo</filename> files because they
may contain different information in different contexts. For
example, if you are using the <function>render</function> and
<function>help</function> functionalities you only need
translation messages for them and not those from other
functionalities that may exist in the central repository but
you didn't download nor use into your working copy.
</para>
<para>
One solution for this could be to have independent PO files
for each functionality of <command>centos-art.sh</command>
script which are combined to create the final PO and MO files
that <application>gettext</application> uses to retrive
translated strings when <command>centos-art.sh</command>
script is running. For this solution to be effective, you must
be selective about the functionalities and locales directories
you download into your working copy. For example, if you want
to use the render functionality and its locale messages only,
you must download the required directories and exclude others.
</para>
<note>
<para>
In case you don't want to be selective and download the whole
repository, the creation of the
<filename>centos-art.sh.po</filename>,
<filename>centos-art.sh.pot</filename> and
<filename>centos-art.sh.mo</filename> files will occur
automatically the first time you run the
<function>prepare</function> functionality (which require the
<function>locale</function> functionality to be available), or
later, by running the following command:
<screen>centos-art locale Scripts/Bash --update</screen>
</para>
<para>
For more information about the <function>prepare</function>
and <function>locale</function> functionalities, see <xref
linkend="scripts-bash-locale" /> and <xref
linkend="scripts-bash-prepare" /> respectively.
</para>
</note>
<para>
As shown in <xref linkend="repository-history-2012-2" />, both
<function>Commons</function> and <function>Locales</function>
functionalities will always be required directories. The
<function>Commons</function> directory contains the common
functionalities and the <function>Locales</function> directory
contains the standard procedures you need to run in order to
build the final <filename>centos-art.sh.mo</filename> file
used by <application>gettext</application> to retrive
translation strings when the <command>centos-art.sh</command>
script is running. Remember that
<filename>centos-art.sh.pot</filename>,
<filename>centos-art.sh.po</filename> files aren't under
version control and they are built by combining each
funtionality message.po file into a PO and later a MO file.
</para>
<example id="repository-history-2012-2">
<title>Directory structure of a rendering-only context</title>
<screenshot>
<screeninfo>Directory structure of a rendering-only context</screeninfo>
<mediaobject>
<textobject>
<programlisting>
/home/centos/Projects/artwork/
|-- Locales/
| `-- Scripts/
| `-- Bash/
| `-- es_ES/
| |-- Functions/
| | |-- Commons/
| | | |-- messages.po
| | | `-- messages.pot
| | |-- Locales/
| | | |-- messages.po
| | | `-- messages.pot
| | `-- Render/
| | |-- messages.po
| | `-- messages.pot
| |-- LC_MESSAGES/
| | `-- centos-art.sh.mo
| |-- centos-art.sh.po
| `-- centos-art.sh.pot
`-- Scripts/
`-- Bash/
|-- Functions/
| |-- Commons/
| |-- Locales/
| `-- Render/
`-- centos-art.sh
</programlisting>
</textobject>
</mediaobject>
</screenshot>
</example>
<para>
A practical example of using the solution described above may
be found when you are working on the corporate identity of
&TCP; and then need to start a new corporate identity project
for another organization. You want to keep the directory
structure of &TCAR; and its automation tool, the
<command>centos-art.sh</command> script. Your new project
requires you to introduce new functionalities to
<command>centos-art.sh</command> which don't fit the needs of
&TCP; (e.g., you want to introduce a
<function>report</function> functionality to mesure how much
connect time do you consume through your PPP internface.) or
you just want to keep the directory structure of your new
project as simple as possible.
</para>
<para>
To go through this it is possible to mix specific parts of
different central repositories into one single working copy.
This is the working copy you'll use to manage your new
project. In <xref linkend="repository-history-2012-1" />, we
see how the <filename class="directory">Render</filename>,
<filename class="directory">Locales</filename> and <filename
class="directory">Commons</filename> directories which come
from the &TCAR; has been integrated into the working copy of
your new project.
</para>
<example id="repository-history-2012-1">
<title>Mixing automation functionalities.</title>
<screenshot>
<screeninfo>Mixing automation functionalities.</screeninfo>
<mediaobject>
<textobject>
<programlisting>
/home/al/Projects/Myapp/
|-- Locales/
| `-- Scripts/
| `-- Bash/
| `-- es_ES/
| |-- Functions/
| | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/
| | | |-- messages.po
| | | `-- messages.pot
| | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/
| | | |-- messages.po
| | | `-- messages.pot
| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| | | |-- messages.po
| | | `-- messages.pot
| | `-- Report/
| | |-- messages.po
| | `-- messages.pot
| |-- LC_MESSAGES/
| | `-- myapp.sh.mo
| |-- myapp.sh.po
| `-- myapp.sh.pot
`-- Scripts/
`-- Bash/
|-- Functions/
| |-- Commons/ <--| from https://projects.centos.org/svn/artwork/
| |-- Locales/ <--| from https://projects.centos.org/svn/artwork/
| |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| `-- Report/
`-- myapp.sh
</programlisting>
</textobject>
</mediaobject>
</screenshot>
</example>
<para>
At this point, your working copy contains files from two
different central repositories. One repository provides the
files of your new organization project and the other one
provides the files related to the <function>render</function>
functionality from &TCAR;. In this environment, all updates
commited to the <filename class="directory">Render</filename>,
<filename class="directory">Locales</filename> and <filename
class="directory">Commons</filename> directories at &TCAR;
will be available to you too, the next time you update your
working copy. Likewise, if you change something in any of
these directories and commit your changes, your changes will
be available to poeple working in &TCAR; the next time they
update their working copies.
</para>
<para>
Understanding the need of mixing different central
repositories into a single working copy is an important step
for reusing the functionalities that come with centos-art.sh
script, but it is not enough if you want to customize the
information produced by it. By default, the centos-art.sh
script uses information related to &TCP;. You probably need to
change this if you are producing images to a different
organization than &TCP;. For example, some of the information
you might need to change would be the copyright holder,
brands, domain names, mailing lists, and so forth. To change
this information you need to duplicate the file
<filename>centos-art.sh</filename> and rename it to something
else. Later, you need to edit the renamed version and change
variables inside according your needs. In <xref
linkend="repository-history-2012-1" />, we used the name
<command>myapp.sh</command> instead of
<command>centos-art.sh</command> so the information we set
inside it could reflect the specific needs that motivated the
creation of a new project without affecting those from &TCP;.
</para>
<para>
Most of the information you need to change in your duplicated
version of <filename>centos-art.sh</filename> file is
controlled by a set of read-only variables. You modify these
variables here and they will be available all along the script
execution time. For example, you can change the value of
<varname>CLI_WRKCOPY</varname> variable inside your duplicated
version of <filename>centos-art.sh</filename> to change the
absolute path you use to store your working copy.
</para>
</simplesect>
<simplesect>
<title>Enhance The CentOS Logo Construction</title>
<para>
The CentOS Logo is made of two different components known as
The CentOS Symbol and The CentOS Type. Presently (at the end
of September), to produce these components, we create one
<acronym>SVG</acronym> image for each PNG image we want to
produce, store it in <filename
class="directory">Identity/Models/Brands/Logos</filename>
directory structure and run the command:
</para>
<cmdsynopsis>
<command>centos-art render Identity/Images/Brands/Logos</command>
</cmdsynopsis>
<para>
This model works and scales well in situations when there
isn't a need to reuse final images among themselves. However,
when you need to reuse images among themselves, a better
solution is required. The goal here would be: don't create
<acronym>SVG</acronym> images for PNG images you can build
based on other PNG images.
</para>
<para>
This might be achieved through one of the following ways:
</para>
<itemizedlist>
<listitem>
<para>
Create a new specific functionality to achieved the goal.
Needed because the <xref linkend="scripts-bash-render" />
specific functionality uses <acronym>SVG</acronym> files as
reference to build images (i.e., one <acronym>SVG</acronym>
image produces one PNG image).
</para>
</listitem>
<listitem>
<para>
Modify <xref linkend="scripts-bash-render" /> functionality to
work in different modes based on file type or file extension.
The first mode would use <acronym>SVG</acronym> files as
reference to build PNG images (just as it was doing so far).
The second mode would use a configuration file named
<filename>render.conf</filename> as reference inside the
design models directory you want to produce images for so as
to build the related PNG images. In this second case, the
configuration file specifies how final PNG images will be
produced (e.g., by appending or overlapping them one another).
</para>
</listitem>
</itemizedlist>
<para>
For example, consider the following command-line:
</para>
<cmdsynopsis>
<command>centos-art render Identity/Images/Brands/Logos</command>
</cmdsynopsis>
<para>
This command should evaluate which type of rendition will be
done, based on whether the source file is a scalable vector
graphic (<acronym>SVG</acronym>) or a configuration file. To
make this decision, the <command>centos-art.sh</command>
script looks for <acronym>SVG</acronym> files first, and
configuration files later. When <acronym>SVG</acronym> files
are found, the <command>centos-art.sh</command> script uses a
list of <acronym>SVG</acronym> files and process them one by
one excluding any related configuration file that could exist.
On the other hand, if no <acronym>SVG</acronym> file is found
inside the related design model directory structure, the
<command>centos-art.sh</command> script will use the
configuration file with the name
<filename>render.conf</filename> to create images as specified
inside it. When neither a <acronym>SVG</acronym> or a
configuration file is found inside the design model directory
structure, the <command>centos-art.sh</command> script
finishes its execution without any error message. For
example, if no <acronym>SVG</acronym> file is found inside
<filename
class="directory">Identity/Models/Brands/Logos/</filename>
directory and the
<filename>Identity/Models/Brands/Logos/images.conf</filename>
configuration file exists therein with the following content:
</para>
<programlisting>
[centos.png]
models = "Identity/Models/Brands/Symbols/centos-symbol-forlogos.svgz Identity/Models/Brands/Types/centos.svgz"
formats = "xpm jpg"
heights = "48 78"
fgcolor = "000000 ffffff"
bgcolor = "ffffff-0"
command = "/usr/bin/convert +append"
[centos-artwork.png]
models = "Identity/Models/Brands/Symbols/centos-symbol-forlogos.svgz Identity/Models/Brands/Types/centos.svgz Identity/Models/Brands/Types/artwork.svgz"
formats = "xpm jpg"
heights = "48 78"
fgcolor = "000000 ffffff"
bgcolor = "ffffff-0"
command = "/usr/bin/convert +append"
</programlisting>
<para>
The <command>centos-art.sh</command> script should produce the
following image files:
</para>
<programlisting>
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.jpg
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.png
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.xpm
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.png
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.jpg
Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.xmp
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.jpg
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.png
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.xpm
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.png
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.jpg
Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.xmp
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.jpg
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.png
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.xpm
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.png
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.jpg
Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.xmp
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.jpg
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.png
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.xpm
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.png
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.jpg
Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.xmp
</programlisting>
<para>
The final location for storing images output inside the
repository is determined by using the design model directory
provided as argument. Basically, the
<command>centos-art.sh</command> script changes the path
components from Models to Images and adds foreground color,
background color, height value and image name to it to
differentiate rendered images.
</para>
<para>
In case you need to restrict the amount of files you want to
produce including their formats, heights, colors and commands,
you need to modify the content of the related
<filename>render.conf</filename> configuration file. There is
not any command-line option available for such tasks. The most
<xref linkend="scripts-bash-render" xreflabel="render"/>
command-line options can do for you is when there are more
than one configuration file inside the same design model
directory and you need to specify which one of them will be
used as reference. In such case you can use the
<option>--filter="REGEX"</option> option.
</para>
<para>
When images are produced through configuration files, the
<command>centos-art.sh</command> script takes the order
provided in the list of design models to build the list of
images you will work with through the command specified. For
example, the order in which images will be appended or
overlapped.
</para>
<para>
Localization of logo images will not be and must not be
supported in any way. That would bring disastrous confusion in
the area of visual recognition.
</para>
</simplesect>
</section>