[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:1.9.0.14) 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)
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/