strange colormap behaviour with postscript printing

[Ben Abbott]

On Jan 17, 2009, at 3:04 PM, Petr Mikulik wrote:

>> | 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

As there is no routinesfor for the gnuplot backend that is  
simultaneously aware of the terminal type and whether or  not any of  
the figure's graphics objects are using a custom color map, I don't  
see any easy way to do that.

It may be necessary to make some compromise. We might (1) issue a  
warning even when the custom color map is not being used by any  
graphics objections, (2) force the use of -dpsc when a custom color  
map is set, or (3) leave the backend as it is.

Of those (1) looks more attractive to me.

Another possibility that occurs to me is to convert the custom color  
map to a monochrome version and have gnuplot respect that?

Petr, is that a possibility?

Ben