[[!meta title="Jason Blevins"]]
I'm currently hosting a private ikiwiki for keeping research notes
which, with some patches and a plugin (below), will
convert inline LaTeX expressions to MathML. I'm working towards a
patchset and instructions for others to do the same.
I've setup a test ikiwiki here where I've
started keeping a few notes on my progress. There is an example of
inline SVG on the homepage (note that the logo scales along with the
font size). There are a few example mathematical expressions in the
sandbox. The MathML is generated
automatically from inline LaTeX expressions using an experimental
plugin I'm working on.
My (also MathML-enabled) homepage: http://jblevins.org/ (still using
Blosxom...maybe one day I'll convert it to ikiwiki...)
Current ikiwki issues of interest:
- [[bugs/recentchanges_feed_links]]
- [[bugs/HTML_inlined_into_Atom_not_necessarily_well-formed]]
- [[plugins/toc/discussion]]
- [[todo/BibTeX]]
- [[todo/svg]]
- [[todo/Option_to_make_title_an_h1?]]
- [[bugs/SVG_files_not_recognized_as_images]]
Plugins
These plugins are experimental. Use them at your own risk. Read the
perldoc documentation for more details. Patches and suggestions are
welcome.
-
mdwn_itex - Works with the mdwn plugin to convert inline LaTeX
expressions to MathML using itex2MML.
-
h1title - If present, use the leading level 1 Markdown header to
set the page title and remove it from the page body.
-
code - Whole file and inline code snippet syntax highlighting
via GNU Source-highlight. The list of supported file extensions is
configurable. There is also some preliminary documentation.
See the FortranWiki for examples.
-
metamail - a plugin for loading metadata from email-style
headers at top of a file (e.g., title: Page Title or
date: November 2, 2008 11:14 EST).
-
pandoc - Markdown page processing via Pandoc. LaTeX and
reStructuredText are optional.
-
path - Provides path-specific template conditionals such as
IS_HOMEPAGE and IN_DIR_SUBDIR.
MathML and SVG support
So far, I've made some notes on sanitizing MathML and SVG via
htmlscrubber on the [[todo/svg]] todo item.
I've also worked out some content-negotiation issues. First of all,
one needs to modify the default templates to use the
XHTML+MathML+SVG doctype (see e.g., this patch).
For most browsers, the content type of the pages should be
application/xhtml+xml. The solution is easy if you want to
just send application/xhtml+xml to everybody:
just change the content type of .html files across the board.
However, if you want to support browsers that don't accept
application/xhtml+xml (and those that will but say they
don't, such as IE with the MathPlayer plugin), then one
needs a mod_rewrite rule like the following:
RewriteCond %{HTTP_ACCEPT} application\/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} (W3C.*Validator|MathPlayer)
RewriteRule \.html$ - [T=application/xhtml+xml]
This solves the problem of MathML and inline SVG in static pages
but some additional work is required for dynamically generated
pages, like page previews, that are generated by ikiwiki.cgi.
We need to allow ikiwiki.cgi to set the content type dynamically
based on the HTTP_CONTENT_TYPE environment variable
(e.g., with the following patch). Then, the following
rewrite rules can pass the correct content type to ikiwiki:
RewriteCond %{HTTP_ACCEPT} application\/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} (W3C.*Validator|MathPlayer)
RewriteRule ikiwiki.cgi$ - [T=application/xhtml+xml]
One final critical issue is that a production-ready setup needs to
implement some sort of on-the-fly error handling. If a user submits
an invalid LaTeX expression or SVG code (not malicious, just invalid)
and saves the page, then browsers like Firefox will halt processing of
the page, preventing any further viewing or editing. A less than
optimal solution is to force users to preview the page before saving.
That way if someone introduces invalid XHTML then they can't save the
page in the first place (unless they post directly to the right URL).
