octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Shai Ayal
Subject: Re: units conversion (was: about contibuting to octave)
Date: Thu, 9 Apr 2009 10:49:52 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]