Blob Blame History Raw
------------------------------------------------------------
* 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.