bugGNU Octave - Bugs: bug #32118, 'Interpreter','tex' fails for...


bug #32118: 'Interpreter','tex' fails for gnuplot and fltk

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Thu 13 Jan 2011 07:53:46 AM UTC  
Category:  Plotting Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  David Bateman <dbateman>
Originator Name:  godfrey Open/Closed:  Closed
Release:  dev 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.


Thu 29 Aug 2013 08:10:19 PM UTC, comment #5:

The FLTK backend now has support for the TeX interpreter so I'm closing this report.

Rik <rik5>
Project Administrator
Sun 16 Jan 2011 09:46:37 PM UTC, comment #4:

Yes this appears to be a regression. The issue is that in the gnuplot backend, the fontsize is now respected in 3.3 for text objects where is wasn't beforehand.. We are now emitting code like

where the

bit is new in 3.3.x. If the font is specifically set or the above is absent then setting the font wrapped in "{}" in the string will temporarily set the font as desired. So only the integral sign above will be printed using the symbol font. However, using

gnuplot no longer respects the "{}" to temporarily set the font. From my point of view this is a gnuplot bug. The way around this in gnuplot is that

should be used instead.. This seems to fix this issue for me with gnuplot 4.2 and 4.4 and so I pushed a fix in the changeset


As for the fltk TeX interpreter, the code at


could be used, but it doesn't separate the parse tree from the renderer as Michael suggested. I hope to have a little time to reimplement this soon, but I'm not holding my breath for 3.4. In any case I've remove the blocker status from this bug and reclassed it as a feature request.


David Bateman <dbateman>
Project MemberIn charge of this item.
Fri 14 Jan 2011 01:57:01 AM UTC, comment #3:

I agree that the gnuplot fix should take precedence since
this is a regression. And, this should be sufficient to
remove the blocker status.

Of course, it would be great if this could work for fltk.
But, it is less important since it is now much easier to overlay
plots with any block of TeX-generated objects.

The fltk implementation will need to be "announced" with
its known limitations. These include (unless David can
do a lot in a short time!!) the TeX interpreter, and the
timing problem with printing that causes failures in scripts
doing many plots or plots though slow interfaces to end up

Even so, the current state (assuming the font problem with
gnuplot TeX interpreter is fixed) is a dramatic improvement
over the current release. Experienced users will, I sure
hope, be really happy.

Michael Godfrey <godfrey>
Project Member
Fri 14 Jan 2011 12:27:05 AM UTC, comment #2:

I marked it as a blocker because if it is completely failing with gnuplot, then people will notice, and I think this is a regression from 3.2, correct?

But I agree that it is not necessary for this feature to work with fltk in 3.4 (though it would be nice if it did :-). So yes, if it is fixed for gnuplot, then remove the blocker status.

John W. Eaton <jwe>
Project Administrator
Thu 13 Jan 2011 11:51:37 PM UTC, comment #1:

For the gnuplot backend the sole issue I see is that when the font is undefined, if you change the font in a string then gnuplot doesn't come back to the old font... I believe this is new to 3.3.x as the text objects now define a fontname and size and didn't previously.. Compare the behavior of

set (gca(0, "fontname", "*")
text(0.5,0.5,'\int_0^x e^(-x) dx','fontsize',20)


set (gca(0, "fontname", "Helvetica")
text(0.5,0.5,'\int_0^x e^(-x) dx','fontsize',20)

in the current tip. A change like

function [f, s, fnt, it, bld] = get_fontname_and_size (t)
if (isempty (t.fontname) || strcmp (t.fontname, "*"))
fnt = "Helvetica";
fnt = t.fontname;

to the start of the get_fontname_and_size function will fix this, but this assumes that the Helvetica font is always available. This was essentially what previous versions (3.0 did but I'm not sure about 3.2) of Octave assumed, but this apparently caused problems for some people.

We need to define a default font in this function, that probably needs to be specific to the platform octave is running on, so I think some discussion is necessary before proposing a fix.

On windows the FLTK assumes that the verdana font is always present. Does this hold for the gnuplot backend? What font is always present on a Mac? Under Linux?

Another way of looking at this issue is that if Octave calls

set label .... font ",20" ....

the fontname is explicitly not set and the default fontname should not be altered as removing the font option above makes the octave code work. So this might be considered a gnuplot bug.

Yes I think that this makes the TeX interpreter unusable in gnuplot and as this feature already exists and works in 3.2.x, it should count as a blocker.

For the FLTK tex interpreter I started working on it, see the thread


I've recently come back to this and am implementing the separation of the parse tree and the rendering as proposed by Michael. So I'll take ownership of this feature request. This part isn't really a blocker for 3.4, so once the gnuplot part is addressed the blocker flag should be removed.


David Bateman <dbateman>
Project MemberIn charge of this item.
Thu 13 Jan 2011 07:53:46 AM UTC, original submission:

Use of 'tex' interpreter appears to be entirely broken.
The substitution of math symbols does not take place
using either backend. The exponent ^ character does
cause exponentiation using gnuplot, but not when
using fltk.

Does this count as a problem for the release?

Michael Godfrey <godfrey>
Project Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by burkart
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by godfrey (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.


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



    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-29 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2012-03-20 burkart Carbon-Copy- => Added burkart
    2011-01-16 dbateman Severity5 - Blocker => 1 - Wish
        Priority5 - Normal => 3 - Low
        Item GroupIncorrect Result => Feature Request
    2011-01-13 dbateman Severity3 - Normal => 5 - Blocker
        StatusNone => In Progress
        Assigned toNone => dbateman

    Back to the top

    Powered by Savane 3.3