[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #32118] 'Interpreter', 'tex' fails for gnuplot

From: David Bateman
Subject: [Octave-bug-tracker] [bug #32118] 'Interpreter', 'tex' fails for gnuplot and fltk
Date: Thu, 13 Jan 2011 23:51:37 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2009091010 Iceweasel/3.0.14 (Debian-3.0.14-1)

Update of bug #32118 (project octave):

                Severity:              3 - Normal => 5 - Blocker            
                  Status:                    None => In Progress            
             Assigned to:                    None => dbateman               


Follow-up 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

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.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]