|
 |
4c79b5 |
|
|
|
4c79b5 |
<html>
|
|
|
6414c4 |
|
|
|
09d4f2 |
|
|
|
6414c4 |
Copyright C 2009, 2010, 2011 Alain Reguera Delgado
|
|
|
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 |
-->
|
|
|
5cee2c |
|
|
|
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>
|
|
|
ec5f63 |
<title>The CentOS Artwork Repository: 3.42 trunk/Scripts/Bash/Functions/Render</title>
|
|
|
4c79b5 |
|
|
|
ec5f63 |
<meta name="description" content="The CentOS Artwork Repository: 3.42 trunk/Scripts/Bash/Functions/Render">
|
|
|
ec5f63 |
<meta name="keywords" content="The CentOS Artwork Repository: 3.42 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 |
|
|
|
5cee2c |
[ < ]
|
|
|
5cee2c |
[ > ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
[ << ]
|
|
|
4c79b5 |
[ Up ]
|
|
|
5cee2c |
[ >> ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
[Top]
|
|
|
4c79b5 |
[Contents]
|
|
|
5cee2c |
[Index]
|
|
|
4c79b5 |
[ ? ]
|
|
|
4c79b5 |
|
|
|
ec5f63 |
|
|
|
5cee2c |
|
|
|
ec5f63 |
3.42 trunk/Scripts/Bash/Functions/Render
|
|
|
6414c4 |
|
|
|
0d952c |
|
|
|
5cee2c |
|
|
|
ec5f63 |
3.42.1 Goals
|
|
|
749e81 |
|
|
|
5cee2c |
The render functionality exists to automate production of files
|
|
|
5cee2c |
inside the working copy. The render functionality is aimed to
|
|
|
5cee2c |
satisfy different file types (e.g., text-based and image-based)
|
|
|
5cee2c |
production needs in different information levels (e.g., different
|
|
|
5cee2c |
languages, release numbers, different architectures, etc.).
|
|
|
5cee2c |
|
|
|
49b888 |
|
|
|
5cee2c |
|
|
|
ec5f63 |
3.42.2 Description
|
|
|
ec5f63 |
|
|
|
e37211 |
|
|
|
5cee2c |
The render functionality relies on "renderable directory
|
|
|
5cee2c |
structures" to produce files. Renderable directory structures can be
|
|
|
5cee2c |
either "identity directory structures" or "translation directory
|
|
|
5cee2c |
structures" with special directories inside.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.3 Renderable identity directory structures
|
|
|
5cee2c |
|
|
|
5cee2c |
Identity directory structures are the starting point of identity
|
|
|
5cee2c |
rendition. Whenever we want to render a component of CentOS corporate
|
|
|
5cee2c |
visual identity we need to point <tt>`centos-art.sh'</tt> to an identity
|
|
|
5cee2c |
directory structure. If such identity directory structure doesn't
|
|
|
5cee2c |
exists, then it is good time to created. Each identity directory
|
|
|
5cee2c |
structure represents one visual manifestation of CentOS corporate
|
|
|
5cee2c |
visual identity. See section trunk/Identity, for more information.
|
|
|
5cee2c |
|
|
|
5cee2c |
The first requirement for an identity directory structure to be
|
|
|
5cee2c |
considered a renderable identity directory structure is its location,
|
|
|
5cee2c |
inside the working copy: it should be under <tt>`trunk/Identity/'</tt> or
|
|
|
5cee2c |
<tt>`branches/Identity/'</tt> directory structure.
|
|
|
5cee2c |
|
|
|
5cee2c |
The second requirement for an identity directory structure to be
|
|
|
5cee2c |
considered a renderable identity directory structure is its directory
|
|
|
5cee2c |
structure: it needs to have one (<tt>`Tpl/'</tt>) directory to store
|
|
|
5cee2c |
design templates files, one <tt>`Img/'</tt> directory to store files
|
|
|
5cee2c |
produced as rendition result, one translation directory structure to
|
|
|
5cee2c |
store translation files and one script directory to store
|
|
|
5cee2c |
pre-rendition configuration scripts. All these directory structures
|
|
|
5cee2c |
are connected among themselves by a common component in their path
|
|
|
5cee2c |
that bonds them altogether. See section trunk/Scripts/Bash/Functions/Path,
|
|
|
5cee2c |
for more information.
|
|
|
5cee2c |
|
|
|
5cee2c |
Inside renderable identity directory structures, <tt>`centos-art.sh'</tt>
|
|
|
5cee2c |
can render image-based and text-based files.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.3.1 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
|
|
|
5cee2c |
another in the file-type itself and the file-extension used to
|
|
|
5cee2c |
describe the file type.
|
|
|
5cee2c |
|
|
|
5cee2c |
Design templates are based on SVG (Scalable Vector Graphics)
|
|
|
5cee2c |
and use the extension .svg. Files produced as rendition result
|
|
|
5cee2c |
(i.e., the final files translated or not) may be text-based files with
|
|
|
5cee2c |
arbitrary extensions, or PNG (Portable Network Graphics) files
|
|
|
5cee2c |
with the extension .png. Definition of whether a final file is
|
|
|
5cee2c |
text-based or image-based is set in the pre-rendition configuration
|
|
|
5cee2c |
script of the renderable directory structure we want to produce files
|
|
|
5cee2c |
for.
|
|
|
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:
|
|
|
2563c2 |
|
|
|
5cee2c |
|
|
|
5cee2c |
One renderable identity directory structure:
|
|
|
5cee2c |
|
|
|
5cee2c |
Specify the identity component we want to produce images for.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Identity/DirName
|
|
|
2563c2 |
|-- Tpl
|
|
|
2563c2 |
| `-- file.svg
|
|
|
2563c2 |
`-- Img
|
|
|
2563c2 |
`-- file.png
|
|
|
2563c2 |
|
|
|
5cee2c |
Inside design template directory, design template files can be
|
|
|
5cee2c |
organized using several directory levels. Using several levels of
|
|
|
5cee2c |
directories inside design template directory let us to create very
|
|
|
5cee2c |
simple but extensible configurations, specially if translated images
|
|
|
5cee2c |
are not required.
|
|
|
5cee2c |
|
|
|
5cee2c |
 Note When we use a "design template without translation"
|
|
|
5cee2c |
configuration, <tt>`centos-art.sh'</tt> creates the <tt>`Img/'</tt> directory
|
|
|
5cee2c |
structure automatically taking the <tt>`Tpl/'</tt> directory structure as
|
|
|
5cee2c |
reference at rendition time.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
In order for 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 CENTOSARTWORK
|
|
|
5cee2c |
object id inside.
|
|
|
5cee2c |
|
|
|
5cee2c |
The CENTOSARTWORK word itself is a convenction name we use to
|
|
|
5cee2c |
define which object/design area, inside a design template, the
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> script will use to export as PNG image at
|
|
|
5cee2c |
rendition time. Whithout such object id specification, the
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> script cannot know what object/design area you
|
|
|
5cee2c |
(as designer) want to export as PNG image file.
|
|
|
5cee2c |
|
|
|
5cee2c |
Inside the working copy, you can find an example of "design template
|
|
|
5cee2c |
without translation" configuration at <tt>`trunk/Identity/Models/'</tt>.
|
|
|
5cee2c |
|
|
|
5cee2c |
See section trunk/Identity, for more information.
|
|
|
2563c2 |
|
|
|
5cee2c |
|
|
|
5cee2c |
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
|
|
|
5cee2c |
of the translation entry is relevant to determine how the identity
|
|
|
5cee2c |
renderable directory entry is processed.
|
|
|
5cee2c |
|
|
|
5cee2c |
If the translation entry is empty (i.e., there is no file inside it),
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> interprets the identity renderable directory
|
|
|
5cee2c |
structure as a "design templates without translation" configuration.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Translations/Identity/DirName
|
|
|
5cee2c |
`-- (empty)
|
|
|
2563c2 |
|
|
|
5cee2c |
If the translation entry is not empty, <tt>`centos-art.sh'</tt> can
|
|
|
5cee2c |
interpret the identity renderable directory structure as any of the
|
|
|
5cee2c |
following configuration: "design templates with translations
|
|
|
5cee2c |
(one-to-one)" or "design templates with translations (optimized)".
|
|
|
5cee2c |
Which one of these configuration is used depends on the value assigned
|
|
|
5cee2c |
to the matching list (MATCHINGLIST) variable.
|
|
|
5cee2c |
|
|
|
5cee2c |
If the matching list variable is empty (as it is by default), then
|
|
|
5cee2c |
"design templates with translations (one-to-one)" configuration is
|
|
|
5cee2c |
used. In this configuration it is required that both design templates
|
|
|
5cee2c |
and translation files have the same file names.
|
|
|
5cee2c |
|
|
|
5cee2c |
If the matching list variable is not empty (because you redefine it in
|
|
|
5cee2c |
the pre-rendition configuration script), then "design templates with
|
|
|
5cee2c |
translations (optimized)" configuration is used instead. In this
|
|
|
5cee2c |
configuration, design templates and translation files don't need to
|
|
|
5cee2c |
have the same names since such relation between them is specified in
|
|
|
5cee2c |
the matching list properly.
|
|
|
5cee2c |
|
|
|
5cee2c |
See section trunk/Translations, for more information.
|
|
|
2563c2 |
|
|
|
5cee2c |
|
|
|
5cee2c |
One pre-rendition configuration script:
|
|
|
5cee2c |
|
|
|
5cee2c |
In order to make an identity entry renderable, a pre-rendition
|
|
|
5cee2c |
configuration script should exist for it. The pre-rendition
|
|
|
5cee2c |
configuration script specifies what type of rendition does
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> will perform and the way it does it.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Scripts/Bash/Functions/Render/Config/Identity/DirName
|
|
|
5cee2c |
`-- render.conf.sh
|
|
|
5cee2c |
|
|
|
5cee2c |
In this configuration the pre-rendition configuration script
|
|
|
5cee2c |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
5cee2c |
|
|
|
5cee2c |
function render_loadConfig {
|
|
|
5cee2c |
|
|
|
5cee2c |
# Define rendition actions.
|
|
|
5cee2c |
ACTIONS[0]='BASE:renderImage'
|
|
|
5cee2c |
|
|
|
5cee2c |
}
|
|
|
5cee2c |
|
|
|
5cee2c |
To produce untranslated images, <tt>`centos-art.sh'</tt> takes one design
|
|
|
5cee2c |
template and creates one temporal instance from it. Later,
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> uses the temporal design template instance as
|
|
|
5cee2c |
source file to export the final untranslated image. The export action
|
|
|
5cee2c |
is possible thanks to Inkscape's command-line interface and the
|
|
|
5cee2c |
CENTOSARTWORK object id we set inside design templates.
|
|
|
5cee2c |
|
|
|
5cee2c |
centos-art.sh render --identity=trunk/Identity/DirName
|
|
|
5cee2c |
-------------------------------------------------
|
|
|
5cee2c |
0 | Execute centos-art.sh on renderable identity directory structure.
|
|
|
5cee2c |
--v----------------------------------------------
|
|
|
5cee2c |
trunk/Identity/DirName/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 |
|
|
|
5cee2c |
Finally, when the untranslated image has been created, the temporal
|
|
|
5cee2c |
design template instance is removed. At this point, the next design
|
|
|
5cee2c |
template in the list is taken to repeat the production flow once again
|
|
|
5cee2c |
and so on, until all design templates be processed.
|
|
|
2563c2 |
|
|
|
5cee2c |
See section trunk/Scripts/Bash/Functions/Render/Config, for more
|
|
|
5cee2c |
information.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.3.2 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 <tt>`centos-art.sh'</tt> 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 |
<tt>`centos-art.sh'</tt> will not produce the final image related to the
|
|
|
5cee2c |
missing component.
|
|
|
5cee2c |
|
|
|
5cee2c |
In order for <tt>`centos-art.sh'</tt> 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
|
|
|
5cee2c |
<tt>`trunk/Translations/Identity/DirName/file.sed'</tt> translation file
|
|
|
5cee2c |
does match <tt>`trunk/Identity/DirName/Tpl/file.svg'</tt> design template,
|
|
|
5cee2c |
but it doesn't match <tt>`trunk/Identity/DirName/File.svg'</tt> or
|
|
|
5cee2c |
<tt>`trunk/Identity/DirName/Tpl/File.svg'</tt> or
|
|
|
5cee2c |
<tt>`trunk/Identity/DirName/Tpl/SubDir/file.svg'</tt> design 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 |
Note If we use no translation file in the translation entry
|
|
|
5cee2c |
(i.e., an empty directory), <tt>`centos-art.sh'</tt> assumes the
|
|
|
5cee2c |
untranslated image production. If we fill the translation entry with
|
|
|
5cee2c |
translation files, <tt>`centos-art.sh'</tt> assumes the translated image
|
|
|
5cee2c |
production.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
To produce final images, <tt>`centos-art.sh'</tt> applies one translation
|
|
|
5cee2c |
file to one design template and produce a translated design template
|
|
|
5cee2c |
instance. Later, <tt>`centos-art.sh'</tt> uses the translated template
|
|
|
5cee2c |
instance to produce the translated image. Finally, when the translated
|
|
|
5cee2c |
image has been produced, <tt>`centos-art.sh'</tt> removes the translated
|
|
|
5cee2c |
design template instance. This production flow is repeated for each
|
|
|
5cee2c |
translation file available in the translatio entry.
|
|
|
5cee2c |
|
|
|
5cee2c |
centos-art.sh render --identity=trunk/Identity/DirName
|
|
|
5cee2c |
-------------------------------------------------
|
|
|
5cee2c |
0 | Execute centos-art.sh on directory structure.
|
|
|
5cee2c |
--v----------------------------------------------
|
|
|
5cee2c |
trunk/Translations/Identity/DirName/file.sed
|
|
|
5cee2c |
-------------------------------------------------
|
|
|
5cee2c |
1 | Apply translation to design template.
|
|
|
5cee2c |
--v----------------------------------------------
|
|
|
5cee2c |
trunk/Identity/DirName/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.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.3.3 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 (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 MATCHINGLIST variable is set in the pre-rendition
|
|
|
5cee2c |
configuration script of the component we want to produce images for.
|
|
|
5cee2c |
By default, the MATCHINGLIST variable is empty which means no
|
|
|
5cee2c |
matching list is used. Otherwise, if MATCHINGLIST variable has a
|
|
|
5cee2c |
value different to empty value then, <tt>`centos-art.sh'</tt> 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:
|
|
|
2563c2 |
|
|
|
2563c2 |
|
|
|
5cee2c |
One entry under <tt>`trunk/Identity/'</tt>:
|
|
|
2563c2 |
|
|
|
5cee2c |
In this configuration we want to produce three images using a
|
|
|
5cee2c |
paragraph-based style, controlled by <tt>`paragraph.svg'</tt> design
|
|
|
5cee2c |
template; and one image using a list-based style, controlled by
|
|
|
5cee2c |
<tt>`list.svg'</tt> design template.
|
|
|
2563c2 |
|
|
|
5cee2c |
trunk/Identity/DirName
|
|
|
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
|
|
|
5cee2c |
|
|
|
2563c2 |
|
|
|
5cee2c |
One entry under <tt>`trunk/Translations/'</tt>:
|
|
|
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.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Translations/Identity/DirName
|
|
|
5cee2c |
|-- 01-welcome.sed
|
|
|
5cee2c |
|-- 02-donate.sed
|
|
|
5cee2c |
|-- 03-docs.sed
|
|
|
5cee2c |
`-- 04-support.sed
|
|
|
5cee2c |
|
|
|
2563c2 |
|
|
|
5cee2c |
One entry under <tt>`trunk/trunk/Scripts/Bash/Functions/Render/Config/'</tt>:
|
|
|
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 <tt>`centos-art.sh'</tt> 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 MATCHINGLIST variable inside the pre-rendition
|
|
|
5cee2c |
configuration script of the component we want to produce images for.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Scripts/Bash/Functions/Render/Config/Identity/DirName
|
|
|
5cee2c |
`-- render.conf.sh
|
|
|
5cee2c |
|
|
|
5cee2c |
In this configuration the pre-rendition configuration script
|
|
|
5cee2c |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
2563c2 |
|
|
|
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 |
|
|
|
5cee2c |
As result, <tt>`centos-art.sh'</tt> will produce <tt>`01-welcome.png'</tt>,
|
|
|
5cee2c |
<tt>`02-donate.png'</tt> and <tt>`04-support.png'</tt> using the
|
|
|
5cee2c |
paragraph-based design template, but <tt>`03-docs.png'</tt> using the
|
|
|
5cee2c |
list-based design template.
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.3.4 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 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 |
<tt>`Tpl/'</tt> 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 |
<tt>`centos-art.sh'</tt>.
|
|
|
5cee2c |
|
|
|
5cee2c |
For example, consider the following configuration:
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
One entry under <tt>`trunk/Identity/Themes/Models/'</tt>:
|
|
|
2563c2 |
|
|
|
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 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.
|
|
|
5cee2c |
|
|
|
5cee2c |
THEMEMODEL | | Design model component
|
|
|
5cee2c |
|<----| |--------------------->|
|
|
|
5cee2c |
trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
|
|
|
5cee2c |
|-- paragraph.svg
|
|
|
5cee2c |
`-- list.svg
|
|
|
5cee2c |
|
|
|
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 |
|
|
|
2563c2 |
|
|
|
5cee2c |
One entry under <tt>`trunk/Identity/Themes/Motifs/'</tt>:
|
|
|
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 |
<tt>`centos-art.sh'</tt> (e.g., Backgrounds, Color information,
|
|
|
5cee2c |
Screenshots, etc.).
|
|
|
5cee2c |
|
|
|
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 |
|
|
|
2563c2 |
|
|
|
5cee2c |
One entry under <tt>`trunk/Translations/'</tt>:
|
|
|
2563c2 |
|
|
|
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 |
| Design model 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 |
|
|
|
5cee2c |
|
|
|
5cee2c |
One entry under <tt>`trunk/Scripts/Bash/Functions/Render/Config/'</tt>:
|
|
|
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 |
<tt>`centos-art.sh'</tt> how to render the component.
|
|
|
5cee2c |
|
|
|
5cee2c |
trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
|
|
|
5cee2c |
`-- render.conf.sh
|
|
|
5cee2c |
|
|
|
5cee2c |
In this configuration the pre-rendition configuration script
|
|
|
5cee2c |
(<tt>`render.conf.sh'</tt>) would look like the following:
|
|
|
5cee2c |
|
|
|
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 |
|
|
|
2563c2 |
|
|
|
2563c2 |
|
|
|
5cee2c |
The production flow of "optimize+flexibility" configuration…
|
|
|
5cee2c |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.4 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 |
(<tt>`Tpl/'</tt>) directory structure to handle common content inside
|
|
|
5cee2c |
translation files. This way, we work on translation templates and
|
|
|
5cee2c |
later use <tt>`centos-art.sh'</tt> 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 <tt>`centos-art.sh'</tt> is executed to produce translation files
|
|
|
5cee2c |
from translation templates.
|
|
|
5cee2c |
|
|
|
5cee2c |
Inside renderable translation directory structures,
|
|
|
5cee2c |
<tt>`centos-art.sh'</tt> can produce text-based files only.
|
|
|
5cee2c |
|
|
|
2563c2 |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.5 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
|
|
|
8e85aa |
and the source location used to perform the duplication action. The
|
|
|
8e85aa |
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 |
|
|
|
2563c2 |
To have a unique directory structure under
|
|
|
2563c2 |
<tt>`trunk/Identity'</tt>, organized by any one of the above
|
|
|
2563c2 |
organizational designs above.
|
|
|
2563c2 |
|
|
|
2563c2 |
To have a unique directory structure under
|
|
|
2563c2 |
<tt>`trunk/Translations'</tt> to store translation files.
|
|
|
2563c2 |
|
|
|
2563c2 |
To have a unique directory structure under
|
|
|
2563c2 |
<tt>`trunk/Scripts/Bash/Functions/Render/Config'</tt> to set pre-rendition
|
|
|
2563c2 |
configuration script.
|
|
|
2563c2 |
|
|
|
2563c2 |
|
|
|
2563c2 |
As convenction, the render_doCopy function uses
|
|
|
2563c2 |
<tt>`trunk/Identity'</tt> directory structure as source location. Once
|
|
|
2563c2 |
the <tt>`trunk/Identity'</tt> 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 FLAG_TO variable.
|
|
|
2563c2 |
|
|
|
5cee2c |
Design templates + No translation:
|
|
|
2563c2 |
|
|
|
2563c2 |
Command:
|
|
|
5cee2c |
- centos-art render -copy=trunk/Identity/DirName -to=trunk/Identity/NewDirName
|
|
|
2563c2 |
|
|
|
2563c2 |
Sources:
|
|
|
5cee2c |
- trunk/Identity/DirName
|
|
|
5cee2c |
- trunk/Translations/Identity/DirName
|
|
|
5cee2c |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/DirName
|
|
|
2563c2 |
|
|
|
2563c2 |
Targets:
|
|
|
2563c2 |
- trunk/Identity/NewDirName
|
|
|
2563c2 |
- trunk/Translations/Identity/NewDirName
|
|
|
2563c2 |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewDirName
|
|
|
2563c2 |
|
|
|
2563c2 |
Renderable layout 2:
|
|
|
2563c2 |
|
|
|
2563c2 |
Command:
|
|
|
2563c2 |
- centos-art render -copy=trunk/Identity/Themes/Motifs/TreeFlower \
|
|
|
2563c2 |
-to=trunk/Identity/Themes/Motifs/NewDirName
|
|
|
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:
|
|
|
2563c2 |
- trunk/Identity/Themes/Motifs/NewDirName
|
|
|
2563c2 |
- trunk/Translations/Identity/Themes
|
|
|
2563c2 |
- trunk/Translations/Identity/Themes/Motifs/NewDirName
|
|
|
2563c2 |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
|
|
|
2563c2 |
- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewDirName
|
|
|
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.
|
|
|
2563c2 |
|
|
|
2563c2 |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.6 Usage
|
|
|
e37211 |
|
|
|
ec5f63 |
|
|
|
ec5f63 |
...
|
|
|
ec5f63 |
|
|
|
e37211 |
|
|
|
e37211 |
|
|
|
5cee2c |
|
|
|
5cee2c |
3.42.7 See also
|
|
|
4c79b5 |
|
|
|
63f275 |
|
|
|
5cee2c |
3.43 trunk/Scripts/Bash/Functions/Render/Config
|
|
|
63f275 |
|
|
|
63f275 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
5cee2c |
[ < ]
|
|
|
5cee2c |
[ > ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
[ << ]
|
|
|
5cee2c |
[ Up ]
|
|
|
5cee2c |
[ >> ]
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
<font size="-1">
|
|
|
5cee2c |
This document was generated on January, 13 2011 using texi2html 1.76.
|
|
|
4c79b5 |
</font>
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
|
|
|
4c79b5 |
</body>
|
|
|
4c79b5 |
</html>
|