Re: son of X-Face:

Rich Burridge (Rich.Burridge@eng.sun.com)
Mon, 16 Aug 1993 22:45:37 -0700

> | I think restricting the image size so arbitrarily is a bad idea; 48x48 is
> | really tiny! All of my other icons are 64x64, and they just don't look all
> | that large. The same people who want color today will want bigger tomorrow.

Let's talk interested parties here. I know that Dan Heller has approached
James for color X-Face:'s for inclusion in the Z-Mail mailtool product. This
runs on Unix, DOS and the Mac. Somebody from Microsoft approached me to
include X-Face: in their mailtool; I suspect they've approached James too by
now. There could be others...

We're talking influential software here; it's no longer a case of just putting
up a list of icons in a row as mail comes in. It's inclusion of a visual
representation of the sender in a special window when viewing a mail message.
I predict that 128x128x8 color images will be required soon. Whatever we
choose now should allow for this possible expansion. There are all those
Usenix FaceSaver images out there. I know they were 128x128 grayscale images
a couple of years ago. Are they saving them as color images yet?

My own feeling is that the size of the image shouldn't be fixed; it should
be included in the data. The XPM standard is nice for this. I easily added
XPM "view by content" support to Sun's file mangler. There are standard
libraries routines that can be used. You can have as many (or as few) colors
as you want. You can edit the files with a text editor.

Another approach is to use a standard palette of colors. The Sun DeskSet tools
use a palette of 72 "standard" colors. This works well, and leaves slots free
for other tools to use.

If XPM is used, then I suggest the mono X-Face: should be converted to use
either XBM or the "mono" part of XPM. Preferably the latter. XPM allows you
to define not only a color representation, but a mono equivalent in the same
file. This might be useful if transmission has to be over low bandwidth lines.

I definitely believe that an RFC should be written.