[Top][All Lists]

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

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

From: xianghang liu
Subject: Re: units conversion (was: about contibuting to octave)
Date: Sat, 28 Mar 2009 15:31:34 +0800

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


> 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?

Xianghang Liu

reply via email to

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