Re: strange colormap behaviour with postscript printing

>> | octave> imagesc(peaks());colormap(gray())
>> | octave> print("gray.png")          # png image is good
>> | octave> colormap(flipud(gray))
>> | octave> print("udgray.png")        # png image is good
>> | octave> colormap(gray)
>> | octave> print("gray.ps")           # ps image is good
>> | octave> print("udgray.ps"))        # ps image is same as above!
>> |
>> | Apparently, when printing to postscript, flipping the colormap  
>> has no effect!
>>
>> Is this a bug in gnuplot, or are we somehow using it incorrectly?
>
> Try
> colormap(rainbow)
> instead of
> colormap(flipud(gray))
> and you will see exactly the same result.
> Try
> print('xxxx.ps', '-dpsc')
> and you will see image with your desired color mapping.
>
>
> The reason is that you are using a custom color map (COLOR map)  
> which you
> try to print to a monochrome postscript printer. Therefore gnuplot  
> ignores
> your specific color map and uses the default gray mapping instead
> ('set palette gray positive|negative gamma _gamma_').
>
> You should print to color postscript to use a custom (Octave's)  
> colormap.
>
> In gnuplot, there is indeed an inconsistency of plots
> test
> splot x*y with pm3d
> run under these situations:
> gnuplot # X11 color display
> gnuplot -gray # X11 gray display
> gnuplot -mono # X11 monochromatic display
> and the same with postscript output
> set term postscript color
> set term postscript mono
> Note that
> set term png
> gives always a color output so that you cannot see any difference.
>
> If gnuplot sends a custom color map to a monochrome postscript  
> device, then
> this would be considered as bug as well.
>
> Any idea how to solve this ambiguity on gnuplot side?
> I don't think this is very needed.
>
>
> Octave could write an error message under this situation:
>
> if any(any(colormap()-gray(rows(colormap())))) && is_mono_output
>    fprintf('WARNING: using default gray mapping for printing on  
> monochrome printer\n');
> end