Re: GSoC project - LaTeX/TeX

[Andrej Lojdl]

2013/7/10 Michael Goffioul <address@hidden>

On Tue, Jul 9, 2013 at 1:19 PM, Andrej Lojdl <address@hidden> wrote:

2013/6/28 Ben Abbott <address@hidden>

On Jun 27, 2013, at 05:53 PM, Andrej Lojdl <address@hidden> wrote:

For converting we can use many different programs proposed by Ben. And I want to thank him for his help. But more or less they are 

same as this combination. If some of them have any new functionality, it needs additional dependencies. I will mention them here if

accidentally missed a good functionality. 

- textogif       [http://www.fourmilab.ch/webtools/textogif/]

- tex2im        [http://www.nought.de/tex2im.html]

- tex2image   [http://dean.serenevy.net/code/projects/tex2image]

 

My understanding is that all of these work in a similar manner to your solution.

  latex default.tex

  dvips default.dvi -o -E default.eps

  convert +adjoin -antialias -transparent $transparentcolor -density $resolution [...] default.eps default.png

Convert includes many options that are either needed or are useful for full Matlab compatibility. 

  -border geometry     surround image with a border of color

  -bordercolor color   border color

  -background color    background color

  -transparent-color color

  -density geometry    horizontal and vertical density of the image

Ghostscript provides for dual resolution (-rnumber1xnumber2), and its pngalpha driver allows the background color to be specified, but I don't think it can handle the border color, linewidth, etc.

Ben 

I didn't post on maintainers list for quite time now. And there are some problems

with my project so maybe it's best to ask here. I believe there are others interested 

in this project and maybe can help me. For more information on how my project is

progressing take a look at http://latexmarkup.blogspot.com/ .

So there are programs for reading string, transforming it to TEX file, then trough 

some additional programs finally to PNG image. Information about bounding box 

can be read from EPS file, and so on...

Next step is to implement this functions directly to Octave source code, and here my 

problems start. Here are methods of interest for this part of project:

- text::properties::update_text_extent - computes bounding box and use use text_to_pixels

method for further processing 

- opengl_renderer::text_to_pixels ( and generaly others text_to_pixels) - transform the

input text to image and store it under pixels value 

- opengl_renderer::draw_text - use pixels value from text objects and sends it to OpenGL

( glps_renderer::draw_text - does something similar but for printing and currently I'm focused 

to on screen rendering )

If I understood how OpenGL functions work, this method use glBitmap to place bitmap image on plot 

and glDrawPixels to write a image to this placeholder on final plot. 

Now when here is small overview what's happening, here are the questions bugging my:

    

    1. When user set interpreter parameter to "latex", all text should be rendered trough LaTeX,

so there should be some code doing this ( there already exist code but it's just a proof of model

outside Octave code ) and that text will never use ft_renderer ( freetype library ). Where should

this code by implemented?

The "interpreter" property is defined at the text object level. So there's a need for some dispatch mechanism (or abstraction layer) to use the right text renderer, depending on the value of interpreter property. At the moment, the text object uses a fixed ft_render member, but this will have to be changed. Just think a bit about it and come back with a draft plan we can discuss about.

 

    2. Should there be some entry point looking at interpreter value and directing rendering of 

text to LaTeX system if needed?

See answer above.

 

    3. Octave computes bounding box, but with LaTeX we can get bounding box from EPS file.

So this value extracted from EPS file should just be stored to bounding box in text::properties::

update_text_extent ?

Yes. Computing the bbox will be part of the rendering process.

  

    4. How to store rendered image to pixels value in opengl_renderer::text_to_pixels method?

AFAIK this method is only used to render tickmark texts. And there's no need to have LaTeX support for those (not 100% sure, though). At the moment, the rasterized version of tickmark texts is not cached.

Michael.

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? 

--

Andrej