# TeX in xlabel ?

Gary wrote:

>> Matplotlib doesn't support \text, and it requires that the
>> first and last characters of a TeX string be $. I guess it >> only processes mathmode. Well, it can't do *everything*. It is on the goals page (http://matplotlib.sourceforge.net/goals.html) to support embedded math strings like s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)'

This wouldn't be too hard - just takes some time that I haven't had of
late.

> Oh well, I've always thought that if you want to support
> Math in a graphics package, you would actually use TeX,
> rather than emulating it. Maybe like PyX:

Yes, but you lose the platform independence and portability by doing
this. It would be nice to be able to choose one or the other -- see
below.

> The problem, of course, is that requiring a TeX system is a
> BIG dependency! It would be nice if one could re-package
> the Tex interpreter to be embedded. I have no idea how big
> a job that would be. You'd also have all the font issues,
> of course, but while that would all be a lot of work, I'm
> not sure it would be more work than trying to re-write TeX!

It would be a monster job. There is basically no way to factor tex
into components -- it's a monolithic system, in part because of the
heavy use of web macros. And web2c, the conversion of web/pascal to
c, is GPLd and less permissive than the matplotlib license. So
embedding tex is a no-go, aside from size considerations. But there
are some possibilities for improving what matplotlib already offers.

One is to fall back on tex where available as a command line tool (as
pyx does, I believe), and use other command line tools to convert the
dvi to png or some other raster format and then embed it. This would
require a few external libs and utilities, but it's certainly doable.

Another idea I had while reading Knuth's "TeX: The Program" is to use
the layout information in the TFM font metric files. Apparently math
fonts have additional layout information in them, like where to place
superscripts. I've looked at several tfm parsing implementations, and
haven't found one yet that actually extracts this information; most
extract the standard font information but not the special math
information. But if we could access this info, we could include the
tfm files for common raster sizes and use the layout info crafted by
the master himself.

A third possibility would be to support mathml, using some good mathml
renderer. Is there a good, free mathml rendering library - what does
mozilla use for this?

JDH

John Hunter wrote:

"Chris" == Chris Barker <Chris.Barker@...259...> writes:

> Gary wrote:
>> Matplotlib doesn't support \text, and it requires that the
>> first and last characters of a TeX string be $. I guess it >> only processes mathmode. Well, it can't do *everything*. It is on the goals page (http://matplotlib.sourceforge.net/goals.html) to support embedded math strings like s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)'

did you mean:

s = r'Mean ($\mu=5$) and standard deviation ($\sigma=1$)'

I think there was a missing "\$".

That would be nice.

It would be nice to be able to choose one or the other --

that would be nice.

It would be a monster job. There is basically no way to factor tex
into components -- it's a monolithic system, in part because of the
heavy use of web macros.

Ah. too bad. It's nice to know you've looked into this some.

> And web2c, the conversion of web/pascal to

c, is GPLd and less permissive than the matplotlib license. So
embedding tex is a no-go, aside from size considerations.

web2c is essentially a compiler of sorts, isn't it? So there wouldn't be any problem with distributing C code created by it would there? In any case, there are LOTS of commercial TeX distributions out there, so there must be a way. This doesn't address the other big issues, however.

AmiPro, the word processor bought by Lotus, then later turned into WordPro, used TeX to format math. I used it for years before I discovered LaTeX because it had such nice math rendering (MS Word's still sucks!). They somehow managed to embed it, so I suppose it can be done! That doesn't mean it's the least bit easy, however.

But there
are some possibilities for improving what matplotlib already offers.

good news, of course.

One is to fall back on tex where available as a command line tool (as
pyx does, I believe), and use other command line tools to convert the
dvi to png or some other raster format and then embed it. This would
require a few external libs and utilities, but it's certainly doable.

That would be a nice option, but I'd rather see a DVI driver built in to Matplotlib, than a raster format. That's how PyX does it. I guess that would require matplotlib to have the same fonts, however. Another option would be PDF or EPS, but that would probably only be convenient for PS and/or PDF output.

Another idea I had while reading Knuth's "TeX: The Program" is to use
the layout information in the TFM font metric files. Apparently math
fonts have additional layout information in them, like where to place
superscripts. I've looked at several tfm parsing implementations, and
haven't found one yet that actually extracts this information; most
extract the standard font information but not the special math
information. But if we could access this info, we could include the
tfm files for common raster sizes and use the layout info crafted by
the master himself.

very cool.

A third possibility would be to support mathml, using some good mathml
renderer. Is there a good, free mathml rendering library - what does
mozilla use for this?

good question. That would be nice, too.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

John Hunter wrote:

[snip]

One is to fall back on tex where available as a command line tool (as
pyx does, I believe), and use other command line tools to convert the
dvi to png or some other raster format and then embed it. This would
require a few external libs and utilities, but it's certainly doable.

+1 for (relatively) low-hanging fruit.

Another idea I had while reading Knuth's "TeX: The Program" is to use
the layout information in the TFM font metric files. Apparently math
fonts have additional layout information in them, like where to place
superscripts. I've looked at several tfm parsing implementations, and
haven't found one yet that actually extracts this information; most
extract the standard font information but not the special math
information. But if we could access this info, we could include the
tfm files for common raster sizes and use the layout info crafted by
the master himself.

I wish you luck!

A third possibility would be to support mathml, using some good mathml
renderer. Is there a good, free mathml rendering library - what does
mozilla use for this?

Mozilla's MathML is inextricably linked into Gecko[1] and cannot be torn out of it.

I've seen some programs out there that render MathML to either rasters or SVG, but they are either commercial or (L)GPL. They are also usually written in Java or C#.

Some possibilities gleaned from http://www.w3.org/Math/implementations.html :

* GtkMathView: C++, GPL, already has Perl and PHP bindings
http://helm.cs.unibo.it/mml-widget/

Okay, that was the only one I found.

In any case, I would not want to be directly writing MathML; it is not intended to be human-writable. There are, however, programs that will convert a restricted mathematical subset of LaTeX to MathML[2]. There are also a few non-TeX syntaxes drifting around with converters to MathML.

···

--
Robert Kern
rkern@...376...

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

John Hunter wrote:

Another idea I had while reading Knuth's "TeX: The Program" is to use
the layout information in the TFM font metric files. Apparently math
fonts have additional layout information in them, like where to place
superscripts. I've looked at several tfm parsing implementations, and
haven't found one yet that actually extracts this information; most
extract the standard font information but not the special math
information. But if we could access this info, we could include the
tfm files for common raster sizes and use the layout info crafted by
the master himself.

Taking this as a challenge (and having little to do while waiting for images to process), I wrote a TFM parser that handles the extra parameters for math symbols. This format[1] is excruciatingly painful.

http://starship.python.net/crew/kernr/tfm.py

And then I realized that the output of tftopl(1) is incredibly easy to parse and contains the same information. <sigh>

Either way, you now have the information you need for some fonts, at least.

···

--
Robert Kern
rkern@...376...

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter