Blame Manuals/Repository/trunk/Scripts/Bash/Functions/Render.texi

8870e9
The @code{render} functionality exists to produce both identity and
8870e9
translation files on different levels of information (i.e., different
8870e9
languages, release numbers, architectures, etc.).
2563c2
5cee2c
The @code{render} functionality relies on ``renderable directory
5cee2c
structures'' to produce files. Renderable directory structures can be
5cee2c
either ``identity directory structures'' or ``translation directory
8870e9
structures'' with special directories inside.
5cee2c
5cee2c
@subsection Renderable identity directory structures
5cee2c
8870e9
Renderable identity directory structures are the starting point of
8870e9
identity rendition. Whenever we want to render a component of CentOS
8870e9
corporate visual identity, we need to point @file{centos-art.sh} to a
8870e9
renderable identity directory structure. If such renderable identity
8870e9
directory structure doesn't exist, then it is good time to create it. 
5cee2c
8870e9
Inside the working copy, one renderable identity directory structures
8870e9
represents one visual manifestation of CentOS corporate visual
8870e9
identity, or said differently, each visual manifestation of CentOS
8870e9
corporate visual identity should have one renderable identity
8870e9
directory structure.
5cee2c
5cee2c
Inside renderable identity directory structures, @file{centos-art.sh}
139290
can render both image-based and text-based files. Specification of
139290
whether a renderable identity directory structure produces image-based
139290
or text-based content is a configuration action that takes place in
139290
the pre-rendition configuration script of that renderable identity
13b177
directory structure.
139290
139290
Inside renderable identity directory structures, content production is
139290
organized in different configurations. A content production
139290
configuration is a unique combination of the components that make an
139290
identity directory structure renderable. One content production
139290
configuration does one thing only (e.g., to produce untranslated
139290
images), but it can be extended (e.g., adding translation files) to
139290
achieve different needs (e.g., to produce translated images).
5cee2c
5cee2c
@subsubsection Design template without translation
5cee2c
5cee2c
The design template without translation configuration is based on a
5cee2c
renderable identity directory structure with an empty translation
5cee2c
directory structure. In this configuration, one design template
5cee2c
produces one untranslated file. Both design templates and final
5cee2c
untranslated files share the same file name, but they differ one
13b177
another in file-type and file-extension.
5cee2c
5cee2c
For example, to produce images without translations (there is no much
5cee2c
use in producing text-based files without translations), consider the
5cee2c
following configuration:
5cee2c
5cee2c
@table @strong
5cee2c
@item One renderable identity directory structure:
5cee2c
13b177
In this example we used @file{Identity/Path/To/Dir} as the identity
13b177
component we want to produce untranslated images for.  Identity
13b177
components can be either under @file{trunk/} or @file{branches/}
13b177
directory structure.
13b177
13b177
The identity component (i.e., @file{Identity/Path/To/Dir}, in this
13b177
case) is also the bond component we use to connect the identity
13b177
directory structures with their respective auxiliar directories (i.e.,
13b177
translation directory structres and pre-rendition configuration
13b177
structures).  The bond component is the path convenction that
13b177
@file{centos-art.sh} uses to know where to look for related
13b177
translations, configuration scripts and whatever auxiliar thing a
13b177
renderable directory structure may need to have.
2563c2
2563c2
@verbatim
13b177
      | The bond component
13b177
      |----------------->|
13b177
trunk/Identity/Path/To/Dir  <-- Renderable identity directory structure.
13b177
|-- Tpl                     <-- Design template directory.
13b177
|   `-- file.svg            <-- Design template file.
13b177
`-- Img                     <-- Directory used to store final files.
13b177
    `-- file.png            <-- Final image-based file produced from
13b177
                                design template file.
5cee2c
@end verbatim
5cee2c
13b177
Inside design template directory, design template files are based on
13b177
@acronym{SVG,Scalable Vector Graphics} and use the extension
13b177
@code{.svg}.  Design template files can be organized using several
13b177
directory levels to create a simple but extensible configuration,
13b177
specially if translated images are not required.
5cee2c
5cee2c
In order for @acronym{SVG,Scalable Vector Graphics} files to be
5cee2c
considered ``design template'' files, they should be placed under the
5cee2c
design template directory and to have set a @code{CENTOSARTWORK}
5cee2c
object id inside.
5cee2c
5cee2c
The @code{CENTOSARTWORK} word itself is a convenction name we use to
5cee2c
define which object/design area, inside a design template, the
13b177
@file{centos-art.sh} script will use to export as
13b177
@acronym{PNG,Portable Network Graphic} image at rendition time.
13b177
Whithout such object id specification, the @file{centos-art.sh} script
13b177
cannot know what object/design area you (as designer) want to export
13b177
as @acronym{PNG,Portable Network Graphic} image file.
13b177
13b177
@quotation
13b177
@strong{Note} At rendition time, the content of @file{Img/} directory
13b177
structure is produced by @file{centos-art.sh} automatically.
13b177
@end quotation
13b177
13b177
When a renderable identity directory structure is configured to
13b177
produce image-based content, @file{centos-art.sh} produces
13b177
@acronym{PNG,Portable Network Graphics} files with the @code{.png}
13b177
extension. Once the base image format has been produced, it is
13b177
possible for @file{centos-art.sh} to use it in order to automatically
13b177
create other image formats that may be needed (@pxref{trunk Scripts
13b177
Bash Functions Render Config}).
5cee2c
5cee2c
Inside the working copy, you can find an example of ``design template
5cee2c
without translation'' configuration at @file{trunk/Identity/Models/}.
5cee2c
5cee2c
@xref{trunk Identity}, for more information.
5cee2c
5cee2c
@item One translation directory structure:
5cee2c
5cee2c
In order for an identity entry to be considered an identity renderable
5cee2c
directory structure, it should have a translation entry. The content
13b177
of the translation entry is relevant to determine how to process the
13b177
identity renderable directory entry.
5cee2c
5cee2c
If the translation entry is empty (i.e., there is no file inside it),
5cee2c
@file{centos-art.sh} interprets the identity renderable directory
5cee2c
structure as a ``design templates without translation'' configuration.
5cee2c
5cee2c
@verbatim
13b177
                   | The bond component
13b177
                   |----------------->|
13b177
trunk/Translations/Identity/Path/To/Dir
5cee2c
`-- (empty)
5cee2c
@end verbatim
5cee2c
5cee2c
If the translation entry is not empty, @file{centos-art.sh} can
13b177
interpret the identity renderable directory structure as one of the
13b177
following configurations: ``design template with translation
13b177
(one-to-one)'' or ``design template with translation (optimized)''.
13b177
Which one of these configurations is used depends on the value
13b177
assigned to the matching list (@var{MATCHINGLIST}) variable in the
13b177
pre-rendition configuration script of the renderable identity
13b177
directory structure we are producing images for.
5cee2c
5cee2c
If the matching list variable is empty (as it is by default), then
13b177
``design template with translation (one-to-one)'' configuration is
5cee2c
used. In this configuration it is required that both design templates
13b177
and translation files have the same file names. This way, @emph{one}
13b177
translation files is applied to @emph{one} design template, to produce
13b177
@emph{one} translated image.
5cee2c
5cee2c
If the matching list variable is not empty (because you redefine it in
13b177
the pre-rendition configuration script), then ``design template with
13b177
translation (optimized)'' configuration is used instead. In this
5cee2c
configuration, design templates and translation files don't need to
13b177
have the same names since such name relationship between them is
13b177
specified in the matching list properly.
5cee2c
5cee2c
@xref{trunk Translations}, for more information.
5cee2c
5cee2c
@item One pre-rendition configuration script:
5cee2c
13b177
In order to make an identity directory structure renderable, a
13b177
pre-rendition configuration script should exist for it.  The
13b177
pre-rendition configuration script specifies what type of rendition
13b177
does @file{centos-art.sh} will perform over the identity directory
13b177
structure and how does it do that.
5cee2c
5cee2c
@verbatim
13b177
                                           | The bond component
13b177
                                           |----------------->|
13b177
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
5cee2c
`-- render.conf.sh
5cee2c
@end verbatim
5cee2c
5cee2c
In this configuration the pre-rendition configuration script
5cee2c
(@file{render.conf.sh}) would look like the following:
5cee2c
5cee2c
@verbatim
5cee2c
function render_loadConfig {
5cee2c
5cee2c
    # Define rendition actions.
5cee2c
    ACTIONS[0]='BASE:renderImage'
5cee2c
5cee2c
}
5cee2c
@end verbatim
5cee2c
13b177
Since translation directory structure is empty, @file{centos-art.sh}
13b177
assumes a ``design template without translation'' configuration to
13b177
produce untranslated images.
13b177
5cee2c
To produce untranslated images, @file{centos-art.sh} takes one design
13b177
template and creates one temporal instance from it.  Later,
5cee2c
@file{centos-art.sh} uses the temporal design template instance as
13b177
source file to export the final untranslated image. The action of
13b177
exporting images from @acronym{SVG,Scalable Vector Graphics} to
13b177
@acronym{PNG,Portable Network Graphics} is possible thanks to
13b177
Inkscape's command-line interface and the @code{CENTOSARTWORK} object
13b177
id we previously set inside design templates.
5cee2c
5cee2c
@verbatim
13b177
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
5cee2c
-------------------------------------------------
5cee2c
0 | Execute centos-art.sh on renderable identity directory structure.
5cee2c
--v----------------------------------------------
13b177
trunk/Identity/Path/To/Dir/Tpl/file.svg
5cee2c
-------------------------------------------------
5cee2c
1 | Create instance from design template.
5cee2c
--v----------------------------------------------
5cee2c
/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
5cee2c
-------------------------------------------------
5cee2c
2 | Render untranslated image from design template instance.
5cee2c
--v----------------------------------------------
5cee2c
trunk/Identity/NewDir/Img/file.png
5cee2c
-------------------------------------------------
5cee2c
3 | Remove design template instance.
5cee2c
@end verbatim
5cee2c
5cee2c
Finally, when the untranslated image has been created, the temporal
13b177
design template instance is removed. At this point,
13b177
@file{centos-art.sh} takes the next design template and repeats the
13b177
whole production flow once again (design template by design template),
13b177
until all design templates be processed.
5cee2c
5cee2c
@xref{trunk Scripts Bash Functions Render Config}, for more
5cee2c
information.
5cee2c
@end table
2563c2
5cee2c
@subsubsection Design template with translation (one-to-one)
5cee2c
5cee2c
Producing untranslated images is fine in many cases, but not always.
5cee2c
Sometimes it is required to produce images in different languages and
5cee2c
that is something that untrasnlated image production cannot achieve.
5cee2c
However, if we fill its empty translation entry with translation files
5cee2c
(one for each design template) we extend the production flow from
5cee2c
untranslated image production to translated image production.
5cee2c
5cee2c
In order for @file{centos-art.sh} to produce images correctly, each
5cee2c
design template should have one translation file and each translation
5cee2c
file should have one design template.  Otherwise, if there is a
5cee2c
missing design template or a missing translation file,
5cee2c
@file{centos-art.sh} will not produce the final image related to the
5cee2c
missing component.
5cee2c
5cee2c
In order for @file{centos-art.sh} to know which is the relation
5cee2c
between translation files and design templates the translation
5cee2c
directory structure is taken as reference.  For example, the
13b177
@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation
13b177
file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design
13b177
template, but it doesn't match
13b177
@file{trunk/Identity/Path/To/Dir/File.svg} or
13b177
@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or
13b177
@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design
13b177
templates.
5cee2c
5cee2c
The pre-rendition configuration script used to produce untranslated
5cee2c
images is the same we use to produce translated images. There is no
5cee2c
need to modify it. So, as we are using the same pre-rendition
5cee2c
configuration script, we can say that translated image production is
5cee2c
somehow an extended/improved version of untranslated image production.
5cee2c
5cee2c
@quotation
5cee2c
@strong{Note} If we use no translation file in the translation entry
5cee2c
(i.e., an empty directory), @file{centos-art.sh} assumes the
5cee2c
untranslated image production. If we fill the translation entry with
5cee2c
translation files, @file{centos-art.sh} assumes the translated image
5cee2c
production.  
5cee2c
@end quotation
5cee2c
5cee2c
To produce final images, @file{centos-art.sh} applies one translation
5cee2c
file to one design template and produce a translated design template
5cee2c
instance. Later, @file{centos-art.sh} uses the translated template
5cee2c
instance to produce the translated image. Finally, when the translated
5cee2c
image has been produced, @file{centos-art.sh} removes the translated
5cee2c
design template instance. This production flow is repeated for each
5cee2c
translation file available in the translatio entry. 
5cee2c
5cee2c
@verbatim
13b177
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
5cee2c
-------------------------------------------------
5cee2c
0 | Execute centos-art.sh on directory structure.
5cee2c
--v----------------------------------------------
13b177
trunk/Translations/Identity/Path/To/Dir/file.sed
5cee2c
-------------------------------------------------
5cee2c
1 | Apply translation to design template.
5cee2c
--v----------------------------------------------
13b177
trunk/Identity/Path/To/Dir/Tpl/file.svg
5cee2c
-------------------------------------------------
5cee2c
2 | Create design template instance.
5cee2c
--v----------------------------------------------
5cee2c
/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
5cee2c
-------------------------------------------------
5cee2c
3 | Render PNG image from template instance.
5cee2c
--v----------------------------------------------
5cee2c
trunk/Identity/NewDir/Img/file.png
5cee2c
-------------------------------------------------
5cee2c
4 | Remove design template instance.
2563c2
@end verbatim
2563c2
5cee2c
@subsubsection Design template with translation (optimized)
5cee2c
5cee2c
Producing translated images satisfies almost all our production images
5cee2c
needs, but there is still a pitfall in them. In order to produce
5cee2c
translated images as in the ``one-to-one'' configuration describes
5cee2c
previously, it is required that one translation file has one design
5cee2c
template. That's useful in many cases, but what would happen if we
5cee2c
need to apply many different translation files to the same design
5cee2c
template?  Should we have to duplicate the same design template file
5cee2c
for each translation file, in order to satisfy the ``one-to-one''
5cee2c
relation? What if we need to assign translation files to design
5cee2c
templates arbitrarily?
5cee2c
5cee2c
Certenly, that's something the ``one-to-one'' configuration cannot
5cee2c
handle.  So, that's why we had to ``optimize'' it. The optimized
5cee2c
configuration consists on using a matching list (@var{MATCHINGLIST})
5cee2c
variable that specifies the relationship between translation files and
5cee2c
design templates in an arbitrary way. Using such matching list between
5cee2c
translation files and design templates let us use as many assignment
5cee2c
combinations as translation files and design templates we are working
5cee2c
with.
5cee2c
5cee2c
The @var{MATCHINGLIST} variable is set in the pre-rendition
5cee2c
configuration script of the component we want to produce images for.
5cee2c
By default, the @var{MATCHINGLIST} variable is empty which means no
5cee2c
matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a
5cee2c
value different to empty value then, @file{centos-art.sh} interprets
5cee2c
the matching list in order to know how translation files are applied
5cee2c
to design templates.
5cee2c
5cee2c
For example, consider the following configuration:
5cee2c
5cee2c
@table @strong
5cee2c
@item One entry under @file{trunk/Identity/}:
5cee2c
5cee2c
In this configuration we want to produce three images using a
5cee2c
paragraph-based style, controlled by @file{paragraph.svg} design
5cee2c
template; and one image using a list-based style, controlled by
5cee2c
@file{list.svg} design template.
2563c2
2563c2
@verbatim
13b177
trunk/Identity/Path/To/Dir
5cee2c
|-- Tpl
5cee2c
|   |-- paragraph.svg
5cee2c
|   `-- list.svg
5cee2c
`-- Img
5cee2c
    |-- 01-welcome.png
5cee2c
    |-- 02-donate.png
5cee2c
    |-- 03-docs.png
5cee2c
    `-- 04-support.png
2563c2
@end verbatim
2563c2
5cee2c
@item One entry under @file{trunk/Translations/}:
2563c2
5cee2c
In order to produce translated images we need to have one translation
5cee2c
file for each translated image we want to produce. Notice how
5cee2c
translation names do match final image file names, but how translation
5cee2c
names do not match design template names. When we use matching list
5cee2c
there is no need for translation files to match the names of design
5cee2c
templates, such name relation is set inside the matching list itself.
2563c2
5cee2c
@verbatim
13b177
trunk/Translations/Identity/Path/To/Dir
5cee2c
|-- 01-welcome.sed
5cee2c
|-- 02-donate.sed
5cee2c
|-- 03-docs.sed
5cee2c
`-- 04-support.sed
5cee2c
@end verbatim
5cee2c
5cee2c
@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}:
2563c2
5cee2c
In order to produce different translated images using specific design
5cee2c
templates, we need to specify the relation between translation files
5cee2c
and design templates in a way that @file{centos-art.sh} could know
5cee2c
exactly what translation file to apply to what design template. This
5cee2c
relation between translation files and design templates is set using
5cee2c
the matching list @var{MATCHINGLIST} variable inside the pre-rendition
5cee2c
configuration script of the component we want to produce images for.  
5cee2c
5cee2c
@verbatim
13b177
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
5cee2c
`-- render.conf.sh
5cee2c
@end verbatim
2563c2
5cee2c
In this configuration the pre-rendition configuration script
5cee2c
(@file{render.conf.sh}) would look like the following:
2563c2
5cee2c
@verbatim
5cee2c
function render_loadConfig {
5cee2c
5cee2c
    # Define rendition actions.
5cee2c
    ACTIONS[0]='BASE:renderImage'
5cee2c
5cee2c
    # Define matching list.
5cee2c
    MATCHINGLIST="\
5cee2c
    paragraph.svg:\
5cee2c
        01-welcome.sed\
5cee2c
        02-donate.sed\
5cee2c
        04-support.sed
5cee2c
    list.svg:\
5cee2c
        03-docs.sed
5cee2c
    "
5cee2c
5cee2c
}
5cee2c
@end verbatim
2563c2
5cee2c
As result, @file{centos-art.sh} will produce @file{01-welcome.png},
5cee2c
@file{02-donate.png} and @file{04-support.png} using the
5cee2c
paragraph-based design template, but @file{03-docs.png} using the
5cee2c
list-based design template.
5cee2c
@end table
2563c2
5cee2c
@subsubsection Design template with translation (optimized+flexibility)
5cee2c
5cee2c
In the production models we've seen so far, there are design templates
5cee2c
to produce untranslated images and translation files which combiend
5cee2c
with design templates produce translated images. That may seems like
5cee2c
all our needs are covered, doesn't it? Well, it @emph{almost} does.
5cee2c
5cee2c
Generally, we use design templates to define how final images will
5cee2c
look like. Generally, each renderable directory structure has one
5cee2c
@file{Tpl/} directory where we organize design templates for that
5cee2c
identity component. So, we can say that there is only one unique
5cee2c
design template definition for each identity component; or what is the
5cee2c
same, said differently, identity components can be produced in one way
5cee2c
only, the way its own design template directory specifies.  This is
5cee2c
not enough for theme production. It is a limitation, indeed.
5cee2c
5cee2c
Initially, to create one theme, we created one renderable directory
5cee2c
structure for each theme component. When we found ourselves with many
5cee2c
themes, and components inside them, it was obvious that the same
5cee2c
design model was duplicated inside each theme. As design models were
5cee2c
independently one another, if we changed one theme's design model,
5cee2c
that change was useless to other themes. So, in order to reuse design
5cee2c
model changes, we unified design models into one common directory
5cee2c
structure.
5cee2c
5cee2c
With design models unified in a common structure, another problem rose
5cee2c
up. As design models also had the visual style of theme components,
5cee2c
there was no difference between themes, so there was no apparent need
5cee2c
to have an independent theme directory structure for each different
5cee2c
theme.  So, it was also needed to separate visual styles from design
5cee2c
models.
5cee2c
5cee2c
At this point there are two independent worklines: one directory
5cee2c
structure to store design models (the final image characteristics
5cee2c
[i.e., dimensions, translation markers, etc.]) and one directory
5cee2c
structure to store visual styles (the final image visual style [i.e.,
5cee2c
the image look and feel]).  So, it is possible to handle both
5cee2c
different design models and different visual styles independtly one
5cee2c
another and later create combinations among them using
5cee2c
@file{centos-art.sh}. 
5cee2c
5cee2c
For example, consider the following configuration:
5cee2c
5cee2c
@table @strong
5cee2c
@item One entry under @file{trunk/Identity/Themes/Models/}:
5cee2c
5cee2c
The design model entry exists to organize design model files (similar
5cee2c
to design templates). Both design models and design templates are very
5cee2c
similar; they both should have the @code{CENTOSARTWORK} export id
5cee2c
present to identify the exportation area, translation marks, etc.
5cee2c
However, design models do use dynamic backgrounds inclusion while
5cee2c
design templates don't.
2563c2
5cee2c
@verbatim
13b177
                        THEMEMODEL | | The bond component
5cee2c
                             |<----| |--------------------->|
5cee2c
trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
5cee2c
|-- paragraph.svg
5cee2c
`-- list.svg
5cee2c
@end verbatim
2563c2
5cee2c
Inisde design models, dynamic backgrounds are required in order for
5cee2c
different artistic motifs to reuse common design models. Firstly, in
5cee2c
order to create dynamic backgrounds inside design models, we import a
5cee2c
bitmap to cover design model's background and later, update design
5cee2c
model's path information to replace fixed values to dynamic values.
2563c2
5cee2c
@item One entry under @file{trunk/Identity/Themes/Motifs/}:
2563c2
5cee2c
The artistic motif entry defines the visual style we want to produce
5cee2c
images for, only. Final images (i.e., those built from combining both
5cee2c
design models and artistic motif backrounds) are not stored here, but
5cee2c
under branches directory structure. In the artistic motif entry, we
5cee2c
only define those images that cannot be produced automatically by
5cee2c
@file{centos-art.sh} (e.g., Backgrounds, Color information,
5cee2c
Screenshots, etc.).
2563c2
5cee2c
@verbatim
5cee2c
                  Artistic motif name | | Artistic motif backgrounds
5cee2c
                             |<-------| |-------->|
5cee2c
trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
5cee2c
|-- Img
5cee2c
|   |-- Png
5cee2c
|   |   |-- 510x300.png
5cee2c
|   |   `-- 510x300-final.png
5cee2c
|   `-- Jpg
5cee2c
|       |-- 510x300.jpg
5cee2c
|       `-- 510x300-final.jpg
5cee2c
|-- Tpl
5cee2c
|   `-- 510x300.svg
5cee2c
`-- Xcf
5cee2c
    `-- 510x300.xcf
5cee2c
@end verbatim
2563c2
5cee2c
@item One entry under @file{trunk/Translations/}:
5cee2c
5cee2c
The translation entry specifies, by means of translation files, the
5cee2c
language-specific information we want to produce image for. When we
5cee2c
create the translation entry we don't use the name of neither design
5cee2c
model nor artistic motif, just the design model component we want to
5cee2c
produce images for.
5cee2c
5cee2c
@verbatim
13b177
                                   | The bond component
5cee2c
                                   |--------------------->|
5cee2c
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
5cee2c
`-- 5
5cee2c
    |-- en
5cee2c
    |   |-- 01-welcome.sed
5cee2c
    |   |-- 02-donate.sed
5cee2c
    |   `-- 03-docs.sed
5cee2c
    `-- es
5cee2c
        |-- 01-welcome.sed
5cee2c
        |-- 02-donate.sed
5cee2c
        `-- 03-docs.sed
5cee2c
@end verbatim
5cee2c
5cee2c
@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}:
5cee2c
5cee2c
There is one pre-rendition configuration script for each theme
5cee2c
component. So, each time a theme component is rendered, its
5cee2c
pre-rendition configuration script is evaluated to teach
5cee2c
@file{centos-art.sh} how to render the component.
5cee2c
5cee2c
@verbatim
5cee2c
trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
5cee2c
`-- render.conf.sh
5cee2c
@end verbatim
5cee2c
5cee2c
In this configuration the pre-rendition configuration script
5cee2c
(@file{render.conf.sh}) would look like the following:
5cee2c
5cee2c
@verbatim
5cee2c
function render_loadConfig {
5cee2c
5cee2c
    # Define rendition actions.
5cee2c
    ACTIONS[0]='BASE:renderImage'
5cee2c
5cee2c
    # Define matching list.
5cee2c
    MATCHINGLIST="\
5cee2c
    paragraph.svg:\
5cee2c
        01-welcome.sed\
5cee2c
        02-donate.sed
5cee2c
    list.svg:\
5cee2c
        03-docs.sed
5cee2c
        "
5cee2c
5cee2c
    # Deifne theme model.
5cee2c
    THEMEMODEL='Default'
5cee2c
5cee2c
}
5cee2c
@end verbatim
2563c2
@end table
2563c2
5cee2c
The production flow of ``optimize+flexibility'' configuration@dots{}
5cee2c
@subsection Renderable translation directory structures
5cee2c
5cee2c
Translation directory structures are auxiliar structures of renderable
5cee2c
identity directory structures. There is one translation directory
5cee2c
structure for each renderable identity directory structure.  Inside
5cee2c
translation directory structures we organize translation files used by
5cee2c
renderable identity directory structures that produce translated
5cee2c
images. Renderable identity directory structures that produce
5cee2c
untranslated images don't use translation files, but they do use a
5cee2c
translation directory structure, an empty translation directory
5cee2c
structure, to be precise.
5cee2c
5cee2c
In order to aliviate production of translation file, we made
5cee2c
translation directory structures renderable adding a template
5cee2c
(@file{Tpl/}) directory structure to handle common content inside
5cee2c
translation files.  This way, we work on translation templates and
5cee2c
later use @file{centos-art.sh} to produce specific translation files
5cee2c
(based on translation templates) for different information (e.g.,
5cee2c
languages, release numbers, architectures, etc.).  
5cee2c
5cee2c
If for some reason, translation files get far from translation
5cee2c
templates and translation templates become incovenient to produce such
5cee2c
translation files then, care should be taken to avoid replacing the
5cee2c
content of translation files with the content of translation templates
5cee2c
when @file{centos-art.sh} is executed to produce translation files
5cee2c
from translation templates.
5cee2c
5cee2c
Inside renderable translation directory structures,
5cee2c
@file{centos-art.sh} can produce text-based files only.
5cee2c
5cee2c
@subsection Copying renderable directory structures 
2563c2
2563c2
A renderable layout is formed by design models, design images,
2563c2
pre-rendition configuration scripts and translations files. This way,
2563c2
when we say to duplicate rendition stuff we are saying to duplicate
2563c2
these four directory structures (i.e., design models, design images,
2563c2
pre-rendition configuration scripts, and related translations files).
2563c2
2563c2
When we duplicate directories, inside `trunk/Identity' directory
2563c2
structure, we need to be aware of renderable layout described above
6a9758
and the source location used to perform the duplication action.  The
6a9758
source location is relevant to centos-art.sh script in order to
2563c2
determine the required auxiliar information inside directory
2563c2
structures that need to be copied too (otherwise we may end up with
2563c2
orphan directory structures unable to be rendered, due the absence of
2563c2
required information).
2563c2
2563c2
In order for a renderable directory structure to be valid, the new
2563c2
directory structure copied should match the following conditions:
2563c2
2563c2
@enumerate
2563c2
@item To have a unique directory structure under
2563c2
@file{trunk/Identity}, organized by any one of the above
2563c2
organizational designs above.
2563c2
2563c2
@item To have a unique directory structure under
2563c2
@file{trunk/Translations} to store translation files.
2563c2
2563c2
@item To have a unique directory structure under
2563c2
@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition
2563c2
configuration script.
2563c2
@end enumerate
2563c2
2563c2
As convenction, the @code{render_doCopy} function uses
2563c2
@file{trunk/Identity} directory structure as source location.  Once
2563c2
the @file{trunk/Identity} directory structure has been specified and
2563c2
verified, the related path information is built from it and copied
2563c2
automatically to the new location specified by @var{FLAG_TO} variable.
2563c2
5cee2c
Design templates + No translation:
2563c2
2563c2
Command:
13b177
- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir
2563c2
2563c2
Sources:
13b177
- trunk/Identity/Path/To/Dir
13b177
- trunk/Translations/Identity/Path/To/Dir
13b177
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
2563c2
2563c2
Targets:
13b177
- trunk/Identity/NewPath/To/Dir
13b177
- trunk/Translations/Identity/NewPath/To/Dir
13b177
- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir
2563c2
2563c2
Renderable layout 2:
2563c2
2563c2
Command:
2563c2
- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \
13b177
                    --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir
2563c2
2563c2
Sources:
2563c2
- trunk/Identity/Themes/Motifs/TreeFlower
2563c2
- trunk/Translations/Identity/Themes
2563c2
- trunk/Translations/Identity/Themes/Motifs/TreeFlower
2563c2
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
2563c2
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower
2563c2
2563c2
Targets:
13b177
- trunk/Identity/Themes/Motifs/NewPath/To/Dir
2563c2
- trunk/Translations/Identity/Themes
13b177
- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir
2563c2
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
13b177
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir
2563c2
2563c2
Notice that design models are not included in source or target
2563c2
locations. This is intentional. In ``Renderable layout 2'', design
2563c2
models live by their own, they just exist, they are there, available
2563c2
for any artistic motif to use. By default `Themes/Models/Default'
2563c2
design model directory structure is used, but other design models
2563c2
directory structures (under Themes/Models/) can be created and used
2563c2
changing the value of THEMEMODEL variable inside the pre-rendition
2563c2
configuration script of the artistic motif source location you want to
2563c2
produce.
2563c2
2563c2
Notice how translations and pre-rendition configuration scripts may
2563c2
both be equal in source and target. This is because such structures
2563c2
are common to all artistic motifs (the default values to use when no
2563c2
specific values are provided).
2563c2
2563c2
- The common directory structures are not copied or deleted. We cannot
2563c2
  copy a directory structure to itself.
2563c2
2563c2
- The common directory structures represent the default value to use
2563c2
  when no specific translations and/or pre-rendition configuration
2563c2
  script are provided inside source location.
2563c2
2563c2
- The specific directory structures, if present, are both copiable and
2563c2
  removable. This is, when you perform a copy or delete action from
2563c2
  source, that source specific auxiliar directories are transfered in
2563c2
  the copy action to a new location (that specified by FLAG_TO
2563c2
  variable).
2563c2
2563c2
- When translations and/or pre-rendition configuration scripts are
2563c2
  found inside the source directory structure, the centos-art.sh
2563c2
  script loads common auxiliar directories first and later specific
2563c2
  auxiliar directories.  This way, identity rendition of source
2563c2
  locations can be customized idividually over the base of common
2563c2
  default values.
2563c2
2563c2
- The specific auxiliar directories are optional.
2563c2
2563c2
- The common auxiliar directories should be present always. This is,
2563c2
  in order to provide the information required by render functionality
2563c2
  (i.e., to make it functional in the more basic level of its
2563c2
  existence).
2563c2
2563c2
Notice how the duplication process is done from `trunk/Identity' on,
2563c2
not the oposite. If you try to duplicate a translation structure (or
2563c2
similar auxiliar directory structures like pre-rendition configuration
2563c2
scripts), the `trunk/Identity' for that translation is not created.
2563c2
This limitation is impossed by the fact that many `trunk/Identity'
2563c2
directory structures may reuse/share the same translation directory
2563c2
structure. We cannot delete one translation (or similar) directory
2563c2
structures while a related `trunk/Identity/' directory structure is
2563c2
still in need of it.
2563c2
2563c2
The `render_doCopy' functionality does duplicate directory structures
2563c2
directly involved in rendition process only. Once such directories
2563c2
have been duplicated, the functionality stops thereat. 
5fb024
5fb024
@subsection Usage
5fb024
5fb024
@itemize
5fb024
@item ...
5fb024
@end itemize
5fb024
5fb024
@subsection See also
5fb024
5fb024
@menu
5fb024
* trunk Scripts Bash Functions Render Config::
5fb024
@end menu