Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

September 15, 2005

itex2MML 1.0 and AbiWord

itex2MML is the engine we use to convert TeX input to MathML output. It’s used by my plugins for MovableType, WordPress and ecto. Originally written by Paul Gartside, I’ve sorta been its default maintainer these past several years.

So you can imagine that I was pleased to learn that the forthcoming AbiWord 2.4 uses itex2MML and gtkMathView to generate and display MathML.

Francis James Franklin and Marc Maurer put a lot of effort into adapting itex2MML for use in AbiWord and, at the same time, cleaning up the code considerably.

I’ve decided to fold their changes into my distribution and bump the version number up to 1.0.

One of the nifty new features of itex2MML 1.0 is the improved error-reporting. Unfortunately, Mozilla, for some reason, decides to “hide” <merror> elements in display equations. So, to see the new, improved error messages, you need to add

merror {display:inline;font-size:1em;}

to your CSS stylesheet.

I’ve also decided to start distributing both Linux and MacOSX binaries, in addition to the source code. Let me know if you have trouble with the binaries or in compiling the source code from scratch.

Whither Safari?

Back in June, I wrote excitedly about the new open-source WebKit, and how it might soon lead to MathML support in Safari. The MathML in Webkit project doesn’t seem to have gone anywhere (though there’s been a flurry of activity on SVG support).

In the meantime, Frank, who’s the maintainer of the MacOSX port of AbiWord, helped Luca Padovani port gtkMathView to MacOSX. So there’s a whole new, high quality, MathML rendering engine on MacOSX1. And it’s highly modular, supporting a variety of frontend inputs and backend renderers.

Is someone interested in working with Luca to incorporate gtkMathView as Safari’s MathML rendering engine?

Update (9/15/2005):

A minor revision, itex2MML 1.01, solves the problem noted by Gong yi Liao below. Subscripts and superscripts for \det, \gcd, \inf, \lim, \liminf, \limsup, \max, \min, \Pr and \sup are now handled correctly2 in display equations.

If you have compilation problems, please give some details as to the system you’re compiling on.

1 Considering the crappy state of Mozilla/Mac’s MathML rendering engine, it’s probably, far and away, the best MathML rendering engine for MacOSX.

2 lim x→0 in display equations (versus lim x→0\lim_{x\to0} in inline equations), as per p. 162 of The TeX Book.

Posted by distler at September 15, 2005 9:19 AM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/644



6 Comments & 0 Trackbacks

Re: itex2MML 1.0 and AbiWord

It seems that the “lim” entity takes the p -> 0 as a subscript but not put it bottom of the string “lim”,

(1)lim p→0f(p) \lim_{p \rightarrow 0} f(p)

and the following is my dirty work on it: itex2MML.l:
“\lim” {yylval=itex2MMLcopystring(yytext+1); return MOB;}
and the line 830 of itex2MML.l:
YY_FLUSH_BUFFER;
should be commented out, or the program can’t be getting compiled.

Posted by: Gong yi Liao on September 15, 2005 11:16 AM | Permalink | Reply to this

Bugfix

and the following is my dirty work on it:
itex2MML.l: "\lim" {yylval=itex2MML_copy_string(yytext+1); return MOB;}

Gah! No. See the Update above.

and the line 830 of itex2MML.l:
YY_FLUSH_BUFFER;
should be commented out, or the program can’t be getting compiled.

Hmmm. I have had no trouble compiling on the following systems

  • GNU Bison version 1.28
flex version 2.5.4
gcc version 4.0.0
on MacOSX 10.4.2
  • GNU Bison version 2.0
flex version 2.5.4
gcc version 4.0.1
on Fedora Core 4.

If you’re having trouble, what’s your system configuration, and what is the compilation error that you are encountering?

Posted by: Jacques Distler on September 15, 2005 9:22 PM | Permalink | PGP Sig | Reply to this

Re: itex2MML 1.0 and AbiWord

Sorry for missing the details, my system configuration is Ubuntu Linux (breezy) comes with gcc 4.0.1 and flex 2.5.31, and this version of flex fail to compile itex2MML and put the error message as:
flex -Pitex2MMLyy -olex.yy.c itex2MML.l cc -c -o lex.yy.o lex.yy.c
itex2MML.l: In function ‘itex2MMLsetup’:
itex2MML.l:831: error: ‘YYFLUSHBUFFER’ undeclared (first use in this function)
itex2MML.l:831: error: (Each undeclared identifier is reported only once
itex2MML.l:831: error: for each function it appears in.)
make: * [lex.yy.o] Error 1

fortunely, there’s a package named flex-old (version 2.5.4a, so , old?) shiped with Ubuntu-breezy can solve this problem, (but this packages conflicts with flex), it compiles itex2MML well without any problem, I’m trying figure out what are the differences between flex and flex-old.
Thanx for the programmer’s great work!

Posted by: Gong Yi Liao on September 16, 2005 12:24 AM | Permalink | Reply to this

YY_FLUSH_BUFFER

This seems to be a confirmed problem with flex 2.5.31. The fix, which is now in my distribution, is

-       YY_FLUSH_BUFFER;
+       yy_flush_buffer( YY_CURRENT_BUFFER );
Posted by: Jacques Distler on September 17, 2005 10:55 AM | Permalink | PGP Sig | Reply to this

Re: itex2MML 1.0 and AbiWord

An update from IEBlog on XHTML support in IE 7.

(I don’t think you’ll like it.)

Posted by: Chris W. on September 20, 2005 10:06 PM | Permalink | Reply to this

XHTML and IE7

If the choice was between doing a half-assed, broken implementation by hacking IE’s HTML parser(!?!?) or doing nothing at all, then I breathe a tremendous sigh of relief that they decided to do nothing.

I mean, really, did you think there was any chance that IE7 would do XHTML correctly?

I ‘spose it’s a good thing that the <?xml?> prolog will no longer throw IE7 into Quirks Mode. Its rendering of these pages will, as a consequence, be slightly less abysmal.

This is the least bad of the possible outcomes. And, more generally, it speaks of a level of maturity previously not seen from the IE Development Team. Perhaps IE8 will support application/xhtml+xml, XHTML 2 and …

If so, there’s a decent chance that it will support them properly.

Posted by: Jacques Distler on September 20, 2005 11:28 PM | Permalink | PGP Sig | Reply to this

Post a New Comment