Re: TeX interpreter for FLTK backend

[David Bateman]

Michael Goffioul wrote:
> 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.
>>
>>     
>
>   
Michael,

I didn't realize that you implemented this in the jhandles backend.

I've thought about this in the last couple of days and it really seems a
bit like overkill, as the parse tree itself is going to be much larger
than the original text, and the savings in time by saving parsed the
text in advance don't seem to be significant. If you want to get a speed
up its probably better to cache the rendered text rather than the parse
tree. Also the parse tree also doesn't handle well the kerning between
characters. A nasty case of that which I complained about is a
superscript over a subscript, for example "x_0^iy". The spacing of the
characters in the x direction should be handled something like

- xpos = 0
- Set normal font style
- Render "x"
- xpos += extent of rendered character "x"
- xmark = Mark current xpos position
- Set subscript font style
- Calculate kerning between "x" and subscript "0"
- xpos += kerning
- Render subscripted "0"
- xpos += extent of rendered subscripted "0"
- Set normal font style
- Calculate the kerning between subscripted "0" and "y"
- xmax = xpos + kerning
- Set xpos = xmark
- Set superscript font style
- Calculate kerning between "x" and superscript "i"
- xpos += kerning
- Render superscripted "i"
- xpos += extent of the rendered superscripted "i"
- Set normal font style
- Calculate kerning between superscripted "i" and "y"
- xpos = max (xmax, xpos + kerning)
- Render "y"

I don't see how this is easily compatible with a parse tree model of the
string and it seems better to me to just treat the parsing of the string
in the renderer. So that the renderer has access to all of the previous
characters to be able to correctly calculate the kerning.

I suppose it makes sense to have several renderers however to inherit
methods between renderers, while keeping the individual renderers clean.

D.