Re: TeX interpreter for FLTK backend

[Michael Goffioul]

Hi David,

It's great that you work on this. However it looks like you put the parsing
code directly into the FT renderer, which was not my initial idea. For reference
you can have a look the way I implemented it in jhandles
(http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/src/org/octave/graphics/SimpleTextEngine.java?revision=HEAD&view=markup).

The idea was to separate the text parsing from the text processing. So you
would have text_parser inherited classes that break down a string into a list
of components, and a set of processors that perform actions on the list of
components.

In the initial implementation, I only provided one text parser
(text_parser_none)
that doesn't do any parsing and one text processor (ft_render) to render the
text with FreeType. But the idea was to enhance this at a later stage with
Matlab-like pseudo-TeX parsing. For instance you can see in txt-eng.h that
I already defined a couple of component classes for sub- and super-script
or a list of elements.

In practice, a string like "x_{a_2}" would be broken down into:
text_element_list:
  text_element_string: x
  text_superscript_element
    text_element_string: a
    text_subscript_element:
      text_element_string: 2

Michael.


On Thu, Nov 11, 2010 at 10:03 PM, David Bateman <address@hidden> wrote:
> One of the last missing features of the FLTK backend that makes me want
> to stick with the gnuplot backend, is that when the "interpreter"
> property is set to "tex", a simple interpreter for symbols, subscripts,
> superscripts, etc allows for simple equations to be used in plots. The
> attached changeset is a first attempt at adding this feature to the FLTK
> backend. The only sub-feature I think is missing is that something like
>
> text (0,0, "{\fontsize{32}\int_{\fontsize{16}0}^{\fontsize{16}x}}")
>
> is supposed to have the x above the 0 and it doesn't yet. Though I'm not
> quite sure of the best way of implementing this.
>
> Also I'd prefer that the "face_stacked_elem" class and the variable
> "lst" of type std::list<face_stacked_elem> was in the ft_render class,
> though when I do that I get a segfault I can't trackdown. The code could
> also perhaps be simplified in other ways and I'd be happy to hear any
> ideas, bugs that you've found, a way of getting the stack into the
> ft_render class, etc before I push this as a changeset
>
> Enjoy
> David
>
> PS : The feature that this changeset adds to the FLTK backend appears to
> be broken in the gnuplot backend in the development sources for my test
> cases. I'll look at fixing it soon.
>