<section>

    <title>Connection between directories</title>

    <para>In order to produce content in CentOS Artwork Repository, it

    is required that all work lines be connected somehow.  This is the

    way automation scripts can know where to retrive the information

    they need to work with (e.g., design model, translation messages,

    output location, etc.).  We build this kind of connection using

    two path constructions named @emph{master paths} and

    @emph{auxiliar paths}.</para>

    <para>The master path points only to directories that contain the

    source files (e.g., SVG files) required to produce base content

    (e.g., PNG files) through automation scripts.  Each master path

    inside the repository may have several auxiliar paths associated,

    but auxiliar paths can only have one master path

    associated.</para>

    <para>The auxiliar paths can point either to directories or files.

    When an auxiliar path points to a directory, that directory

    contains information that modifies somehow the content produced

    from master paths (e.g., translation messages) or provides the

    output information required to know where to store the content

    produced from master path.  When an auxiliar path points to a

    file, that file has no other purpose but to document the master

    path it refers to.</para>

    <para>The relation between auxiliar paths and master paths is

    realized combining two path informations which are: the master

    path itself and one second level directory structure from the

    repository.  Generally, the master path is considered the path

    identifier and the second level directory structure taken from the

    repository is considered the common part of the path where the

    identifier is appended.</para>

    <programlisting>-----+---------------+----------------------------+------+-----------

    Path | Suffix        | Identifier                 |Prefix| Type

    -----+---------------+----------------------------+------+-----------

    A  |               |trunk/Identity/Models/Brands|      | Directory

    -----+---------------+----------------------------+------+-----------

    B  |  trunk/Manual/|trunk/Identity/Models/Brands|.texi | File

    -----+---------------+----------------------------+------+-----------

    C  | trunk/Locales/|trunk/Identity/Models/Brands|      | Directory

    -----+---------------+----------------------------+------+-----------

    D  |               |trunk/Identity/Images/Brands|      | Directory

    -----+---------------+----------------------------+------+-----------

    E  | trunk/Locales/|trunk/Identity/Images/Brands|.texi | File

    -----+---------------+----------------------------+------+-----------

    A = Master path.  B = Auxiliar path to documentation entry.  C =

    Auxiliar path to translation messages.  D = Auxiliar path to final

    content output.  E = Auxiliar path to documentation entry.

    </programlisting>

    <para>The path information described above (@pxref{Path

    construction}) is used by direct rendition and can be taken as

    reference to add other components that are equally produced in the

    repository.  To add new components that make use of direct

    rendition inside the repository, change just the component name

    used above (e.g., @file{Brands}) to that one you want to add,

    without changing the path structure around it.</para>

    <para>The file organization used by theme rendition extends direct

    rendition by separating design models information from backgrounds

    information.  To better understand this configuration, you can

    consider it as two independent lists, one of design models and one

    of artistic motifs, which are arbitrary combined between

    themselves in order to render images in specific ways. The

    possibilities of this configuration are endless and let us

    describe visual manifestations very well.  For example, consider

    the organization used to produce @file{Anaconda} images; for

    CentOS distribution major release 5; using @file{Default} design

    models and version @file{3} of @file{Flame} artistic motif:

    <programlisting>-----+---------------+------------------------------------------------------+------+-----------

    Path | Suffix        | Identifier

    |Prefix| Type

    -----+---------------+------------------------------------------------------+------+-----------

    A  |

    |trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|      |

    Directory

    -----+---------------+------------------------------------------------------+------+-----------

    B  |

    trunk/Manual/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|.texi

    | File

    -----+---------------+------------------------------------------------------+------+-----------

    C  |

    trunk/Locales/|trunk/Identity/Models/Themes/Default/Distro/5/Anaconda|

    | Directory

    -----+---------------+------------------------------------------------------+------+-----------

    D  |

    |trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda|      |

    Directory

    -----+---------------+------------------------------------------------------+------+-----------

    E  |

    trunk/Locales/|trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda|.texi

    | File

    -----+---------------+------------------------------------------------------+------+-----------

    A = Master path.  B = Auxiliar path to documentation entry.  C =

    Auxiliar path to translation messages.  D = Auxiliar path to final

    content output.  E = Auxiliar path to documentation entry.

    </programlisting>

    </para>

    <para>The path information described above (@pxref{Path

    construction extended}) is used by theme rendition and can be

    taken as reference to add other components that are equally

    produced in the repository.</para>

    <para>In this configuration we can change both design model name

    (e.g., @file{Default}) and artistic motif name (e.g.,

    @file{Flame/3}) to something else in order to achieve a different

    result. The only limitations impossed are the storage space

    provided in the server machine and your own creativeness as

    graphic designer.</para>

    <note><para>A theme ready for implementation may consume from 100

    MB to 400 MB of storage space. The exact space consumed by a theme

    depends on the amount of screen resolutions the theme supports.

    The more screen resolutions the theme supports, the more storage

    space demanded for it.</para></note>

    <para>In this configuration we saw how to build the path

    information for @file{Anaconda} component as part of CentOS

    Distribution visual manifestation, but that is not the only

    component we have inside CentOS Distribution visual manifestation.

    There are other components like Syslinux, Grub, Rhgb, Gdm, Kdm,

    Gsplash and Ksplash that share a similar file organization to that

    described above for @file{Anaconda} component.</para>

</section>