diff --git a/Manual/Directories/trunk/Scripts/Functions/Render.texi b/Manual/Directories/trunk/Scripts/Functions/Render.texi index 6e67700..1d8f1d1 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render.texi @@ -1,777 +1,281 @@ -Rendition is the action through we produce content (images specially) -inside The CentOS Artwork Repository. In order to produce content -through rendition, the directory structure where that content is -stored in must be renderable (i.e., the rendition action must be -applied to a directory structure considered renderable). Presently, -renderable directories are stored under @file{trunk/Identity/Images} -and @file{trunk/Identity/Themes/Motifs} directories only. - -In order to render content inside renderable directory structures you -can use the @code{render} functionality of @command{centos-art.sh} -script. The @code{render} functionality takes one design template -(a.k.a., design model) from the template directory related and creates -an instance of it in order to apply translation messages, if any. -Later, using the translated design template instance, the command -renders the final content based on whether the design template -instance is a SVG file or XHTML file. If the design template instace -is a SVG file, the final content produced is a PNG image. On the other -hand, if the design template instance is a XHTML file, the final -content produced is a XHTML file. The rendition flow described so far -is known as the @command{centos-art.sh} script @emph{base-rendition} -flow and take place both in @emph{direct rendition} and @emph{theme -rendition}. - -Besides the base-rendition flow, the @command{centos-art} provides -@emph{post-rendition} and @emph{last-rendition} flows. The -post-rendition flow is applied to files produced as result of -base-rendition flow under the same directory structure. For example, -you can use post-rendition action to convert the PNG base output into -different outputs formats (e.g., JPG, PDF, etc.) before passing to -process the next file in the same directory structure. The -last-rendition flow, on the other hand, is applied to all files -produced as result of both base-rendition and post-rendition flows in -the same directory structure, just before passing to process a -different directory structure. For example, the @file{Preview.png} -image from Ksplash component is made of three images. In order to -build the @file{Preview.png} image through @command{centos-art.sh} we -need to wait for all the three images the @file{Preview.png} image is -made of to be rendered in order to combine them all together into just -one image (i.e., the @file{Preview.png} image). This is something we -can't do using post-rendition flow. - -Inside @file{trunk/Identity} directory structure, you can find that -base-rendition, post-rendition and last-rendition flows can be -combined to build @emph{directory-specific} rendition. The -directory-specific rendition exists to process specific renderable -directories in very specific ways. Using directory-specific rendition -speeds up production of different components like Syslinux, Grub, Gdm, -Kdm and Ksplash that require intermediate formats or even several -independent files, in order for the final content to be created. - -@subheading Renderable identity directory structures - -Renderable identity directory structures are the starting point of -identity rendition. Whenever we want to render a component of CentOS -corporate visual identity, we need to point @file{centos-art.sh} to a -renderable identity directory structure. If such renderable identity -directory structure doesn't exist, then it is good time to create it. - -Inside the working copy, one renderable identity directory structures -represents one visual manifestation of CentOS corporate visual -identity, or said differently, each visual manifestation of CentOS -corporate visual identity should have one renderable identity -directory structure. - -Inside renderable identity directory structures, @file{centos-art.sh} -can render both image-based and text-based files. Specification of -whether a renderable identity directory structure produces image-based -or text-based content is a configuration action that takes place in -the pre-rendition configuration script of that renderable identity -directory structure. - -Inside renderable identity directory structures, content production is -organized in different configurations. A content production -configuration is a unique combination of the components that make an -identity directory structure renderable. One content production -configuration does one thing only (e.g., to produce untranslated -images), but it can be extended (e.g., adding translation files) to -achieve different needs (e.g., to produce translated images). - -@subsubheading Design template without translation - -The design template without translation configuration is based on a -renderable identity directory structure with an empty translation -directory structure. In this configuration, one design template -produces one untranslated file. Both design templates and final -untranslated files share the same file name, but they differ one -another in file-type and file-extension. - -For example, to produce images without translations (there is no much -use in producing text-based files without translations), consider the -following configuration: +@subheading Goals -@table @strong -@item One renderable identity directory structure: - -In this example we used @file{Identity/Path/To/Dir} as the identity -component we want to produce untranslated images for. Identity -components can be either under @file{trunk/} or @file{branches/} -directory structure. - -The identity component (i.e., @file{Identity/Path/To/Dir}, in this -case) is also the bond component we use to connect the identity -directory structures with their respective auxiliar directories (i.e., -translation directory structres and pre-rendition configuration -structures). The bond component is the path convenction that -@file{centos-art.sh} uses to know where to look for related -translations, configuration scripts and whatever auxiliar thing a -renderable directory structure may need to have. - -@verbatim - | The bond component - |----------------->| -trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. -|-- Tpl <-- Design template directory. -| `-- file.svg <-- Design template file. -`-- Img <-- Directory used to store final files. - `-- file.png <-- Final image-based file produced from - design template file. -@end verbatim - -Inside design template directory, design template files are based on -@acronym{SVG,Scalable Vector Graphics} and use the extension -@code{.svg}. Design template files can be organized using several -directory levels to create a simple but extensible configuration, -specially if translated images are not required. - -In order for @acronym{SVG,Scalable Vector Graphics} files to be -considered ``design template'' files, they should be placed under the -design template directory and to have set a @code{CENTOSARTWORK} -object id inside. - -The @code{CENTOSARTWORK} word itself is a convenction name we use to -define which object/design area, inside a design template, the -@file{centos-art.sh} script will use to export as -@acronym{PNG,Portable Network Graphic} image at rendition time. -Whithout such object id specification, the @file{centos-art.sh} script -cannot know what object/design area you (as designer) want to export -as @acronym{PNG,Portable Network Graphic} image file. - -@quotation -@strong{Note} At rendition time, the content of @file{Img/} directory -structure is produced by @file{centos-art.sh} automatically. -@end quotation - -When a renderable identity directory structure is configured to -produce image-based content, @file{centos-art.sh} produces -@acronym{PNG,Portable Network Graphics} files with the @code{.png} -extension. Once the base image format has been produced, it is -possible for @file{centos-art.sh} to use it in order to automatically -create other image formats that may be needed (--- @strong{Removed}(pxref:trunk Scripts -Bash Functions Render Config) ---). - -Inside the working copy, you can find an example of ``design template -without translation'' configuration at @file{trunk/Identity/Models/}. - -@xref{Directories trunk Identity}, for more information. - -@item One translation directory structure: - -In order for an identity entry to be considered an identity renderable -directory structure, it should have a translation entry. The content -of the translation entry is relevant to determine how to process the -identity renderable directory entry. - -If the translation entry is empty (i.e., there is no file inside it), -@file{centos-art.sh} interprets the identity renderable directory -structure as a ``design templates without translation'' configuration. - -@verbatim - | The bond component - |----------------->| -trunk/Translations/Identity/Path/To/Dir -`-- (empty) -@end verbatim - -If the translation entry is not empty, @file{centos-art.sh} can -interpret the identity renderable directory structure as one of the -following configurations: ``design template with translation -(one-to-one)'' or ``design template with translation (optimized)''. -Which one of these configurations is used depends on the value -assigned to the matching list (@var{MATCHINGLIST}) variable in the -pre-rendition configuration script of the renderable identity -directory structure we are producing images for. - -If the matching list variable is empty (as it is by default), then -``design template with translation (one-to-one)'' configuration is -used. In this configuration it is required that both design templates -and translation files have the same file names. This way, @emph{one} -translation files is applied to @emph{one} design template, to produce -@emph{one} translated image. - -If the matching list variable is not empty (because you redefine it in -the pre-rendition configuration script), then ``design template with -translation (optimized)'' configuration is used instead. In this -configuration, design templates and translation files don't need to -have the same names since such name relationship between them is -specified in the matching list properly. - ---- @strong{Removed}(xref:trunk Translations) ---, for more information. - -@item One pre-rendition configuration script: - -In order to make an identity directory structure renderable, a -pre-rendition configuration script should exist for it. The -pre-rendition configuration script specifies what type of rendition -does @file{centos-art.sh} will perform over the identity directory -structure and how does it do that. - -@verbatim - | The bond component - |----------------->| -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - -} -@end verbatim - -Since translation directory structure is empty, @file{centos-art.sh} -assumes a ``design template without translation'' configuration to -produce untranslated images. - -To produce untranslated images, @file{centos-art.sh} takes one design -template and creates one temporal instance from it. Later, -@file{centos-art.sh} uses the temporal design template instance as -source file to export the final untranslated image. The action of -exporting images from @acronym{SVG,Scalable Vector Graphics} to -@acronym{PNG,Portable Network Graphics} is possible thanks to -Inkscape's command-line interface and the @code{CENTOSARTWORK} object -id we previously set inside design templates. - -@verbatim -centos-art.sh render --identity=trunk/Identity/Path/To/Dir -------------------------------------------------- -0 | Execute centos-art.sh on renderable identity directory structure. ---v---------------------------------------------- -trunk/Identity/Path/To/Dir/Tpl/file.svg -------------------------------------------------- -1 | Create instance from design template. ---v---------------------------------------------- -/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg -------------------------------------------------- -2 | Render untranslated image from design template instance. ---v---------------------------------------------- -trunk/Identity/NewDir/Img/file.png -------------------------------------------------- -3 | Remove design template instance. -@end verbatim - -Finally, when the untranslated image has been created, the temporal -design template instance is removed. At this point, -@file{centos-art.sh} takes the next design template and repeats the -whole production flow once again (design template by design template), -until all design templates be processed. - ---- @strong{Removed}(xref:trunk Scripts Bash Functions Render Config) ---, for more -information. -@end table +This section describes the @code{render} functionality of +@command{centos-art.sh} script and general examples about content +rendition inside a working copy of CentOS Artwork Repository. -@subsubheading Design template with translation (one-to-one) - -Producing untranslated images is fine in many cases, but not always. -Sometimes it is required to produce images in different languages and -that is something that untrasnlated image production cannot achieve. -However, if we fill its empty translation entry with translation files -(one for each design template) we extend the production flow from -untranslated image production to translated image production. - -In order for @file{centos-art.sh} to produce images correctly, each -design template should have one translation file and each translation -file should have one design template. Otherwise, if there is a -missing design template or a missing translation file, -@file{centos-art.sh} will not produce the final image related to the -missing component. - -In order for @file{centos-art.sh} to know which is the relation -between translation files and design templates the translation -directory structure is taken as reference. For example, the -@file{trunk/Translations/Identity/Path/To/Dir/file.sed} translation -file does match @file{trunk/Identity/Path/To/Dir/Tpl/file.svg} design -template, but it doesn't match -@file{trunk/Identity/Path/To/Dir/File.svg} or -@file{trunk/Identity/Path/To/Dir/Tpl/File.svg} or -@file{trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg} design -templates. - -The pre-rendition configuration script used to produce untranslated -images is the same we use to produce translated images. There is no -need to modify it. So, as we are using the same pre-rendition -configuration script, we can say that translated image production is -somehow an extended/improved version of untranslated image production. - -@quotation -@strong{Note} If we use no translation file in the translation entry -(i.e., an empty directory), @file{centos-art.sh} assumes the -untranslated image production. If we fill the translation entry with -translation files, @file{centos-art.sh} assumes the translated image -production. -@end quotation - -To produce final images, @file{centos-art.sh} applies one translation -file to one design template and produce a translated design template -instance. Later, @file{centos-art.sh} uses the translated template -instance to produce the translated image. Finally, when the translated -image has been produced, @file{centos-art.sh} removes the translated -design template instance. This production flow is repeated for each -translation file available in the translatio entry. - -@verbatim -centos-art.sh render --identity=trunk/Identity/Path/To/Dir -------------------------------------------------- -0 | Execute centos-art.sh on directory structure. ---v---------------------------------------------- -trunk/Translations/Identity/Path/To/Dir/file.sed -------------------------------------------------- -1 | Apply translation to design template. ---v---------------------------------------------- -trunk/Identity/Path/To/Dir/Tpl/file.svg -------------------------------------------------- -2 | Create design template instance. ---v---------------------------------------------- -/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg -------------------------------------------------- -3 | Render PNG image from template instance. ---v---------------------------------------------- -trunk/Identity/NewDir/Img/file.png -------------------------------------------------- -4 | Remove design template instance. -@end verbatim - -@subsubheading Design template with translation (optimized) - -Producing translated images satisfies almost all our production images -needs, but there is still a pitfall in them. In order to produce -translated images as in the ``one-to-one'' configuration describes -previously, it is required that one translation file has one design -template. That's useful in many cases, but what would happen if we -need to apply many different translation files to the same design -template? Should we have to duplicate the same design template file -for each translation file, in order to satisfy the ``one-to-one'' -relation? What if we need to assign translation files to design -templates arbitrarily? - -Certenly, that's something the ``one-to-one'' configuration cannot -handle. So, that's why we had to ``optimize'' it. The optimized -configuration consists on using a matching list (@var{MATCHINGLIST}) -variable that specifies the relationship between translation files and -design templates in an arbitrary way. Using such matching list between -translation files and design templates let us use as many assignment -combinations as translation files and design templates we are working -with. - -The @var{MATCHINGLIST} variable is set in the pre-rendition -configuration script of the component we want to produce images for. -By default, the @var{MATCHINGLIST} variable is empty which means no -matching list is used. Otherwise, if @var{MATCHINGLIST} variable has a -value different to empty value then, @file{centos-art.sh} interprets -the matching list in order to know how translation files are applied -to design templates. - -For example, consider the following configuration: +@subheading Description -@table @strong -@item One entry under @file{trunk/Identity/}: - -In this configuration we want to produce three images using a -paragraph-based style, controlled by @file{paragraph.svg} design -template; and one image using a list-based style, controlled by -@file{list.svg} design template. - -@verbatim -trunk/Identity/Path/To/Dir -|-- Tpl -| |-- paragraph.svg -| `-- list.svg -`-- Img - |-- 01-welcome.png - |-- 02-donate.png - |-- 03-docs.png - `-- 04-support.png -@end verbatim - -@item One entry under @file{trunk/Translations/}: - -In order to produce translated images we need to have one translation -file for each translated image we want to produce. Notice how -translation names do match final image file names, but how translation -names do not match design template names. When we use matching list -there is no need for translation files to match the names of design -templates, such name relation is set inside the matching list itself. - -@verbatim -trunk/Translations/Identity/Path/To/Dir -|-- 01-welcome.sed -|-- 02-donate.sed -|-- 03-docs.sed -`-- 04-support.sed -@end verbatim - -@item One entry under @file{trunk/trunk/Scripts/Bash/Functions/Render/Config/}: - -In order to produce different translated images using specific design -templates, we need to specify the relation between translation files -and design templates in a way that @file{centos-art.sh} could know -exactly what translation file to apply to what design template. This -relation between translation files and design templates is set using -the matching list @var{MATCHINGLIST} variable inside the pre-rendition -configuration script of the component we want to produce images for. - -@verbatim -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - - # Define matching list. - MATCHINGLIST="\ - paragraph.svg:\ - 01-welcome.sed\ - 02-donate.sed\ - 04-support.sed - list.svg:\ - 03-docs.sed - " - -} -@end verbatim - -As result, @file{centos-art.sh} will produce @file{01-welcome.png}, -@file{02-donate.png} and @file{04-support.png} using the -paragraph-based design template, but @file{03-docs.png} using the -list-based design template. -@end table +The @code{render} functionlity of @command{centos-art.sh} script +standardizes rendition tasks inside the working copy of CentOS Artwork +Repository. + +Inside the working copy of CentOS Artwork Repository, rendition tasks +take place inside renderable directories. Inside the @code{render} +functionality of @command{centos-art.sh} script, you can control +rendition tasks through different flows of rendition named +base-rendition, post-rendition, last-rendition and directory-specific +rendition. + +@subsubheading Renderable directories -@subsubheading Design template with translation (optimized+flexibility) - -In the production models we've seen so far, there are design templates -to produce untranslated images and translation files which combiend -with design templates produce translated images. That may seems like -all our needs are covered, doesn't it? Well, it @emph{almost} does. - -Generally, we use design templates to define how final images will -look like. Generally, each renderable directory structure has one -@file{Tpl/} directory where we organize design templates for that -identity component. So, we can say that there is only one unique -design template definition for each identity component; or what is the -same, said differently, identity components can be produced in one way -only, the way its own design template directory specifies. This is -not enough for theme production. It is a limitation, indeed. - -Initially, to create one theme, we created one renderable directory -structure for each theme component. When we found ourselves with many -themes, and components inside them, it was obvious that the same -design model was duplicated inside each theme. As design models were -independently one another, if we changed one theme's design model, -that change was useless to other themes. So, in order to reuse design -model changes, we unified design models into one common directory -structure. - -With design models unified in a common structure, another problem rose -up. As design models also had the visual style of theme components, -there was no difference between themes, so there was no apparent need -to have an independent theme directory structure for each different -theme. So, it was also needed to separate visual styles from design -models. - -At this point there are two independent worklines: one directory -structure to store design models (the final image characteristics -[i.e., dimensions, translation markers, etc.]) and one directory -structure to store visual styles (the final image visual style [i.e., -the image look and feel]). So, it is possible to handle both -different design models and different visual styles independtly one -another and later create combinations among them using -@file{centos-art.sh}. - -For example, consider the following configuration: +In order for a directory structure to be considered renderable, it +should have one directory structure for input files and one directory +structure for output files. Optionally, a third directory structure +might be available for storing translation files. + +Renderable directories are very tied to the way content is produced +inside the working copy of CentOS Artwork Repository. Presently, +content is produced through the following organizations: @table @strong -@item One entry under @file{trunk/Identity/Themes/Models/}: - -The design model entry exists to organize design model files (similar -to design templates). Both design models and design templates are very -similar; they both should have the @code{CENTOSARTWORK} export id -present to identify the exportation area, translation marks, etc. -However, design models do use dynamic backgrounds inclusion while -design templates don't. - -@verbatim - THEMEMODEL | | The bond component - |<----| |--------------------->| -trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ -|-- paragraph.svg -`-- list.svg -@end verbatim - -Inisde design models, dynamic backgrounds are required in order for -different artistic motifs to reuse common design models. Firstly, in -order to create dynamic backgrounds inside design models, we import a -bitmap to cover design model's background and later, update design -model's path information to replace fixed values to dynamic values. - -@item One entry under @file{trunk/Identity/Themes/Motifs/}: - -The artistic motif entry defines the visual style we want to produce -images for, only. Final images (i.e., those built from combining both -design models and artistic motif backrounds) are not stored here, but -under branches directory structure. In the artistic motif entry, we -only define those images that cannot be produced automatically by -@file{centos-art.sh} (e.g., Backgrounds, Color information, -Screenshots, etc.). - -@verbatim - Artistic motif name | | Artistic motif backgrounds - |<-------| |-------->| -trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ -|-- Img -| |-- Png -| | |-- 510x300.png -| | `-- 510x300-final.png -| `-- Jpg -| |-- 510x300.jpg -| `-- 510x300-final.jpg -|-- Tpl -| `-- 510x300.svg -`-- Xcf - `-- 510x300.xcf -@end verbatim - -@item One entry under @file{trunk/Translations/}: - -The translation entry specifies, by means of translation files, the -language-specific information we want to produce image for. When we -create the translation entry we don't use the name of neither design -model nor artistic motif, just the design model component we want to -produce images for. - -@verbatim - | The bond component - |--------------------->| -trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ -`-- 5 - |-- en - | |-- 01-welcome.sed - | |-- 02-donate.sed - | `-- 03-docs.sed - `-- es - |-- 01-welcome.sed - |-- 02-donate.sed - `-- 03-docs.sed -@end verbatim - -@item One entry under @file{trunk/Scripts/Bash/Functions/Render/Config/}: - -There is one pre-rendition configuration script for each theme -component. So, each time a theme component is rendered, its -pre-rendition configuration script is evaluated to teach -@file{centos-art.sh} how to render the component. - -@verbatim -trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/ -`-- render.conf.sh -@end verbatim - -In this configuration the pre-rendition configuration script -(@file{render.conf.sh}) would look like the following: - -@verbatim -function render_loadConfig { - - # Define rendition actions. - ACTIONS[0]='BASE:renderImage' - - # Define matching list. - MATCHINGLIST="\ - paragraph.svg:\ - 01-welcome.sed\ - 02-donate.sed - list.svg:\ - 03-docs.sed - " - - # Deifne theme model. - THEMEMODEL='Default' - -} -@end verbatim +@item Direct rendition + +In direct rendition, there is one directory structure for input files +(@file{trunk/Identity/Models}) and one directory structure for output +files (e.g., @file{trunk/Identity/Images}). Optionally, a third +directory structure is available to store the input related +translation files (e.g., @file{trunk/Locales/Identity/Models}). + +In direct rendition, when the @code{render} functionality of +@command{centos-art.sh} script is executed, it uses the input +directory structure to build a list of files to process, which is used +as reference to determine the location of the translation file and the +location of the output file, as well. + +@item Theme-specific rendition + +In theme-specific rendition, there is one directory structure to store +input files @file{trunk/Identity/Themes/Models}, one directory +structure to store translation files +(@file{trunk/Locales/Identity/Themes/Models/}), one directory structure +to store artistic motifs (@file{trunk/Identity/Themes/Motifs}) and one +directory structure to store output files +(@file{trunk/Identity/Themes/Motifs}). + +In theme-specific rendition, when the @code{render} functionality of +@command{centos-art.sh} script is executed, it uses the input +directory structure to build a list of files to process, which is used +as reference to determine the location of the translation file and the +location of the output file, as well. + +In contrast with direct rendition, when we use theme-specific +rendition, it is possible to combine both design models and artistic +motifs to produce output in an arbitrary way. This configuration is +specially interesting because it is possible to create different +artistic motifs and one unique design model in order to produce one +unique theme structure with different visual styles. Or the opposite, +to create different theme structures and apply one unique visual style +to produce different visual styles with the same theme structure. Or +even push a bit farther and experiment with arbitrary combinations +among them all. + @end table -The production flow of ``optimize+flexibility'' configuration@dots{} -@subheading Renderable translation directory structures - -Translation directory structures are auxiliar structures of renderable -identity directory structures. There is one translation directory -structure for each renderable identity directory structure. Inside -translation directory structures we organize translation files used by -renderable identity directory structures that produce translated -images. Renderable identity directory structures that produce -untranslated images don't use translation files, but they do use a -translation directory structure, an empty translation directory -structure, to be precise. - -In order to aliviate production of translation file, we made -translation directory structures renderable adding a template -(@file{Tpl/}) directory structure to handle common content inside -translation files. This way, we work on translation templates and -later use @file{centos-art.sh} to produce specific translation files -(based on translation templates) for different information (e.g., -languages, release numbers, architectures, etc.). - -If for some reason, translation files get far from translation -templates and translation templates become incovenient to produce such -translation files then, care should be taken to avoid replacing the -content of translation files with the content of translation templates -when @file{centos-art.sh} is executed to produce translation files -from translation templates. - -Inside renderable translation directory structures, -@file{centos-art.sh} can produce text-based files only. - -@subheading Copying renderable directory structures - -A renderable layout is formed by design models, design images, -pre-rendition configuration scripts and translations files. This way, -when we say to duplicate rendition stuff we are saying to duplicate -these four directory structures (i.e., design models, design images, -pre-rendition configuration scripts, and related translations files). - -When we duplicate directories, inside `trunk/Identity' directory -structure, we need to be aware of renderable layout described above -and the source location used to perform the duplication action. The -source location is relevant to centos-art.sh script in order to -determine the required auxiliar information inside directory -structures that need to be copied too (otherwise we may end up with -orphan directory structures unable to be rendered, due the absence of -required information). - -In order for a renderable directory structure to be valid, the new -directory structure copied should match the following conditions: - -@enumerate -@item To have a unique directory structure under -@file{trunk/Identity}, organized by any one of the above -organizational designs above. - -@item To have a unique directory structure under -@file{trunk/Translations} to store translation files. - -@item To have a unique directory structure under -@file{trunk/Scripts/Bash/Functions/Render/Config} to set pre-rendition -configuration script. -@end enumerate - -As convenction, the @code{render_doCopy} function uses -@file{trunk/Identity} directory structure as source location. Once -the @file{trunk/Identity} directory structure has been specified and -verified, the related path information is built from it and copied -automatically to the new location specified by @var{FLAG_TO} variable. - -Design templates + No translation: - -Command: -- centos-art render --copy=trunk/Identity/Path/To/Dir --to=trunk/Identity/NewPath/To/Dir - -Sources: -- trunk/Identity/Path/To/Dir -- trunk/Translations/Identity/Path/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir - -Targets: -- trunk/Identity/NewPath/To/Dir -- trunk/Translations/Identity/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir - -Renderable layout 2: - -Command: -- centos-art render --copy=trunk/Identity/Themes/Motifs/TreeFlower \ - --to=trunk/Identity/Themes/Motifs/NewPath/To/Dir - -Sources: -- trunk/Identity/Themes/Motifs/TreeFlower -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/TreeFlower -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower - -Targets: -- trunk/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir - -Notice that design models are not included in source or target -locations. This is intentional. In ``Renderable layout 2'', design -models live by their own, they just exist, they are there, available -for any artistic motif to use. By default `Themes/Models/Default' -design model directory structure is used, but other design models -directory structures (under Themes/Models/) can be created and used -changing the value of THEMEMODEL variable inside the pre-rendition -configuration script of the artistic motif source location you want to -produce. - -Notice how translations and pre-rendition configuration scripts may -both be equal in source and target. This is because such structures -are common to all artistic motifs (the default values to use when no -specific values are provided). - -- The common directory structures are not copied or deleted. We cannot - copy a directory structure to itself. - -- The common directory structures represent the default value to use - when no specific translations and/or pre-rendition configuration - script are provided inside source location. - -- The specific directory structures, if present, are both copiable and - removable. This is, when you perform a copy or delete action from - source, that source specific auxiliar directories are transfered in - the copy action to a new location (that specified by FLAG_TO - variable). - -- When translations and/or pre-rendition configuration scripts are - found inside the source directory structure, the centos-art.sh - script loads common auxiliar directories first and later specific - auxiliar directories. This way, identity rendition of source - locations can be customized idividually over the base of common - default values. - -- The specific auxiliar directories are optional. - -- The common auxiliar directories should be present always. This is, - in order to provide the information required by render functionality - (i.e., to make it functional in the more basic level of its - existence). - -Notice how the duplication process is done from `trunk/Identity' on, -not the oposite. If you try to duplicate a translation structure (or -similar auxiliar directory structures like pre-rendition configuration -scripts), the `trunk/Identity' for that translation is not created. -This limitation is impossed by the fact that many `trunk/Identity' -directory structures may reuse/share the same translation directory -structure. We cannot delete one translation (or similar) directory -structures while a related `trunk/Identity/' directory structure is -still in need of it. - -The `render_doCopy' functionality does duplicate directory structures -directly involved in rendition process only. Once such directories -have been duplicated, the functionality stops thereat. +In both direct and theme-specific rendition, if the location where the +output file should be stored doesn't exist, the @code{render} +functionality of @command{centos-art.sh} script will create it for +you. + +In both direct and theme-specific rendition, if the input related +translation file doesn't exist, the @code{render} functionality of +@command{centos-art.sh} script will produce the output in the same +language of its input file. + +@subsubheading The base-rendition flow + +The base-rendition flow is the first rendition flow of all rendition +flows available and takes place immediatly after executing the +@code{render} functionality of @command{centos-art.sh} script. + +The base-rendition consist on producing different output formats in +different languages from one single input format. This is, one input +file produces one output file. Inside the @code{render} functionality +of @command{centos-art.sh} script, the input format is always an XML +file (e.g., SVG, XHTML, Docbook) and the output format depends on the +input file provided. + +For example, when the input format is a SVG file, the base output is a +PNG file; when the input format is XHTML the base output is an XHTML +file; when the input format is a Docbook file the base output is an +XHTML file. + +@subsubheading The post-rendition flow + +The post-rendition flow takes place after base-rendition and is +applied to create modified copies of the file produced by +base-rendition in the same directory structure. + +For example, when the input format is a SVG file and the output is a +PNG file, we can use post-rendition to extend the base output to other +image formats. In fact, it is possible to do anything permitted by the +ImageMagick and Netpbm programs (e.g., resize, rotate, reduce color, +etc.) over the base output. + +@subsubheading The last-rendition flow + +The last-rendition flow takes place after post-rendition and is +applied to all files produced as result of both base-rendition and +post-rendition flows in the same directory structure, just before +passing to process a different directory structure. + +For example, consider the @file{Preview.png} image of Ksplash which is +made of three different images. In order to build the +@file{Preview.png} image, we need to create the three images the +@file{Preview.png} image is made of first (e.g., through +base-rendition) and then, combine them all together into one new +image, the @file{Preview.png} image in this case. + +Another example of using last-rendition flow is that related to GDM +and KDM @file{tar.gz} file construction. Each @file{tar.gz} file is +made of several files that need to be put together in order to make +them installable. In the very specific case of GDM and KDM some of the +required files are retrived from design models directory structure and +others from artistic motifs directory structure after had been +produced through base-rendition. In this case, the action of grouping +files and packing them is realized through last-rendition action. This +couldn't be possible through post-rendition because we need to wait to +have two images first (produced through base-rendition) before we +could grouping them all into the @file{tar.gz} package. + +@subsubheading The directory-specific rendition flow + +The directory-specific rendition flow isn't a rendition flow by itself +but a combination of rendition flows that are applied to specific +directories at rendition time. + +Inside the working copy of CentOS Artwork Repository there are some +directories structures that exist to achieve specific tasks every time +they are produced. The directory-specific rendition flow provides a +way for the @code{render} functionality of @command{centos-art.sh} +script to know what actions to apply to what directory structure when +producing them. + +The directory-specific rendition flow combines the base-rendition, +post-rendition and last-rendition flows in specific ways and applies +them to specific directory structures when they are detected. Using +this configuration can speed up production of different components +like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate +formats or even several independent files, in order for the final +content to be created. + +@subsubheading Translations + +To translate output files, the @code{render} functionality of +@command{centos-art.sh} script creates a translated instance of the +input file and uses it then to create the base output file. The +translated instance is created using the related translation messages +of the input file. Translation messages are stored under +@file{trunk/Locales} and are created using the @code{locale} +functionality of @command{centos-art.sh} script (@pxref{Directories +trunk Scripts Functions Locale}). @subheading Usage -@itemize -@item ... -@end itemize +@command{centos-art render [OPTIONS] path/to/dir} + +@subsubheading Synopsis + +The @file{path/to/dir} parameter refers the path information related +to the directory structure inside the working copy of CentOS Artwork +Repository you'r going to produce. This path information defines +whether to perform direct or theme-specific rendition. + +You can use the @file{path/to/dir} information to control the amount +of components you'll produce inside a specific renderable location. +The more deep you go inside the path the more specific you are when +producing theme components. Sometimes, you can also combine the use of +@file{path/to/dir} with the @option{--filter} option to have a finer +control over the files you produce. + +The @code{render} functionality of @command{centos-art.sh} script +accepts the following optios: + +@table @option +@item --quiet + +Supress all output messages, including confirmation question. Use this +option with care. + +@item --filter="REGEX" + +Reduce the list of files to process using @samp{REGEX} as pattern. + +@item --answer-yes + +Assume `yes' to all confirmation questions. + +@item --dont-commit-changes + +Supress all commit and update actions realized over files already +processed, before and after the action itself had took place in the +working copy. + +@item --releasever="STRING" + +Produce content for the release version specified in @samp{STRING}. +This option is generaly used in direct rendition, where design models +aren't organized using release versions and architectures as +reference. + +@item --basearch="STRING" + +Produce content for the architecture specified in @samp{STRING}. This +option is generaly used in direct rendition, where design models aren't +organized using release versions and architectures as reference. + +@item --convert="STRING" + +Uses post-rendition to convert output produced by base-rendition to +any image format specified in @samp{STRING}. This option is an +interface for the @command{convert} command of ImageMagick tool set, +so it is applicable to images output only. + +@item --rotate="STRING" + +Uses post-rendition to rotate output produced by base-rendition to any +angle specified in @samp{STRING}. This option is an interface for the +@command{convert} command of ImageMagick tool set, so it is +applicable to images output only. + +@item --resize="STRING" + +Uses post-rendition to resize the base-rendition output to any angle +specified in @samp{STRING}. This option is an interface for the +@command{convert} command of ImageMagick tool set, so it is applicable +to images output only. + +@item --group-by="STRING" + +Group base output files inside directories. Directories used to stored +base output files are named using the file extension of base output +files. For example: if the base output file is a @file{.png} file, it +is moved inside a @file{Png/} directory; if the current file is a +@file{.jpg} file, it is stored inside a @file{Jpg/} directory, and so +on. + +Directories used to group files are created in the same location that +base output files would normaly do. + +@item --theme-model="STRING" +Specify, in the @samp{STRING}, the name of the theme model you want to +use to produce theme motifs. By default, if this option is not passed, +the @samp{Default} theme model is used as reference to produce theme +motifs. +@end table + +@subsubheading Examples + +@table @command +@item centos-art render trunk/Identity/Images/Brands +@item centos-art render trunk/Identity/Images/Brands --filter="symbol" +@item centos-art render trunk/Identity/Themes/Motifs/Flame/2 +@end table @subheading See also -@menu -@comment --- Removed(* Directories trunk Scripts Functions Render Config::) --- -@end menu +@itemize +@item @ref{Directories trunk Scripts Functions} +@item @ref{Directories trunk Scripts} +@item @ref{Directories trunk} +@end itemize diff --git a/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi b/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi index 8f4a159..253225c 100755 --- a/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Tuneup.texi @@ -7,35 +7,34 @@ maintainance inside a working copy of CentOS Artwork Repository. @subheading Description The @code{tuneup} functionality of @command{centos-art.sh} script -provides the standard way of maintaining files inside your working -copy of CentOS Artwork Repository. +provides the standard way of maintaining files inside the working copy +of CentOS Artwork Repository. Tasks related to file maintainance are repetitive. You might find yourself doing them time after time inside the working copy of CentOS -Artwork Repository. Some of these maintainance tasks are updating top -comments on shell scripts, creating table of contents for web pages, -updating metadata related to design models and remove unused -definitions on design models. - -The maintainance tasks are associated to file extensions. This way, -the @code{tuneup} functionality know what maintainance tasks should be -applied to what files inside the working copy of CentOS Artwork -Repository. For example, when you execute the @code{tuneup} -functionality, it makes a list of files based on supported extensions -(e.g., @file{.sh}, @file{.svg} and @file{.xhtml}) and apply -maintainance tasks file by file accordingly to its file extension. +Artwork Repository. Some of these maintainance tasks do update top +comments on shell scripts, create table of contents for web pages, +update metadata related to design models and remove unused definitions +from design models. + +When you execute the @code{tuneup} functionality of +@command{centos-art.sh} script, it looks for all files that match the +supported extensions (e.g., @file{.sh}, @file{.svg} and @file{.xhtml}) +in the directory specified, builds a list with them and applies the +maintainance tasks using file extensions as reference. @subsubheading Maintaining @file{.sh} files -If shell scripts are found, the @code{tuneup} functionality reads a -comment template -(@file{trunk/Scripts/Functions/Prepare/Config/shell_topcomment.sed}) -and applies it to the shell scripts, one by one. As result, all shell +If shell scripts are found, the @code{tuneup} functionality of +@command{centos-art.sh} script reads a comment template from +@file{trunk/Scripts/Functions/Prepare/Config/shell_topcomment.sed} and +applies it to shell scripts found, one by one. As result, all shell scripts will end up having the same copyright and license information the comment template does. -In order for the comment template to be applied correctly, the shell -script you write must have the following structure: +In order for the shell script top comment template to be applied +correctly, the shell scripts you write must have the following +structure: @verbatim 1| #!/bin/bash @@ -55,9 +54,10 @@ script you write must have the following structure: 15| } @end verbatim -The comment template replaces all the lines between the -@samp{Copyright} line (e.g., line 5) and the first separator line -(e.g., line 9). Everything else in the file will remain immutable. +The @code{tuneup} functionality of @command{centos-art.sh} script +replaces all lines between the @samp{Copyright} line (e.g., line 5) +and the first separator line (e.g., line 9), inclusively. Everything +else in the file will remain immutable. @subsubheading Maintaining @file{.svg} files @@ -69,30 +69,32 @@ metadata template has been applied and, before passing to next file, all unused definition are removed from file, too. The metadata we apply from the metadata template is created dynamicaly -using the file found absolute path, the workstation time information -and the @command{centos-art.sh} script copyright information as +combining the file absolute path, the workstation time information and +the @command{centos-art.sh} script copyright holder information as reference. Additionally, the @emph{Creative Common Distribution-ShareAlike 3.0 License} is also set in the metadata. The elimination of unused definitions inside SVG files takes place through the @option{--vacuum-defs} option of @command{inkscape} -command-line interface. +command-line interface which is described in its man page +(@command{man inkscape}). @subsubheading Maintaining @file{.xhtml} files -If web pages are found, the @code{tuneup} functionality transforms web -page headings to make them accessible through a table of contents. -The table of contents is expanded in place, wherever the @code{
} piece of code be in the page. +If web pages are found, the @code{tuneup} functionality of +@command{centos-art.sh} script transforms web page headings to make +them accessible through a table of contents. The table of contents is +expanded in place, wherever the @code{
} piece +of code be in the page. Once the @code{
} piece of code has be expanded, there is no need to put anything else in the page. You can run the @code{tuneup} functionality everytime you update the heading information so as to update the table of contents, too. -In order for the @code{tuneup} functionality to transform headings, -you need to put headings in just one line using one of the following -forms: +In order for the @code{tuneup} functionality of +@command{centos-art.sh} script to transform headings, you need to put +headings in just one line using one of the following forms: @verbatim

Title

@@ -106,8 +108,8 @@ and @option{href} options from the anchor element are set dynamically using the md5sum output of combining the page location, the @code{head-} string and the heading string. If any of the components used to build the heading reference changes, you need to run the the -@code{tuneup} functionality in order for the anchor elements to use -the correct information. +@code{tuneup} functionality of @command{centos-art.sh} script in order +for the anchor elements to use the correct information. @subheading Usage diff --git a/Manual/repository.info.bz2 b/Manual/repository.info.bz2 index adb3198..d7c7288 100644 Binary files a/Manual/repository.info.bz2 and b/Manual/repository.info.bz2 differ diff --git a/Manual/repository.pdf b/Manual/repository.pdf index 052b563..0499be7 100644 Binary files a/Manual/repository.pdf and b/Manual/repository.pdf differ diff --git a/Manual/repository.txt.bz2 b/Manual/repository.txt.bz2 index 3aad201..c5b6113 100644 Binary files a/Manual/repository.txt.bz2 and b/Manual/repository.txt.bz2 differ diff --git a/Manual/repository.xhtml.tar.bz2 b/Manual/repository.xhtml.tar.bz2 index 75fe9bb..d4e42b3 100644 Binary files a/Manual/repository.xhtml.tar.bz2 and b/Manual/repository.xhtml.tar.bz2 differ diff --git a/Manual/repository.xml b/Manual/repository.xml index c35e97b..a0dfd80 100644 --- a/Manual/repository.xml +++ b/Manual/repository.xml @@ -2982,349 +2982,147 @@ centos-art.sh prepare [OPTIONS] Directories
The <file>trunk/Scripts/Functions/Render</file> Directory - Directories trunk Scripts Functions RenderRendition is the action through we produce content (images specially) inside The CentOS Artwork Repository. In order to produce content through rendition, the directory structure where that content is stored in must be renderable (i.e., the rendition action must be applied to a directory structure considered renderable). Presently, renderable directories are stored under trunk/Identity/Images and trunk/Identity/Themes/Motifs directories only. - In order to render content inside renderable directory structures you can use the render functionality of centos-art.sh script. The render functionality takes one design template (a.k.a., design model) from the template directory related and creates an instance of it in order to apply translation messages, if any. Later, using the translated design template instance, the command renders the final content based on whether the design template instance is a SVG file or XHTML file. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a XHTML file, the final content produced is a XHTML file. The rendition flow described so far is known as the centos-art.sh script base-rendition flow and take place both in direct rendition and theme rendition. - Besides the base-rendition flow, the centos-art provides post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs formats (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow, on the other hand, is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art.sh we need to wait for all the three images the Preview.png image is made of to be rendered in order to combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. - Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created. - Renderable identity directory structures - Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS corporate visual identity, we need to point centos-art.sh to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it. - Inside the working copy, one renderable identity directory structures represents one visual manifestation of CentOS corporate visual identity, or said differently, each visual manifestation of CentOS corporate visual identity should have one renderable identity directory structure. - Inside renderable identity directory structures, centos-art.sh can render both image-based and text-based files. Specification of whether a renderable identity directory structure produces image-based or text-based content is a configuration action that takes place in the pre-rendition configuration script of that renderable identity directory structure. - Inside renderable identity directory structures, content production is organized in different configurations. A content production configuration is a unique combination of the components that make an identity directory structure renderable. One content production configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). - Design template without translation - The design template without translation configuration is based on a renderable identity directory structure with an empty translation directory structure. In this configuration, one design template produces one untranslated file. Both design templates and final untranslated files share the same file name, but they differ one another in file-type and file-extension. - For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration: + Directories trunk Scripts Functions Render + Goals + This section describes the render functionality of centos-art.sh script and general examples about content rendition inside a working copy of CentOS Artwork Repository. + Description + The render functionlity of centos-art.sh script standardizes rendition tasks inside the working copy of CentOS Artwork Repository. + Inside the working copy of CentOS Artwork Repository, rendition tasks take place inside renderable directories. Inside the render functionality of centos-art.sh script, you can control rendition tasks through different flows of rendition named base-rendition, post-rendition, last-rendition and directory-specific rendition. + Renderable directories + In order for a directory structure to be considered renderable, it should have one directory structure for input files and one directory structure for output files. Optionally, a third directory structure might be available for storing translation files. + Renderable directories are very tied to the way content is produced inside the working copy of CentOS Artwork Repository. Presently, content is produced through the following organizations: - One renderable identity directory structure: + Direct rendition - In this example we used Identity/Path/To/Dir as the identity component we want to produce untranslated images for. Identity components can be either under trunk/ or branches/ directory structure. - The identity component (i.e., Identity/Path/To/Dir, in this case) is also the bond component we use to connect the identity directory structures with their respective auxiliar directories (i.e., translation directory structres and pre-rendition configuration structures). The bond component is the path convenction that centos-art.sh uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have. - | -trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. -|-- Tpl <-- Design template directory. -| `-- file.svg <-- Design template file. -`-- Img <-- Directory used to store final files. - `-- file.png <-- Final image-based file produced from - design template file. -]]> - Inside design template directory, design template files are based on SVGScalable Vector Graphics and use the extension .svg. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required. - In order for SVGScalable Vector Graphics files to be considered “design template” files, they should be placed under the design template directory and to have set a CENTOSARTWORK object id inside. - The CENTOSARTWORK word itself is a convenction name we use to define which object/design area, inside a design template, the centos-art.sh script will use to export as PNGPortable Network Graphic image at rendition time. Whithout such object id specification, the centos-art.sh script cannot know what object/design area you (as designer) want to export as PNGPortable Network Graphic image file. - - Note At rendition time, the content of Img/ directory structure is produced by centos-art.sh automatically. - - When a renderable identity directory structure is configured to produce image-based content, centos-art.sh produces PNGPortable Network Graphics files with the .png extension. Once the base image format has been produced, it is possible for centos-art.sh to use it in order to automatically create other image formats that may be needed (— Removed(pxref:trunk Scripts Bash Functions Render Config) —). - Inside the working copy, you can find an example of “design template without translation” configuration at trunk/Identity/Models/. - See Directories trunk Identity, for more information. + In direct rendition, there is one directory structure for input files (trunk/Identity/Models) and one directory structure for output files (e.g., trunk/Identity/Images). Optionally, a third directory structure is available to store the input related translation files (e.g., trunk/Locales/Identity/Models). + In direct rendition, when the render functionality of centos-art.sh script is executed, it uses the input directory structure to build a list of files to process, which is used as reference to determine the location of the translation file and the location of the output file, as well. - One translation directory structure: + Theme-specific rendition - In order for an identity entry to be considered an identity renderable directory structure, it should have a translation entry. The content of the translation entry is relevant to determine how to process the identity renderable directory entry. - If the translation entry is empty (i.e., there is no file inside it), centos-art.sh interprets the identity renderable directory structure as a “design templates without translation” configuration. - | -trunk/Translations/Identity/Path/To/Dir -`-- (empty) -]]> - If the translation entry is not empty, centos-art.sh can interpret the identity renderable directory structure as one of the following configurations: “design template with translation (one-to-one)” or “design template with translation (optimized)”. Which one of these configurations is used depends on the value assigned to the matching list (MATCHINGLIST) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for. - If the matching list variable is empty (as it is by default), then “design template with translation (one-to-one)” configuration is used. In this configuration it is required that both design templates and translation files have the same file names. This way, one translation files is applied to one design template, to produce one translated image. - If the matching list variable is not empty (because you redefine it in the pre-rendition configuration script), then “design template with translation (optimized)” configuration is used instead. In this configuration, design templates and translation files don't need to have the same names since such name relationship between them is specified in the matching list properly. - — Removed(xref:trunk Translations) —, for more information. + In theme-specific rendition, there is one directory structure to store input files trunk/Identity/Themes/Models, one directory structure to store translation files (trunk/Locales/Identity/Themes/Models/), one directory structure to store artistic motifs (trunk/Identity/Themes/Motifs) and one directory structure to store output files (trunk/Identity/Themes/Motifs). + In theme-specific rendition, when the render functionality of centos-art.sh script is executed, it uses the input directory structure to build a list of files to process, which is used as reference to determine the location of the translation file and the location of the output file, as well. + In contrast with direct rendition, when we use theme-specific rendition, it is possible to combine both design models and artistic motifs to produce output in an arbitrary way. This configuration is specially interesting because it is possible to create different artistic motifs and one unique design model in order to produce one unique theme structure with different visual styles. Or the opposite, to create different theme structures and apply one unique visual style to produce different visual styles with the same theme structure. Or even push a bit farther and experiment with arbitrary combinations among them all. +
+ In both direct and theme-specific rendition, if the location where the output file should be stored doesn't exist, the render functionality of centos-art.sh script will create it for you. + In both direct and theme-specific rendition, if the input related translation file doesn't exist, the render functionality of centos-art.sh script will produce the output in the same language of its input file. + The base-rendition flow + The base-rendition flow is the first rendition flow of all rendition flows available and takes place immediatly after executing the render functionality of centos-art.sh script. + The base-rendition consist on producing different output formats in different languages from one single input format. This is, one input file produces one output file. Inside the render functionality of centos-art.sh script, the input format is always an XML file (e.g., SVG, XHTML, Docbook) and the output format depends on the input file provided. + For example, when the input format is a SVG file, the base output is a PNG file; when the input format is XHTML the base output is an XHTML file; when the input format is a Docbook file the base output is an XHTML file. + The post-rendition flow + The post-rendition flow takes place after base-rendition and is applied to create modified copies of the file produced by base-rendition in the same directory structure. + For example, when the input format is a SVG file and the output is a PNG file, we can use post-rendition to extend the base output to other image formats. In fact, it is possible to do anything permitted by the ImageMagick and Netpbm programs (e.g., resize, rotate, reduce color, etc.) over the base output. + The last-rendition flow + The last-rendition flow takes place after post-rendition and is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. + For example, consider the Preview.png image of Ksplash which is made of three different images. In order to build the Preview.png image, we need to create the three images the Preview.png image is made of first (e.g., through base-rendition) and then, combine them all together into one new image, the Preview.png image in this case. + Another example of using last-rendition flow is that related to GDM and KDM tar.gz file construction. Each tar.gz file is made of several files that need to be put together in order to make them installable. In the very specific case of GDM and KDM some of the required files are retrived from design models directory structure and others from artistic motifs directory structure after had been produced through base-rendition. In this case, the action of grouping files and packing them is realized through last-rendition action. This couldn't be possible through post-rendition because we need to wait to have two images first (produced through base-rendition) before we could grouping them all into the tar.gz package. + The directory-specific rendition flow + The directory-specific rendition flow isn't a rendition flow by itself but a combination of rendition flows that are applied to specific directories at rendition time. + Inside the working copy of CentOS Artwork Repository there are some directories structures that exist to achieve specific tasks every time they are produced. The directory-specific rendition flow provides a way for the render functionality of centos-art.sh script to know what actions to apply to what directory structure when producing them. + The directory-specific rendition flow combines the base-rendition, post-rendition and last-rendition flows in specific ways and applies them to specific directory structures when they are detected. Using this configuration can speed up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created. + Translations + To translate output files, the render functionality of centos-art.sh script creates a translated instance of the input file and uses it then to create the base output file. The translated instance is created using the related translation messages of the input file. Translation messages are stored under trunk/Locales and are created using the locale functionality of centos-art.sh script (see Directories trunk Scripts Functions Locale). + Usage + centos-art render [OPTIONS] path/to/dir + Synopsis + The path/to/dir parameter refers the path information related to the directory structure inside the working copy of CentOS Artwork Repository you'r going to produce. This path information defines whether to perform direct or theme-specific rendition. + You can use the path/to/dir information to control the amount of components you'll produce inside a specific renderable location. The more deep you go inside the path the more specific you are when producing theme components. Sometimes, you can also combine the use of path/to/dir with the option to have a finer control over the files you produce. + The render functionality of centos-art.sh script accepts the following optios: + - One pre-rendition configuration script: + - In order to make an identity directory structure renderable, a pre-rendition configuration script should exist for it. The pre-rendition configuration script specifies what type of rendition does centos-art.sh will perform over the identity directory structure and how does it do that. - | -trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -`-- render.conf.sh -]]> - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - - Since translation directory structure is empty, centos-art.sh assumes a “design template without translation” configuration to produce untranslated images. - To produce untranslated images, centos-art.sh takes one design template and creates one temporal instance from it. Later, centos-art.sh uses the temporal design template instance as source file to export the final untranslated image. The action of exporting images from SVGScalable Vector Graphics to PNGPortable Network Graphics is possible thanks to Inkscape's command-line interface and the CENTOSARTWORK object id we previously set inside design templates. - - Finally, when the untranslated image has been created, the temporal design template instance is removed. At this point, centos-art.sh takes the next design template and repeats the whole production flow once again (design template by design template), until all design templates be processed. - — Removed(xref:trunk Scripts Bash Functions Render Config) —, for more information. + Supress all output messages, including confirmation question. Use this option with care. -
- Design template with translation (one-to-one) - Producing untranslated images is fine in many cases, but not always. Sometimes it is required to produce images in different languages and that is something that untrasnlated image production cannot achieve. However, if we fill its empty translation entry with translation files (one for each design template) we extend the production flow from untranslated image production to translated image production. - In order for centos-art.sh to produce images correctly, each design template should have one translation file and each translation file should have one design template. Otherwise, if there is a missing design template or a missing translation file, centos-art.sh will not produce the final image related to the missing component. - In order for centos-art.sh to know which is the relation between translation files and design templates the translation directory structure is taken as reference. For example, the trunk/Translations/Identity/Path/To/Dir/file.sed translation file does match trunk/Identity/Path/To/Dir/Tpl/file.svg design template, but it doesn't match trunk/Identity/Path/To/Dir/File.svg or trunk/Identity/Path/To/Dir/Tpl/File.svg or trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg design templates. - The pre-rendition configuration script used to produce untranslated images is the same we use to produce translated images. There is no need to modify it. So, as we are using the same pre-rendition configuration script, we can say that translated image production is somehow an extended/improved version of untranslated image production. - - Note If we use no translation file in the translation entry (i.e., an empty directory), centos-art.sh assumes the untranslated image production. If we fill the translation entry with translation files, centos-art.sh assumes the translated image production. - - To produce final images, centos-art.sh applies one translation file to one design template and produce a translated design template instance. Later, centos-art.sh uses the translated template instance to produce the translated image. Finally, when the translated image has been produced, centos-art.sh removes the translated design template instance. This production flow is repeated for each translation file available in the translatio entry. - - Design template with translation (optimized) - Producing translated images satisfies almost all our production images needs, but there is still a pitfall in them. In order to produce translated images as in the “one-to-one” configuration describes previously, it is required that one translation file has one design template. That's useful in many cases, but what would happen if we need to apply many different translation files to the same design template? Should we have to duplicate the same design template file for each translation file, in order to satisfy the “one-to-one” relation? What if we need to assign translation files to design templates arbitrarily? - Certenly, that's something the “one-to-one” configuration cannot handle. So, that's why we had to “optimize” it. The optimized configuration consists on using a matching list (MATCHINGLIST) variable that specifies the relationship between translation files and design templates in an arbitrary way. Using such matching list between translation files and design templates let us use as many assignment combinations as translation files and design templates we are working with. - The MATCHINGLIST variable is set in the pre-rendition configuration script of the component we want to produce images for. By default, the MATCHINGLIST variable is empty which means no matching list is used. Otherwise, if MATCHINGLIST variable has a value different to empty value then, centos-art.sh interprets the matching list in order to know how translation files are applied to design templates. - For example, consider the following configuration: - - One entry under trunk/Identity/: + - In this configuration we want to produce three images using a paragraph-based style, controlled by paragraph.svg design template; and one image using a list-based style, controlled by list.svg design template. - + Reduce the list of files to process using REGEX as pattern. - One entry under trunk/Translations/: + - In order to produce translated images we need to have one translation file for each translated image we want to produce. Notice how translation names do match final image file names, but how translation names do not match design template names. When we use matching list there is no need for translation files to match the names of design templates, such name relation is set inside the matching list itself. - + Assume `yes' to all confirmation questions. - One entry under trunk/trunk/Scripts/Bash/Functions/Render/Config/: + - In order to produce different translated images using specific design templates, we need to specify the relation between translation files and design templates in a way that centos-art.sh could know exactly what translation file to apply to what design template. This relation between translation files and design templates is set using the matching list MATCHINGLIST variable inside the pre-rendition configuration script of the component we want to produce images for. - - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - - As result, centos-art.sh will produce 01-welcome.png, 02-donate.png and 04-support.png using the paragraph-based design template, but 03-docs.png using the list-based design template. + Supress all commit and update actions realized over files already processed, before and after the action itself had took place in the working copy. -
- Design template with translation (optimized+flexibility) - In the production models we've seen so far, there are design templates to produce untranslated images and translation files which combiend with design templates produce translated images. That may seems like all our needs are covered, doesn't it? Well, it almost does. - Generally, we use design templates to define how final images will look like. Generally, each renderable directory structure has one Tpl/ directory where we organize design templates for that identity component. So, we can say that there is only one unique design template definition for each identity component; or what is the same, said differently, identity components can be produced in one way only, the way its own design template directory specifies. This is not enough for theme production. It is a limitation, indeed. - Initially, to create one theme, we created one renderable directory structure for each theme component. When we found ourselves with many themes, and components inside them, it was obvious that the same design model was duplicated inside each theme. As design models were independently one another, if we changed one theme's design model, that change was useless to other themes. So, in order to reuse design model changes, we unified design models into one common directory structure. - With design models unified in a common structure, another problem rose up. As design models also had the visual style of theme components, there was no difference between themes, so there was no apparent need to have an independent theme directory structure for each different theme. So, it was also needed to separate visual styles from design models. - At this point there are two independent worklines: one directory structure to store design models (the final image characteristics [i.e., dimensions, translation markers, etc.]) and one directory structure to store visual styles (the final image visual style [i.e., the image look and feel]). So, it is possible to handle both different design models and different visual styles independtly one another and later create combinations among them using centos-art.sh. - For example, consider the following configuration: - - One entry under trunk/Identity/Themes/Models/: + - The design model entry exists to organize design model files (similar to design templates). Both design models and design templates are very similar; they both should have the CENTOSARTWORK export id present to identify the exportation area, translation marks, etc. However, design models do use dynamic backgrounds inclusion while design templates don't. - | -trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ -|-- paragraph.svg -`-- list.svg -]]> - Inisde design models, dynamic backgrounds are required in order for different artistic motifs to reuse common design models. Firstly, in order to create dynamic backgrounds inside design models, we import a bitmap to cover design model's background and later, update design model's path information to replace fixed values to dynamic values. + Produce content for the release version specified in STRING. This option is generaly used in direct rendition, where design models aren't organized using release versions and architectures as reference. - One entry under trunk/Identity/Themes/Motifs/: + - The artistic motif entry defines the visual style we want to produce images for, only. Final images (i.e., those built from combining both design models and artistic motif backrounds) are not stored here, but under branches directory structure. In the artistic motif entry, we only define those images that cannot be produced automatically by centos-art.sh (e.g., Backgrounds, Color information, Screenshots, etc.). - | -trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ -|-- Img -| |-- Png -| | |-- 510x300.png -| | `-- 510x300-final.png -| `-- Jpg -| |-- 510x300.jpg -| `-- 510x300-final.jpg -|-- Tpl -| `-- 510x300.svg -`-- Xcf - `-- 510x300.xcf -]]> + Produce content for the architecture specified in STRING. This option is generaly used in direct rendition, where design models aren't organized using release versions and architectures as reference. - One entry under trunk/Translations/: + - The translation entry specifies, by means of translation files, the language-specific information we want to produce image for. When we create the translation entry we don't use the name of neither design model nor artistic motif, just the design model component we want to produce images for. - | -trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ -`-- 5 - |-- en - | |-- 01-welcome.sed - | |-- 02-donate.sed - | `-- 03-docs.sed - `-- es - |-- 01-welcome.sed - |-- 02-donate.sed - `-- 03-docs.sed -]]> + Uses post-rendition to convert output produced by base-rendition to any image format specified in STRING. This option is an interface for the convert command of ImageMagick tool set, so it is applicable to images output only. - One entry under trunk/Scripts/Bash/Functions/Render/Config/: + - There is one pre-rendition configuration script for each theme component. So, each time a theme component is rendered, its pre-rendition configuration script is evaluated to teach centos-art.sh how to render the component. - - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - + Uses post-rendition to rotate output produced by base-rendition to any angle specified in STRING. This option is an interface for the convert command of ImageMagick tool set, so it is applicable to images output only. + + + + + + Uses post-rendition to resize the base-rendition output to any angle specified in STRING. This option is an interface for the convert command of ImageMagick tool set, so it is applicable to images output only. + + + + + + Group base output files inside directories. Directories used to stored base output files are named using the file extension of base output files. For example: if the base output file is a .png file, it is moved inside a Png/ directory; if the current file is a .jpg file, it is stored inside a Jpg/ directory, and so on. + Directories used to group files are created in the same location that base output files would normaly do. + + + + + + Specify, in the STRING, the name of the theme model you want to use to produce theme motifs. By default, if this option is not passed, the Default theme model is used as reference to produce theme motifs.
- The production flow of “optimize+flexibility” configuration&dots; - Renderable translation directory structures - Translation directory structures are auxiliar structures of renderable identity directory structures. There is one translation directory structure for each renderable identity directory structure. Inside translation directory structures we organize translation files used by renderable identity directory structures that produce translated images. Renderable identity directory structures that produce untranslated images don't use translation files, but they do use a translation directory structure, an empty translation directory structure, to be precise. - In order to aliviate production of translation file, we made translation directory structures renderable adding a template (Tpl/) directory structure to handle common content inside translation files. This way, we work on translation templates and later use centos-art.sh to produce specific translation files (based on translation templates) for different information (e.g., languages, release numbers, architectures, etc.). - If for some reason, translation files get far from translation templates and translation templates become incovenient to produce such translation files then, care should be taken to avoid replacing the content of translation files with the content of translation templates when centos-art.sh is executed to produce translation files from translation templates. - Inside renderable translation directory structures, centos-art.sh can produce text-based files only. - Copying renderable directory structures - A renderable layout is formed by design models, design images, pre-rendition configuration scripts and translations files. This way, when we say to duplicate rendition stuff we are saying to duplicate these four directory structures (i.e., design models, design images, pre-rendition configuration scripts, and related translations files). - When we duplicate directories, inside `trunk/Identity' directory structure, we need to be aware of renderable layout described above and the source location used to perform the duplication action. The source location is relevant to centos-art.sh script in order to determine the required auxiliar information inside directory structures that need to be copied too (otherwise we may end up with orphan directory structures unable to be rendered, due the absence of required information). - In order for a renderable directory structure to be valid, the new directory structure copied should match the following conditions: - - - To have a unique directory structure under trunk/Identity, organized by any one of the above organizational designs above. - - - To have a unique directory structure under trunk/Translations to store translation files. - - - To have a unique directory structure under trunk/Scripts/Bash/Functions/Render/Config to set pre-rendition configuration script. - - - As convenction, the render_doCopy function uses trunk/Identity directory structure as source location. Once the trunk/Identity directory structure has been specified and verified, the related path information is built from it and copied automatically to the new location specified by FLAG_TO variable. - Design templates + No translation: - Command: - centos-art render –copy=trunk/Identity/Path/To/Dir –to=trunk/Identity/NewPath/To/Dir - Sources: - trunk/Identity/Path/To/Dir - trunk/Translations/Identity/Path/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir - Targets: - trunk/Identity/NewPath/To/Dir - trunk/Translations/Identity/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir - Renderable layout 2: - Command: - centos-art render –copy=trunk/Identity/Themes/Motifs/TreeFlower \ –to=trunk/Identity/Themes/Motifs/NewPath/To/Dir - Sources: - trunk/Identity/Themes/Motifs/TreeFlower - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/TreeFlower - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower - Targets: - trunk/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir - Notice that design models are not included in source or target locations. This is intentional. In “Renderable layout 2”, design models live by their own, they just exist, they are there, available for any artistic motif to use. By default `Themes/Models/Default' design model directory structure is used, but other design models directory structures (under Themes/Models/) can be created and used changing the value of THEMEMODEL variable inside the pre-rendition configuration script of the artistic motif source location you want to produce. - Notice how translations and pre-rendition configuration scripts may both be equal in source and target. This is because such structures are common to all artistic motifs (the default values to use when no specific values are provided). - - The common directory structures are not copied or deleted. We cannot copy a directory structure to itself. - - The common directory structures represent the default value to use when no specific translations and/or pre-rendition configuration script are provided inside source location. - - The specific directory structures, if present, are both copiable and removable. This is, when you perform a copy or delete action from source, that source specific auxiliar directories are transfered in the copy action to a new location (that specified by FLAG_TO variable). - - When translations and/or pre-rendition configuration scripts are found inside the source directory structure, the centos-art.sh script loads common auxiliar directories first and later specific auxiliar directories. This way, identity rendition of source locations can be customized idividually over the base of common default values. - - The specific auxiliar directories are optional. - - The common auxiliar directories should be present always. This is, in order to provide the information required by render functionality (i.e., to make it functional in the more basic level of its existence). - Notice how the duplication process is done from `trunk/Identity' on, not the oposite. If you try to duplicate a translation structure (or similar auxiliar directory structures like pre-rendition configuration scripts), the `trunk/Identity' for that translation is not created. This limitation is impossed by the fact that many `trunk/Identity' directory structures may reuse/share the same translation directory structure. We cannot delete one translation (or similar) directory structures while a related `trunk/Identity/' directory structure is still in need of it. - The `render_doCopy' functionality does duplicate directory structures directly involved in rendition process only. Once such directories have been duplicated, the functionality stops thereat. - Usage + Examples + + + centos-art render trunk/Identity/Images/Brands + centos-art render trunk/Identity/Images/Brands --filter="symbol" + centos-art render trunk/Identity/Themes/Motifs/Flame/2 + +
+ See also • - ... + Directories trunk Scripts Functions + + + Directories trunk Scripts + + + Directories trunk - See also - - -
@@ -3337,12 +3135,12 @@ function render_loadConfig { Goals This section describes the tuneup functionality of centos-art.sh script and general examples about file maintainance inside a working copy of CentOS Artwork Repository. Description - The tuneup functionality of centos-art.sh script provides the standard way of maintaining files inside your working copy of CentOS Artwork Repository. - Tasks related to file maintainance are repetitive. You might find yourself doing them time after time inside the working copy of CentOS Artwork Repository. Some of these maintainance tasks are updating top comments on shell scripts, creating table of contents for web pages, updating metadata related to design models and remove unused definitions on design models. - The maintainance tasks are associated to file extensions. This way, the tuneup functionality know what maintainance tasks should be applied to what files inside the working copy of CentOS Artwork Repository. For example, when you execute the tuneup functionality, it makes a list of files based on supported extensions (e.g., .sh, .svg and .xhtml) and apply maintainance tasks file by file accordingly to its file extension. + The tuneup functionality of centos-art.sh script provides the standard way of maintaining files inside the working copy of CentOS Artwork Repository. + Tasks related to file maintainance are repetitive. You might find yourself doing them time after time inside the working copy of CentOS Artwork Repository. Some of these maintainance tasks do update top comments on shell scripts, create table of contents for web pages, update metadata related to design models and remove unused definitions from design models. + When you execute the tuneup functionality of centos-art.sh script, it looks for all files that match the supported extensions (e.g., .sh, .svg and .xhtml) in the directory specified, builds a list with them and applies the maintainance tasks using file extensions as reference. Maintaining .sh files - If shell scripts are found, the tuneup functionality reads a comment template (trunk/Scripts/Functions/Prepare/Config/shell_topcomment.sed) and applies it to the shell scripts, one by one. As result, all shell scripts will end up having the same copyright and license information the comment template does. - In order for the comment template to be applied correctly, the shell script you write must have the following structure: + If shell scripts are found, the tuneup functionality of centos-art.sh script reads a comment template from trunk/Scripts/Functions/Prepare/Config/shell_topcomment.sed and applies it to shell scripts found, one by one. As result, all shell scripts will end up having the same copyright and license information the comment template does. + In order for the shell script top comment template to be applied correctly, the shell scripts you write must have the following structure: - The comment template replaces all the lines between the Copyright line (e.g., line 5) and the first separator line (e.g., line 9). Everything else in the file will remain immutable. + The tuneup functionality of centos-art.sh script replaces all lines between the Copyright line (e.g., line 5) and the first separator line (e.g., line 9), inclusively. Everything else in the file will remain immutable. Maintaining .svg files If scalable vector graphics are found, the tuneup functionality reads a metadata template (trunk/Scripts/Functions/Tuneup/Config/svg_metadata.sed) and applies it to all files found, one by one. Immediatly after the metadata template has been applied and, before passing to next file, all unused definition are removed from file, too. - The metadata we apply from the metadata template is created dynamicaly using the file found absolute path, the workstation time information and the centos-art.sh script copyright information as reference. Additionally, the Creative Common Distribution-ShareAlike 3.0 License is also set in the metadata. - The elimination of unused definitions inside SVG files takes place through the option of inkscape command-line interface. + The metadata we apply from the metadata template is created dynamicaly combining the file absolute path, the workstation time information and the centos-art.sh script copyright holder information as reference. Additionally, the Creative Common Distribution-ShareAlike 3.0 License is also set in the metadata. + The elimination of unused definitions inside SVG files takes place through the option of inkscape command-line interface which is described in its man page (man inkscape). Maintaining .xhtml files - If web pages are found, the tuneup functionality transforms web page headings to make them accessible through a table of contents. The table of contents is expanded in place, wherever the <div class="toc"></div> piece of code be in the page. + If web pages are found, the tuneup functionality of centos-art.sh script transforms web page headings to make them accessible through a table of contents. The table of contents is expanded in place, wherever the <div class="toc"></div> piece of code be in the page. Once the <div class="toc"></div> piece of code has be expanded, there is no need to put anything else in the page. You can run the tuneup functionality everytime you update the heading information so as to update the table of contents, too. - In order for the tuneup functionality to transform headings, you need to put headings in just one line using one of the following forms: + In order for the tuneup functionality of centos-art.sh script to transform headings, you need to put headings in just one line using one of the following forms: Title

Title

Title

]]> - In the example above, h1 can vary from h1 to h6. Closing tag must be present and also match the openning tag. The value of and options from the anchor element are set dynamically using the md5sum output of combining the page location, the head- string and the heading string. If any of the components used to build the heading reference changes, you need to run the the tuneup functionality in order for the anchor elements to use the correct information. + In the example above, h1 can vary from h1 to h6. Closing tag must be present and also match the openning tag. The value of and options from the anchor element are set dynamically using the md5sum output of combining the page location, the head- string and the heading string. If any of the components used to build the heading reference changes, you need to run the the tuneup functionality of centos-art.sh script in order for the anchor elements to use the correct information. Usage Synopsis centos-art tuneup [OPTIONS] path/to/dir