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

 Submitted by: Michael 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 Originator Name: godfrey Open/Closed: Closed Release: dev Operating System: GNU/Linux

Add a New Comment (Rich Markup):

## You are not logged in

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>
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.

D.

David Bateman <dbateman>
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
crashing.

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>
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>
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)

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

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.

David Bateman <dbateman>
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>

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

Attach File(s):

Comment:

No files currently attached

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -unavailable- added by rik5 (Posted a comment)
• -unavailable- added by jwe (Posted a comment)
• -unavailable- added by dbateman (Posted a comment)
• -unavailable- added by godfrey (Submitted the item)
•

Do you think this task is very important?
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):

Date Changed By Updated Field Previous Value => Replaced By
Thu 29 Aug 2013 08:10:19 PM UTCrik5StatusIn ProgressFixed
Open/ClosedOpenClosed
Tue 20 Mar 2012 03:11:30 PM UTCburkartCarbon-Copy-Added burkart
Sun 16 Jan 2011 09:46:37 PM UTCdbatemanSeverity5 - Blocker1 - Wish
Priority5 - Normal3 - Low
Item GroupIncorrect ResultFeature Request
Thu 13 Jan 2011 11:51:37 PM UTCdbatemanSeverity3 - Normal5 - Blocker
StatusNoneIn Progress
Assigned toNonedbateman