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: PlottingSeverity: 1 - Wish
Priority: 3 - LowItem Group: Feature Request
Status: FixedAssigned to: David Bateman <dbateman>
Originator Name: godfreyOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich 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

http://hg.savannah.gnu.org/hgweb/octave/rev/beb4f0f27a32

As for the fltk TeX interpreter, the code at

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

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

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.

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>

 

(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 burkart
  • -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?
    If so, you can click here to 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
    Thu 29 Aug 2013 08:10:19 PM UTCrik5StatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Tue 20 Mar 2012 03:11:30 PM UTCburkartCarbon-Copy-=>Added burkart
    Sun 16 Jan 2011 09:46:37 PM UTCdbatemanSeverity5 - Blocker=>1 - Wish
      Priority5 - Normal=>3 - Low
      Item GroupIncorrect Result=>Feature Request
    Thu 13 Jan 2011 11:51:37 PM UTCdbatemanSeverity3 - Normal=>5 - Blocker
      StatusNone=>In Progress
      Assigned toNone=>dbateman

    Back to the top


    Powered by Savane 3.1-cleanup