# MultiMarkdown 3.0b4 Released - Major Update

02/14/2011 19:58:01

MultiMarkdown 3.0b4 is a major upgrade:

• Found and fixed a step in the parser (under HeadingSection) that was slowing down the program on longer documents by orders of magnitude — thanks to Ioa for prompting the search. My 7000+ line test document takes approx 0.150 seconds to convert to XHTML with peg-markdown, and 0.290 seconds with peg-multimarkdown. By comparison, the perl version of MMD takes approximately 8.3 seconds. Running XSLT takes additional time, so the speed difference when converting to LaTeX would be even more pronounced! There may be additional speed benefits to be squeezed out of code optimization, but I’m not sure it’s worth the effort right now as these benefits would likely be minimal at this point.

• John MacFarlane fixed a bug in list edge cases discovered by a MMD user — that fix is incorporated, as well as a speed-up in HTML processing per his release notes.

• Metadata that is exported to LaTeX and includes “space-space-newline” as a marker for a line break is now processed so that things like multi-line addresses for letters are properly handled.

• italics are now handled with \emph{} in LaTeX

• memoir and “regular” latex modes now output the same logical division levels for h1, h2, etc. (i.e. part, chapter, section, subsection, subsubsection, paragraph, subparagraph), The subparagraph option for h7 will only appear when converting directly from MMD to LaTeX, since no <h7> exists in XHTML. beamer mode uses a different set of divisions.

• The peg-multimarkdown source repository now includes the documentation wiki, the sample gallery, support files, and test suite as submodules. They can therefore be downloaded separately as well since they exist as their own repositories. The update_submodules shell script will update them all automatically (on Mac or *nix systems).

• The LaTeX support files now include a functioning version of the manuscript setup so that you can create pdf’s using the “standard” novel manuscript format. This includes some examples of using LaTeX code to replace what used to be done with XSLT processing. My goal is that most of what was done using XSLT with MMD 2.0 can be done with pure LaTeX in MMD 3.0. Naturally, anyone who used XSLT to customize XHTML output will still need to use that approach.

• The MultiMarkdown-Gallery (included as samples in the source repo) has been updated so that everything works with MMD 3.0. I have included the source text, the “correct” LaTeX output, and the “correct” PDF so that you can verify everything on your system is working appropriately.

• Mac users can now install Platypus and use the make drop command to build drag and drop apps, or they can be downloaded from the downloads page. These will run multimarkdown -b or multimarkdown -t latex -b on files dropped on them. Similar approaches can be used to make other drag and drop apps as required.

I think I’m getting close to being able to finalize 3.0. Things left to be accomplished:

• Finish updating User’s Guide for 3.0 (thanks to etherealmind for contributing to the wiki!)

• Improve Windows installer (I have received a submission of a true installer that I need to test out, but should make things much better for Windows users — more to come!)

Things that likely won’t be included in 3.0, but may appear in the future:

• I am considering using libxslt to build in support for XSLT processing to the binary. Not sure about this, versus just including the xsltproc binary in the installer for Windows users.

• I have begun working on ODF support for MMD 3. It’s in very early stages, but the basics shouldn’t be too hard. For now, will need to use MMD 3 to create the content.xml file, and then you can zip the template directory to create an .odt file (which is a zipfile). I have a working minimalist template that is used, as well as a shell script that zips the folder for you into a file that can be opened in LibreOffice, OpenOffice, etc. This might be finished in time for 3.0, but if not I hope to have it ready fairly soon. This will likely become the official way to create an RTF file moving forward since OpenDocument can easily be converted.