Re: units conversion (was: about contibuting to octave)

[Shai Ayal]

On Sat, Mar 28, 2009 at 10:31 AM, xianghang liu <address@hidden> wrote:
>
>
> On Fri, Mar 27, 2009 at 6:29 PM, Shai Ayal <address@hidden> wrote:
>>
>> On Thu, Mar 26, 2009 at 12:30 PM, xianghang liu <address@hidden>
>> wrote:
>> >
>> >
>> > On Sat, Mar 14, 2009 at 4:44 AM, John W. Eaton <address@hidden> wrote:
>> >>
>> >> On 13-Mar-2009, Shai Ayal wrote:
>> >>
>> >> | Your code, if I understand correctly, uses pdfLaTeX to render the
>> >> | string. While this seems the ultimate solution (pdfLaTeX is a very
>> >> | good LaTeX renderer), it poses a bit of a problem in the context of
>> >> | the whole octave/backend paradigm:
>> >> | 1 If we put this code in the backend, than octave cannot compute text
>> >> extents.
>> >> | 2 If we put this code in octave, than we have rendering in octave --
>> >> | i.e. octave will produce bitmaps
>> >> |
>> >> | maybe we should just go with the second choice and let octave produce
>> >> | bitmaps for text objects with renderer=LaTeX
>> >> |
>> >> | Another choice could be to split the text renderer from the general
>> >> | renderer, so we would have 2 types of backends: a graphics backend
>> >> and
>> >> | a text backend, where the text backend would produce extents for
>> >> | octave and bitmaps for the graphics backend
>> >>
>> >> We might want to borrow something from matplotlib, which currently has
>> >> a simplified TeX equation parser that uses the actual TeX algorithm
>> >> for glyph placement.  See the file
>> >>
>> >>
>> >>
>> >>  
>> >> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/mathtext.py
>> >>
>> >> As I understand it, they also allow full (pdf?)latex parsing so that
>> >> you can embed arbitrarily complex TeX blobs in the graphs if that's
>> >> what you want to do.
>> >>
>> >> I also see that matplotlib comes with its own set of font metric files
>> >> and some .ttf font files.
>> >>
>> >> jwe
>> >
>> > I have attached the code that calculate the bounding box of a text
>> > object
>> > with FreeType2 API. It can parse simple TeX strings and is borrowed from
>> > the
>> > Java code of Micheal in jhandles.
>>
>> It looks very impressive. I managed to compile it on debian, but the
>> tga files it produced were all totally black, so I cannot comment on
>> the output.
>>
>> > 1. Shall we implement a TeX parser as the parser in matplot?
>> >     If so, we might need to use tools such as yacc.
>> > 2. Shall we implement the mapping from font properties(name, italic,...)
>> > to
>> > the path of fontfile on different platforms as FontManager in matplot?
>> > In my opinion this might be necessary.
>>
>> I think that while the two above features would be very good to
>> implement, maybe first you try to integrate this into octave core and
>> the opengl-renderer? This way you could gain some knowledge of the
>> internals of octave that might also make adding the above features
>> easier.
>>
>> Shai
>>
>>
>>
>> > Xianghang Liu
>> >
>
> I will try to integrate the code into octave as soon as possible. After a
> rough glance I think the code in graphics.h/cc, gl_render.h/cc,
> fltk_backend.cc is relevant to my task currently. Do I miss anything
> important?

A few things to help you along the way:
all of the octave-core graphics is in the files:
src/graphics.cc
src/graphics.h.in
src/genrops.awk

where genprops.awk converts graphics.h.in to graphics.h

the gl-render.{h,cc} has all the opengl rendering stuff

the fltk backend is just the decorations. I'm not sure you need to do
anything with it

I guess most of your work would be in graphics.cc to calculate the
bounding box , and in gl_render.cc to render.

Shai