Re: strange colormap behaviour with postscript printing

[Petr M. <mi...@ph...>]

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


---
PM