Re: TeX interpreter for FLTK backend

[Michael Goffioul]

Well, the point was not that much about speed, but about flexibility
re-usability and extendability. Personally, I think separating the parsing
from the processing is cleaner. I don't see how merging both will help
in solving the problem you mentioned about the sub-/superscript, as
you're actually doing the same actions: parsing and processing. To
solve the problem, you'll have to keep track of a state, something you
can also do in a processor.

Technically, you could also write a compiler without having an intermediate
tree, but that would make the implementation much less flexible.

Anyway, I'm not gonna implement it myself, so it's up to you to decide
how you want to do it. If you're going with your solution, then I guess
txt-eng.h file could be largely cleaned up, as it would contains a bunch
of useless class definitions.

Michael.


On Mon, Nov 15, 2010 at 10:48 PM, David Bateman <address@hidden> wrote:
> 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.
>
>