Re: Binary standards for images and sounds

[Mark Wedel <master@rahul.net>]

 XPM images: Converting the color names to RGB values would be the
only challenging part of the interperter, and even that would not be
difficult.  The only difficult part is having the client know that the 
RGB values for a color are (since, if it is not running X, probably
does not have an rgb.txt database).

 There are at least a couple solutions to this problem:

1) Have the server convert the color names to RGB values (probably not good
for those systems that can do color lookup)

2) HAve the client have a file (or internally) of the colors that the
XPM images use.  Have a mechanism for the client to request RGB information
on a color that it does not know about (so if new colors get added to
the XPM images, the client can get RGB values for them).  The client then
could probably store this information, so it only needs to be requested
once for each color.

 This method also has the advantage the unix clients that have access to
an rgb.txt file, but happen to be missing a color can request the color.

 This could be added to the protocol as something like
COLOR (name)	(client->server request for RGB values for color name)
COLOR (name) (rgb values)	(server->client filling the information)

 This assumes that the server has access to a color file.  I don't think
that this is a very big assumption.  The entire rgb.txt file is around
16K, and in worse case, a person running a server without X installed
could just grab this file off some site.

 I think my real point about XPM images is that they will not really be
any more difficult to convert to client display format than any other
method.  We could use ppm, but then the ppm has to be converted, and
so on.  Also, most 'standard' formats don't have masking, or at least
I don't think they do.

 So, in quick summary, XPM conversion on the client server should be
quite easy to do, as long as the client can get the RGB color values for
some color.

 --Mark