From: Andrew S. <and...@ma...> - 2010-08-02 19:01:45
|
Hi! Thanks for the quick initial response. On Mon, Aug 02, 2010 at 12:45:55PM -0400, Waylan Limberg wrote: > Hmm, I'm not a real big fan of Swig myself (mostly through my own lack of > success in compiling a few packages). It's not that Swig is bad (it > certainly has it's merits), but this just feels like too heavy of > a dependency for it to be shipped with Python-Markdown. Understood. > Of course, extensions can certainly live as third party packages, so > it may be appropriate that way. For me, this would be absolutely fine. I wasn't angling for more. > > required (thus meaning that it can _internally_ cope with different > > browser requirements). > > While this may be appropriate on a case by case basis for certain > projects, this seems like a bad idea to me for a general use > extension. Browser sniffing and making images available for a web > server to serve separate from the markdown document just doesn't > belong here. Of course, if an individual project needs those > features, they could certainly hack up the basic extension to fit > their specific needs. Absolutely! I misspoke a little. I would propose that the extension have a switch by which it can be told to produce MathML, SVG, or PNG. Then the calling script can do the browser selection or just choose one and so pass the appropriate option to the extension. Alternatively, the extension can just do the conversion to MathML and then the calling script can further pass the whole XHTML document through SVGMath to do the rest. I mentioned this because one of the major issues with MathML is its lack of browser support. But it's chicken-and-egg: people don't want to adopt MathML until it's supported widely, but the push to get it supported widely won't come until lots of people use it and see how good it is. So being able to offer a choice is a way of getting people to use MathML without losing their audience. > On the other hand, I haven't looked at the solutions offered in other > languages. Maybe those issues have already been worked out and a > default behavior has been established, in which case we could simply > copy it. As I said, I've done the PHP coding and the guy who currently maintains itex2MML has done the ruby version. A perl version is no doubt not far off (that one I could do myself but don't have an application to hand right now in which to use it!). > Any chance we could see the source of your CGI script? Yes of course! I should have put that in my earlier email. My apologies. My additions to itex2MML are available at: http://www.math.ntnu.no/~stacey/code/itexToMML The python cgi script is in cgi-bin/itex.py (relative to that link). The whole thing is a bzr repository. Note that this isn't a live version but just the code. > Again, thanks for taking the time to get this started. No problem! Thanks for the quick initial reply, Andrew |