bugGNU Octave - Bugs: bug #32118, 'Interpreter','tex' fails for...

 
 

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

Submitter:  Michael Godfrey <godfrey>
Submitted:  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:  dbateman
Originator Name:  godfrey Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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


set label "{/Symbol \\362}@_0^x e^{-x} dx" at  0.5,0.5 left rotate by 0.000000 offset character -0.000000,0.000000 font ",20" enhanced front textcolor rgb "#000000";


where the


... font ",20" ...


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


... font ",20" ...


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


... font "{},20" ...


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>
Group Member
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>
Group Member
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>
Group 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>
Group Member
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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-29 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2012-03-20 burkart Carbon-Copy- Added burkart
    2011-01-16 dbateman Severity5 - Blocker 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupIncorrect Result Feature Request
    2011-01-13 dbateman Severity3 - Normal 5 - Blocker
        StatusNone In Progress
        Assigned toNone dbateman

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code