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

[David Bateman]

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)

against

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";
  else
    fnt = t.fontname;
  endif

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

http://octave.1599824.n4.nabble.com/TeX-interpreter-for-FLTK-backend-td3038693.html

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.

D.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?32118>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/