------------------------------------------------------------ * Rename trunk/Identity/Models/ to trunk/Identity/Manuals/ * Reduce attention on the idea of creating a big book holding all about CentOS corporate visual identity. The trunk/Identity/Manuals/ structure starts replacing the trunk/Manuals/ structure. All ideas inside trunk/Manuals need to be moved to trunk/Identity/Manuals common visual style. * As both manuals and design models get growing, I've found that using a set of scalable vector graphic as design templates/models --to define how illustrations look like--, and a set of translation files --to define the illustrations language-- to describe small ideas is more flexible (since an innovative graphic design point of view) than creating a big book describing all the same small ideas by means of texts and illustrations using LaTeX format. Using scalable vector graphics design templates/models and translation files to produce multi-language illustrations is straightforward. Note: translation files are applied to design templates using rendering scripts. * Inside trunk/Identity/Manuals/, the format used to create each specific flayer is A4-Landscape (297x210mm). ------------------------------------------------------------ * Inside Themes structure similar design templates are repeated constantly. In order to optimeze Themes' structure, split Themes' structure in the following two structures: 1. trunk/Identity/Themes/Models: This structure contains design templates (SVG) only. Models structure is organized by Names (e.g., Default, Alternative, etc.). Convenctional models define art work sizes, formats and position of elements in the screen. For example, inside models structure is where you set that Anaconda Header art work is 800x88 pixels, the anaconda splash is about 510x300 pixels, the GDM non-graphical definitions (i.e., .xml, and .desktop files.), and so on. 2. trunk/Identity/Themes/Motifs: This structure contains artistic motifs images (e.g.: .xcf, .png, .jpg, .xpm, .ppm, etc.) and rendering scripts only[1]. [1]: Rendering script files are currently inside each renderable art work structure. In the near future, rendering script files will be replaced by a command line utility. As previously set, Motifs strcutre is organized by Names (e.g., Modern, TreeFlower, etc.). Each name represents one artistic motif. Convenctional artistic motifs define visual style for CentOS distribution (Distro), promotion (Promo), and web sites (Web). Conventional artisitc motifs structure, also, covers specific artistic motif's design, copyright note, license (CC-SA), author(s), color, and palettes[2]. [2]: Palette files are required to produce color-limited images, automatically. Two examples of color-limited images are anaconda prompt (indexed to 16 colors), and GRUB splash (indexed to 14 colors). A relevant directory inside each artistic motif structure is that used for Backgrounds (Distro/Backgrounds/). The background directory stores images for many different sizes and screen resolutions. Images inside background directory are passed through Models design templates to produce the theme's final images. ------------------------------------------------------------ * /branches/Identity/Themes/$THEME/$BRANCH_ID/ This structure is used to store alternative theme designs that share one common design concept. The common design concept is defined at /trunk/Identity/Themes/$THEME/. - `$THEME': is a case-sensitive name that match one name under /trunk/Identity/Themes/ (e.g., Modern, TreeFlower, etc.). - `$BRANCH_ID': represents a unique serial number used to identify the branch (e.g., 1.0, 2.0, 3.0, etc.). For example, if you have a different design proposition (e.g., 1.0, 2.0, and 3.0) based on TreeFlower's concept, then the directory structure will look similar to the following: /branches/Identity/Themes/TreeFlower/1.0/ /branches/Identity/Themes/TreeFlower/2.0/ /branches/Identity/Themes/TreeFlower/3.0/ You can repeat the previous naming process in cascade as long as different graphic designs arise. For example, if you find that a completly different design can be derived from 1.0 then you can create one branch, named 1.1 to store the idea: /branches/Identity/Themes/TreeFlower/1.1/ The /branches/Identity/Themes/$THEME/$BRANCH_ID/ directory structure is the same structure used under trunk. So, all rendering and automation scripts available inside trunk structure are available in here too. The directory structure described in this section is for completly different designs, compared with its trunk version. If you only want to experiment new ideas around the same turnk design then do not use this structure. Instead, go to the Motif's directory in the trunk's structure and create a new motif file to work your idea. For example: /trunk/Identity/Themes/TreeFlower/Motif/motif.svg /trunk/Identity/Themes/TreeFlower/Motif/motif-1.svg /trunk/Identity/Themes/TreeFlower/Motif/motif-2.svg /trunk/Identity/Themes/TreeFlower/Motif/motif-n.svg In the above path, the motif.svg file is the theme's default design used on distribution, websites, and promotion art works. The other files (i.e., motif-1.svg, motif-2.svg, motif-n.svg) are alternative ideas of the same design. ------------------------------------------------------------ * Create/Design a command line utility to achive the same task of invocation rendering script (render.sh) files. - When invoking the command line utility, users can provide a path, absolute or relative, to an specific framework. After verifying the provided framework as valid path, image rendering starts for that specific framework. If no path is provided to the command line utility, print the usage message and quit. Brain Storm 1: ------------- If such a command line is created name flexibility inside the repository may be limited. Presently, there is one render.sh script inside each renderable art work component which points to an entry in the scripts configuration structure. If renderable art work components change their path, the rendering action is not affected because both configuration scripts and translation structures remains immutable out of renderable strucutres. Thinking how to design an efficient command line interface that help us automate most tasks inside CentOS Artwork Repository, I propose to realy on a strong name convenction to bond renderable structures, scripts, and translations files altogether. Presently, invokation rendering scripts call one configuration file. The configuration file defines which task(s) to do and what function(s) to call for that art work, that one the rendering script was invoked from. For brevity, a function initialization script is called to make all functions available inside the configuration script and functions loaded inside it. If the invokation script is removed, we have to find some way to make that bond between renderable art work component and configuration script. The first idea coming to my mind is using some kind of name convenction on paths so we could relay on it. For exmample, if you are inside the following directory, or provide it to the command line utility: Themes/Motifs/Modern/Info The command line utility should verify if that directory exists firstly, and later if it has a configuration script associated. To determine which configuration script is associated with this path we need to build a common path that can be compared no matter where the command line utility was invoked from. For example, taken the above path as reference, we could build such a common path using its absolute path: /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Info And later, manipulate the string to build its assiciated configuration script. The manipulation, relays on the following name convenction: - Insert the Scripts/Bash/Config/ string before Identity/ - Remove the theme' name (e.g., Modern/) from the string. Note: Pay attention to trailing slashes. They are part of string manipulation. This convenction produces the following path: /home/centos/artwork/trunk/Scripts/Bash/Config/Identity/Themes/Motifs/Info If the above configuration directory exists, and it has the render.conf.sh script inside, then it can be assumed as a valid configuration entry in the configuration structure. Otherwise there is no configuartion file for the specified framework, and by extension no actions related to it. Note: Actions are based one functions loaded in the render.conf.sh script. If the script render.conf.sh is empty, or malformed you will have a result of the same nature. This schema relays completly on names convenctions. So in order to the command line utility to work, the repository should have a strong name convenction and changes to it need to be carefuly planned before commit them. - The command line utility should provide the following: - List of valid frameworks: This feature lets users to know available frameworks where the command line utility can be used for image rendering inside CentOS Artwork Repository. - Usage message: This functionality lets the user to know how to use the command line utility. It resumes available options and features. - Online framework documentation: This feature lets users request information about specific art works and available actions inside CentOS Artwork Repository, anywhere, anytime. - ... * Remove invocation rendering script (render.sh) files.