On Fri, Apr 10, 2009 at 6:20 AM, xianghang liu <
address@hidden> wrote:
>
>
> On Fri, Apr 10, 2009 at 3:45 AM, Shai Ayal <
address@hidden> wrote:
>>
>> 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.
>> it compiles fine for me on fedora 8 with gcc 4.1.2
>> I attach the output of the configure script on this machine below:
>> Maybe try a
>> make clean && ./configure && make
>>
>> Octave is now configured for i686-pc-linux-gnu
>>
>> Source directory: .
>> Installation prefix: /usr/local
>> C compiler: gcc -mieee-fp -Wall -W -Wshadow -g -O2
>> C++ compiler: g++ -mieee-fp -I/usr/include/freetype2 -Wall
>> -W -Wshadow -Wold-style-cast -g -O2
>> Fortran compiler: gfortran -O -mieee-fp
>> Fortran libraries: -L/usr/lib/gcc/i386-redhat-linux/4.1.2
>> -L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. -lhdf5 -lz
>> -lgfortranbegin -lgfortran -lm
>> BLAS libraries: -llapack -lblas
>> FFTW libraries: -lfftw3 -lfftw3f
>> GLPK libraries: -lglpk
>> UMFPACK libraries: -lumfpack
>> AMD libraries: -lamd
>> CAMD libraries: -lcamd
>> COLAMD libraries: -lcolamd
>> CCOLAMD libraries: -lccolamd
>> CHOLMOD libraries: -lcholmod
>> CXSPARSE libraries: -lcxsparse
>> ARPACK libraries:
>> QRUPDATE libraries:
>> HDF5 libraries: -lhdf5
>> CURL libraries: -lcurl
>> REGEX libraries: -lpcre
>> QHULL libraries: -lqhull
>> OPENGL libraries: -L/usr/X11R6/lib -lGL -lGLU -lfreetype -lftgl
>> FLTK backend libs: -lfltk_gl -lGLU -lGL -lfltk
>> X11 include flags:
>> X11 libraries: -lX11
>> CARBON libraries:
>> LIBS: -lreadline -lncurses -ldl -lblas -lhdf5 -lz -lm
>> Default pager: less
>> gnuplot: gnuplot
>> Magick config:
>>
>> Do internal array bounds checking: false
>> Build static libraries: false
>> Build shared libraries: true
>> Dynamic Linking: true (dlopen)
>> Include support for GNU readline: true
>> 64-bit array dims and indexing: false
>>
>> configure: WARNING: qrupdate not found. The QR & Cholesky updating
>> functions will be slow.
>> configure: WARNING: arpack not found. This will result in a lack of
>> the eigs function.
>> configure: WARNING: GraphicsMagick++ config script not found.
>> Assuming GraphicsMagic++ library and header files are missing, so
>> imread will not be fully functional
>> configure:
>>
>> NOTE: libraries may be skipped if a library is not found OR
>> if the library on your system is missing required features.
>
>
> Thanks a lot for your help.
> All modules compiles well except "fltk_backend.oct" on my system.
> When I build fltk_backend.o with 'make fltk_backend.o', it execute the
> command
> 'g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc
> -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2
> -I/usr/local/include -I/usr/local/include/FL/images -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT
> ./DLD-FUNCTIONS/fltk_backend.cc -o pic/fltk_backend.o'
> and failed.
> But after I delete the argument -DHAVE_CONFIG_H it will success and the
> fltk_backend.oct will be built. But when I execute 'backend("fltk")' in
> Octave command line, I get an error "error: feval: function `__init_fltk__'
> not found". When I entered '__init<TAB>' __init_fltk__ can be found. But an
> error is got "error: `__init_fltk__' undefined near line 1 column 1" when I
> execute it.
>
> Thanks
> --
> Xianghang Liu
>