bugGNU Octave - Bugs: bug #49223, gnuplot with -depslatexstandalone...


bug #49223: gnuplot with -depslatexstandalone fails to produce axis labels

Submitted by:  None
Submitted on:  Thu 29 Sep 2016 06:38:36 PM UTC  
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  R.S.Carmenes Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.0-rc2
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

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


( Jump to the original submission)

Thu 06 Oct 2016 06:22:19 PM UTC, comment #33:

I pushed Dan's patch to the stable branch (http://hg.savannah.gnu.org/hgweb/octave/rev/883b72cdf0b2).

Rik <rik5>
Project Administrator
Thu 06 Oct 2016 03:25:59 PM UTC, comment #32:

Yes, that silences the errors with gnuplot 4.4.

Mike Miller <mtmiller>
Project Administrator
Thu 06 Oct 2016 06:43:24 AM UTC, comment #31:

gnuplot 4.4.0 evidently still uses the old conditional syntax. Give the attached patch a try; it appears to work for me under 4.4.0 and 5.0+, but I don't have Qt running in gnuplot 4.4.0. I also tried to get rid of the extraneous

reported here


(file #38668)

Dan Sebald <sebald>
Thu 06 Oct 2016 12:28:47 AM UTC, comment #30:

This change has broken any plot with gnuplot 4.4, please either reopen or let's open a new bug about this regression.

Mike Miller <mtmiller>
Project Administrator
Mon 03 Oct 2016 07:54:40 PM UTC, comment #29:

I pushed the change to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/43fe18c1129e). Closing report.

Rik <rik5>
Project Administrator
Mon 03 Oct 2016 06:33:14 PM UTC, comment #28:

I tried your latest patch and it works well form me (I am using gnuplot 5.0.4); To my short understanding, this seems a better approach than removing \gplbacktext.

Mon 03 Oct 2016 05:05:10 AM UTC, comment #27:

I think I have a near satisfactory solution. I tried the approach mentioned in the previous post:

1) Use gnuplot's terminal background color option
2) Draw the "backtext"
3) Render all the PostScript (i.e., all in one file)
4) Draw the "fronttext"

That at least makes everything not behind the axes background (which is?) visible.

I had to do a little bit of a trick for the Qt terminal, which for some reason doesn't have a background color option. Since we aren't sure what interactive terminal is being used, no less when creating a hard copy, I've done the conditioning on the terminal inside of gnuplot code itself.

Furthermore, I see that the figure property "inverthardcopy" is what forces the white color. SO, give this a try:

and then process with

Again, not a perfect solution, but better and I think adequate for 4.2 release.

(file #38651)

Dan Sebald <sebald>
Mon 03 Oct 2016 03:28:24 AM UTC, comment #26:

I'm attaching a little diff file to illustrate things. I wanted to set both axes and figure color to "none", hoping to see the axis tick annotation come through--but it didn't. So I think that print() is turning the rectangles back on somehow. The changes in the diff file will show that is the case.

Try the following:

with and without the applied diff. After disabling the background figure rectangle (set obj 1 rect), the ticks labels become visible, as desired. As I see it, there is never a reason for anything to be further back than the figure background rectangle. So, we need:

1) background
2) some text
3) all PostScript graphics objects
4) some text

We can't split the background from all the other PostScript objects if Octave is initiating things. I'm proposing that we leave out the background rectangle (set obj 1 rect) and post-process the TeX/LaTeX file to add a TeX command that draws that rectangle before processing/including all the other plot elements.

OR, there might be an alternative. Most gnuplot terminals have a setting for background color:

We could attempt to use that, but I don't know how far back in gnuplot version history color option consistency is. It is probably worth a try doing this first.

Keep in mind that no matter what we do, the group order listed above (1 through 4) will never be a complete solution. Someone someday will create text/labels with backgrounds and maybe those overlap and the text of one label will show through the background of another label.

The other thing you'll notice about the little diff I made is that the axes background color is being cast to white (not yellow) when printed. I think that was done for a reason, but I don't see the point of it--if the user wants the background printed white, s/he will just choose white.

(file #38650)

Dan Sebald <sebald>
Mon 03 Oct 2016 02:42:12 AM UTC, comment #25:

I pushed the tiny cset to get rid of the old code for 4.2.5. I guess that leaves writing a little Octave function to do the search and replace on the generated .tex file. When should it be invoked? I believe it is only required for the gnuplot toolkit whenever "latex" is in the device name. Does the "standalone" option make a difference?

Rik <rik5>
Project Administrator
Sun 02 Oct 2016 07:11:31 PM UTC, comment #24:

gnuplot-4.4.0 is compatible with this change. Your example from https://savannah.gnu.org/bugs/index.php?49223#comment19 works the same under gnuplot-4.4.0 (x11) and gnuplot-5.4.0 (qt). Printing to pdflatexstandalone doesn't work because of the age of gnuplot 4.4.0.

Dan Sebald <sebald>
Sun 02 Oct 2016 06:27:29 PM UTC, comment #23:

I've tried your change. I'm fine with it. By not using the "backtext" group, it simply relies on the order of drawing the PostScript elements. There isn't a way to fix this (hold on, I just had an idea...), and that is probably why I stopped pursuing bug report https://savannah.gnu.org/bugs/?48200 . In order to maintain the desired order, we'd need the ability to

1) Render rectangular background (a postscript element)
2) Render axis annotation
3) Render the axis lines (postscript elements)

and the grouping I described (where all PostScript is bundled into one layer) doesn't do that.

The one idea I just had (and it isn't the best) is if we could render the background rectangle via LaTeX. That's an easy rendering, as LaTeX can at least draw rectangles pretty well (although most everything else in LaTeX graphics is somewhat dodgy). But, this too would require post-modification of a file created by gnuplot. Is it worth the effort? Don't know.

BTW, it wouldn't be too difficult to write an Octave script equivalent of "sed".

Dan Sebald <sebald>
Sun 02 Oct 2016 05:26:29 PM UTC, comment #22:

Yes, that's it exactly, and probably what motivated me to attempt a change in gnuplot's latex driver. (This happened in June only; what memory.) It is the following type of requirement:

that is the major issue. gnuplot's method of grouping into

1) Background text
2) All EPS elements
3) Foreground text

takes away the granularity. It's only the EPS-latex family of terminals that group like this, and I wanted to get rid of it. We'd not have to do anything special, as EPS-latex would match the ordering of Qt, WXT, x11 and all other terminals.

Dan Sebald <sebald>
Sun 02 Oct 2016 02:15:07 PM UTC, comment #21:

Is this also related to bug #48200?

Rik <rik5>
Project Administrator
Sun 02 Oct 2016 01:59:44 PM UTC, comment #20:

Attached is a cset that removes the obsolete code for 4.2.5. If someone can apply the patch and it passes with gnuplot 4.4 then I will commit it.

(file #38646)

Rik <rik5>
Project Administrator
Sun 02 Oct 2016 01:55:25 PM UTC, comment #19:

I don't othink we should assume that all installs will have sed (think Windows) which is why it would be preferable to have Octave modify the generated file, or resolve this a different way.

Also, changing the layer property in Octave has other effects besides just the tics. Try

We need to preserve that.

I experimented with removing the lines

and the layer property still worked correctly for me.

However, it didn't solve the issue of the axis labels not appearing when the layer is set to "bottom". So it appears that there are two things still to be done. 1) Clean up this FIXME which no longer appears necessary, although I can only test back to gnuplot 4.6.6, and 2) Replace 'gplbacktext{%' in the generated tex file.

Rik <rik5>
Project Administrator
Sat 01 Oct 2016 09:30:25 PM UTC, comment #18:

That works. sed is a pretty powerful script...

I've found a broader bug when investigating this issue. It applies to all toolkits. When the axes has a "color" property of "none", there are no objects found that can be plotted and the print.m code doesn't account for that an throws an error. I was going to post here, but decided to open a new report given its scope is all toolkits, not just gnuplot:


Dan Sebald <sebald>
Sat 01 Oct 2016 06:21:26 PM UTC, comment #17:

If useful, I can add to #15 from observation of several plots:

(1) first occurence of \gplbacktext is to globally define the macro \gplbacktext as an empty function; this appears once in every *.tex output:


(this is certainly redefined somewhere, somehow).

(2) the latest occurence in every file is just that macro alone on the line preceding the macro that includes the pdf whith the plot (but without the text).

(3) the rest of occurences is one for every subplot in the figure, and it always comes after "\gplgaddtomacro"; the complete line is:


Therefore, in a file like the test I provided, it appears three times, and only the 2nd is needed to be changed. In a figure with 4 plots, it appears 6 times, and the 4 occurences with the pattern "gplbacktext{%" are to be modified to get the correct result.

The following naïve implementation works for me (on Linux):

graphics_toolkit gnuplot
title('Plot title should be on top')
legend('single legend')
text(0,20,'internal text at position (0,20)')
xlabel('X Label')
ylabel('Y Label')
system(['sed -i "s,gplbacktext{%,gplfronttext{%," ' fname '.tex']);
system(['pdflatex ' fname '.tex']);

Sat 01 Oct 2016 06:10:43 PM UTC, comment #16:

OK, thanks. There is also the possibility of redefining \gplbactext, which is a very PostScript-ee thing to do.

However, I think the solution is already present in Octave. The axes object has a layer property, which I noticed by looking through the gnuplot toolkit code:

So, the following works with the current code:

where I've added an extra "set()" command.

The issue is that the border being on the bottom layer doesn't seem to be of any practical use unless perhaps the white background rectangle can be forced even further back. So, what to do? Again, this front/back from gnuplot's perspective isn't something I like--my preference in gnuplot would be to just maintain the draw order as depth and let the user/application deal with the layering. I'll look around a bit and see if there is something sensible, otherwise if there is a way to make "top" be the default border layer for gnuplot toolkit, that might be the preference.

Dan Sebald <sebald>
Sat 01 Oct 2016 04:34:11 PM UTC, comment #15:

@Dan: I pushed your cset making pdflatex and pdflatexstandalone options for gnuplot (http://hg.savannah.gnu.org/hgweb/octave/rev/83f106bfcb37).

If there is no easy way to direct gnuplot to remove the gplbacktext macro then we could do it ourselves. It would be simple to rely on an outside tool like sed or perl, but more portable if we just did it ourselves. It wouldn't be that hard to fopen the file, search and replace this one string, and then close it again.

I did use 'grep gplbactext' on the generated tex file and it was found three times. We would need to use the more specific pattern

Rik <rik5>
Project Administrator
Sat 01 Oct 2016 04:12:14 PM UTC, comment #14:

Thank you!

the trick on #12 works great and I can easily implement a sed to automate it until a proper patch is available.

#13 works great too, and the plot is even sligtlñy better too (label boxes have better proportions).

Sat 01 Oct 2016 01:55:06 AM UTC, comment #13:

Attached is a patch that implements print 'pdflatex' and 'pdflatexstandalone' (simply an alias of cairo equivalents) and fixes 'pdfcairolatexstandalone' so that it processes with a simple "pdflatex" invocation at the command line. For example:

I will look at the original bug (layering) next.

(file #38635)

Dan Sebald <sebald>
Fri 30 Sep 2016 09:02:17 PM UTC, comment #12:

Oh... I think this is an issue with gnuplot which I had discussed with gnuplot developers several months back. The tic annotation is present, but it is obscured by the white background of the plot. To see this, change the output file as follows

The lengthy discussion for this is here:


The tex family of gnuplot terminals is the only one that utilizes this "front"/"back" layer code that is sporadically used in gnuplot core code. The problem is that it doesn't provide enough fine control of layer position for rectangles and various EPS elements that might be in the plot. I wanted to change this behavior by removing this front/back layer subgrouping and simply retain the layer order--the consequence being that there could be mulitple EPS files per figure depending upon how complex the order of objects is...but multiple files is not something that would concern me. Anyway, my change wasn't accepted.

Let me see if I can change Octave to force that white background triangle to the back somehow or place all text in the "front" layer.

BTW, you are doing

epstopdf test-inc.eps
pdflatex test.tex

rather than

latex test
dvips test -o test.ps
ps2pdf test.ps

You might be able to save a step by using the pdflatex terminal rather than epslatex. Hmm... I see that isn't working:

octave:10> print('-dpdflatexstandalone','-color','test')
error: print.m: PDFLATEXSTANDALONE output is not available for the Gnuplot graphics toolkit
error: called from
_gnuplot_print_ at line 174 column 7
print at line 497 column 14

I think this is supposed to work, as it is a small variation of the pdfcairo terminal. I'll look at that as well.

Dan Sebald <sebald>
Fri 30 Sep 2016 07:58:27 PM UTC, comment #11:

Just noting that last year I had written a demo for "print" as part of this large group of bugs:


that was extracted from changeset. The demo is in this file:


"demo print" would allow selecting the toolkit and the output mode and then try to run a linux application to view the output. It was a quick way to test all the combinations and judge the quality of output. It also gives the user some idea of how to use/process the output format. It worked pretty nicely for linux, but Windows/Mac I'm not sure.

Dan Sebald <sebald>
Fri 30 Sep 2016 11:47:11 AM UTC, comment #10:

I know about the png output, and it is now very nice indeed, but still, everything has its uses. I know nothing about svg, though, and I am not sure if I'll open a new front! Thanks for the tip anyway. I hope the corners in the interaction with the gnuplot backend will be rounded though.

Thank you.

Fri 30 Sep 2016 12:03:31 AM UTC, comment #9:

Try going to png format using 4.2.0. This has been improved a lot. Also, svg is another good option because then you can really post-process the results in a program like inkscape.

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 11:51:22 PM UTC, comment #8:

Sure it has to do with gnuplot, but not alone, because octave 4.0.3 gives correct results using the very same gnuplot version (5.0.4).

gnuplot is more convenient for me because I need to output plots and also (processed) images, and the later are badly compressed to jpeg with a noticeable loose of quality when exported by the gl2ps engine, whereas gnuplot keeps them with the original quality. I couldn't find a way to make gl2ps export images without jpeg compression.

Thank you.

Thu 29 Sep 2016 10:53:43 PM UTC, comment #7:

I think the problem is with gnuplot, rather than the qt or fltk toolkits. I tried your example from comment #4 without the line

and I got a 2-D figure that was correct. When I used gnuplot the figure does not include the axis labels.

For the time being, I would try using a different toolkit as a workaround.

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 10:18:02 PM UTC, comment #6:

Let's update the last comment: the 3D plot work well with the fltk graphics_toolkit, but fails to draw vertical lines with the gnuplot toolkit!

And on 2D plots (like my sample), the numbers disappear the gnuplot, but not with fltk.

Thu 29 Sep 2016 10:01:21 PM UTC, comment #5:

Also, let me add that I have tested the sample you pointed with the mexican hat, and it works well for me too. So the problem is with 2-D plots, not with 3-D.

Thu 29 Sep 2016 09:58:45 PM UTC, comment #4:

I post the full message again, for some reason it was heavely truncated:

Bad results are obtained when printing plots with -depslatexstandalone with octave 4.20.0rc2 under Linux. I am not sure if this was already present on rc1.
However octave 4.0.3 was correct in this respect.

The symptom is that axis numbers disappear; the rest of labels and text are ok. See this sample:

graphics_toolkit gnuplot
title('Plot title should be on top')
legend('single legend')
text(0,20,'internal text at position (0,20)')
xlabel('X Label')
ylabel('Y Label')

then, from outside, we can process the resulting output with:

epstopdf test-inc.eps
pdflatex test.tex

On the resulting test.pdf, axis numbering is (apparently) absent.

After some investigation, comparing eps output on 4.0.3 and 4.20.0rc2, I found a line that may give a clue about the culprit:

1.00 1.00 1.00 C 1.000 0 0 11519 8639 BoxColFill

It seems to control the background and I wonder if it is either missplaced (too early?) or misscontrolled (wrong colors or wrong tranparency?). Removing that line in the eps file or modifying some of its parameters allows the numbers to become visible.

I compared the bad eps file with that obtained with


and the line above is present, but here, without any bad side effect. In fact, the -deps option renders a very nice output. Great job!


Thu 29 Sep 2016 06:59:07 PM UTC, comment #3:

There is sample code at http://wiki.octave.org/Printing_with_FLTK. Can you try that code and see what the result is? It works for me with 4.2.0-rc2, although I stopped after generating Postscript.

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 06:50:21 PM UTC, comment #2:

Also, what graphics toolkit are you using?

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 06:49:51 PM UTC, comment #1:

The sample code, or sample eps file, does not appear to be attached.

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 06:38:36 PM UTC, original submission:


Bad results are obtained when printing plots with -depslatexstandalone with octave 4.20.0rc2 under Linux.

I am not sure if this was already present on rc1.
However octave 4.0.3 was correct in this respect.

The symptom is that axis numbers disappear; the rest of labels and text are ok. See this sample:



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

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


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

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

    Only project members can vote.




    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-06 sebald Attached File- => Added octave-gnuplot_fix_conditional_bug49223-djs2016oct06.patch, #38668
    2016-10-03 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2016-10-03 sebald Attached File- => Added octave-gnuplot_terminal_background_bug49223-djs2016oct02.patch, #38651
    2016-10-03 sebald Attached File- => Added disable_background_rectangle.diff, #38650
    2016-10-02 rik5 Attached File- => Added borderback.cset, #38646
    2016-10-01 sebald Attached File- => Added octave-gnuplot_print_pdflatex_bug49223-djs2016sep30.patch, #38635
    2016-09-29 rik5 CategoryPlotting => Plotting with gnuplot
        StatusWorks For Me => Confirmed
        Summarywrong eps with -depslatexstandalone => gnuplot with -depslatexstandalone fails to produce axis labels
    2016-09-29 rik5 StatusNone => Works For Me

    Back to the top

    Powered by Savane 3.4