bugGNU Octave - Bugs: bug #42838, gnuplot 5.0 print gives black plots

 
 

bug #42838: gnuplot 5.0 print gives black plots

Submitter:  None
Submitted:  Thu 24 Jul 2014 07:40:41 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  4 Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 15 Feb 2016 07:59:43 PM UTC, comment #58: 
Mike Miller <mtmiller>
Group Member
Sat 13 Feb 2016 12:46:08 AM UTC, comment #57: 

I have no objection. My package manager provides gnuplot 5, so I'd actually prefer  that it be supported by Octave 4.0.x

Ben Abbott <bpabbott>
Group Member
Fri 12 Feb 2016 10:51:15 PM UTC, comment #56: 

This patch looks relatively easy to cherry-pick onto the stable branch. Since gnuplot 5 is quickly getting out there, should we move this to stable for 4.0.1?

Mike Miller <mtmiller>
Group Member
Sun 13 Dec 2015 08:12:31 PM UTC, comment #55: 

I can confirm this bug is now fixed. Going back to a previous development version of Octave shows the black background in a printed pdf of a plot, and from the default branch it prints correctly.

Mike Miller <mtmiller>
Group Member
Sun 13 Dec 2015 01:19:02 PM UTC, comment #54: 

@Rik,

I overcame my apprehension and pushed a changeset.

http://hg.savannah.gnu.org/hgweb/octave/rev/c7d881aec36c

If it works, then this can be closed.

Ben Abbott <bpabbott>
Group Member
Fri 27 Nov 2015 05:12:24 AM UTC, comment #53: 

@Ben: Sounds like maybe a bit paranoid.  Stuff does break on the development branch, but that is precisely where it doesn't hurt anyone.  Besides, I always find that it is easier to start with code under version control and tweak it rather than to start from scratch.  If your patch is committed and gnuplot 5.0.1 introduces a few more odditities then at least we will know how to begin getting it to work.

Rik <rik5>
Group administrator
Fri 27 Nov 2015 01:49:24 AM UTC, comment #52: 

@Rik,

The patch could be applied, and then followed up with a another patch when 5.0.1 is out (although a second patch may not be needed).

I'd like to take care of that but work life and the three kids at home makes it difficult for me to do much. So if I push a change, and something breaks, I may have trouble getting around to fixing it.

Maybe I'm just being paranoid. Thoughts?

Ben Abbott <bpabbott>
Group Member
Wed 25 Nov 2015 04:14:54 AM UTC, comment #51: 

@Ben: Do you want to apply your patch from comment #37?  Or are you waiting for gnuplot 5.0.1 to arrive in case the behavior has changed?

Rik <rik5>
Group administrator
Tue 21 Jul 2015 09:55:53 AM UTC, comment #50: 

https://savannah.gnu.org/bugs/?42838#comment25


Please take the last Ethan's reply in
http://sourceforge.net/p/gnuplot/bugs/1561/


I don't know what was happening in the Octave->gnuplot original example, but I think the introduction of "set mono" has probably changed things. Please file a new bug report if there are still problems.


set monochorme (set mono) option is a new command in gnuplot 5.0.1.

Tatsuro MATSUOKA <tmacchant>
Wed 24 Jun 2015 01:16:39 PM UTC, comment #49: 

Ben,
Tatsuro reports:

In general, gnuplot 5.0.0 is buggy.
I recommend to make change of octave code not for 5.0.0 but for 5.0.1.

Release Notes for 5.0.1 is here:
http://www.gnuplot.info/ReleaseNotes_5_0_1.html


Tatsuro

But, Fedora 22 is currently on:
gnuplot-common-5.0.0-8.fc22.x86_64

So, things may change again soon.
(I'll work on the fltk doc for using full LaTeX for
figure 15.7)

Michael Godfrey <godfrey>
Group Member
Wed 24 Jun 2015 09:43:25 AM UTC, comment #48: 

Ben,

This is being done for Matlab compatibility even though
it is a VERY bad idea. epsc only has significance within
Matlab/Octave. After creating the *.epsc file its name
has to be changed if it is to be recognized as Encapsulated
PostScript.

Anyhow, it appears that nothing can be done beyond
recommending using -color.

Michael Godfrey <godfrey>
Group Member
Wed 24 Jun 2015 12:10:27 AM UTC, comment #47: 

Perhaps the implication that eps is b/w and epsc is color is because (for Octave) the print command below produces a b/w result
+verbation+
print figure.eps
-verbatim-
But this one produces a color eps-file.

print figure.epsc



Ben Abbott <bpabbott>
Group Member
Tue 23 Jun 2015 10:31:55 PM UTC, comment #46: 

Ben: You could be right, but it appeared to say that a file
with suffix eps was b/w.  And this was used as an argument against
using the suffix eps, which is not valid. I see no problem
with the current use of .eps in, for example, the Manual build,
and elsewhere.

Michael Godfrey <godfrey>
Group Member
Tue 23 Jun 2015 09:37:07 PM UTC, comment #45: 

I think the EPS vs EPSC comment was regarding Matlab's syntax for printing. Meaning

print -deps figure.eps

prints a grayscale eps-file. And

print -depsc figure.eps

prints a color eps-file.

Ben Abbott <bpabbott>
Group Member
Tue 23 Jun 2015 08:20:42 PM UTC, comment #44: 

There was a comment about this on the maintainers list to
the effect that EPS is black and white and EPSC is color.
This is not the Adobe definition. EPS is Encapsulated PostScript.
There is no definition for EPSC. While there could be
problems with using EPS as in now done, color is not at at issue.

Michael Godfrey <godfrey>
Group Member
Mon 22 Jun 2015 07:48:28 AM UTC, comment #43: 

Ben,

Good idea to have some review and testing. All that I
can report is that it looks good on Fedora 22 with
gnuplot 5.0.0.8.

I will check some more plots soon.

Michael Godfrey <godfrey>
Group Member
Mon 22 Jun 2015 12:17:35 AM UTC, comment #42: 

Ok. Thanks fo the help!

Since I can't build Octave 4.x on MacOS X, I find myself feeling paranoid.

I'd like to have jwe, Jordi, or Rik take a look before pushing.

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 10:50:05 PM UTC, comment #41: 

Ben,
as I said, I ran your tests using gnuplot 4.6 and they
looked OK. However, I cannot do a build on a system
running 4.6.

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 10:17:41 PM UTC, comment #40: 

Yes. The new patch is the same as the old with the two lines removed. My only worry is the unlikely event that plotting with gnuplot 4.6 will be broken.

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 09:54:29 PM UTC, comment #39: 

Ben,

Does your new patch replace the old one?

Anyhow, the old one with my minor fix seemed to work.

Need more testing?

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 09:49:51 PM UTC, comment #38: 

Ben,

I think that you got it.  All I did to the first patch result
was to comment out lines 346 and 350 of _gnuplot_drawnow_.m

This compiled and Manual plots looked OK.

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 08:15:31 PM UTC, comment #37: 

Opps. Try this one.

(file #34287)

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 08:03:22 PM UTC, comment #36: 

Ben,

The build with your patch crashed at:
parse error near line 346 of file /home/godfrey/d/src/octave/hg/octave/scripts/plot/util/__gnuplot_drawnow__.m

  syntax error

>>>   else

         ^

so, I am kind of stuck for a bit.

Will try to figure things out after a while.




Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 06:53:37 PM UTC, comment #35: 

The gnuplot manual indicates that the density parameter that follows "solid" is optional. So I think it is ok not to include it (i.e. no transparency).

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 06:51:37 PM UTC, comment #34: 

Michael,

Sorry for asking for more ... can you try a 2D plot in Octave (default branch) using both gnuplot-4.6 and 5.0?


Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 06:51:05 PM UTC, comment #33: 

Ben,

Are you happy with the 2 commands with "solid" with no argument
following it?

Any idea what this does?

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 06:40:20 PM UTC, comment #32: 

I ran them on my Mac using gnuplot 4.6 patchlevel 6

Both OK. broken is black/white
         working sin curve is red

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 06:30:28 PM UTC, comment #31: 

Michael,

For gnuplot 5, that is what I meant.

We should verify nothing breaks for gnuplot 4.6.x too. Are you able to use an old version of gnuplot and run some tests?

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 06:27:45 PM UTC, comment #30: 

I can't test this on the default branch, but have attached a changeset. Once it is confirmed to work with gnuplot 4.6.x and 5.0.x, the changeset may be pushed.

(file #34286)

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 06:21:58 PM UTC, comment #29: 

Ben,

Is what you mean by "good plots" that
broken.eps produces black rectangle
and
working.eps produces the expected sin wave ?

That is what I got.

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 05:57:43 PM UTC, comment #28: 

If someone would confirm that the commands below produce two good plots, I'll file a bug report for gnuplot.


set terminal postscript enhanced size 7.77777777778,5.83333333333 eps
set output 'broken.eps';
set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#ffffff"
set obj 2 rectangle from graph 0,0 to graph 1,1 behind fc rgb "#ffffff"
plot sin (x)
set output 'working.eps';
set terminal postscript color enhanced size 7.77777777778,5.83333333333 eps
plot sin (x)


Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 05:17:33 PM UTC, comment #27: 

One more observation: the sombrero plot in the Manual comes
out correctly in color!

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 05:11:32 PM UTC, comment #26: 

My patch does not solve all the problems.
Worst is that while most plots are visible, they are in
black and white. And, the polar plot in the Manual
comes out with black fill.

So, some has been learned, but more work is needed.
And, it would be good to establish if the gnuplot folks
consider this behavior as bugs. A key issue is what
"solid" with no argument does, if if this is viewed
as an error.

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 03:18:18 PM UTC, comment #25: 

Below is a script that demonstrates the problem. It appears that the postscript terminal is to blame, or maybe Octave's options for the postscript terminal are wrong?


set terminal postscript enhanced size 7.77777777778,5.83333333333 eps
set output 'broken.eps';
set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#ffffff"
set obj 2 rectangle from graph 0,0 to graph 1,1 behind fc rgb "#ffffff"
plot sin (x)
set output 'working.eps';
set terminal postscript color enhanced size 7.77777777778,5.83333333333 eps
plot sin (x)


Can someone else confirm?

Does this match all examples?

Is the problem with gnuplot or Octave? If gnuplot, then does the bug report below cover it.

http://sourceforge.net/p/gnuplot/bugs/1561/



Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 03:09:06 PM UTC, comment #24: 

Ben,

I just quickly read your comments. Thanks for all the information.
And, I have tried a few more experiments. It does appear that
additional changes may be needed, and/or bug report to gnuplot.
But, using  "solid" without any argument is not a good choice.
This needs to be fixed in 2 places in _go_draw_figure_.m
as the attached patch shows.

With this patch I get plots that so far seem right. But, I
suspect that using commands like set(h, "color","#abcdef")
may produce unexpected results.

Using the attached patch may get things back to about where they
were with gnuplot 4...




(file #34285)

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 02:51:28 PM UTC, comment #23: 

Opps, comment 22 is responding to 20.

The "solid {<density>}" maybe a gnuplot bug.


set style fill {empty
                     | {transparent} solid {<density>}
                     | {transparent} pattern {<n>}}
                    {border {lt} {lc <colorspec>} | noborder}



Set style fill transparent Some terminals support the attribute transparent for filled areas. In the case of transparent solid fill areas, the density parameter is interpreted as an alpha value; that is, density 0 is fully transparent, density 1 is fully opaque. In the case of transparent pattern fill, the background of the pattern is either fully transparent or fully opaque.


I expect a density of 0 implies that the rectangle object is invisible. If so, changing the density to 0 is equivalent to removing the "set obj" command. Am I reading the gnuplot doc correctly? If so, has anyone constructed a simple gnuplot script that reproduces the problem? If that can be done, then I recommend filling a bug report for gnuplot.

Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 02:25:40 PM UTC, comment #22: 

Michael,

The link to the relevant page in the manual is below.

http://gnuplot.sourceforge.net/docs_4.2/node226.html

The command is placing a rectangle filled by the figure's color behind all other objects.

The syntax for 4.6 is


set object <index>
       <object-type> <object-properties>
       {front|back|behind} {fc|fillcolor <colorspec>} {fs <fillstyle>}
       {default} {lw|linewidth <width>}


with <filestyle> being


set style fill {empty
                     | {transparent} solid {<density>}
                     | {transparent} pattern {<n>}}
                    {border {lt} {lc <colorspec>} | noborder}


For 5.0 it is


set object <index>
       <object-type> <object-properties>
       {front|back|behind} {clip|noclip}
       {fc|fillcolor <colorspec>} {fs <fillstyle>}
       {default} {lw|linewidth <width>} {dt|dashtype <dashtype>}
   unset object <index>


with <filestyle> being


set style fill {empty
                     | {transparent} solid {<density>}
                     | {transparent} pattern {<n>}}
                    {border {lt} {lc <colorspec>} | noborder}


As the syntax has changed it is likely this part of gunplot has been modified or rewritten. I did a simple search of gnuplot's bugs but didn't find a report matching this.

http://sourceforge.net/p/gnuplot/bugs/search/?q=%22set+obj%22

I tried the simple gnuplot script below, but it does not produce the black rectangle in gnuplot 5


set terminal postscript enhanced color size 10,7.5 eps 20 dashlength 2
#set terminal pdf size 5,4 color
set output 'test.eps'
plot sin(x)
set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#acacff" fs solid no border


Ben Abbott <bpabbott>
Group Member
Sun 21 Jun 2015 02:07:36 PM UTC, comment #21: 

The gnuplot documentation always shows the keyword solid
followed by its argument. And, in go_draw_figure.m
replacing:
solid noborder
by
solid 0 noborder
corrects the problem.
Using solid 1.0 noborder produces the black background.
So, it appears that gnuplot 4 assumed 0 if there was
no argument after 'sold", but gnuplot 5 assumes 1.0

I tested this in a test file and am building an updated
system now, but it appears to work.

Patch to follow.

Michael Godfrey <godfrey>
Group Member
Sun 21 Jun 2015 12:19:00 PM UTC, comment #20: 

Below are the lines in:
_go_draw_figure_.m
that causes the black plots.

      bg = get (h, "color");
      if (isnumeric (bg))
        fprintf (plot_stream, "set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb \"#%02x%02x%02x\" fs solid noborder\n", round (255 * bg));


It is the fprintf that causes the problem. Does anyone know
the purpose of this text in the gnuplot input? 
For simple plots the result appears
correct without this line in the input.

I will take a look at the gnuplot Manual to determine what this
line is supposed to do.

It appears that gnuplot 5.0 interpretes this line differently
from gnuplot 4.

Michael Godfrey <godfrey>
Group Member
Thu 04 Jun 2015 11:01:47 PM UTC, comment #19: 

Mike: I posted some more information, but somehow
it got lost. Quickly, I tried:
x = -10:0.1:10;
 plot (x, sin (x));
 print zzz.eps
This crashed with:

octave-gui: vbo/vbo_exec_draw.c:278: vbo_exec_vtx_unmap: Assertion `exec->vtx.buffer_ptr != ((void *)0)' failed.
panic: Aborted -- stopping myself...

This was using current Octave as:octave --no-gui
Obviously, the code in the Manual build does generate
EPS, but it is black filled.


Michael Godfrey <godfrey>
Group Member
Thu 04 Jun 2015 07:02:38 PM UTC, comment #18: 

Mike: I agree that the problem is with the gnuplot
black fill. And, gnuplot 5 generates it and gnuplot
4, for the same input, does not.
The real question is how to fix it. The web page mentioned
in bug report #37273 suggested that an input change
would turn off the black fill. Obviously, it is possible
to generate plots using gnuplot 5 with no black fill.

I took a quick look on the gnuplot website but did not
see any mention of this as a known bug.

I am really short of time right now and leaving on a trip
in the morning. But, checking if there really is a
workaround would be worth a bit of time. If that fails,
a bug report to gnuplot. (Or both!)

Michael
p.s. Nice work identifying exactly the problem. That
will help in any case.

Michael Godfrey <godfrey>
Group Member
Thu 04 Jun 2015 11:27:06 AM UTC, comment #17: 

Michael: I can confirm your observation that 3D plots do render to a file correctly with gnuplot version 5, only 2D plots have the black area fill.

Remember, this is about printed files, and yes this is a gnuplot problem.

I have attached two eps files generated by Octave with gnuplot 4.6.6 and 5.0.0 respectively. One can diff the files and see the differences between them.

The important difference is the following line that appears in the gnuplot version 5 output:


1.000 540 400 10618 7998 BoxColFill


Removing that line removes the black area fill and the line plot is visible.

(file #34157, file #34158)

Mike Miller <mtmiller>
Group Member
Thu 04 Jun 2015 09:59:50 AM UTC, comment #16: 

I noticed that with current stable system not all Manual
plots are black. Specifically plots 15.6 and 15.7
are correct. These are 3-D plots, so this may be a hint
about the problem. Also, the information referred to in
bug report #37273 may help.

Since the Manual plots work correctly if run outside
the build process, it is doubtful that this is a gnuplot
problem.

Just finding what is different in the build flow for the
simple first example:
x= -10:.1:10;
plot(x,sin(x))
should help. This plot, as I said, works fine when run using
the version of Octave which was built by the make which produces
a black plot in the Manual. Somehow, fill may be turned on
as stated in #37273. This may be a new "feature" in
gnuplot 5.

Also, note that this report is a continuation of #44458.

Michael Godfrey <godfrey>
Group Member
Sat 07 Mar 2015 06:57:51 PM UTC, comment #15: 

This was reported as affecting a Mac OSX user also in duplicate bug #44458, updating OS field.

Mike Miller <mtmiller>
Group Member
Wed 30 Jul 2014 01:31:18 AM UTC, comment #14: 

When I've attempted it in the past, it was a long process, but If you have the time, it may be possible to isolate the problem by selectively removing commands from the gnuplot plot-stream produced by octave. Unfortunately, the binary data makes that painful :-(

Ben Abbott <bpabbott>
Group Member
Wed 30 Jul 2014 01:26:25 AM UTC, comment #13: 

No, that simple example works perfectly both on-screen with either X11 or Qt terminals, and EPS output looks right.

Mike Miller <mtmiller>
Group Member
Wed 30 Jul 2014 01:21:22 AM UTC, comment #12: 

In my previous comment, the gnuplot commands are preceded by "gnupot>". The rest is gnuplot output.

Ben Abbott <bpabbott>
Group Member
Wed 30 Jul 2014 01:19:33 AM UTC, comment #11: 

Ok. Maybe a simpler test?


gnuplot> plot sin(x)
gnuplot> set terminal postscript enhanced size 10,7.5 eps 20 dashlength 2
Terminal type set to 'postscript'
Options are 'eps enhanced defaultplex \
   leveldefault monochrome colortext \
   dashed dashlength 2.0 linewidth 1.0 butt noclip \
   nobackground \
   palfuncparam 2000,0.003 \
   size 10.00in, 7.50in "Helvetica" 20  fontscale 1.0 '
gnuplot> set output './debug.eps';
gnuplot> plot sin(x)


Is debug.eps also all black?

Ben Abbott <bpabbott>
Group Member
Wed 30 Jul 2014 01:09:48 AM UTC, comment #10: 

Thanks, ok I did that and I get the same plot, all black plot background with only the axis tickmarks visible. EPS file from gnuplot 5.0rc1 attached.

This has not been reported to gnuplot as far as I know.

(file #31795)

Mike Miller <mtmiller>
Group Member
Wed 30 Jul 2014 12:44:10 AM UTC, comment #9: 

Has this problem been reported to the gnuplot developers?

Can someone running gnuplot v5rc# try editing the log file (file #31773, octave-print-commands.log) and change the 3rd line to


set output './debug.eps';


Then from a terminal/shell prompt, type


gnuplot octave-print-commands.log


And then attach the eps-file (junk.eps) that is created.

If the file looks good, then there may be a bug in Octave. However, if the
plot looks bad, then my expectation is that the bug is with gnuplot.

Ben Abbott <bpabbott>
Group Member
Wed 30 Jul 2014 12:37:06 AM UTC, comment #8: 

Ben, can you repost your suggestion? It got mangled by savannah. All I saw in the email copy was to rename the output file to './debug.eps'. I tried this, no difference.

Mike Miller <mtmiller>
Group Member
Sat 26 Jul 2014 06:20:42 PM UTC, comment #7: 

Has this problem been reported to the gnuplot developers?

Can someone running gnuplot v5rc# try editing the log file and change the 3rd line to


set output './debug.eps';
-verbatim+

Then from a terminal/shell prompt, type

+verbatim+
gnuplot octave-print-commands.log


And then attach the eps-file (junk.eps) that is created.

If the file looks good, then there may be a bug in Octave. However, if the plot looks correct, then my expectations is that the bug is with gnuplot.

Ben Abbott <bpabbott>
Group Member
Fri 25 Jul 2014 01:00:31 AM UTC, comment #6: 

That means I am posting the log to gnuplot bug tracker?

(file #31773)

Anonymous
Fri 25 Jul 2014 12:56:50 AM UTC, comment #5: 

Use the -debug option:


print -debug test.pdf


This will create a file in your current directory called octave-print-commands.log, which is the input file to gnuplot. I just verified that I can do this, pass this file to gnuplot 4.6.5 and it works fine, while it fails with gnuplot 5.0rc1.

Note that the command file will direct gnuplot to create a eps file in the /tmp directory, Octave uses other tools to convert eps to pdf.

Mike Miller <mtmiller>
Group Member
Thu 24 Jul 2014 11:40:07 PM UTC, comment #4: 

How should I generate these? I am new to Octave so I am not so sure

Anonymous
Thu 24 Jul 2014 11:34:32 PM UTC, comment #3: 

Confirmed here, using gnuplot built from current cvs head (reports version as 5.0 patchlevel rc1).

Since an earlier version of gnuplot works with Octave and the bleeding edge 5.0 prerelease doesn't, you might want to involve the gnuplot developers and see what has changed and where this should be addressed. You can get Octave to generate the intermediate output that is piped to gnuplot if you need for debugging.

Mike Miller <mtmiller>
Group Member
Thu 24 Jul 2014 08:15:45 PM UTC, comment #2: 

Btw, it's gnuplot, not GNUPlot. It's unrelated to GNU.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 24 Jul 2014 08:06:29 PM UTC, comment #1: 

Downgraded to GNUPlot 4.6.5 and worked.

Anonymous
Thu 24 Jul 2014 07:40:41 PM UTC, original submission:  

I am trying to plot with the attached script, and I get black plots for whatever format I am using as attached PDF. I am using gnuplot graphics package. The plot windows look good though. GNUPlot version is 5.0

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34287:  bug_42838.changeset added by bpabbott (2KiB - application/octet-stream)
file #34285:  gs_5.0_fix.diff added by godfrey (2KiB - text/x-patch)
file #34157:  line-gnuplot4.eps added by mtmiller (21KiB - image/x-eps)
file #34158:  line-gnuplot5.eps added by mtmiller (22KiB - image/x-eps)
file #31795:  debug.eps added by mtmiller (89KiB - image/x-eps)
file #31773:  octave-print-commands.log added by None (2MiB - text/plain)
file #31770:  Control_to_Output.m added by None (925B - text/x-objcsrc)
file #31771:  Control_to_Output_Magnitude.pdf added by None (18KiB - application/unknown)
file #31772:  Control_to_Output_Phase.pdf added by None (12KiB - application/unknown)

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 24 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-13 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2015-12-13 bpabbott StatusPatch Submitted Ready For Test
    2015-11-18 mtmiller Dependencies- bugs #46425 is dependent
    2015-06-21 bpabbott Attached File#34286 Removed
    2015-06-21 bpabbott Attached File- Added bug_42838.changeset, #34287
    2015-06-21 bpabbott Attached File- Added gnuplot5_color.patch, #34286
        Priority5 - Normal 4
        StatusConfirmed Patch Submitted
    2015-06-21 godfrey Attached File- Added gs_5.0_fix.diff, #34285
    2015-06-04 mtmiller Attached File- Added line-gnuplot4.eps, #34157
        Attached File- Added line-gnuplot5.eps, #34158
    2015-05-28 mtmiller Dependencies- bugs #45206 is dependent
    2015-03-07 mtmiller Release3.8.1 dev
        Operating SystemGNU/Linux Any
    2015-03-07 mtmiller Dependencies- bugs #44458 is dependent
    2014-07-30 mtmiller Attached File- Added debug.eps, #31795
    2014-07-25 None Attached File- Added octave-print-commands.log, #31773
    2014-07-24 mtmiller StatusNone Confirmed
        Summarygnuplot print gives black plots gnuplot 5.0 print gives black plots
    2014-07-24 jordigh SummaryGNUPlot print gives black plots gnuplot print gives black plots
    2014-07-24 None Attached File- Added Control_to_Output.m, #31770
        Attached File- Added Control_to_Output_Magnitude.pdf, #31771
        Attached File- Added Control_to_Output_Phase.pdf, #31772

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code