| ------------------------------------------------------------ |
| * 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. |
| |