On Thursday, July 9, 2009 at 23:35:51 (-0700) Alan W. Irwin writes:
> For your information there is a peculiar but designed interaction between
> the background colour and _default_ cmap1.
> If you run example 16 with the background set to a light-coloured value, e.g.,
> c/x16c -dev psc -o test.ps -bg fffff
> c/x16c -dev psc -o test.ps -cmap0 cmap1_black_on_white.pal
> you get very different default cmap1 values than if you run with a black
> background colour. The result is independent of device driver. I originally
> thought this was some horrible bug, but it turns out the vertex logic used
> to set the _default_ cmap1 depends on the mean background colour by design.
> I wasted a lot of time on this today (including a binary search to
> "discover" that the effect was not there for -bg 7f7f7f but was there for
> -bg 808080) so I thought I should mention it here so that others don't waste
> their time trying to track down this "bug".
Sorry this was never documented except in code. The idea here is that when
switching from a black background (such as I typically use for interactive
plotting) to a white background good for paper, cmap1's that are meant to fade
to background at some point must necessarily change.