lehors@aenegada.inria.fr (Arnaud Le Hors) (07/16/90)
Last year, we (Koala team at Bull Research, France) designed the XPM
(X PixMap) format for storing/retrieving X pixmaps to/from ascii files,
patterned along the X bitmap format as defined in the Xlib.
Since then, a lot of people used this public-domain format, and we thought
that it needed an upgrade in design. So here is the specs of the second version
of this format, to be discussed on comp.windows.x. We will provide afterwards
a sample public domain library for reading/writing/including this new format.
Please either post or mail to us your feelings about this format.
First, Why another image format?
We felt that most images bundled with X applications will be small "icons",
and that since many applications are color-customizable, existing image formats
such as gif, tiff, iff, etc... were intended for big images with well-defined
colors and so weren't adapted to the task.
So XPM was designed with these criterions in mind:
- be editable by hand (under emacs, vi...). Color pixmap editors aren't
available everywhere
- be includable in code. It is unreasonable to load 1000 pixmap files on each
start of an application.
- be a portable, mailable ascii format
- provide defaults for monochrome/color/grayscale renderings
- provide overriding of colors. This way if the user want your application
to be blueish instead of greenish, you can use the SAME icon files,
We hope that XPM2 will meet these demands better than XPM1. Here it is:
XPM2 the new XPM format for X pixmaps
New features :
1. More concise
2. Different types: natural, C or C++ includable or Lisp includable.
3. A more general color/grayscale/mono specification of colors (as
Colas previously proposed).
Explanations :
1. More concise :
Attributes width, height, ncolors and chars_per_pixel are on a single
line, the first one after the header line (comments excluded). All
the different values are stored in a single array of strings (one per
line) in case of includable type format. No need to specify the
different attributes' names, they can easily be determined by the
location where values are. They will possibly be specified in
comments.
2. Different types :
The aim is to provide includable formats for different languages which
all will be read by the same function. Indeed the different types are
much alike, and it will be very easy to develop a unique read function
dealing with all of them. The format and its type will be read in the
header line which is composed as follows. The first two characters are
just ignored, providing space for any language comment characters.
Then is the string XPM2 followed by a type description keyword (C,
Lisp, and none for the natural type) separated by a space. This will
specify the syntax of the rest of the format. Comments are allowed
and, for the natural type format start at an exclamation mark and end
at the end of the line following the X ressource convention.
Thus for the "Plaid.xpm" file of the current distrib the natural XPM2
will look like :
! XPM2
! plaid pixmap
! width height ncolors chars_per_pixel
22 22 4 2
! colors
c red m white s light_color
Y c yellow m black s lines_in_mix
+ c yellow m white s lines_in_dark
x m black s dark_color
! pixels
x x x x x x x x x x x x + x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x + x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x + x x x x x
Y Y Y Y Y x Y Y Y Y Y + x + x + x + x + x +
x x x x x x x x x x x x + x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x + x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x + x x x x x
x x x x Y x x x
x x x Y x x
x x x x Y x x x
x x x Y x x
x x x x Y x x x
x x x x x x x x x x x x x x x x x x x x x x
x x x x Y x x x
x x x Y x x
x x x x Y x x x
x x x Y x x
x x x x Y x x x
It's called natural because of its simplicity and its readability.
It's designed for manual editing.
The C includable XPM2 will look like :
/*XPM2 C */
/* plaid pixmap */
static char * plaid[] = {
/* width height ncolors chars_per_pixel */
"22 22 4 2",
/* colors */
" c red m white s light_color",
"Y c yellow m black s lines_in_mix",
"+ c yellow m white s lines_in_dark",
"x m black s dark_color",
/* pixels */
"x x x x x x x x x x x x + x x x x x",
" x x x x x x x x x x x x x x x x",
....
" x x x Y x x ",
" x x x x Y x x x"
} ;
For C++ this format still works fine. The double slash comment line
will eventually be supported but this is not absolutly needed. In
fact, if we limit the C comments to single line, both C and C++
comments can be detected by the first slash. Anyway several solutions
can be considered about this.
Finally the Lisp includable XPM2 will look like :
; XPM2 Lisp
; plaid pixmap
(setq plaid '(
; width height ncolors chars_per_pixel
"22 22 4 2"
; colors
" c red m white s light_color"
"Y c yellow m black s lines_in_mix"
"+ c yellow m white s lines_in_dark"
"x m black s dark_color"
; pixels
"x x x x x x x x x x x x + x x x x x"
" x x x x x x x x x x x x x x x x"
....
" x x x Y x x "
" x x x x Y x x x"
))
As you can see the formats are very similar and it will be very easy
to make traductor from one type to another one, if needed.
3. A more general specification of colors :
Each entry in the "color table" will be of the form:
chars [key color] ...
where chars is the chars_per_pixel length string (surrounded by
*nothing*) representing the pixels, color is the specified color, and
key is a keyword describing in which context this color should be
used. These keys will have the following values :
c color visual
m mono visual
s symbolic name
and possibly (not stated yet) :
4 4-level grayscale
g grayscale with more than 4 levels
(or we can have g4, g16, g256...)
Colors can be specified by giving colorname, the RGB code following
the # character, or the HSV code following the % character.
The "symbolic" name provides the ability of specifying the colors at
load time, and not to hard-code to them in the file.
XReadPixmapFile will have one more arg: a table of pairs symbolic
name, actual pixel which will override the eventual default for the
given point in the xpm file.
Symbolic names and comments must be stored while reading to be able to
edit an xpm in some visual without destroying the colors for another
one, and will be handled back to XWritePixmapFile.
Arnaud LE HORS
BULL Research FRANCE -- Koala Project | Email : lehors@mirsa.inria.fr
Inria - Sophia Antipolis | Phone : (33) 93 65 77 71
2004, Route des Lucioles | Telex : 97 00 50 F
06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66
Colas Nahaboo, BULL Research FRANCE -- Koala Project -- GWM X11 Window Manager
colas@mirsa.inria.fr Phone: (33) 93.65.77.70, Fax: (33) 93 65 77 66