Re: er...xbmtoxpm???

[(Raphael Quinet)]

> From  Wed Feb 23 09:27:27 1994
> 
> In terms of black and white, whether a color should be marked as black
> or white can depend on the item.  In some cases, certain colors might
> be meant as foreground (and thus black), and in other cases, that same
> color might be part of the background (and thus white.)
> 
>  For greycale machines, I would first be interested in seeing how
> the XPM library handled colors that are loaded (does it turn them into
> an approximate grey?)  But in any case, what shade of grey it should be
> should probably be determined on whether the object is in the foreground
> or background.
> 
You have two alternatives if you want to display a color on a greyscale or
black and white monitor:
- Use the color as is, and let the X server do the necessary conversion.  This
  is the easiest way, but you may not be able to distinguish colors that are
  close in brightness, like dark green and dark blue, or light yellow and
  white.
- Use the nice features in the XPM library and provide different conversions
  for the same color.  For each "color", you may give a color name for color
  displays, but also a (possibly different) color name for grayscale displays
  and a (possibly different) color name for black and white displays.  Using
  this feature, you may for example convert the dark green pixels in a
  picture to white (on black and white displays), and convert the dark blue
  pixels to black.  You will then be able to see the differences between the
  two colors.  This will require a clever design for each face, but will lead
  to better results.

[about the symbolic names for foreground and background]
> 
>  I suppose (what maybe Raphael was talking about) is have the same face
> for numerous archetypes, but just keep one copy on disk.  As you laod them,
> then color them for the different archetypes.
> 
That's more or less what I meant.

>  This saves a little disk space, but makes the program more complicated.
> And since the crossfire.pix file can be gzip'd, the size savings is
> very small.
> 
Ok.  Let's keep the program simple (Simple?  Only joking...).

-Raphael