colas@avahi.inria.fr (Colas Nahaboo) (03/01/91)
Just a word to describe XPM:
XPM is an image format specifically designed for icon in X applications, not
a general icon format. The XPM (informal) project is to provide:
- ascii humanly understandable, mailable and emacs-editable format
(NO compression in the format. compression best handled externally by
"compress" or other external programs at the library level)
- includable in C/C++ code as well as read/write from/to files
- with defaults for color, greyscale, and mono visual renderings
- with symbolic color names for overriding colors. An application can thus
have the same file for displaying icons with blueish or greenish shades,
if the user customized it to be blue or green.
- with "transparent" colors for non-rectangular icons
- with multiple icons with symbolic names in the file for icon animation,
or multiple icon states (or resolutions, etc...)
- last, but not least, with a robust, efficient, and free C library to
read/write/include XPM files in user code, which we will contribute to the
X community, and hope to the X consortium for R6 inclusion (in Xmu ?)
- string-to-pixmap converter for Xt
- converters to/from pbmplus
- set of conventions, independent of the format itself, on color names, etc...
History:
First version (XPM1) co-designed by Daniel Dardailler at Bull (now at OSF)
and me. Version included in Daniel's XFedor color font/pixmap editor and
the Gwm window manager and went out in 1988.
This format was simple (ascii & includable), but spread rapidly, and got
used in many applications (Builder Xcessory by ICS), despite its limits
and the slowness of the implementation.
Second version (XPM2) was designed mid-90 by Arnaud Lehors, also from the Koala
Project at Bull research, and incorporated language-independance (C, Lisp,
or any-language includable), symbolic colors, defaults for visual types,
and an efficient implementation. Arnaud held a BOF at the last Xconf, and
was obvious there that we needed to come with a standard to propose to the
X consortium.
Now we are federating an effort to come to a final XPM format, and a set of
conventions for use (the "ICCCM" of icon design), such as meaning of symbolic
color names such as background, border, none, etc... and a good sample
implementation of the library. From XPM2, we have dropped multi-language
support (people now develop only in C or C++, or link to underlying C
librairies), and added multi-pixmap files for icon animation support.
We have set a mailing list for this on xpm-talk@mirsa.inria.fr (requests on
xpm-talk-request@mirsa.inria.fr) for discussing it. We urge everybody who has
any ideas on icon usage to join this list.
I include in this mail the last proposal on the format from
Arnaud <lehors@sa.inria.fr>:
We have worked (colas and I) on designing the new XPM format and have got to
the following. It comes from the XPM2 format limited to the C syntax and
extended to support multiple pixmaps file.
Here it goes:
----
The XPM format is a C syntax array of strings composed of different which can
define several pixmap as described below:
<Header line>
<Dictionary>
<Declaration and Beginning of Assignment>
<Pixmap>
[<Pixmap> ...]
<End of array>
<End of Assignment>
The Header line is:
/* XPM */
The Dictionary which is optional will be used to speed up access to a
particular pixmaps. It is composed as follows:
/* XPMDICT,
<name> <offset>
<name> <offset>
...
*/
The Declaration and Beginning of Assignment is:
static char * <name>[] = {
The Pixmap section includes different subsections which are:
<PixmapName>
<Hints>
<Colors>
<Pixels>
The PixmapName subsection is just a string containing the pixmap name:
"<PixmapName>",
The Hints are:
"<width> <height> <ncolors> <chars_per_pixels>",
The Colors subsection is composed of <ncolors> strings composed as follows:
"<chars> <key> <colorname> [ <key> <colorname> ...]",
Where keys may have the following values:
m for mono visual
s for symbolic name
g4 for 4-level grayscale
g for grayscale with more than 4 levels
c for color visual
The Pixels subsection is composed by <height> strings of
<width>*<chars_per_pixel> characters, where every <chars_per_pixel> length
string must be one of the previously defined in the Colors section.
Then comes the End of array which is 0.
And The End of Assignment which is:
};
This gives in an other way the following format:
/* XPM */
[/* XPMDICT
<name> <offset>
[<name> <offset>...]
*/]
static char * <name>[] = {
"<pixmapname>",
"<width> <height> <ncolors> <chars_per_pixels>",
"<chars> <key> <colorname> [ <key> <colorname> ...]",
....
"<chars><chars>....",
....
[
0
} ;
-----
At first glance we thought we could support multiple pixmaps in a single file
by just having different arrays in one file but this would lead to have two
different behaviors weither the file is included or not. Here with the present
format we would have the same capabilities in both cases which we think is an
important point.
The dictionary is commented out and then would not be used when included but it
doesn't matter because seeking a given pixmapname in memory should be fast
enough. The dictionary is optionnal and should be built by some external tool.
Converting XPM2 C file to this format would be really easy since you just
have to replace XPM2 by XPM and add the pixmap name line.
In addition to the format definition we would like to define an XPM Convention
which will list things which are not really part of the format but that people
would like to see supported by XPM library and application using it. This would
include things like the list of the default color keys (c, m, g4, ...), the
standard symbols (background, foreground, border, ...), the "transparent"
colorname (None), etc...
Besides, we still have to define the library functions. We are not going to
provide any backward compatibility because we need many modifications to handle
multiple pixmaps file would and we think it's still time to change the whole
stuff (not so much code depend on it). We rather like to define something
clean and helpful which will be as acceptable as possible by the mit.
What I can say yet is that it will provide two different level of functions.
Indeed we want to provide ordinary applications with functionalities similar
to what the current library does. This should include a function to get one
pixmap from a file or data, a function to get a list of pixmaps from a file or
data (with the possibility to get them all), and a function to write pixmaps
out to a file.
But we also want to provide applications such as pixmap editors with functions
reading and writing XPM file without creating any pixmap. In order to achieve
this goal we will define an XpmData structure in which all the informations
about the pixmap will be stored and that the application will be allowed to
manipulate.
Give me some time to think a little more about this and I'll let you know what
can be done.
Of course any comment about all of this will be wellcome and even expected.
Arnaud.
--
Colas Nahaboo, colas@sa.inria.fr, Bull Research, Koala Project, GWM X11 WM
Phone:(33) 93.65.77.70(.66 Fax), INRIA, B.P.109 - 06561 Valbonne Cedex, FRANCE.