[5634] in Athena Bugs
rt 7.0F: xwud - "a little learning is a dangerous thing"
daemon@ATHENA.MIT.EDU (sethf@ATHENA.MIT.EDU)
Tue Jul 31 07:01:09 1990
From: sethf@ATHENA.MIT.EDU
To: bugs@ATHENA.MIT.EDU
Date: Tue, 31 Jul 90 07:00:56 EDT
System name: frumious-bandersnatch
Type and version: RTPC-ROMPC 7.0F
Display type: apa16
[Everything that follows refers to monochrome images and monochrome
displays - color images are another problem]
What were you trying to do?
Display a certain image. It came out solid black.
What's wrong:
In the ancient bygone days before R4, xwud paid essentially no
regard to the color map in a window dump. This was a bad thing, and has
been dealt with in the modern era. However, there is such a thing as
paying TOO much attention, to the detriment of overall sanity.
To determine which pixels to assign to colors, the xwud code has
if (out_image->depth == 1) {
if (fgname &&
...
else if (ncolors && XAllocColor(dpy, colormap, &colors[1]))
gc_val.foreground = colors[1].pixel;
else
gc_val.foreground = BlackPixel (dpy, screen);
with similar for background.
Since the internal color map wasn't significant for a long time,
many images exist with colormaps that were never tested. Undumping those
images may not work with this version of xwud, as for various reasons
both entries could receive the same color from XAllocColor. In general,
the fitting lacks a necessary sanity check.
What should have happened:
Xwud should check to make sure that the two color used aren't
identical. If they are, the picture will just be a blank. While correct
from a certain literal standpoint, that's hardly the 'best display' from
another perspective.
In this case, it should arbitrarily set one color to the opposite of
the other, and make the reverse choice if -rv is given.
Please describe any relevant documentation references:
xwud(1)
