Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!inria!mirsa!aenegada.inria.fr!lehors From: lehors@aenegada.inria.fr (Arnaud Le Hors) Newsgroups: comp.windows.x Subject: XPM2 pixmap format proposal Keywords: XPM XPM2 pixmap format Message-ID: <8428@mirsa.inria.fr> Date: 16 Jul 90 13:47:22 GMT Sender: news@mirsa.inria.fr Reply-To: lehors@aenegada.inria.fr (Arnaud Le Hors) Organization: Koala Project, Bull Research France Lines: 195 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