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

[Shai Ayal]

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
>
Xianghang, I now compiled it on a Debian system (Virtualization!) with
gcc version 4.3.3 (Debian 4.3.3-7)/GNU Make 3.81 and it also compiles
fine.

What versions of ftlk do you gave installed? For me it's 1.1.9.

when I do a
touch src/DLD-FUNCTIONS/fltk_backend.cc && make
the actual compile commend for fltk_backend is:
g++ -c  -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc
-DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow
-Wold-style-cast -g -O2 -D_THREAD_SAFE -D_REENTRANT
./DLD-FUNCTIONS/fltk_backend.cc -o pic/fltk_backend.o

Shai

p.s. this is OT, but the touch command above trigger the follwing:
1. a re-link of liboctinterp (which is extremely memory intensive)
2. rebuild of all the src/pic modules
3. rebuild of the documents.

I understand step 3, since fltk_backend might contain a docstring whic
has to be incorporated into the texi docs, but why step 1 & 2?