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


bug #42838: gnuplot 5.0 print gives black plots

Submitted by:  None
Submitted on:  Thu Jul 24 19:40:41 2014  
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 4Item Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: dev
Operating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Mon Feb 15 19:59:43 2016, comment #58:

Thanks, grafted onto stable here:


Mike Miller <mtmiller>
Project Administrator
Sat Feb 13 00:46:08 2016, 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>
Project Member
Fri Feb 12 22:51:15 2016, 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>
Project Administrator
Sun Dec 13 20:12:31 2015, 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>
Project Administrator
Sun Dec 13 13:19:02 2015, comment #54:


I overcame my apprehension and pushed a changeset.


If it works, then this can be closed.

Ben Abbott <bpabbott>
Project Member
Fri Nov 27 05:12:24 2015, 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>
Project Administrator
Fri Nov 27 01:49:24 2015, comment #52:


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>
Project Member
Wed Nov 25 04:14:54 2015, 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>
Project Administrator
Tue Jul 21 09:55:53 2015, comment #50:


Please take the last Ethan's reply in

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 Jun 24 13:16:39 2015, comment #49:

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:


But, Fedora 22 is currently on:

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

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


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

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

Michael Godfrey <godfrey>
Project Member
Wed Jun 24 00:10:27 2015, 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
print figure.eps
But this one produces a color eps-file.

Ben Abbott <bpabbott>
Project Member
Tue Jun 23 22:31:55 2015, 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>
Project Member
Tue Jun 23 21:37:07 2015, comment #45:

I think the EPS vs EPSC comment was regarding Matlab's syntax for printing. Meaning
prints a grayscale eps-file. And
prints a color eps-file.

Ben Abbott <bpabbott>
Project Member
Tue Jun 23 20:20:42 2015, 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>
Project Member
Mon Jun 22 07:48:28 2015, comment #43:


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

I will check some more plots soon.

Michael Godfrey <godfrey>
Project Member
Mon Jun 22 00:17:35 2015, 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>
Project Member
Sun Jun 21 22:50:05 2015, comment #41:

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>
Project Member
Sun Jun 21 22:17:41 2015, 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>
Project Member
Sun Jun 21 21:54:29 2015, comment #39:


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>
Project Member
Sun Jun 21 21:49:51 2015, comment #38:


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>
Project Member
Sun Jun 21 20:15:31 2015, comment #37:

Opps. Try this one.

(file #34287)

Ben Abbott <bpabbott>
Project Member
Sun Jun 21 20:03:22 2015, comment #36:


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>
Project Member
Sun Jun 21 18:53:37 2015, 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>
Project Member
Sun Jun 21 18:51:37 2015, comment #34:


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>
Project Member
Sun Jun 21 18:51:05 2015, comment #33:


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

Any idea what this does?

Michael Godfrey <godfrey>
Project Member
Sun Jun 21 18:40:20 2015, 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>
Project Member
Sun Jun 21 18:30:28 2015, comment #31:


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>
Project Member
Sun Jun 21 18:27:45 2015, 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>
Project Member
Sun Jun 21 18:21:58 2015, comment #29:


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

That is what I got.

Michael Godfrey <godfrey>
Project Member
Sun Jun 21 17:57:43 2015, comment #28:

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

Ben Abbott <bpabbott>
Project Member
Sun Jun 21 17:17:33 2015, comment #27:

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

Michael Godfrey <godfrey>
Project Member
Sun Jun 21 17:11:32 2015, 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>
Project Member
Sun Jun 21 15:18:18 2015, 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?

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.


Ben Abbott <bpabbott>
Project Member
Sun Jun 21 15:09:06 2015, comment #24:


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>
Project Member
Sun Jun 21 14:51:28 2015, comment #23:

Opps, comment 22 is responding to 20.

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

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>
Project Member
Sun Jun 21 14:25:40 2015, comment #22:


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


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

The syntax for 4.6 is

with <filestyle> being

For 5.0 it is

with <filestyle> being

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.


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

Ben Abbott <bpabbott>
Project Member
Sun Jun 21 14:07:36 2015, comment #21:

The gnuplot documentation always shows the keyword solid
followed by its argument. And, in go_draw_figure.m
solid noborder
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>
Project Member
Sun Jun 21 12:19:00 2015, comment #20:

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

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>
Project Member
Thu Jun 4 23:01:47 2015, 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:
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>
Project Member
Thu Jun 4 19:02:38 2015, 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!)

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

Michael Godfrey <godfrey>
Project Member
Thu Jun 4 11:27:06 2015, 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:

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

(file #34157, file #34158)

Mike Miller <mtmiller>
Project Administrator
Thu Jun 4 09:59:50 2015, 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

Just finding what is different in the build flow for the
simple first example:
x= -10:.1:10;
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>
Project Member
Sat Mar 7 18:57:51 2015, comment #15:

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

Mike Miller <mtmiller>
Project Administrator
Wed Jul 30 01:31:18 2014, 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>
Project Member
Wed Jul 30 01:26:25 2014, 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>
Project Administrator
Wed Jul 30 01:21:22 2014, comment #12:

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

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

Ok. Maybe a simpler test?

Is debug.eps also all black?

Ben Abbott <bpabbott>
Project Member
Wed Jul 30 01:09:48 2014, 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>
Project Administrator
Wed Jul 30 00:44:10 2014, 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

Then from a terminal/shell prompt, type

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>
Project Member
Wed Jul 30 00:37:06 2014, 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>
Project Administrator
Sat Jul 26 18:20:42 2014, 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

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

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

(file #31773)

Fri Jul 25 00:56:50 2014, comment #5:

Use the -debug option:

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>
Project Administrator
Thu Jul 24 23:40:07 2014, comment #4:

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

Thu Jul 24 23:34:32 2014, 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>
Project Administrator
Thu Jul 24 20:15:45 2014, comment #2:

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

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Thu Jul 24 20:06:29 2014, comment #1:

Downgraded to GNUPlot 4.6.5 and worked.

Thu Jul 24 19:40:41 2014, 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



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

Attach File(s):

Attached Files
file #34287:  bug_42838.changeset added by bpabbott (2kB - application/octet-stream)
file #34285:  gs_5.0_fix.diff added by godfrey (2kB - text/x-patch)
file #34157:  line-gnuplot4.eps added by mtmiller (21kB - image/x-eps)
file #34158:  line-gnuplot5.eps added by mtmiller (22kB - image/x-eps)
file #31795:  debug.eps added by mtmiller (89kB - image/x-eps)
file #31773:  octave-print-commands.log added by None (2MB - 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 (18kB - application/unknown)
file #31772:  Control_to_Output_Phase.pdf added by None (12kB - application/unknown)


Depends on the following items: None found

   bug dependencies.


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 24 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Dec 13 20:12:31 2015mtmillerStatusReady For Test=>Fixed
    Sun Dec 13 13:19:02 2015bpabbottStatusPatch Submitted=>Ready For Test
    Wed Nov 18 13:26:14 2015mtmillerDependencies-=>bugs #46425 is dependent
    Sun Jun 21 20:15:40 2015bpabbottAttached File#34286=>Removed
    Sun Jun 21 20:15:31 2015bpabbottAttached File-=>Added bug_42838.changeset, #34287
    Sun Jun 21 18:27:45 2015bpabbottAttached File-=>Added gnuplot5_color.patch, #34286
      Priority5 - Normal=>4
      StatusConfirmed=>Patch Submitted
    Sun Jun 21 15:09:06 2015godfreyAttached File-=>Added gs_5.0_fix.diff, #34285
    Thu Jun 4 11:27:06 2015mtmillerAttached File-=>Added line-gnuplot4.eps, #34157
      Attached File-=>Added line-gnuplot5.eps, #34158
    Thu May 28 23:11:42 2015mtmillerDependencies-=>bugs #45206 is dependent
    Sat Mar 7 18:57:51 2015mtmillerRelease3.8.1=>dev
      Operating SystemGNU/Linux=>Any
    Sat Mar 7 18:55:38 2015mtmillerDependencies-=>bugs #44458 is dependent
    Wed Jul 30 01:09:48 2014mtmillerAttached File-=>Added debug.eps, #31795
    Fri Jul 25 01:00:31 2014NoneAttached File-=>Added octave-print-commands.log, #31773
    Thu Jul 24 23:34:32 2014mtmillerStatusNone=>Confirmed
      Summarygnuplot print gives black plots=>gnuplot 5.0 print gives black plots
    Thu Jul 24 20:15:45 2014jordighSummaryGNUPlot print gives black plots=>gnuplot print gives black plots
    Thu Jul 24 19:40:41 2014NoneAttached 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.1-cleanup1