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.