octave-maintainers
[Top][All Lists]
Advanced

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

Re: Text properties and FTGL


From: Shai Ayal
Subject: Re: Text properties and FTGL
Date: Tue, 28 Oct 2008 20:06:13 +0200

On Tue, Oct 28, 2008 at 7:44 PM, John W. Eaton <address@hidden> wrote:
> On 28-Oct-2008, John Swensen wrote:
>
> |
> | On Oct 26, 2008, at 12:31 AM, Shai Ayal wrote:
> |
> | >
> | > 2. How to make it generic enough that in the future we can incorporate
> | > some TeX parsing
> |
> | Do you have any ideas on how to do the TeX parsing?  Do you intend to
> | develop your own renderer, or use existing tools like pdflatex?  I
> | messed around for a few hours last night with the following sequence
> | of events:
> |
> | 1) Run an equation string through pdflatex
> | 2) Read in the resulting pdf with the poppler library
> | 3) Render the pdf onto a cairo graphics context.
> | (this is how it is done in the little utility pdf2svg except they
> | write the graphics context to an SVG file with a cairo SVG context
> | instead of displaying it to the screen.)
> |
> | I found a library that allows you to render onto a cairo context and
> | then copy the cairo surface into an OpenGL texture and then draw it.
> | I couldn't this to work in conjunction with steps (1)-(3).  I can run
> | the examples from http://www.cairographics.org/OpenGL/ and I can draw
> | to a simple cairo based GTK widget, but I can't seem to get the two to
> | work together.
> |
> | Is there some other easier way of rendering LaTeX equations to OpenGL?
>
> You might also look at the way the Emacs preview-latex mode works.
> That doesn't rely on any special toolkit or widget (other than Emacs
> ability to embed images in an Emacs buffer).  So we should be able to
> do this in a reasonably portable way.  I would not want to link it too
> closely to a particular toolkit or widget.

I agree with not want to link it too closely to a particular toolkit
or widget. We also have to remember that we need for it to work both
on-screen (e.g. opengl) and off screen (probably postscript). That's
why I thought writing our own simple TeX parser (e.g. support greek,
super & sub) would be best.
My objection to using TeX to render is that we would get a bitmap back
(I'm sure there is some way get a bitmap from TeX w/o resorting to a
TeX->pdf->bitmap) which would look good on screen, but really bad on a
printer.

All that being said, I haven't contributed anything in months, and I
don't see this changing soon, all I can manage is reading and
answering on this list

Shai


reply via email to

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