## October 22, 2007

### SVG in MathML in …

As I’ve mentioned before, there is an effort afoot to enable the inclusion of MathML and SVG (and maybe other) markup in HTML5. But that’s a long way off (if it happens at all). What I really want to talk about, today, is an issue that affects us in the here and now: mixing MathML and SVG markup.

The subject came up in a discussion over at Sam’s blog about SVG-in-HTML5. Some people were arguing that, even if it were technically possible, it would be undesirable to sully HTML5 with the inclusion of foreign dialects, like MathML or SVG. The latter, in particular, was in some quarters considered too “presentational.”

This annoyed me sufficiently that I gave the following example:

Say I wish to discuss irreducible representations of SU(3). I think it should be perfectly acceptable to point out that: $\begin{svg} \end{svg}\otimes\begin{svg} \end{svg}=\begin{svg} \end{svg}\oplus\begin{svg} \end{svg}$.

Actually, what I wrote at Sam’s blog was a somewhat bastardized version of the above1. At the time, I really had no idea how to properly include SVG fragments inside a MathML equation. It turns out that the “correct” answer is some horrible kludge, involving embedding the SVG in the MathML <semantics> element. Go figure …

It seems to me that the Spec-writers at the W3C haven’t put much thought into how to combine these markup dialects. The best I could find, by way of guidance, was an unfinished note from 2003. Work has started on MathML 3.0, but, apparently, remedying this situation is beyond the scope of their charter. So we’re not going to get any help from that quarter.

Which is unfortunate. The folks over at the n-Category Café have been clamouring for the ability to include fairly sophisticated diagrams. One way or another, I intend to find a MATHML+SVG solution for them. It would be a shame if the way forward involved reverse-engineering what the browser-makers (i.e. Mozilla, since neither Safari nor Opera support MathML) have implemented, and tailoring our markup accordingly.

In the particular case of Young tableaux, it would be easy to extend itex2MML to make entering the above formula as simple as

$\tableau{2} \otimes \tableau{1} = \tableau{2 1} \oplus \tableau{3}$

I once wrote a LaTeX macro to to do precisely that. I may yet implement this in itex, but we really need a more general solution for including SVG fragments in itex equations.

Introducing the itex “svg” environment:

\begin{svg}
...
\end{svg}

into which you can drop an arbitrary SVG fragment. It takes care of supplying the requisite <semantics> and <annotation-xml> tags.

“How does this work with Instiki’s LaTeX export?” you ask. To get something that also works in the LaTeX export, you would write

\begin{svg}
...
\end{svg}\includegraphics[width=...]{foo}

where foo.pdf is a file, containing a PDF version of the graphic.

In itex, \includegraphics is a NOOP, and the SVG figure is embedded in the MathML output. Conversely, in Instiki’s LaTeX output, the svg environment is a NOOP and, instead, the graphicx package is invoked to include the external figure. Not ideal, but until someone invents a LaTeX preprocessor that converts inline SVG into PDF \specials, it’s the best we can do.

To accomplish all of this, there are new versions of

• itex2MML
• the itexToMML plugin for MovableType (bundled with itex2MML)
• Instiki

[Update (10/24/2007): Revised, so that the itex2MML stream filter (used by the MT plugin) has the nice error-recovery it used to have. This doesn’t affect Instiki.]

As nifty as the above may be, it still only scratches the surface of what we need.

In the taxonomy of that unfinished note, there are also cases where one wants to embed MathML in SVG. For instance, it would be preferable if the labels on this Feynman diagram

1-loop diagram, coupling electron to an external EM field e e γ
1-loop Contribution to Electron Magnetic Moment

were embedded snippets of MathML, instead of kludgily positioned glyphs in an <svg:text> element. The latter barely suffices2 in this case; in other examples, it would clearly be doomed. The <svg:foreignObject> element is presumably the way to go. I say “presumably,” because there are, currently, no browsers that support both <foreignObject> and MathML.

Finally, there are more complicated diagrams, of the sort beloved by the denizens of the n-Category Café like, say

drawn from this post, where there are several other interesting examples.

That’s where some real thought is required.

Perhaps an xy-pic to SVG+MathML translator (built into itex2MML)?

#### Update (10/26/2007): Not up to the task

I couldn’t resist redoing the above graphic in SVG, just to see what it would take. As you might have guessed (since you can see them), all the symbols are crudely-positioned text, rather than real MathML equations, embedded in <foreignObject> elements. Even so, one can see the improvement (try, for instance, resizing the text in your browser).

Complicated commutative diagram, realized in SVG 1 1 1 1 Id Id A B ρ H H K K φ1 φ2 NA NB NA NB

To automatically generate such a diagram, one might want to use an input syntax based on xy-pic or DC-pic. For instance, in DC-pic, some semblance3 of the above figure would be generated by (Category Theorists rejoice!)

\begindc[2]
\obj(30,20){$1$}[ll1]
\obj(80,20){$1$}[lr1]
\obj(30,70){$A$}[A]
\obj(80,70){$B$}[B]
\obj(30,120){$1$}[ul1]
\obj(80,120){$1$}[ur1]
\mor{ul1}{A}{$N_A$}[\atright,\solidarrow]
\mor{ur1}{B}{$N_B$}
\mor{A}{ll1}{$N_A^\vee$}[\atright,\solidarrow]
\mor{B}{lr1}{$N_B^\vee$}
\mor{ll1}{lr1}{$H$}[\atright,\solidarrow]
\mor{ul1}{ur1}{$H$}
\cmor((25,115)(10,70)(25,25)) \pdown(5,70){$Id$}
\cmor((85,115)(100,70)(85,25)) \pdown(105,70){$Id$}
\cmor((35,75)(55,80)(75,75)) \pright(55,85){$K$}
\cmor((35,65)(55,60)(75,65)) \pright(55,55){$K'$}
%should be double arrows:
\mor(55,82)(55,58){$\rho$}
\mor(30,70)(7,70){}
\mor(80,70)(103,70){}
\mor(77,117)(35,75){$\phi_1$}[\atright,\solidarrow]
\mor(75,65)(33,23){$\phi_2$}
\enddc

Unfortunately, as that example illustrates, the existing capabilities of SVG are rather far from what one would want, in order to implement such a thing. In order for a command like

\mor{ur1}{B}{$N_B$}

to place a label on an arrow, <foreignObject> would need to be able to compute the size of the box containing its content (in this case, “$N_B$”) and, that knowledge in hand, compute its own position relative to the arrow it’s labelling. In fact, to draw the arrow itself, DC-pic needs to calculate the size of the boxes containing the source (“ur1”) and target (“B”). These calculations are done in the LaTeX packages mentioned above, but they seem to be beyond the current capabilities of SVG.

One would need something like CSVG.

1 Actually, the above example is still somewhat bastardized, as the SVG should be sized in em, rather than px. Because of a Mozilla bug, we can’t do that currently. Which means that the SVG graphics do not rescale along with the text.

2 Provided you’re not on a Mac. Because of this bug, Mac users, using release versions of Mozilla-based browsers can’t see the labels at all. You can get around this by using a nightly build from mid-November, 2006.

3 Not quite, alas. DC-pic doesn’t have native support for double-arrows ($\Rightarrow$), and has limitations on arrowheads. These shortcomings could be rectified by allowing the embedding of raw PicTex commands.

Posted by distler at October 22, 2007 11:40 PM

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

### Re: SVG in MathML in …

In fact the W3C’s web browser has supported (presentation) MathML inside SVG since a long time. Also, it has other interesting features to use MathML with other standards.

Nevertheless, I do not think the W3C describes a way to use SVG inside MathML. According to the specification, what you propose with the “semantic” element is an annotation of its first child (the “annotation-xml” element) which is syntactically correct but has not the expected meaning…

Posted by: fred_wang on October 25, 2007 3:03 PM | Permalink | Reply to this
Weblog: Musings
Tracked: October 29, 2007 12:03 AM

### Re: SVG in MathML in …

I’m integrating RELAX NG schemas for XHTML5, SVG 1.1 and MathML 2.0. I’m not sure what I should do about annotation-xml. Currently I just have an anything-goes hole there.

Do you have advice on what the content model of annotation-xml should be when I already have grammar productions for the svg element and XHTML5 elements at hand?

How did you come up with the value of the encoding attribute? To me, the attribute seems badly under-specified.

Posted by: Henri Sivonen on December 17, 2007 10:17 AM | Permalink | Reply to this

### annotation-xml

Do you have advice on what the content model of annotation-xml should be when I already have grammar productions for the svg element and XHTML5 elements at hand?

Obviously, it needs to be namespace-well-formed XML. Presumably, it should be a valid XHTML+MathML+SVG fragment. Beyond that, I think it is, by design, an anything-goes hole.

How did you come up with the value of the encoding attribute?

Like any moron, I followed an example.

Posted by: Jacques Distler on December 17, 2007 1:02 PM | Permalink | PGP Sig | Reply to this

### Re: annotation-xml

Do you have advice on what the content model of annotation-xml should be when I already have grammar productions for the svg element and XHTML5 elements at hand?

Obviously, it needs to be namespace-well-formed XML. Presumably, it should be a valid XHTML+MathML+SVG fragment. Beyond that, I think it is, by design, an anything-goes hole.

Well-formed, i.e. single-root, is not obvious from MathML 2.0 but it is from the latest MathML 3.0 draft.

It is generally accepted that a MathML fragment is rooted at math and that an SVG fragment is rooted at svg. However, it is not clear if a single-root XHTML fragment is rooted at html, body, div or any XHTML element. I’m seen examples with a lone img.

Also, besides XHTML and SVG should any other namespace be allowed? Or just OpenMath? (What even happens when OpenMath meets a browser?)

How did you come up with the value of the encoding attribute?

Like any moron, I followed an example.

Interesting. The same document contains another example that uses a bogus MIME type image/svg instead and also violates the rule that annotation-xml must contain a well-formed (i.e. single-root) subdocument.

I wonder if I should enforce some kind of concordance between the encoding value and the actual child element.

Posted by: Henri Sivonen on December 17, 2007 2:36 PM | Permalink | Reply to this

### Re: annotation-xml

However, it is not clear if a single-root XHTML fragment is rooted at html, body, div or any XHTML element. I’m seen examples with a lone img.

I think one should allow it to be rooted at any “FLOW” element (which would include div and img, but not html or body).

I wonder if I should enforce some kind of concordance between the encoding value and the actual child element

As far as I can tell, current clients completely ignore the encoding value. But it certainly would be good practice to enforce that the encoding value accord with the actual child element.

But now you’re pretty much asking me to make up a Spec on the spot. The subject of this post was how little guidance has been given for the construction of compound documents of this sort.

I can tell you what sounds right to me, and what I am doing here on Musings and in my Instiki and itex2MML software (see here and here).

But there could conceivably be other stakeholders who have different ideas. I’d be happy to host a discussion if they were interested in chiming in with their opinions.

Posted by: Jacques Distler on December 17, 2007 3:14 PM | Permalink | PGP Sig | Reply to this

### Re: annotation-xml

However, it is not clear if a single-root XHTML fragment is rooted at html, body, div or any XHTML element. I’m seen examples with a lone img.

I think one should allow it to be rooted at any “FLOW” element (which would include div and img, but not html or body).

For now, I have allowed block, inline and html. I allowed html due to a MathML spec example and due to the current stance of the HTML 5 draft.

I wonder if I should enforce some kind of concordance between the encoding value and the actual child element As far as I can tell, current clients completely ignore the encoding value. But it certainly would be good practice to enforce that the encoding value accord with the actual child element.

The encoding attribute is now optional but if it is present, concordance with the namespace of the child is required. The encoding values are per MathML 2.0. MathML 3.0 draft style is not supported.

But now you’re pretty much asking me to make up a Spec on the spot. The subject of this post was how little guidance has been given for the construction of compound documents of this sort.

Considering that the speccing is thin, I thought I’d try to find out about actual practice.

I can tell you what sounds right to me, and what I am doing here on Musings and in my Instiki and itex2MML software (see here and here).

Until a few moments ago, Validator.nu had a bug that showed up on Musings because of the way buffer boundaries happened to align. It is now fixed though. The current usage patterns on Musings seem to fit the integration points I have in the schema.

(It appears that your front page side bar has some content pulled from elsewhere without thorough Windows-1252 escape sanitizing.)

But there could conceivably be other stakeholders who have different ideas. I’d be happy to host a discussion if they were interested in chiming in with their opinions.

I’d be particularly interested in learning what foreign markup is actually deployed on the Web in annotation-xml and what the expected and actual consuming programs are.

Posted by: Henri Sivonen on December 21, 2007 8:08 AM | Permalink | Reply to this

### Windows-1252

(It appears that your front page side bar has some content pulled from elsewhere without thorough Windows-1252 escape sanitizing.)

Technorati Blog Cosmos.

I’ve done my best to correct the stuff one retrieves via their API. At some point, one hits the point of diminishing returns.

I’d be particularly interested in learning what foreign markup is actually deployed on the Web in annotation-xml and what the expected and actual consuming programs are.

There’s someone else actually deploying this stuff on the Web?

Cool! I’d like to meet him/her.

Posted by: Jacques Distler on December 21, 2007 10:41 AM | Permalink | PGP Sig | Reply to this

### Re: SVG in MathML in …

Gecko 1.9 (Firefox 3) will support svg:foreignobject and MathML. You can embed SVG, MathML and HTML in each other freely.

Posted by: Robert O'Callahan on December 17, 2007 4:57 PM | Permalink | Reply to this

### Re: SVG in MathML in …

Cool!

Now all we need is for Karl Tomlinson to finish fixing MathML in Mozilla Trunk. I’m hesitant to start filing new MathML-related bugs until Karl has fixed the ones he’s currently working on.

Posted by: Jacques Distler on December 17, 2007 6:21 PM | Permalink | PGP Sig | Reply to this
Weblog: Musings
Excerpt: Taking the new Firefox out for a spin.
Tracked: February 4, 2008 3:51 PM

### Re: SVG in MathML in …

FireFox 3 Beta 3 and Amaya 10 pre-release both support mathml in svg and a physical science oriented page can pass validator.nu validation without math: nor svg: prefixes on elements. That is cause for celebration!

Posted by: Dana Lee Ling on March 8, 2008 7:44 PM | Permalink | Reply to this

### math + svg in Instiki via itex2mml+javascript?

Hi Jacques,

Perhaps we can include support for some basic drawing primitives inside itex2mml, in the style of TikZ?

I’m thinking of course of the nLab context. Basically what we need to start off with is some basic support for lines (could be curved, with arrow heads and labelled text), rectangles, etc.

I think we should bet on TikZ establishing itself as the de-facto drawing package for TeX in the near future. It’s a great package. So let’s futureproof ourselves and start catering for the basic TikZ primitives in itex2mml.

All of the primitives I mentioned above can easily be coded into SVG, and the math can be added via the foreignObject method (which would of course call itex2mml recursively, to convert the math inside dollar signs into mathML).

The only annoying problem, of course, is the fact that in TikZ, one can anchor “nodes” for text at the center (default) or at any of the following positions: north, northeast, east, etc., or adjusted versions thereof. However, the foreignObject method always anchors the “stuff” it contains in the northwest corner, causing a big problem for labels, as you say above.

But I say: let’s just workaround this using javascript. Namely, one uses the bbox method to find the bounding box of the foreignObject, and then one can calculate the renormalized position (i.e. if the user intended that label to be centered on co-ordinate (3,1) say, then the javascript simply sets x = x - bbox(foreignObject)/2 and y=y-bbox(foreignObject)/2.

I believe that Instiki already uses javascript in quite an integral way, so it can’t be argued that using javascript somehow breaks the core principles of Instiki. Moreover it will be fast.

I’ve had a look at the code for itex2mml and it looks nice and neat; it should be a snap to put this feature in and add support for some basic drawing primitves (with labelled text). At least enough to be able to convert the following 2-cell commutative diagram into SVG:

\begin{tikzpicture}
\node (a) at (0,1) {$a$};
\node (b) at (1,1) {$b$};
\node (c) at (0,0) {$c$};
\node (d) at (1,0) {$d$};

\draw (a) edge[->] node[above]{$f$} (b)
edge[->] node[left]{$g$} (c);
\draw (b) edge[->] node[right]{$h$} (d);
\draw (c) edge[->] node[below]{$k$} (d);
\draw[double, implies-] (b) – node[below right=-3]{$\phi$} (c);
\end{tikzpicture}

The alternative method is to use tex4ht route to convert TikZ into SVG (it is possible to combine this with the the foreignObject method for math, due to some code by Olivier Binda). The advantage of this latter method is that at one stroke, one theoretically immediately obtains the full power of TikZ. The disadvantage is that one needs to have TeX and tex4ht installed on the server, and it’s a tad buggy.

What are your thoughts on this?

Posted by: Bruce Bartlett on May 17, 2009 10:45 AM | Permalink | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

itex2MML, as you have seen, is a Lex/Yacc formal grammar. Armed with a formal description of (a subset of) the TikZ grammar, it would not be hard to support that in itex2MML.

The problems I see are the following.

1. It is extremely useful to be able to embed pictures in equations (hence the svg environment). TikZ doesn’t allow for that. The tikzpicture environment can only occur outside equations.
2. Programs like Instiki, which use itex2MML, don’t actually pass the whole text to itex2MML. They make separate calls to itex2MML for each equation. They would, thus, have to also be made aware of the tikzpicture environment.
3. itex2MML doesn’t attempt to support all of LaTeX. It only supports what I (and all my users, such as yourself) consider a useful subset. I don’t know enough about TikZ to know what a useful subset would be.
4. It’s not obvious (to me, yet), that composing in TikZ is the optimal solution for most users. There are, for instance, WYSIWYG tools for composing SVG. Perhaps a tool that converted SVG to TikZ would be more useful. (You could use the SVG for the online version, and the generated TikZ code for the LaTeX version of your document.)

Finding a good graphics solution that permits re-use, both online and in LaTeX, is very important. We really do need to think carefully about the best route to achieve that goal, before undertaking a major re-architecting.

The alternative method is to use tex4ht route to convert TikZ into SVG (it is possible to combine this with the the foreignObject method for math, due to some code by Olivier Binda).

I haven’t looked at Olivier’s modifications, but the existing tex4ht TikZ→SVG converter is crap.

The disadvantage is that one needs to have TeX and tex4ht installed on the server, and it’s a tad buggy.

That is a serious understatement. I’m dubious of its suitability even for offline use. It’s certainly not something I would put on the server, for automated conversion.

Posted by: Jacques Distler on May 17, 2009 11:47 AM | Permalink | PGP Sig | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

Okay, here are some thoughts.

1. It looks as if you can put TikZ into equations. I just tried it, and it worked. I shoved the whole \begin{tikzpicture} … \end{tikzpicture} into a math equation, with a \begin{aligned} … \end{aligned} wrapper so everything lined up nicely, and it seemed to work fine.

2. Indeed, the itex2mml will have to become aware of \begin{tikzpicture} environments. But that’s basically on the same level as making it aware of \begin{array} environments, and so on. (The only sublety is that I’m not sure how the recursion works in itex2mml; one would need to parse the tikzpicture environment first so that  math inside it could be turned into mathML by a later call of itex2mml.)

3. Yes, indeed one would have to at least start by supporting a fraction of the TikZ syntax. But I don’t think its rocket science to figure out what the initial support should be: basic lines and rectangles, arrows, labels. Just enough to draw some commutative diagrams (keep the higher categorists happy, while at least providing everyone some basic toys). Further syntax can be added incrementally. The advantage is that everything remains compatible at every stage, and moreover outputting to Latex from an Instiki document should be a breeze.

4. One can imagine composing a picture in, say Inkscape, then outputting SVG and pasting it into the edit box of an Instiki page. But I don’t think this is a good solution. The SVG syntax is klunky, the output from Inkscape will have all sorts of horrible decimal places and so on, and it just clutters up the edit page. Ordinary mathematicians reading that edit page will be terribly frightened. On the other hand, TikZ syntax looks very friendly to the average mathematician, and is much less verbose. We were discussing this point at the nForum.

On the other hand, at some point Inkscape will be able to output TikZ syntax. That gives another input method.

itex2MML, as you have seen, is a Lex/Yacc formal grammar.

Well that sounds great, though I admit I don’t really know what it means. Let’s hope that Till Tantau would indeed be able to produce a formal description of the TikZ grammar. But we need not wait till then; I think the basic primitives can be hard-coded by ourselves. After all, I guess things will be different when HTML5 comes along in a (decade’s time?!).

Posted by: Bruce Bartlett on May 17, 2009 12:06 PM | Permalink | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

1. It looks as if you can put TikZ into equations.

That’s good!

I had been led to believe you couldn’t.

The only sublety is that I’m not sure how the recursion works in itex2mml;

It doesn’t.

So (as it stands):

• you can embed SVG in itex (using \begin{svg}...\end{svg})
• you can embed itex in SVG (using $...$)

But you can’t embed itex in SVG in itex. At that level — if you insist on nesting MathML inside SVG inside MathML inside XHTML, you have to break down and actually embed MathML code in the innermost layer.

One can imagine composing a picture in, say Inkscape, then outputting SVG and pasting it into the edit box of an Instiki page. But I don’t think this is a good solution. The SVG syntax is klunky, the output from Inkscape will have all sorts of horrible decimal places and so on, and it just clutters up the edit page.

There are utilities for cleaning up the SVG produced by Inkscape. But, even then, the output is far more verbose and inefficient than it could be.

The same, I suspect, would be true of the TikZ code spit out by Inkscape. Except, that, in the latter case, I doubt there are any tools for optimizing the output.

Note that, by the same token, the SVG generated by tex4ht is even worse (frequently, it’s not even SVG).

By contrast, I wouldn’t characterize hand-crafted SVG as “klunky”. It’s not as high-level as TikZ code; it’s more like raw PGF. It’s a little more verbose, but not much more; if anything, the slightly greater verbosity makes it more readable.

Where TikZ seems to win is the overlay of higher-level commands for various graphical constructs (there are TikZ packages for a dizzying variety of specialties).

For instance, look at a Feynman diagram in TikZ. It uses the trees, and decorations libraries. or the Petri net example (from the TikZ manual), which uses arrows, shapes, snakes, automata, backgrounds and petri

Even your example (which, as it happens, doesn’t work for me), uses the arrows package.

It is completely impractical to imagine building these sundry packages into the itex2MML core (they’re add-on packages for TikZ, fer cryin’ out loud!). So, to handle even the absurdly simple commutative diagram of your example, we’d need to create some sort of extension mechanism …

The whole thing makes my head hurt.

Posted by: Jacques Distler on May 18, 2009 12:53 AM | Permalink | PGP Sig | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

It’s true that well-written SVG code isn’t so bad, but I don’t think it’s suitable for an Instiki edit page environment. All those (svg) (/svg) (path) tags look so out of place in the text page, it will definitely scare most people off. On the other hand TikZ is in TeX format and won’t scare people off. That’s my main point. It may sound small, but big things hinge on small things like this.

I don’t propose writing a full TikZ interpreter from the ground up. That would be a gimungous project, and probably impossible due to SVG’s limitations. I say just quickly build in some quick and dirty support for the things people use most of the time eg. at the nLab: a line (with arrowhead) from here to there, with a label on it. That should be quick to do. Later on one can think about building in more stuff. Tell the users: these are the basic things we support from TikZ. They needn’t know that “under the hood” you have hardcoded these things in as a shortcut way, as opposed to elegantly building up TiKZ primitives from the ground up, moving on to packages etc.

Posted by: Bruce Bartlett on May 18, 2009 11:54 AM | Permalink | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

On the other hand TikZ is in TeX format and won’t scare people off. That’s my main point. It may sound small, but big things hinge on small things like this.

The proper point of comparison is probably SVG versus PGF syntax. The latter is somewhat terser, but not more legible, and seems just as likely to scare people off as SVG would.

TikZ code (which, frankly, doesn’t look much like TeX to me; it looks more like postscript) overlays all sorts of ‘higher level’ commands (some in TikZ core, most in packages), which is a clear improvement over either SVG or PGF.

The problem is how to get there from here.

They needn’t know that “under the hood” you have hardcoded these things in as a shortcut way,

Whether they know it or not, that’s what is being proposed that we do. So it’s important to determine whether or not that’s a viable way to go.

Let me contrast the situation with the choices faced in building itex2MML in the first place.

One might have said the same thing:

LaTeX has a zillion packages. You can’t build all of the features of all of those packages into itex2MML core; you’d need some sort of extension mechanism. That’s a nightmare …

But, in fact, it’s not so bad.

itex2MML is only designed to handle equations. The vast majority of LaTeX packages are concerned with other things, so we can forget about them. Of the much smaller number of packages, concerned with equations, only one — amsmath — is sufficiently popular to be really worth worrying about. So we can hard-code some of the most popular features from amsmath, and not worry about the rest.

That made the whole problem tractable, without building in some extensibility mechanism.

When it comes to TikZ, and figure-drawing, it’s not so clear.

If all you want to do is draw some commutative diagrams, a few TikZ primitives, and maybe the contents of the arrows package would suffice.

But, then, if you wanted to draw some figures, apropos of 2D TQFTs, an entirely different (set of) package(s) would be required. Someone drawing Feynman diagrams (I should point out that the audience for Instiki does not consist solely of category theorists!) would want yet another set of packages…

It’s really not obvious to me what a “reasonable” subset of TikZ (that one might hard-code into itex2MML) would look like.

A more reasonable target (well, at least a more circumscribed target — whether it’s reasonable remains to be seen) would be a PGF→SVG interpreter.

Is there a way to take TikZ input (which can and should depend on a variety of TikZ packages) and capture the PGF output?

Posted by: Jacques Distler on May 18, 2009 12:47 PM | Permalink | PGP Sig | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

Is there a way to take TikZ input (which can and should depend on a variety of TikZ packages) and capture the PGF output?

Not that I know of. We can always ask. I think the best way to think is in terms of the three layers: TikZ is the frontend layer, then you get the basic layer, then you get the system layer.

If you want to go that route, then if I understand things right, the following method might work: one “hardcodes” a TeX interpreter that will parse the TeX source code .def and .sty files for TikZ. That is, we have a streamlined program that takes a TikZ segment of code and outputs the basic layer pgf commands. (The reason I’d like to do this ourselves, as opposed to giving it to TeX, is because hopefully this is just an interpreting device; no typesetting takes place. Thus it should be much faster than the Tex4ht setup.

There is already a (not bad I think) basic layer -> SVG translator (the pgfsys-common-svg.def and pgfsys-tex4ht.def files). One just needs to adjust the latter: currently, whenever it actually inserts some math (i.e. text), it calls tex4ht to translate this into mathML, and then it inserts it itself. I say we simply ask it to call itex2mml instead. I’m sure this will be much faster and streamlined. It might work.

The whole thing hinges on a huge misunderstanding I might have about how TeX actually works. I am working on the theory that it is primarily a language interpretation problem to go from TikZ to system-layer PGF, as opposed to a typographical problem. And that any typographical problems (eg. at some point, the interpreter needs to compute the width of a text node) might be solvable with javescript.

Posted by: Bruce Bartlett on May 18, 2009 6:01 PM | Permalink | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

I get the same impression as you do from reading the PGF manual: that all the actual typesetting is done by the PGF system layer (with differing drivers for differing outputs), with the transition from the “frontend layer” (TikZ) through the “basic layer” and then down to the “system layer” being about translation rather than typesetting. Actually, I can’t really imagine how it could be otherwise, since only the “driver” that knows what output format is necessary (PS, PDF, etc.) has a hope of actually doing any typesetting, and the driver only operates at the system layer.

Posted by: Mike Shulman on May 23, 2009 9:39 AM | Permalink | Reply to this

### Re: math + svg in Instiki via itex2mml+javascript?

Can you give some examples of the bugs in the existing tex4ht TikZ$\to$SVG converter? (Is it actually a PGF$\to$SVG converter?) I wonder whether our efforts might not be better spent improving it rather than rewriting another system from the ground up.

Posted by: Mike Shulman on May 22, 2009 10:20 AM | Permalink | Reply to this

Post a New Comment