lehors@avahi.inria.fr (Arnaud Le Hors) (01/24/91)
The Icon Format BOF at the 5th Annual X Technical Conference.
This report gives a summary of the different issues which have been discussed
at the BOF. There were about 20 persons (We forgot to make a list of
attendees names, sorry).
It appears that at the present time some people use private formats but are
looking for some standard and some people use XPM version 1 or 2. None uses
any image format like tiff or giff which do not adress the problem.
XPM thus seems to be THE pixmap format for X developers.
Everyone agrees to say that an icon format is different from an image format.
Indeed icons which usually are symbols have some kind of semantic which does
not exist with images. On an icon one can define some symbolic colors which
may be modified when modifying a color on an image will not actually make
any sense.
A short description of XPM2 has been given, for more details see the
documention include in the distribution available on ftp expo.lcs.mit.edu and
avahi.inria.fr. The XPM format version 2 has the major advantage to provide
symbolic color names which appear to be really useful for everyone. The new
library includes a much more flexible parser than the first version and
pixmaps are created much more efficiently.
Among the people using XPM, they all use the C includable syntax. If some
people don't mind having the different syntaxes (Natural, C, Lisp) even if
they don't use them, some find that it is a burden when developping parsers
and managing archives with different files which may be of different types.
Face to this, it has been proposed to limit the XPM format to its C syntax
after having checked that really none (or only few) use the other syntaxes.
In addition to the features provided by the current XPM2 library (version 2.8)
it would be interesting to be able to define non-rectangular icons. To provide
such icons we could define some kind of transparent color name such as 'None'
which would actually result in defining a stipple (mask). This stipple would be
returned from the creation functions in addition to the created pixmap. Thus
the application using the X11R4 shape extension could perform non-rectangular
icons.
People have requested an XPM mailing list which will be created soon and
annouced on comp.windows.x. Also it will be defined an archive site to share
XPM files. In order to avoid symbolic names conflicts, some standard symbols
such as "background" and "border" should be defined.
A "background" symbol would provide a standard way to override the pixmap
background to whatever color being at the location where the pixmap must go.
People would like to see XPM in Xlib. Too late for R5, we will try for R6.
Several applications already use XPM 1 or 2, with at least three pixmap
editors,
gwm the generic window manager, OSF internal version of mwm, and some desktops.
People don't think that an icon format has to include a compression mechanism.
Icons are usually small (eg. 64x64) and thus there is no need for compression.
The mechanism which is implemented in the current XPM library and which uses
the standard compress program is enough when needed. On the other hand this
implementation doesn't work on VMS platforms and thus it should be optional.
It has been proposed to adress the issue of storing several pixmaps in a
single file by using some external standard utility like ar, in the way that
compress is used. But nothing is definitive yet, this will be discussed later
on. Moreover, since people use XPM to store frames of animations, including
more than one pixmap in a single file should be a sensible feature.
In order to be complete the XPM package should include a String to Pixmap
converter. Several issues have been approached about this. First, what should
be the name? Indeed, it would be nice to keep a way to define other string to
pixmap converters which could appear in the future and which could coexist.
Then, what should be the syntax of the resources? Basically two problems must
be adressed: a way to specify an XPM filename and a way to specify overriding
colors. This will be discussed on the coming mailing list. There is presently
a student from the university of Florida who is working on an implementation.
--
Arnaud LE HORS XPM2 Designer
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