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: Fri, 27 Mar 2009 13:29:53 +0300

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
>



reply via email to

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