|
 |
4c79b5 |
|
|
|
4c79b5 |
<html>
|
|
|
ccb7a3 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
Permission is granted to copy, distribute and/or modify this document
|
|
|
4c79b5 |
under the terms of the GNU Free Documentation License, Version 1.2 or
|
|
|
4c79b5 |
any later version published by the Free Software Foundation; with no
|
|
|
4c79b5 |
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
|
|
|
4c79b5 |
copy of the license is included in the section entitled GNU Free
|
|
|
4c79b5 |
Documentation License.
|
|
|
4c79b5 |
-->
|
|
|
4a9d2a |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
|
4c79b5 |
Karl Berry <karl@freefriends.org>
|
|
|
4c79b5 |
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
|
4c79b5 |
and many others.
|
|
|
4c79b5 |
Maintained by: Many creative people <dev@texi2html.cvshome.org>
|
|
|
4c79b5 |
Send bugs and suggestions to <users@texi2html.cvshome.org>
|
|
|
4c79b5 |
|
|
|
4c79b5 |
-->
|
|
|
4c79b5 |
<head>
|
|
|
4a9d2a |
<title>CentOS Artwork Repository: 3.53 trunk/Scripts/Bash/Functions/Render</title>
|
|
|
4c79b5 |
|
|
|
4a9d2a |
<meta name="description" content="CentOS Artwork Repository: 3.53 trunk/Scripts/Bash/Functions/Render">
|
|
|
4a9d2a |
<meta name="keywords" content="CentOS Artwork Repository: 3.53 trunk/Scripts/Bash/Functions/Render">
|
|
|
4c79b5 |
<meta name="resource-type" content="document">
|
|
|
4c79b5 |
<meta name="distribution" content="global">
|
|
|
4c79b5 |
<meta name="Generator" content="texi2html 1.76">
|
|
|
4c79b5 |
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
|
4c79b5 |
<style type="text/css">
|
|
|
4c79b5 |
|
|
|
1e9202 |
@import "/home/centos/artwork/trunk/Identity/Models/Css/Texi2html/common.css";
|
|
|
4c79b5 |
|
|
|
4c79b5 |
a.summary-letter {text-decoration: none}
|
|
|
4c79b5 |
pre.display {font-family: serif}
|
|
|
4c79b5 |
pre.format {font-family: serif}
|
|
|
4c79b5 |
pre.menu-comment {font-family: serif}
|
|
|
4c79b5 |
pre.menu-preformatted {font-family: serif}
|
|
|
4c79b5 |
pre.smalldisplay {font-family: serif; font-size: smaller}
|
|
|
4c79b5 |
pre.smallexample {font-size: smaller}
|
|
|
4c79b5 |
pre.smallformat {font-family: serif; font-size: smaller}
|
|
|
4c79b5 |
pre.smalllisp {font-size: smaller}
|
|
|
4c79b5 |
span.sansserif {font-family:sans-serif; font-weight:normal;}
|
|
|
4c79b5 |
ul.toc {list-style: none}
|
|
|
4c79b5 |
-->
|
|
|
4c79b5 |
</style>
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
</head>
|
|
|
4c79b5 |
|
|
|
4c79b5 |
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4a9d2a |
[ < ]
|
|
|
4a9d2a |
[ > ]
|
|
|
4c79b5 |
|
|
|
300762 |
[ << ]
|
|
|
300762 |
[ Up ]
|
|
|
4a9d2a |
[ >> ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
[Top]
|
|
|
4c79b5 |
[Contents]
|
|
|
4a9d2a |
[Index]
|
|
|
4c79b5 |
[ ? ]
|
|
|
4c79b5 |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53 trunk/Scripts/Bash/Functions/Render
|
|
|
3f9ae1 |
|
|
|
4a9d2a |
The render functionality exists to produce both identity and
|
|
|
4a9d2a |
translation files on different levels of information (i.e., different
|
|
|
4a9d2a |
languages, release numbers, architectures, etc.).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The render functionality relies on "renderable directory
|
|
|
4a9d2a |
structures" to produce files. Renderable directory structures can be
|
|
|
4a9d2a |
either "identity directory structures" or "translation directory
|
|
|
4a9d2a |
structures" with special directories inside.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.1 Renderable identity directory structures
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Renderable identity directory structures are the starting point of
|
|
|
4a9d2a |
identity rendition. Whenever we want to render a component of CentOS
|
|
|
4a9d2a |
corporate visual identity, we need to point <tt>`centos-art.sh'</tt> to a
|
|
|
4a9d2a |
renderable identity directory structure. If such renderable identity
|
|
|
4a9d2a |
directory structure doesn't exist, then it is good time to create it.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside the working copy, one renderable identity directory structures
|
|
|
4a9d2a |
represents one visual manifestation of CentOS corporate visual
|
|
|
4a9d2a |
identity, or said differently, each visual manifestation of CentOS
|
|
|
4a9d2a |
corporate visual identity should have one renderable identity
|
|
|
4a9d2a |
directory structure.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside renderable identity directory structures, <tt>`centos-art.sh'</tt>
|
|
|
4a9d2a |
can render both image-based and text-based files. Specification of
|
|
|
4a9d2a |
whether a renderable identity directory structure produces image-based
|
|
|
4a9d2a |
or text-based content is a configuration action that takes place in
|
|
|
4a9d2a |
the pre-rendition configuration script of that renderable identity
|
|
|
4a9d2a |
directory structure.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside renderable identity directory structures, content production is
|
|
|
4a9d2a |
organized in different configurations. A content production
|
|
|
4a9d2a |
configuration is a unique combination of the components that make an
|
|
|
4a9d2a |
identity directory structure renderable. One content production
|
|
|
4a9d2a |
configuration does one thing only (e.g., to produce untranslated
|
|
|
4a9d2a |
images), but it can be extended (e.g., adding translation files) to
|
|
|
4a9d2a |
achieve different needs (e.g., to produce translated images).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.1.1 Design template without translation
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The design template without translation configuration is based on a
|
|
|
4a9d2a |
renderable identity directory structure with an empty translation
|
|
|
4a9d2a |
directory structure. In this configuration, one design template
|
|
|
4a9d2a |
produces one untranslated file. Both design templates and final
|
|
|
4a9d2a |
untranslated files share the same file name, but they differ one
|
|
|
4a9d2a |
another in file-type and file-extension.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
For example, to produce images without translations (there is no much
|
|
|
4a9d2a |
use in producing text-based files without translations), consider the
|
|
|
4a9d2a |
following configuration:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One renderable identity directory structure:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In this example we used <tt>`Identity/Path/To/Dir'</tt> as the identity
|
|
|
4a9d2a |
component we want to produce untranslated images for. Identity
|
|
|
4a9d2a |
components can be either under <tt>`trunk/'</tt> or <tt>`branches/'</tt>
|
|
|
4a9d2a |
directory structure.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The identity component (i.e., <tt>`Identity/Path/To/Dir'</tt>, in this
|
|
|
4a9d2a |
case) is also the bond component we use to connect the identity
|
|
|
4a9d2a |
directory structures with their respective auxiliar directories (i.e.,
|
|
|
4a9d2a |
translation directory structres and pre-rendition configuration
|
|
|
4a9d2a |
structures). The bond component is the path convenction that
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> uses to know where to look for related
|
|
|
4a9d2a |
translations, configuration scripts and whatever auxiliar thing a
|
|
|
4a9d2a |
renderable directory structure may need to have.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
| The bond component
|
|
|
4a9d2a |
|----------------->|
|
|
|
4a9d2a |
trunk/Identity/Path/To/Dir <-- Renderable identity directory structure.
|
|
|
4a9d2a |
|-- Tpl <-- Design template directory.
|
|
|
4a9d2a |
| `-- file.svg <-- Design template file.
|
|
|
4a9d2a |
`-- Img <-- Directory used to store final files.
|
|
|
4a9d2a |
`-- file.png <-- Final image-based file produced from
|
|
|
4a9d2a |
design template file.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside design template directory, design template files are based on
|
|
|
4a9d2a |
SVG (Scalable Vector Graphics) and use the extension
|
|
|
4a9d2a |
.svg. Design template files can be organized using several
|
|
|
4a9d2a |
directory levels to create a simple but extensible configuration,
|
|
|
4a9d2a |
specially if translated images are not required.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order for SVG (Scalable Vector Graphics) files to be
|
|
|
4a9d2a |
considered "design template" files, they should be placed under the
|
|
|
4a9d2a |
design template directory and to have set a CENTOSARTWORK
|
|
|
4a9d2a |
object id inside.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The CENTOSARTWORK word itself is a convenction name we use to
|
|
|
4a9d2a |
define which object/design area, inside a design template, the
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> script will use to export as
|
|
|
4a9d2a |
PNG (Portable Network Graphic) image at rendition time.
|
|
|
4a9d2a |
Whithout such object id specification, the <tt>`centos-art.sh'</tt> script
|
|
|
4a9d2a |
cannot know what object/design area you (as designer) want to export
|
|
|
4a9d2a |
as PNG (Portable Network Graphic) image file.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
 Note At rendition time, the content of <tt>`Img/'</tt> directory
|
|
|
4a9d2a |
structure is produced by <tt>`centos-art.sh'</tt> automatically.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
When a renderable identity directory structure is configured to
|
|
|
4a9d2a |
produce image-based content, <tt>`centos-art.sh'</tt> produces
|
|
|
4a9d2a |
PNG (Portable Network Graphics) files with the .png
|
|
|
4a9d2a |
extension. Once the base image format has been produced, it is
|
|
|
4a9d2a |
possible for <tt>`centos-art.sh'</tt> to use it in order to automatically
|
|
|
4a9d2a |
create other image formats that may be needed (see section trunk/Scripts/Bash/Functions/Render/Config).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside the working copy, you can find an example of "design template
|
|
|
4a9d2a |
without translation" configuration at <tt>`trunk/Identity/Models/'</tt>.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
See section trunk/Identity, for more information.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One translation directory structure:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order for an identity entry to be considered an identity renderable
|
|
|
4a9d2a |
directory structure, it should have a translation entry. The content
|
|
|
4a9d2a |
of the translation entry is relevant to determine how to process the
|
|
|
4a9d2a |
identity renderable directory entry.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
If the translation entry is empty (i.e., there is no file inside it),
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> interprets the identity renderable directory
|
|
|
4a9d2a |
structure as a "design templates without translation" configuration.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
| The bond component
|
|
|
4a9d2a |
|----------------->|
|
|
|
4a9d2a |
trunk/Translations/Identity/Path/To/Dir
|
|
|
4a9d2a |
`-- (empty)
|
|
|
4a9d2a |
|
|
|
4a9d2a |
If the translation entry is not empty, <tt>`centos-art.sh'</tt> can
|
|
|
4a9d2a |
interpret the identity renderable directory structure as one of the
|
|
|
4a9d2a |
following configurations: "design template with translation
|
|
|
4a9d2a |
(one-to-one)" or "design template with translation (optimized)".
|
|
|
4a9d2a |
Which one of these configurations is used depends on the value
|
|
|
4a9d2a |
assigned to the matching list (MATCHINGLIST) variable in the
|
|
|
4a9d2a |
pre-rendition configuration script of the renderable identity
|
|
|
4a9d2a |
directory structure we are producing images for.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
If the matching list variable is empty (as it is by default), then
|
|
|
4a9d2a |
"design template with translation (one-to-one)" configuration is
|
|
|
4a9d2a |
used. In this configuration it is required that both design templates
|
|
|
4a9d2a |
and translation files have the same file names. This way, one
|
|
|
4a9d2a |
translation files is applied to one design template, to produce
|
|
|
4a9d2a |
one translated image.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
If the matching list variable is not empty (because you redefine it in
|
|
|
4a9d2a |
the pre-rendition configuration script), then "design template with
|
|
|
4a9d2a |
translation (optimized)" configuration is used instead. In this
|
|
|
4a9d2a |
configuration, design templates and translation files don't need to
|
|
|
4a9d2a |
have the same names since such name relationship between them is
|
|
|
4a9d2a |
specified in the matching list properly.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
See section trunk/Translations, for more information.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One pre-rendition configuration script:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order to make an identity directory structure renderable, a
|
|
|
4a9d2a |
pre-rendition configuration script should exist for it. The
|
|
|
4a9d2a |
pre-rendition configuration script specifies what type of rendition
|
|
|
4a9d2a |
does <tt>`centos-art.sh'</tt> will perform over the identity directory
|
|
|
4a9d2a |
structure and how does it do that.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
| The bond component
|
|
|
4a9d2a |
|----------------->|
|
|
|
4a9d2a |
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
|
|
|
4a9d2a |
`-- render.conf.sh
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In this configuration the pre-rendition configuration script
|
|
|
4a9d2a |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
function render_loadConfig {
|
|
|
4a9d2a |
|
|
|
4a9d2a |
# Define rendition actions.
|
|
|
4a9d2a |
ACTIONS[0]='BASE:renderImage'
|
|
|
4a9d2a |
|
|
|
4a9d2a |
}
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Since translation directory structure is empty, <tt>`centos-art.sh'</tt>
|
|
|
4a9d2a |
assumes a "design template without translation" configuration to
|
|
|
4a9d2a |
produce untranslated images.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
To produce untranslated images, <tt>`centos-art.sh'</tt> takes one design
|
|
|
4a9d2a |
template and creates one temporal instance from it. Later,
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> uses the temporal design template instance as
|
|
|
4a9d2a |
source file to export the final untranslated image. The action of
|
|
|
4a9d2a |
exporting images from SVG (Scalable Vector Graphics) to
|
|
|
4a9d2a |
PNG (Portable Network Graphics) is possible thanks to
|
|
|
4a9d2a |
Inkscape's command-line interface and the CENTOSARTWORK object
|
|
|
4a9d2a |
id we previously set inside design templates.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
0 | Execute centos-art.sh on renderable identity directory structure.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
trunk/Identity/Path/To/Dir/Tpl/file.svg
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
1 | Create instance from design template.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
2 | Render untranslated image from design template instance.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
trunk/Identity/NewDir/Img/file.png
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
3 | Remove design template instance.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Finally, when the untranslated image has been created, the temporal
|
|
|
4a9d2a |
design template instance is removed. At this point,
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> takes the next design template and repeats the
|
|
|
4a9d2a |
whole production flow once again (design template by design template),
|
|
|
4a9d2a |
until all design templates be processed.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
See section trunk/Scripts/Bash/Functions/Render/Config, for more
|
|
|
4a9d2a |
information.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.1.2 Design template with translation (one-to-one)
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Producing untranslated images is fine in many cases, but not always.
|
|
|
4a9d2a |
Sometimes it is required to produce images in different languages and
|
|
|
4a9d2a |
that is something that untrasnlated image production cannot achieve.
|
|
|
4a9d2a |
However, if we fill its empty translation entry with translation files
|
|
|
4a9d2a |
(one for each design template) we extend the production flow from
|
|
|
4a9d2a |
untranslated image production to translated image production.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order for <tt>`centos-art.sh'</tt> to produce images correctly, each
|
|
|
4a9d2a |
design template should have one translation file and each translation
|
|
|
4a9d2a |
file should have one design template. Otherwise, if there is a
|
|
|
4a9d2a |
missing design template or a missing translation file,
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> will not produce the final image related to the
|
|
|
4a9d2a |
missing component.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order for <tt>`centos-art.sh'</tt> to know which is the relation
|
|
|
4a9d2a |
between translation files and design templates the translation
|
|
|
4a9d2a |
directory structure is taken as reference. For example, the
|
|
|
4a9d2a |
<tt>`trunk/Translations/Identity/Path/To/Dir/file.sed'</tt> translation
|
|
|
4a9d2a |
file does match <tt>`trunk/Identity/Path/To/Dir/Tpl/file.svg'</tt> design
|
|
|
4a9d2a |
template, but it doesn't match
|
|
|
4a9d2a |
<tt>`trunk/Identity/Path/To/Dir/File.svg'</tt> or
|
|
|
4a9d2a |
<tt>`trunk/Identity/Path/To/Dir/Tpl/File.svg'</tt> or
|
|
|
4a9d2a |
<tt>`trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg'</tt> design
|
|
|
4a9d2a |
templates.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The pre-rendition configuration script used to produce untranslated
|
|
|
4a9d2a |
images is the same we use to produce translated images. There is no
|
|
|
4a9d2a |
need to modify it. So, as we are using the same pre-rendition
|
|
|
4a9d2a |
configuration script, we can say that translated image production is
|
|
|
4a9d2a |
somehow an extended/improved version of untranslated image production.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Note If we use no translation file in the translation entry
|
|
|
4a9d2a |
(i.e., an empty directory), <tt>`centos-art.sh'</tt> assumes the
|
|
|
4a9d2a |
untranslated image production. If we fill the translation entry with
|
|
|
4a9d2a |
translation files, <tt>`centos-art.sh'</tt> assumes the translated image
|
|
|
4a9d2a |
production.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
To produce final images, <tt>`centos-art.sh'</tt> applies one translation
|
|
|
4a9d2a |
file to one design template and produce a translated design template
|
|
|
4a9d2a |
instance. Later, <tt>`centos-art.sh'</tt> uses the translated template
|
|
|
4a9d2a |
instance to produce the translated image. Finally, when the translated
|
|
|
4a9d2a |
image has been produced, <tt>`centos-art.sh'</tt> removes the translated
|
|
|
4a9d2a |
design template instance. This production flow is repeated for each
|
|
|
4a9d2a |
translation file available in the translatio entry.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
0 | Execute centos-art.sh on directory structure.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
trunk/Translations/Identity/Path/To/Dir/file.sed
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
1 | Apply translation to design template.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
trunk/Identity/Path/To/Dir/Tpl/file.svg
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
2 | Create design template instance.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
3 | Render PNG image from template instance.
|
|
|
4a9d2a |
--v----------------------------------------------
|
|
|
4a9d2a |
trunk/Identity/NewDir/Img/file.png
|
|
|
4a9d2a |
-------------------------------------------------
|
|
|
4a9d2a |
4 | Remove design template instance.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.1.3 Design template with translation (optimized)
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Producing translated images satisfies almost all our production images
|
|
|
4a9d2a |
needs, but there is still a pitfall in them. In order to produce
|
|
|
4a9d2a |
translated images as in the "one-to-one" configuration describes
|
|
|
4a9d2a |
previously, it is required that one translation file has one design
|
|
|
4a9d2a |
template. That's useful in many cases, but what would happen if we
|
|
|
4a9d2a |
need to apply many different translation files to the same design
|
|
|
4a9d2a |
template? Should we have to duplicate the same design template file
|
|
|
4a9d2a |
for each translation file, in order to satisfy the "one-to-one"
|
|
|
4a9d2a |
relation? What if we need to assign translation files to design
|
|
|
4a9d2a |
templates arbitrarily?
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Certenly, that's something the "one-to-one" configuration cannot
|
|
|
4a9d2a |
handle. So, that's why we had to "optimize" it. The optimized
|
|
|
4a9d2a |
configuration consists on using a matching list (MATCHINGLIST)
|
|
|
4a9d2a |
variable that specifies the relationship between translation files and
|
|
|
4a9d2a |
design templates in an arbitrary way. Using such matching list between
|
|
|
4a9d2a |
translation files and design templates let us use as many assignment
|
|
|
4a9d2a |
combinations as translation files and design templates we are working
|
|
|
4a9d2a |
with.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The MATCHINGLIST variable is set in the pre-rendition
|
|
|
4a9d2a |
configuration script of the component we want to produce images for.
|
|
|
4a9d2a |
By default, the MATCHINGLIST variable is empty which means no
|
|
|
4a9d2a |
matching list is used. Otherwise, if MATCHINGLIST variable has a
|
|
|
4a9d2a |
value different to empty value then, <tt>`centos-art.sh'</tt> interprets
|
|
|
4a9d2a |
the matching list in order to know how translation files are applied
|
|
|
4a9d2a |
to design templates.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
For example, consider the following configuration:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Identity/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In this configuration we want to produce three images using a
|
|
|
4a9d2a |
paragraph-based style, controlled by <tt>`paragraph.svg'</tt> design
|
|
|
4a9d2a |
template; and one image using a list-based style, controlled by
|
|
|
4a9d2a |
<tt>`list.svg'</tt> design template.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
trunk/Identity/Path/To/Dir
|
|
|
4a9d2a |
|-- Tpl
|
|
|
4a9d2a |
| |-- paragraph.svg
|
|
|
4a9d2a |
| `-- list.svg
|
|
|
4a9d2a |
`-- Img
|
|
|
4a9d2a |
|-- 01-welcome.png
|
|
|
4a9d2a |
|-- 02-donate.png
|
|
|
4a9d2a |
|-- 03-docs.png
|
|
|
4a9d2a |
`-- 04-support.png
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Translations/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order to produce translated images we need to have one translation
|
|
|
4a9d2a |
file for each translated image we want to produce. Notice how
|
|
|
4a9d2a |
translation names do match final image file names, but how translation
|
|
|
4a9d2a |
names do not match design template names. When we use matching list
|
|
|
4a9d2a |
there is no need for translation files to match the names of design
|
|
|
4a9d2a |
templates, such name relation is set inside the matching list itself.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
trunk/Translations/Identity/Path/To/Dir
|
|
|
4a9d2a |
|-- 01-welcome.sed
|
|
|
4a9d2a |
|-- 02-donate.sed
|
|
|
4a9d2a |
|-- 03-docs.sed
|
|
|
4a9d2a |
`-- 04-support.sed
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/trunk/Scripts/Bash/Functions/Render/Config/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order to produce different translated images using specific design
|
|
|
4a9d2a |
templates, we need to specify the relation between translation files
|
|
|
4a9d2a |
and design templates in a way that <tt>`centos-art.sh'</tt> could know
|
|
|
4a9d2a |
exactly what translation file to apply to what design template. This
|
|
|
4a9d2a |
relation between translation files and design templates is set using
|
|
|
4a9d2a |
the matching list MATCHINGLIST variable inside the pre-rendition
|
|
|
4a9d2a |
configuration script of the component we want to produce images for.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
|
|
|
4a9d2a |
`-- render.conf.sh
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In this configuration the pre-rendition configuration script
|
|
|
4a9d2a |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
function render_loadConfig {
|
|
|
3f9ae1 |
|
|
|
4a9d2a |
# Define rendition actions.
|
|
|
4a9d2a |
ACTIONS[0]='BASE:renderImage'
|
|
|
3f9ae1 |
|
|
|
4a9d2a |
# Define matching list.
|
|
|
4a9d2a |
MATCHINGLIST="\
|
|
|
4a9d2a |
paragraph.svg:\
|
|
|
4a9d2a |
01-welcome.sed\
|
|
|
4a9d2a |
02-donate.sed\
|
|
|
4a9d2a |
04-support.sed
|
|
|
4a9d2a |
list.svg:\
|
|
|
4a9d2a |
03-docs.sed
|
|
|
4a9d2a |
"
|
|
|
3f9ae1 |
|
|
|
4a9d2a |
}
|
|
|
4a9d2a |
|
|
|
4a9d2a |
As result, <tt>`centos-art.sh'</tt> will produce <tt>`01-welcome.png'</tt>,
|
|
|
4a9d2a |
<tt>`02-donate.png'</tt> and <tt>`04-support.png'</tt> using the
|
|
|
4a9d2a |
paragraph-based design template, but <tt>`03-docs.png'</tt> using the
|
|
|
4a9d2a |
list-based design template.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.1.4 Design template with translation (optimized+flexibility)
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In the production models we've seen so far, there are design templates
|
|
|
4a9d2a |
to produce untranslated images and translation files which combiend
|
|
|
4a9d2a |
with design templates produce translated images. That may seems like
|
|
|
4a9d2a |
all our needs are covered, doesn't it? Well, it almost does.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Generally, we use design templates to define how final images will
|
|
|
4a9d2a |
look like. Generally, each renderable directory structure has one
|
|
|
4a9d2a |
<tt>`Tpl/'</tt> directory where we organize design templates for that
|
|
|
4a9d2a |
identity component. So, we can say that there is only one unique
|
|
|
4a9d2a |
design template definition for each identity component; or what is the
|
|
|
4a9d2a |
same, said differently, identity components can be produced in one way
|
|
|
4a9d2a |
only, the way its own design template directory specifies. This is
|
|
|
4a9d2a |
not enough for theme production. It is a limitation, indeed.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Initially, to create one theme, we created one renderable directory
|
|
|
4a9d2a |
structure for each theme component. When we found ourselves with many
|
|
|
4a9d2a |
themes, and components inside them, it was obvious that the same
|
|
|
4a9d2a |
design model was duplicated inside each theme. As design models were
|
|
|
4a9d2a |
independently one another, if we changed one theme's design model,
|
|
|
4a9d2a |
that change was useless to other themes. So, in order to reuse design
|
|
|
4a9d2a |
model changes, we unified design models into one common directory
|
|
|
4a9d2a |
structure.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
With design models unified in a common structure, another problem rose
|
|
|
4a9d2a |
up. As design models also had the visual style of theme components,
|
|
|
4a9d2a |
there was no difference between themes, so there was no apparent need
|
|
|
4a9d2a |
to have an independent theme directory structure for each different
|
|
|
4a9d2a |
theme. So, it was also needed to separate visual styles from design
|
|
|
4a9d2a |
models.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
At this point there are two independent worklines: one directory
|
|
|
4a9d2a |
structure to store design models (the final image characteristics
|
|
|
4a9d2a |
[i.e., dimensions, translation markers, etc.]) and one directory
|
|
|
4a9d2a |
structure to store visual styles (the final image visual style [i.e.,
|
|
|
4a9d2a |
the image look and feel]). So, it is possible to handle both
|
|
|
4a9d2a |
different design models and different visual styles independtly one
|
|
|
4a9d2a |
another and later create combinations among them using
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt>.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
For example, consider the following configuration:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Identity/Themes/Models/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The design model entry exists to organize design model files (similar
|
|
|
4a9d2a |
to design templates). Both design models and design templates are very
|
|
|
4a9d2a |
similar; they both should have the CENTOSARTWORK export id
|
|
|
4a9d2a |
present to identify the exportation area, translation marks, etc.
|
|
|
4a9d2a |
However, design models do use dynamic backgrounds inclusion while
|
|
|
4a9d2a |
design templates don't.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
THEMEMODEL | | The bond component
|
|
|
4a9d2a |
|<----| |--------------------->|
|
|
|
4a9d2a |
trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
|
|
|
4a9d2a |
|-- paragraph.svg
|
|
|
4a9d2a |
`-- list.svg
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inisde design models, dynamic backgrounds are required in order for
|
|
|
4a9d2a |
different artistic motifs to reuse common design models. Firstly, in
|
|
|
4a9d2a |
order to create dynamic backgrounds inside design models, we import a
|
|
|
4a9d2a |
bitmap to cover design model's background and later, update design
|
|
|
4a9d2a |
model's path information to replace fixed values to dynamic values.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Identity/Themes/Motifs/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The artistic motif entry defines the visual style we want to produce
|
|
|
4a9d2a |
images for, only. Final images (i.e., those built from combining both
|
|
|
4a9d2a |
design models and artistic motif backrounds) are not stored here, but
|
|
|
4a9d2a |
under branches directory structure. In the artistic motif entry, we
|
|
|
4a9d2a |
only define those images that cannot be produced automatically by
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> (e.g., Backgrounds, Color information,
|
|
|
4a9d2a |
Screenshots, etc.).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Artistic motif name | | Artistic motif backgrounds
|
|
|
4a9d2a |
|<-------| |-------->|
|
|
|
4a9d2a |
trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
|
|
|
4a9d2a |
|-- Img
|
|
|
4a9d2a |
| |-- Png
|
|
|
4a9d2a |
| | |-- 510x300.png
|
|
|
4a9d2a |
| | `-- 510x300-final.png
|
|
|
4a9d2a |
| `-- Jpg
|
|
|
4a9d2a |
| |-- 510x300.jpg
|
|
|
4a9d2a |
| `-- 510x300-final.jpg
|
|
|
4a9d2a |
|-- Tpl
|
|
|
4a9d2a |
| `-- 510x300.svg
|
|
|
4a9d2a |
`-- Xcf
|
|
|
4a9d2a |
`-- 510x300.xcf
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Translations/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The translation entry specifies, by means of translation files, the
|
|
|
4a9d2a |
language-specific information we want to produce image for. When we
|
|
|
4a9d2a |
create the translation entry we don't use the name of neither design
|
|
|
4a9d2a |
model nor artistic motif, just the design model component we want to
|
|
|
4a9d2a |
produce images for.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
| The bond component
|
|
|
4a9d2a |
|--------------------->|
|
|
|
4a9d2a |
trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
|
|
|
4a9d2a |
`-- 5
|
|
|
4a9d2a |
|-- en
|
|
|
4a9d2a |
| |-- 01-welcome.sed
|
|
|
4a9d2a |
| |-- 02-donate.sed
|
|
|
4a9d2a |
| `-- 03-docs.sed
|
|
|
4a9d2a |
`-- es
|
|
|
4a9d2a |
|-- 01-welcome.sed
|
|
|
4a9d2a |
|-- 02-donate.sed
|
|
|
4a9d2a |
`-- 03-docs.sed
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
One entry under <tt>`trunk/Scripts/Bash/Functions/Render/Config/'</tt>:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
There is one pre-rendition configuration script for each theme
|
|
|
4a9d2a |
component. So, each time a theme component is rendered, its
|
|
|
4a9d2a |
pre-rendition configuration script is evaluated to teach
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> how to render the component.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
|
|
|
4a9d2a |
`-- render.conf.sh
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In this configuration the pre-rendition configuration script
|
|
|
4a9d2a |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
function render_loadConfig {
|
|
|
4a9d2a |
|
|
|
4a9d2a |
# Define rendition actions.
|
|
|
4a9d2a |
ACTIONS[0]='BASE:renderImage'
|
|
|
4a9d2a |
|
|
|
4a9d2a |
# Define matching list.
|
|
|
4a9d2a |
MATCHINGLIST="\
|
|
|
4a9d2a |
paragraph.svg:\
|
|
|
4a9d2a |
01-welcome.sed\
|
|
|
4a9d2a |
02-donate.sed
|
|
|
4a9d2a |
list.svg:\
|
|
|
4a9d2a |
03-docs.sed
|
|
|
4a9d2a |
"
|
|
|
4a9d2a |
|
|
|
4a9d2a |
# Deifne theme model.
|
|
|
4a9d2a |
THEMEMODEL='Default'
|
|
|
4a9d2a |
|
|
|
4a9d2a |
}
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The production flow of "optimize+flexibility" configuration…
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.2 Renderable translation directory structures
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Translation directory structures are auxiliar structures of renderable
|
|
|
4a9d2a |
identity directory structures. There is one translation directory
|
|
|
4a9d2a |
structure for each renderable identity directory structure. Inside
|
|
|
4a9d2a |
translation directory structures we organize translation files used by
|
|
|
4a9d2a |
renderable identity directory structures that produce translated
|
|
|
4a9d2a |
images. Renderable identity directory structures that produce
|
|
|
4a9d2a |
untranslated images don't use translation files, but they do use a
|
|
|
4a9d2a |
translation directory structure, an empty translation directory
|
|
|
4a9d2a |
structure, to be precise.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order to aliviate production of translation file, we made
|
|
|
4a9d2a |
translation directory structures renderable adding a template
|
|
|
4a9d2a |
(<tt>`Tpl/'</tt>) directory structure to handle common content inside
|
|
|
4a9d2a |
translation files. This way, we work on translation templates and
|
|
|
4a9d2a |
later use <tt>`centos-art.sh'</tt> to produce specific translation files
|
|
|
4a9d2a |
(based on translation templates) for different information (e.g.,
|
|
|
4a9d2a |
languages, release numbers, architectures, etc.).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
If for some reason, translation files get far from translation
|
|
|
4a9d2a |
templates and translation templates become incovenient to produce such
|
|
|
4a9d2a |
translation files then, care should be taken to avoid replacing the
|
|
|
4a9d2a |
content of translation files with the content of translation templates
|
|
|
4a9d2a |
when <tt>`centos-art.sh'</tt> is executed to produce translation files
|
|
|
4a9d2a |
from translation templates.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Inside renderable translation directory structures,
|
|
|
4a9d2a |
<tt>`centos-art.sh'</tt> can produce text-based files only.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.3 Copying renderable directory structures
|
|
|
4a9d2a |
|
|
|
4a9d2a |
A renderable layout is formed by design models, design images,
|
|
|
4a9d2a |
pre-rendition configuration scripts and translations files. This way,
|
|
|
4a9d2a |
when we say to duplicate rendition stuff we are saying to duplicate
|
|
|
4a9d2a |
these four directory structures (i.e., design models, design images,
|
|
|
4a9d2a |
pre-rendition configuration scripts, and related translations files).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
When we duplicate directories, inside `trunk/Identity' directory
|
|
|
4a9d2a |
structure, we need to be aware of renderable layout described above
|
|
|
4a9d2a |
and the source location used to perform the duplication action. The
|
|
|
4a9d2a |
source location is relevant to centos-art.sh script in order to
|
|
|
4a9d2a |
determine the required auxiliar information inside directory
|
|
|
4a9d2a |
structures that need to be copied too (otherwise we may end up with
|
|
|
4a9d2a |
orphan directory structures unable to be rendered, due the absence of
|
|
|
4a9d2a |
required information).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
In order for a renderable directory structure to be valid, the new
|
|
|
4a9d2a |
directory structure copied should match the following conditions:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
To have a unique directory structure under
|
|
|
4a9d2a |
<tt>`trunk/Identity'</tt>, organized by any one of the above
|
|
|
4a9d2a |
organizational designs above.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
To have a unique directory structure under
|
|
|
4a9d2a |
<tt>`trunk/Translations'</tt> to store translation files.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
To have a unique directory structure under
|
|
|
4a9d2a |
<tt>`trunk/Scripts/Bash/Functions/Render/Config'</tt> to set pre-rendition
|
|
|
4a9d2a |
configuration script.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
As convenction, the render_doCopy function uses
|
|
|
4a9d2a |
<tt>`trunk/Identity'</tt> directory structure as source location. Once
|
|
|
4a9d2a |
the <tt>`trunk/Identity'</tt> directory structure has been specified and
|
|
|
4a9d2a |
verified, the related path information is built from it and copied
|
|
|
4a9d2a |
automatically to the new location specified by FLAG_TO variable.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Design templates + No translation:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Command:
|
|
|
4a9d2a |
- centos-art render -copy=trunk/Identity/Path/To/Dir -to=trunk/Identity/NewPath/To/Dir
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Sources:
|
|
|
4a9d2a |
- trunk/Identity/Path/To/Dir
|
|
|
4a9d2a |
- trunk/Translations/Identity/Path/To/Dir
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Targets:
|
|
|
4a9d2a |
- trunk/Identity/NewPath/To/Dir
|
|
|
4a9d2a |
- trunk/Translations/Identity/NewPath/To/Dir
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Renderable layout 2:
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Command:
|
|
|
4a9d2a |
- centos-art render -copy=trunk/Identity/Themes/Motifs/TreeFlower \
|
|
|
4a9d2a |
-to=trunk/Identity/Themes/Motifs/NewPath/To/Dir
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Sources:
|
|
|
4a9d2a |
- trunk/Identity/Themes/Motifs/TreeFlower
|
|
|
4a9d2a |
- trunk/Translations/Identity/Themes
|
|
|
4a9d2a |
- trunk/Translations/Identity/Themes/Motifs/TreeFlower
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Targets:
|
|
|
4a9d2a |
- trunk/Identity/Themes/Motifs/NewPath/To/Dir
|
|
|
4a9d2a |
- trunk/Translations/Identity/Themes
|
|
|
4a9d2a |
- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
|
|
|
4a9d2a |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Notice that design models are not included in source or target
|
|
|
4a9d2a |
locations. This is intentional. In "Renderable layout 2", design
|
|
|
4a9d2a |
models live by their own, they just exist, they are there, available
|
|
|
4a9d2a |
for any artistic motif to use. By default `Themes/Models/Default'
|
|
|
4a9d2a |
design model directory structure is used, but other design models
|
|
|
4a9d2a |
directory structures (under Themes/Models/) can be created and used
|
|
|
4a9d2a |
changing the value of THEMEMODEL variable inside the pre-rendition
|
|
|
4a9d2a |
configuration script of the artistic motif source location you want to
|
|
|
4a9d2a |
produce.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Notice how translations and pre-rendition configuration scripts may
|
|
|
4a9d2a |
both be equal in source and target. This is because such structures
|
|
|
4a9d2a |
are common to all artistic motifs (the default values to use when no
|
|
|
4a9d2a |
specific values are provided).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- The common directory structures are not copied or deleted. We cannot
|
|
|
4a9d2a |
copy a directory structure to itself.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- The common directory structures represent the default value to use
|
|
|
4a9d2a |
when no specific translations and/or pre-rendition configuration
|
|
|
4a9d2a |
script are provided inside source location.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- The specific directory structures, if present, are both copiable and
|
|
|
4a9d2a |
removable. This is, when you perform a copy or delete action from
|
|
|
4a9d2a |
source, that source specific auxiliar directories are transfered in
|
|
|
4a9d2a |
the copy action to a new location (that specified by FLAG_TO
|
|
|
4a9d2a |
variable).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- When translations and/or pre-rendition configuration scripts are
|
|
|
4a9d2a |
found inside the source directory structure, the centos-art.sh
|
|
|
4a9d2a |
script loads common auxiliar directories first and later specific
|
|
|
4a9d2a |
auxiliar directories. This way, identity rendition of source
|
|
|
4a9d2a |
locations can be customized idividually over the base of common
|
|
|
4a9d2a |
default values.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- The specific auxiliar directories are optional.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
- The common auxiliar directories should be present always. This is,
|
|
|
4a9d2a |
in order to provide the information required by render functionality
|
|
|
4a9d2a |
(i.e., to make it functional in the more basic level of its
|
|
|
4a9d2a |
existence).
|
|
|
4a9d2a |
|
|
|
4a9d2a |
Notice how the duplication process is done from `trunk/Identity' on,
|
|
|
4a9d2a |
not the oposite. If you try to duplicate a translation structure (or
|
|
|
4a9d2a |
similar auxiliar directory structures like pre-rendition configuration
|
|
|
4a9d2a |
scripts), the `trunk/Identity' for that translation is not created.
|
|
|
4a9d2a |
This limitation is impossed by the fact that many `trunk/Identity'
|
|
|
4a9d2a |
directory structures may reuse/share the same translation directory
|
|
|
4a9d2a |
structure. We cannot delete one translation (or similar) directory
|
|
|
4a9d2a |
structures while a related `trunk/Identity/' directory structure is
|
|
|
4a9d2a |
still in need of it.
|
|
|
4a9d2a |
|
|
|
4a9d2a |
The `render_doCopy' functionality does duplicate directory structures
|
|
|
4a9d2a |
directly involved in rendition process only. Once such directories
|
|
|
4a9d2a |
have been duplicated, the functionality stops thereat.
|
|
|
4a9d2a |
|
|
|
3f9ae1 |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.4 Usage
|
|
|
3d6160 |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
...
|
|
|
4a9d2a |
|
|
|
e37211 |
|
|
|
e37211 |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.53.5 See also
|
|
|
300762 |
|
|
|
4a9d2a |
|
|
|
4a9d2a |
3.54 trunk/Scripts/Bash/Functions/Render/Config
|
|
|
4a9d2a |
|
|
|
4a9d2a |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4a9d2a |
[ < ]
|
|
|
4a9d2a |
[ > ]
|
|
|
4c79b5 |
|
|
|
300762 |
[ << ]
|
|
|
4a9d2a |
[ Up ]
|
|
|
4a9d2a |
[ >> ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
<font size="-1">
|
|
|
4a9d2a |
This document was generated on February, 25 2011 using texi2html 1.76.
|
|
|
4c79b5 |
</font>
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
</body>
|
|
|
4c79b5 |
</html>
|