------------------------------------------------------------

* Rename trunk/Identity/Models/ to trunk/Identity/Manuals/

* Reduce attention on the idea of creating a big book holding all

  about CentOS corporate visual identity. The trunk/Identity/Manuals/

  structure starts replacing the trunk/Manuals/ structure.  All ideas

  inside trunk/Manuals need to be moved to trunk/Identity/Manuals

  common visual style.

* As both manuals and design models get growing, I've found that

  using a set of scalable vector graphic as design templates/models

  --to define how illustrations look like--, and a set of translation

  files --to define the illustrations language-- to describe small

  ideas is more flexible (since an innovative graphic design point of

  view) than creating a big book describing all the same small ideas

  by means of texts and illustrations using LaTeX format.

  Using scalable vector graphics design templates/models and

  translation files to produce multi-language illustrations is

  straightforward.

    Note: translation files are applied to design templates using

    rendering scripts.

* Inside trunk/Identity/Manuals/, the format used to create each

  specific flayer is A4-Landscape (297x210mm).

------------------------------------------------------------

* Inside Themes structure similar design templates are repeated

  constantly.  In order to optimeze Themes' structure, split Themes'

  structure in the following two structures:

    1. trunk/Identity/Themes/Models: This structure contains design

       templates (SVG) only. 

       Models structure is organized by Names (e.g., Default,

       Alternative, etc.).  Convenctional models define art work

       sizes, formats and position of elements in the screen.

       For example, inside models structure is where you set that

       Anaconda Header art work is 800x88 pixels, the anaconda splash

       is about 510x300 pixels, the GDM non-graphical definitions

       (i.e., .xml, and .desktop files.), and so on.

    2. trunk/Identity/Themes/Motifs: This structure contains artistic

       motifs images (e.g.: .xcf, .png, .jpg, .xpm, .ppm, etc.) and

       rendering scripts only[1].

            [1]: Rendering script files are currently inside each

            renderable art work structure. In the near future,

            rendering script files will be replaced by a command line

            utility.

       As previously set, Motifs strcutre is organized by Names (e.g.,

       Modern, TreeFlower, etc.). Each name represents one artistic

       motif. Convenctional artistic motifs define visual style for

       CentOS distribution (Distro), promotion (Promo), and web sites

       (Web). Conventional artisitc motifs structure, also, covers

       specific artistic motif's design, copyright note, license

       (CC-SA), author(s), color, and palettes[2].

            [2]: Palette files are required to produce color-limited

            images, automatically. Two examples of color-limited

            images are anaconda prompt (indexed to 16 colors), and

            GRUB splash (indexed to 14 colors).

       A relevant directory inside each artistic motif structure is

       that used for Backgrounds (Distro/Backgrounds/). The background

       directory stores images for many different sizes and screen

       resolutions. Images inside background directory are passed

       through Models design templates to produce the theme's final

       images.

------------------------------------------------------------

* /branches/Identity/Themes/$THEME/$BRANCH_ID/ 

  This structure is used to store alternative theme designs that share

  one common design concept. The common design concept is defined at

  /trunk/Identity/Themes/$THEME/.

    - `$THEME': is a case-sensitive name that match one name under

      /trunk/Identity/Themes/ (e.g., Modern, TreeFlower, etc.).

    - `$BRANCH_ID': represents a unique serial number used to identify

      the branch (e.g., 1.0, 2.0, 3.0, etc.).

  For example, if you have a different design proposition (e.g., 1.0,

  2.0, and 3.0) based on TreeFlower's concept, then the directory

  structure will look similar to the following:

    /branches/Identity/Themes/TreeFlower/1.0/

    /branches/Identity/Themes/TreeFlower/2.0/

    /branches/Identity/Themes/TreeFlower/3.0/

  You can repeat the previous naming process in cascade as long as

  different graphic designs arise. For example, if you find that a

  completly different design can be derived from 1.0 then you can

  create one branch, named 1.1 to store the idea:

    /branches/Identity/Themes/TreeFlower/1.1/

  The /branches/Identity/Themes/$THEME/$BRANCH_ID/ directory structure

  is the same structure used under trunk. So, all rendering and

  automation scripts available inside trunk structure are available in

  here too.

  The directory structure described in this section is for completly

  different designs, compared with its trunk version. If you only want

  to experiment new ideas around the same turnk design then do not use

  this structure. Instead, go to the Motif's directory in the trunk's

  structure and create a new motif file to work your idea. For

  example:

    /trunk/Identity/Themes/TreeFlower/Motif/motif.svg

    /trunk/Identity/Themes/TreeFlower/Motif/motif-1.svg

    /trunk/Identity/Themes/TreeFlower/Motif/motif-2.svg

    /trunk/Identity/Themes/TreeFlower/Motif/motif-n.svg

  In the above path, the motif.svg file is the theme's default design

  used on distribution, websites, and promotion art works.  The other

  files (i.e., motif-1.svg, motif-2.svg, motif-n.svg) are alternative

  ideas of the same design.

------------------------------------------------------------

* Create/Design a command line utility to achive the same task of

  invocation rendering script (render.sh) files.

  - When invoking the command line utility, users can provide a path,

    absolute or relative, to an specific framework. After verifying

    the provided framework as valid path, image rendering starts for

    that specific framework.

    If no path is provided to the command line utility, print the

    usage message and quit.

    Brain Storm 1: 

    -------------

    If such a command line is created name flexibility inside the

    repository may be limited. 

    Presently, there is one render.sh script inside each renderable

    art work component which points to an entry in the scripts

    configuration structure. If renderable art work components change

    their path, the rendering action is not affected because both

    configuration scripts and translation structures remains immutable

    out of renderable strucutres.

    Thinking how to design an efficient command line interface that

    help us automate most tasks inside CentOS Artwork Repository, I

    propose to realy on a strong name convenction to bond renderable

    structures, scripts, and translations files altogether.

    Presently, invokation rendering scripts call one configuration

    file. The configuration file defines which task(s) to do and what

    function(s) to call for that art work, that one the rendering

    script was invoked from. For brevity, a function initialization

    script is called to make all functions available inside the

    configuration script and functions loaded inside it.

    If the invokation script is removed, we have to find some way to

    make that bond between renderable art work component and

    configuration script. The first idea coming to my mind is using

    some kind of name convenction on paths so we could relay on it.

    For exmample, if you are inside the following directory, or

    provide it to the command line utility:

        Themes/Motifs/Modern/Info

    The command line utility should verify if that directory exists

    firstly, and later if it has a configuration script associated. To

    determine which configuration script is associated with this path

    we need to build a common path that can be compared no matter

    where the command line utility was invoked from. For example,

    taken the above path as reference, we could build such a common

    path using its absolute path:

        /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Info

    And later, manipulate the string to build its assiciated

    configuration script. The manipulation, relays on the following

    name convenction: 

        - Insert the Scripts/Bash/Config/ string before Identity/

        - Remove the theme' name (e.g., Modern/) from the string.

        Note: Pay attention to trailing slashes. They are part of

        string manipulation.

    This convenction produces the following path:

        /home/centos/artwork/trunk/Scripts/Bash/Config/Identity/Themes/Motifs/Info

    If the above configuration directory exists, and it has the

    render.conf.sh script inside, then it can be assumed as a valid

    configuration entry in the configuration structure. Otherwise

    there is no configuartion file for the specified framework, and by

    extension no actions related to it. 

        Note: Actions are based one functions loaded in the

        render.conf.sh script. If the script render.conf.sh is empty,

        or malformed you will have a result of the same nature.

    This schema relays completly on names convenctions. So in order to

    the command line utility to work, the repository should have a

    strong name convenction and changes to it need to be carefuly

    planned before commit them.

  - The command line utility should provide the following:

    - List of valid frameworks: This feature lets users to know

      available frameworks where the command line utility can be used

      for image rendering inside CentOS Artwork Repository.

    - Usage message: This functionality lets the user to know how to

      use the command line utility. It resumes available options and

      features.

    - Online framework documentation: This feature lets users request

      information about specific art works and available actions

      inside CentOS Artwork Repository, anywhere, anytime.

    - ...

* Remove invocation rendering script (render.sh) files.