Re: GSoC project - LaTeX/TeX

[Michael Goffioul]

On Wed, Jul 10, 2013 at 3:12 PM, Andrej Lojdl <address@hidden> wrote:

So text rendering part should be modified. There should be DISPATCH MECHANISM changing 

renderer depending on interpreter property. 

1. ft_renderer ( default / fixed text renderer )

    Renders text and stores data to pixels value od text_object.

This rendering is happening in text-eng-ft file. After rendering 

is finished  text_object is pushed to opengl_render (who is 

rendering final plot) and use data in pixels value to draw 

image of text on plot. 

2. latex_renderer ( will be picked when interpreter is set to "latex" )

    It push string to TEX file, then converts it to DVI file and so on...

As result of this renderer we will have text_object with image in 

pixels value and already calculated bounding box. Then it just should

be pushed to OpenGL trough draw_text method. 

Latex rendering is needed for text and axes so maybe is best 

to integrate this dispatch mechanism into graphics.cc . As I see it 

if there is freetype library text_renderer is defined. So if interpreter 

is set to "latex" it should be using latex render. All methods working 

with ft_renderer wont be needed. 

Am I developing this plan in right direction? 

I think it's obvious that there should be a common abstract class on top of ft_renderer and latex_renderer providing the text rendering API. A common pattern that is used throughout octave is to have a base abstract class, a set of concrete inherited classes and a top-level wrapper class that holds a "rep" pointer to the actual object (and is responsible for efficient memory management).

The biggest example is octave_value/octave_base_value and all the classes derived from octave_base_value, though that example might be a bit complex. I suggest you have a read through the octave_mutex/octave_base_mutex and graphics_event/base_graphics_event examples.

Michael.