On Thu, Apr 9, 2009 at 10:57 AM, xianghang liu <
address@hidden> wrote:
>
>
> On Thu, Apr 9, 2009 at 3:49 PM, Shai Ayal <
address@hidden> wrote:
>>
>> On Thu, Apr 9, 2009 at 6:39 AM, xianghang liu <
address@hidden>
>> wrote:
>> >
>> >
>> > On Thu, Apr 9, 2009 at 11:11 AM, xianghang liu <
address@hidden>
>> > wrote:
>> >>
>> >>
>> >> On Sat, Mar 28, 2009 at 3:38 PM, Shai Ayal <
address@hidden> wrote:
>> >>>
>> >>> 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
>> >>
>> > I have some problems in compiling the 'fltk_backend.oct ' in the release
>> > code of ocatve-3.1.55. I just follow the compile instructions on the
>> > wikisite of octave.
>> > The error information is attached. Would you please have a look at it?
>> > Thanks a lot.
>>
>> On what platform are you compiling?
>> I'll try to recreate on debian
>>
>> Shai
>
> My system is Ubuntu 8.04 / GNU Make 3.81 / gcc 4.2.4.
> Thanks.