diff --git a/Identity/TODO b/Identity/TODO deleted file mode 100644 index d43b904..0000000 --- a/Identity/TODO +++ /dev/null @@ -1,229 +0,0 @@ ------------------------------------------------------------- -* 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. -