Text properties and FTGL

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Text properties and FTGL

John Swensen
So I have been messing around with FTGL today and it looks quite easy  
to use.  I was able to get the xlabel, ylabel, and zlabel working  
(kindof!) and have a few questions and comments.

Comments
FTGL is very easy to use.  I used their simple little singleton class  
example from the web page for getting fonts back to octave and then  
did a simple render of the label property in label sections of the  
opengl_renderer::draw() function in gl-render.cc.  I used the  
FTTextureFont, since it appears that it is the only one that is anti-
aliased and allows difference colors.

Problems
1) At first, I was trying the following command to draw a sample plot  
and xlabel:
t=-pi:0.1:pi; plot(t,sin(t),'ro','LineWidth',2);  
xlabel('asdfASDFQWERqwerZXCVzxcvasdfASDF');
The text was showing up very, very large even for a fontsize of 12  
points with a 72 points per inch resolution.  When I tried to reduce  
the fontsize down below a out 5, the text simply disappeared and even  
at 6 it was huge.  Not even the first letter 'a' was visible in its  
entirety on the screen.  I was quite confused.
Then, I tried the following command for plotting:
t = -100:100; plot(t,100*sin(t),'r');  
xlabel('asdfASDFqwerQWERzxcvZXCV');
With this command, the text looked much more reasonably sized so I cam  
to the conclusion that the OpenGL render method is really plotting at  
the size of the signal values, rather than scaling up to some sort of  
default size.  I think we need to scale up the plots so that 12 points  
in text with a 72 ppi screen is really 12 points.
(BIG CAVEAT: I know next to nothing about OpenGL, so I am not a lot of  
help when having to do low level OpenGL stuff.)

Also, I searched around on the internet a bit about fonts in OpenGL  
and it seems that FTGL using Freetype is in fact the "best" option out  
there.  However, it seemed that there is a general consensus that  
OpenGL doesn't do small font sizes well.  Things start to get fuzzy  
and then disappear (just like I was seeing when I thought just  
shrinking the fontsize property would fix things).  Since I don't know  
OpenGL I can' t appreciate why this happens, but I think that scaling  
the plots to match the text size should work, since I don't know of  
many situations where a font size smaller than 6 pt is necessary anyway.

I guess I don't think a patch would be in order right now since the  
labels aren't very useful when their size changes relative to the plot  
at hand.

2) The position property is not working for the xlabel position  
property.  I guess maybe this is expected behavior.  I don't know if  
Matlab allows you to update the label positions after they have been  
drawn or not.

I'll let you know when I have more figured out.

John Swensen


Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Shai Ayal-2
On Sun, Oct 26, 2008 at 4:06 AM, John Swensen <[hidden email]> wrote:

> So I have been messing around with FTGL today and it looks quite easy to
> use.  I was able to get the xlabel, ylabel, and zlabel working (kindof!) and
> have a few questions and comments.
>
> Comments
> FTGL is very easy to use.  I used their simple little singleton class
> example from the web page for getting fonts back to octave and then did a
> simple render of the label property in label sections of the
> opengl_renderer::draw() function in gl-render.cc.  I used the FTTextureFont,
> since it appears that it is the only one that is anti-aliased and allows
> difference colors.
>
> Problems
> 1) At first, I was trying the following command to draw a sample plot and
> xlabel:
> t=-pi:0.1:pi; plot(t,sin(t),'ro','LineWidth',2);
> xlabel('asdfASDFQWERqwerZXCVzxcvasdfASDF');
> The text was showing up very, very large even for a fontsize of 12 points
> with a 72 points per inch resolution.  When I tried to reduce the fontsize
> down below a out 5, the text simply disappeared and even at 6 it was huge.
>  Not even the first letter 'a' was visible in its entirety on the screen.  I
> was quite confused.
> Then, I tried the following command for plotting:
> t = -100:100; plot(t,100*sin(t),'r'); xlabel('asdfASDFqwerQWERzxcvZXCV');
> With this command, the text looked much more reasonably sized so I cam to
> the conclusion that the OpenGL render method is really plotting at the size
> of the signal values, rather than scaling up to some sort of default size.
>  I think we need to scale up the plots so that 12 points in text with a 72
> ppi screen is really 12 points.
> (BIG CAVEAT: I know next to nothing about OpenGL, so I am not a lot of help
> when having to do low level OpenGL stuff.)

You are right. For the way I did it in octplot, complete with
rotations and alignemnts, have a look at:
http://octplot.svn.sourceforge.net/viewvc/octplot/trunk/octplot/src/text.cpp?revision=468&view=markup
lines 182-218. Note line 208 which scales everything so that one unit
equals one pixel.

My main problem with implementing text in gl-render was not the actual
rendering -- as you say it is not very hard, but rather the problems
surrounding text:
1. Which fonts?
2. How to make it generic enough that in the future we can incorporate
some TeX parsing
3. How to report back to octave the size of the rendered text --
needed e.g. to determine the number of ticks
All of these (and maybe more) need to be determined before we even get
to the actual rendering, which , as you can see, is already almost
done in octplot -- just need to copy it.

> Also, I searched around on the internet a bit about fonts in OpenGL and it
> seems that FTGL using Freetype is in fact the "best" option out there.
>  However, it seemed that there is a general consensus that OpenGL doesn't do
> small font sizes well.  Things start to get fuzzy and then disappear (just
> like I was seeing when I thought just shrinking the fontsize property would
> fix things).  Since I don't know OpenGL I can' t appreciate why this
> happens, but I think that scaling the plots to match the text size should
> work, since I don't know of many situations where a font size smaller than 6
> pt is necessary anyway.

I think you are correct -- the problem Is twofold
1. freetype can't render small sizes as well as the font designers
intended since this portion of the truetype "standard" is patented
http://freetype.sourceforge.net/patents.html
2. OpenGL itself is based on single precision floating point, so you
can run into it's accuracy problems quite easily

However, I think this is not so much a problem since small fonts in
hardcopy which will hopefully be postscript, will look good.
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John Swensen

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?

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
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.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Shai Ayal-2
On Tue, Oct 28, 2008 at 7:44 PM, John W. Eaton <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
On 28-Oct-2008, Shai Ayal wrote:

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

Why would it have to be a bitmap?  If we use scalable fonts, tex+dvips
or pdftex should be able to produce a postscript or pdf file that is
scalable.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Shai Ayal-2
On Tue, Oct 28, 2008 at 8:14 PM, John W. Eaton <[hidden email]> wrote:

> On 28-Oct-2008, Shai Ayal wrote:
>
> | 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.
>
> Why would it have to be a bitmap?  If we use scalable fonts, tex+dvips
> or pdftex should be able to produce a postscript or pdf file that is
> scalable.
>
> jwe

Sounds good, but I don't really know anything about these - I use &
love LaTeX/TeX, but never delved into the details. Some issues:
1) this would be a time-consuming process, so we'd probably have to
set up some caching for the bitmaps
2) You have the whole TeX distro as a run-time dependency -
problematic for windows machines (and maybe macs also)

Shai
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Søren Hauberg
In reply to this post by John W. Eaton-6
tir, 28 10 2008 kl. 13:44 -0400, skrev John W. Eaton:
> I would not want to link it too
> closely to a particular toolkit or widget.

Would that really be that terrible? I mean, isn't it better to have
something that works with Cairo, than not having anything at all. Also,
Cairo isn't that tied to other high level toolkits. You can use it with
most (all?) high-level toolkits such as GTK and QT.

Søren

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
In reply to this post by Shai Ayal-2
On 28-Oct-2008, Shai Ayal wrote:

| 2) You have the whole TeX distro as a run-time dependency -
| problematic for windows machines (and maybe macs also)

We should not let the shortcomings of a proprietary operating system
dictate what is the best way to do something in Octave.  Remember the
GNU part of GNU Octave?  Part of the goal of the Octave project is to
promote free software.  So is it a bad thing if you have to use a free
system for everything to be easy to install and for all of the
features to work properly?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
In reply to this post by Søren Hauberg
On 28-Oct-2008, Søren Hauberg wrote:

| tir, 28 10 2008 kl. 13:44 -0400, skrev John W. Eaton:
| > I would not want to link it too
| > closely to a particular toolkit or widget.
|
| Would that really be that terrible? I mean, isn't it better to have
| something that works with Cairo, than not having anything at all. Also,
| Cairo isn't that tied to other high level toolkits. You can use it with
| most (all?) high-level toolkits such as GTK and QT.

My point was just to caution against making the link to a particular
toolkit in such a way that it would be difficult to switch later.  I
know very little about Cairo specifically, so I don't know whether it
would be a good choice.  What would it be used for?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

bpabbott
Administrator
In reply to this post by Shai Ayal-2

On Tuesday, October 28, 2008, at 02:31PM, "Shai Ayal" <[hidden email]> wrote:

>On Tue, Oct 28, 2008 at 8:14 PM, John W. Eaton <[hidden email]> wrote:
>> On 28-Oct-2008, Shai Ayal wrote:
>>
>> | 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.
>>
>> Why would it have to be a bitmap?  If we use scalable fonts, tex+dvips
>> or pdftex should be able to produce a postscript or pdf file that is
>> scalable.
>>
>> jwe
>
>Sounds good, but I don't really know anything about these - I use &
>love LaTeX/TeX, but never delved into the details. Some issues:
>1) this would be a time-consuming process, so we'd probably have to
>set up some caching for the bitmaps
>2) You have the whole TeX distro as a run-time dependency -
>problematic for windows machines (and maybe macs also)
>
>Shai
>

Requiring TeX/LaTeX isn't much of a problem for Macs. The package managers Fink and DarwinPorts each have TeX/LaTeX packages.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John Swensen
In reply to this post by John W. Eaton-6

On Oct 28, 2008, at 1:44 PM, John W. Eaton wrote:
>
>
> 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.
>
> jwe

I downloaded the source code for preview latex and skimmed through  
their documentation and it looks like they do essentially a similar  
thing.  They run the latex code through one of the many TeX variants  
(depending on configuration) and then draw it directly into the  
buffer.  I'm not sure exactly how they draw it into the buffer, but  
that part is really the hangup for us.  Also, theirs also takes a bit  
of time and works in the background.

So, even though I should not be considered an expert on this, I think  
the following might be the way to go:

1) Use tex/latex/pdflatex to convert from an equation string to a dvi/
ps/pdf
2) Find a less platform/toolkit specific method of converting from pdf  
to a OpenGL texture
3) Draw the texture as one would expect
Since even poppler isn't dependent on a particular toolkit (it is in  
fact derived from the Xpdf codebase) maybe it will be as simple as  
make a new output device for poppler which renders to OpenGL.  It  
already renders to a GDK pixbuf and a QT QPixMap.  That being said, I  
once again iterate that I know very little about OpenGL and exactly  
how hard that might be.  Can an openGL texture kindof be treated as a  
pixel buffer?  If so, maybe the little extra won't be too hard?

There was an alternate route that I started to go down at the start of  
this and it was
1) .tex to .ps
2) Use pstoedit to convert to an SVG
3) Tried to get a library called svgl (intended for use from python,  
but since it is a C++ compiled extension it might be easy to  
incorporate) to render the output to OpenGL.
I had problems with this method also, as pstoedit didn't seem to  
render equations to SVG properly.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Shai Ayal-2
In reply to this post by John W. Eaton-6
On Tue, Oct 28, 2008 at 8:55 PM, John W. Eaton <[hidden email]> wrote:

> On 28-Oct-2008, Søren Hauberg wrote:
>
> | tir, 28 10 2008 kl. 13:44 -0400, skrev John W. Eaton:
> | > I would not want to link it too
> | > closely to a particular toolkit or widget.
> |
> | Would that really be that terrible? I mean, isn't it better to have
> | something that works with Cairo, than not having anything at all. Also,
> | Cairo isn't that tied to other high level toolkits. You can use it with
> | most (all?) high-level toolkits such as GTK and QT.
>
> My point was just to caution against making the link to a particular
> toolkit in such a way that it would be difficult to switch later.  I
> know very little about Cairo specifically, so I don't know whether it
> would be a good choice.  What would it be used for?
>
I'm not exactly sure, but I think using our current fltk_backend
analogy, cairo would be a replacement for OpenGL, not fltk since cairo
itself is just a canvas -- it has no widgets etc... Cairo is great for
2D -- much better than OpenGL IMHO, but has no support for 3D, which
is a bit problematic ....

Shai

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Thomas Weber-8
In reply to this post by John W. Eaton-6
On Tue, Oct 28, 2008 at 02:41:44PM -0400, John W. Eaton wrote:

> On 28-Oct-2008, Shai Ayal wrote:
>
> | 2) You have the whole TeX distro as a run-time dependency -
> | problematic for windows machines (and maybe macs also)
>
> We should not let the shortcomings of a proprietary operating system
> dictate what is the best way to do something in Octave.  Remember the
> GNU part of GNU Octave?  Part of the goal of the Octave project is to
> promote free software.  So is it a bad thing if you have to use a free
> system for everything to be easy to install and for all of the
> features to work properly?

Eh, adding TeX as dependency would be the end to all kind of usage
pattern:
- using it on small machines (someone posted once about using Octave as
  some kind of portable calculator on a handheld or whatever)
- compiling at least the basic ingredients yourself (TeXLive comes in at
  150 MB, MikTeX's basic installer has something about 80 MB).

Seriously, we can probably add GTK, QT and wxWidgets and still have a
smaller footprint. I mean, 80+MB for rendering a few symbols?

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Jordi Gutiérrez Hermoso
2008/10/28 Thomas Weber <[hidden email]>:
> Eh, adding TeX as dependency would be the end to all kind of usage
> pattern:

Well, it wouldn't have to be a hard dependency. Make it a compile-time
option.  That seems to be the approach for many other of the larger
components of Octave. TeX is a standard part of a GNU system anyways.

> using it on small machines

A handheld calculator doesn't really need to produce
publication-quality plots anyways, does it?

Also, I expect most people who use Octave already use LaTeX or TeX. Or
am I being naïve?

- Jordi G. H.

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John Swensen

On Oct 28, 2008, at 10:23 PM, Jordi Gutiérrez Hermoso wrote:

> 2008/10/28 Thomas Weber <[hidden email]>:
>> Eh, adding TeX as dependency would be the end to all kind of usage
>> pattern:
>
> Well, it wouldn't have to be a hard dependency. Make it a compile-time
> option.  That seems to be the approach for many other of the larger
> components of Octave. TeX is a standard part of a GNU system anyways.
>
>> using it on small machines
>
> A handheld calculator doesn't really need to produce
> publication-quality plots anyways, does it?
>
> Also, I expect most people who use Octave already use LaTeX or TeX. Or
> am I being naïve?
>
> - Jordi G. H.
>

I have a new alternate solution, that is probably more amenable to  
those who don't want to be tied to a specific toolkit.  It is a  
combination of a couple existing libraries.

1) balhtexml - This is the library used by MediaWiki (same as used by  
Wikipedia) to allow people to use LaTeX code inline with the web  
pages.  They also have a command line tool and a library that could  
easily be linked against directly.
2) gtkmathviewer - Despite having dependencies on GTK, the "core" of  
gtkmathviewer does not depend on GTK and could be ripped out and a  
simple render to a bitmap/pixmap could be done for inclusion into the  
OpenGL plots.

I think in the long run this will look less pretty than the LaTeX  
output, but seems simpler and dependent on less stuff.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

Shai Ayal-2
On Wed, Oct 29, 2008 at 5:51 AM, John Swensen <[hidden email]> wrote:

>
> On Oct 28, 2008, at 10:23 PM, Jordi Gutiérrez Hermoso wrote:
>
>> 2008/10/28 Thomas Weber <[hidden email]>:
>>>
>>> Eh, adding TeX as dependency would be the end to all kind of usage
>>> pattern:
>>
>> Well, it wouldn't have to be a hard dependency. Make it a compile-time
>> option.  That seems to be the approach for many other of the larger
>> components of Octave. TeX is a standard part of a GNU system anyways.
>>
>>> using it on small machines
>>
>> A handheld calculator doesn't really need to produce
>> publication-quality plots anyways, does it?
>>
>> Also, I expect most people who use Octave already use LaTeX or TeX. Or
>> am I being naïve?
>>
>> - Jordi G. H.
>>
>
> I have a new alternate solution, that is probably more amenable to those who
> don't want to be tied to a specific toolkit.  It is a combination of a
> couple existing libraries.
>
> 1) balhtexml - This is the library used by MediaWiki (same as used by
> Wikipedia) to allow people to use LaTeX code inline with the web pages.
>  They also have a command line tool and a library that could easily be
> linked against directly.

I could not find this library on google. Could you provide a line?

> 2) gtkmathviewer - Despite having dependencies on GTK, the "core" of
> gtkmathviewer does not depend on GTK and could be ripped out and a simple
> render to a bitmap/pixmap could be done for inclusion into the OpenGL plots.

This looks nice but renders MathML, not LaTeX

> I think in the long run this will look less pretty than the LaTeX output,
> but seems simpler and dependent on less stuff.

I don't think we really need to be as pretty as LaTeX - I really think
having a small subset (greek, sub, super) is enough. It seems a wasted
effort to try and re-write LaTeX. If you really need very complex
LaTeX text on your plot, you can always use some ps+TeX trick:
I think we will use gl2ps to get postscript output from our OpenGL
code, and it supports combined ps+latex:

http://www.geuz.org/gl2ps/#tthFtNtAAB

i.e. you get 2 output files files -- a ps file with all the graphics
and a latex file which \includes the graphics and adds the text. This
way, on your hardcopy (but not on-screen) you can have true LaTeX
capabilities.

Shai

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John Swensen

On Oct 29, 2008, at 12:18 AM, Shai Ayal wrote:

>>
>> 1) balhtexml - This is the library used by MediaWiki (same as used by
>> Wikipedia) to allow people to use LaTeX code inline with the web  
>> pages.
>> They also have a command line tool and a library that could easily be
>> linked against directly.
>
> I could not find this library on google. Could you provide a line?
>
Sorry, that is blahtexml (http://gva.noekeon.org/blahtexml/ and http://www.mediawiki.org/wiki/Extension:Blahtex)


>> 2) gtkmathviewer - Despite having dependencies on GTK, the "core" of
>> gtkmathviewer does not depend on GTK and could be ripped out and a  
>> simple
>> render to a bitmap/pixmap could be done for inclusion into the  
>> OpenGL plots.
>
> This looks nice but renders MathML, not LaTeX
Right, that is why I proposed the two step process of LaTeX to MathML,  
then MathML to something that can be rendered to the OpenGL plot.

>
>
>> I think in the long run this will look less pretty than the LaTeX  
>> output,
>> but seems simpler and dependent on less stuff.
>
> I don't think we really need to be as pretty as LaTeX - I really think
> having a small subset (greek, sub, super) is enough. It seems a wasted
> effort to try and re-write LaTeX. If you really need very complex
> LaTeX text on your plot, you can always use some ps+TeX trick:
> I think we will use gl2ps to get postscript output from our OpenGL
> code, and it supports combined ps+latex:
>
> http://www.geuz.org/gl2ps/#tthFtNtAAB
>
> i.e. you get 2 output files files -- a ps file with all the graphics
> and a latex file which \includes the graphics and adds the text. This
> way, on your hardcopy (but not on-screen) you can have true LaTeX
> capabilities.
>
> Shai

I think that small subset should also have \dot, \ddot, \hat, \tilde,  
and maybe a couple others, since these get used quite frequently.

Would you be averse to having the two options available at compile  
time?  That way, for those with systems where LaTeX and libpoppler are  
available (whether gtk or QT), we could compile in the support for the  
full interpreter?

My latest test involved the following process, and while I haven't got  
it to draw in the Octave OpenGL plot yet, I do have it drawing in an  
OpenGL window as a texture on the cube
1) Run pdflatex on an equation: e.g.   \dot{x}(t) = Ax(t) + bu(t)
2) Run pdfcrop on the file to cut it down from a full page to just the  
bounding box
3) Load the resulting PDF with libpoppler and put it into a pixel buffer
4) Transfer the pixel buffer to an OpenGL texture
5) Apply the texture to the side of a cube (I'm assuming I could apply  
this to a transparent plane also?)

I haven't timed this yet because I am still doing (1)-(2) manually  
from the command line, but (1)-(2) really only need to be done once.  
Even (3) only needs to be done once unless some sort of zooming or  
resizing of the text takes place.  Also, libpoppler does the scaling  
and such before it converts it to a pixmap, so the text looks good  
even at large and small scales.  This process actually seems quite  
simple and doable to me, and is even a fairly simple process given  
these libraries are readily available on your platform.  I know that  
all of these are readily available on Linux and OSX, but have no clue  
about windows.


John

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
In reply to this post by Jordi Gutiérrez Hermoso
On 28-Oct-2008, Jordi Gutiérrez Hermoso wrote:

| 2008/10/28 Thomas Weber <[hidden email]>:
| > Eh, adding TeX as dependency would be the end to all kind of usage
| > pattern:
|
| Well, it wouldn't have to be a hard dependency. Make it a compile-time
| option.

Or it could be determined at run time that TeX is not available.  The
only loss would be that TeX macros would not be properly expanded in
text objects.  I don't see that as a big loss, and I certainly don't
see it as a good enough reason to settle for a hacked-up solution that
only does a partial and probably poor job of handling TeX markup.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Text properties and FTGL

John W. Eaton-6
In reply to this post by John Swensen
On 29-Oct-2008, John Swensen wrote:

| I think that small subset should also have \dot, \ddot, \hat, \tilde,  
| and maybe a couple others, since these get used quite frequently.

And someone else will of course want \int and \sum and \begin{array}
and ...  So I think it would be best to simply make it possible to use
all of TeX, interpreted by TeX itself rather than some kluge.

| Would you be averse to having the two options available at compile  
| time?  That way, for those with systems where LaTeX and libpoppler are  
| available (whether gtk or QT), we could compile in the support for the  
| full interpreter?

That adds maintenance overhead.  I'd say just require TeX for TeX
markup, and if that is not available, then skip the transformation of
the TeX parts.

jwe
12