Sun 18 Jan 2015 06:39:44 PM UTC, comment #15:
I downloaded the source for gnuplot 4.6.6 and installed and now the lines are correctly black. So this is not an Octave problem, but a gnuplot one.
I applied the one-line patch to get black and white eps output here (http://hg.savannah.gnu.org/hgweb/octave/rev/40b0f41a7100).
Closing report.
|
Sun 18 Jan 2015 06:57:00 AM UTC, comment #14:
I have changed the binary data in a2.gp to readable data,
and run gnuplot, but I got the same black & white image.
One of the differences is gnuplot version:
You are using 4.6.2 and I am using 4.6.4
In the relase notes of 4.6.3, one of the fixes is:
- FIX suppression of color in linetypes after "set term ... mono"
so maybe that's the reason for the difference.
|
Sat 17 Jan 2015 10:33:25 PM UTC, comment #13:
Thanks, I will check why the red lines are shown.
|
Sat 17 Jan 2015 10:14:24 PM UTC, comment #12:
I commented out the code which does "set palette" in _go_draw_axes_.m and added a line to print out the value of the mono variable.
Attached are the actual postscript and .gp files.
(file #32859)
|
Sat 17 Jan 2015 09:58:58 PM UTC, comment #11:
answer to comment 9:
I am using MXE-octave (one of the last versions), with
make update-checksum-default-octave which uses
http://hydra.nixos.org/build/18517875/download/1/octave-4.1.0+.tar.gz.
gnuplot version is the version that comes with the mxe-version
( Version 4.6 patchlevel 4). I do not define the terminal, it defined by octave.
Can you attach the file without 'set pallete' but with red lines?
|
Fri 16 Jan 2015 04:53:02 PM UTC, comment #10:
As I said back in comment #2, your patch gets things a lot closer. I'm happy to apply it as a partial fix and then report another bug about the red lines being output.
|
Thu 15 Jan 2015 10:38:29 PM UTC, comment #9:
Well, just to be certain. What mercurial ID are you at when you are running your test code? And no patches are applied to the code tree when you are running? Also, what is your version of gnuplot and what terminal are you using?
If I comment out the lines you suggested then I do not end up with 'set palette' in the resulting a2.gp file, but the lines are still red. If your lines are black, this suggests that gnuplot may be in error.
|
Thu 15 Jan 2015 09:59:08 PM UTC, comment #8:
I have the same values of mono (1 & 1), but the result is black & white postscript, and not black white & red.
My a2.gp file is different, it does not contain the "set palette" lines.
Any hints how to solve this?
|
Thu 15 Jan 2015 06:28:25 AM UTC, comment #7:
Results:
It seems that _go_draw_axes_ is called twice, perhaps once to draw the plot for printing and then a second time to restore the image.
|
Wed 14 Jan 2015 05:35:44 PM UTC, comment #6:
sorry.
I meant to comment out the lines
and print the value of mono before these lines.
thanks
|
Wed 14 Jan 2015 05:29:33 PM UTC, comment #5:
From some reason, the file a2.gp contains the lines
that causes the problem. It seems that the mono variable
was false inside go_draw_axes.m instead of being true.
Could you please comment out (only for the check) the lines
|
Wed 14 Jan 2015 04:55:31 PM UTC, comment #4:
I uploaded the four files in a gzipped tar archive.
The plots were made on a Linux machine using Mercurial rev: 19577:f64cdbe11621. gnuplot is version 4.6.2, the plotting terminal (GNUTERM) was "wxt". Octave was run with 'run-octave -f --no-gui-libs' (no configuration files, CLI interface).
The second plot, a2.ps, has the grid lines in red.
(file #32825)
|
Wed 14 Jan 2015 06:32:53 AM UTC, comment #3:
This is very odd indeed.
could you please run the following commands:
and attach the .ps and .gp outputs?
Thanks
|
Wed 14 Jan 2015 05:19:31 AM UTC, comment #2:
You're patch definitely gets a lot closer. The grid lines are still red, which is odd. I've attached the results I get with your patch in the file surf_with_cset.ps.
I also produced the output from FLTK in the file surf_fltk.ps. There is a small difference in that FLTK really does convert the image itself to black and white which means large positive and large negative values are both dark since one is dark red and the other is dark blue. In contrast, gnuplot uses an intensity scale that varies from dark for large negative numbers to light for large positive numbers.
(file #32823)
|
Tue 13 Jan 2015 07:01:06 PM UTC, comment #1:
I think the the source of the problem is from the line
"set palette positive color model RGB maxcolor..."
(line 1636 in _go_draw_axes_.m).
A fix for that can be
in line 1634.
Please check the attached cs.
(file #32818)
|
Sun 11 Jan 2015 03:01:35 AM UTC, original submission:
The -deps switch should produce a black and white image. The -depsc switch should produce a color image.
When using gnuplot (4.6.2) with x11 and WXT terminals the output is in color, and lines which should be black are instead red. The output is correctly colored when using -depsc.
Sample code:
Attached is a plot made with the x11 terminal.
|