Handling Math in Real-World Workflows: Practical Lessons
http://www.idealliance.org/proceedings/xml05/ship/17/17-Mathews.HTML

"There are many good tools for converting Word documents into XML, and a number of them support conversion of Equation Editor/MathType equations into MathML. All of them ultimately rely on MathType conversion facilities. MathType can convert all the equations in a document into a textual form (either MathML or TeX/LaTeX)."

"The main problem with converting Word documents is not software but authors. Documents that have been carefully authored to be regular in their format tend to convert well. However, most Word documents are not carefully authored. The author often enters simple math expressions as a mix of symbols entered directly into Word, and Equation Editor or MathType equations for the more complicated bits. Similarly, the document text may look uniform, but is really a mix of many styles. Consequently, a number of production workflows have manuscripts cleaned up or re-keyed, and lock them down to an XML schema."

"LaTeX conversion is harder. There are three or four main LaTeX-to-XML+MathML converters: TtM, TeX4ht, Hermes, and WebEQ."

"A new LaTeX converter called Hermes [7] is still in development, but seems promising. It is currently best run on Linux hardware. If authors use special macro packages, Hermes can output content MathML markup, which is basically unique among TeX converters."

"In general, both Word and LaTeX conversions are difficult, time- and labor-intensive tasks, except in rare situations where the authoring is rigorously controlled. Consequently, virtually all of the production workflows with which we are familiar outsource the conversion of manuscripts."

"Like all XML languages, MathML is verbose and not intended for direct human editing, therefore WYSIWYG tools are essential for productivity."

"Another common workflow pattern, particularly in enterprise settings, arises when output formatting is fairly regular and not too complex (e.g., regular updates to technical manuals). In these situations, the emphasis is usually on coming up with a robust, high-volume, hands-off composition process. Such workflows are more likely to rely on techniques such as using XSL to produce HTML, or XSL-FO engines."

MathML Workflows in STM Publishing
http://www.dessci.com/en/reference/white_papers/mathml_workflows.htm

"One of the chief characteristics of STM (Scientific, Technical, Medical) content is the presence of mathematical equations. ... Now that many publishers are moving to a production system built around a central XML-based repository, describing mathematics using MathML, the XML-based language for mathematics, is a better choice. And, support for MathML is virtually an absolute requirement for targeting the new HTML+MathML delivery medium for publishing web content containing math. "

"MathType 5 has the ability to convert equations to MathML. This can be done one equation at a time, but usually an entire Word document is converted to HTML+MathML using MathType's MathPage feature. A web page produced in this manner can be published directly to the web but in an XML-based production system, a transformation could be done on the page to get it into the repository. MathType's conversion capabilities are also available through a scripting API, which can be used to automate conversion of equations to MathML in a workflow setting."

"MathType is not a true MathML editor as it contains features that have no analog in MathML. MathType produces MathML as a translation process and, like most translations, the results are not 100% equivalent to the original. MathType is also only capable of producing Presentation MathML, rather than Content MathML."

"The MathFlow and WebEQ Editors, on the other hand, are MathML editors from the start — they represent the equation internally in MathML and read and save in MathML."

"As TeX must always be converted to MathML, there's not much to say about the authoring process for TeX except perhaps that such authors should consider MacKichan's Scientific Word and Workplace as these are TeX-oriented authoring systems that can save as MathML."

"The mathematics representation of both TeX and LaTeX is equivalent to Presentation MathML. Except for trivial mathematics, conversion to Content MathML is problematic."

"Computer algebra systems, like Waterloo Maple's Maple [14] and Wolfram Research's Mathematica [15], are built around a "notebook" interface and contain conversion to and from MathML. This should make it possible for a scientist or engineer to do their basic research and documentation within the interactive environment of these products. They can then submit such a notebook document to the publisher for conversion and integration into the XML repository. In fact, Mathematica version 4.2's notebook files are XML-based so, in theory, an XML-to-XML transformation is all that would be needed to incorporate a notebook into a publisher's XML repository."

"TeX4ht is a free software package for converting TeX and LaTeX documents into various HTML and XML formats. It is highly configurable and supports conversion of equations into MathML."

"If the output medium for the publication is HTML+MathML, the conversion is fairly simple. XSLT can be used to transform the repository XML items into HTML elements. "

"If the output medium is PDF or PostScript for print, the process is a bit more involved. One route is with XyEnterprise's XPP product [21] which combines a content management system with PDF and print output processing and MathML support."

"Another possible route to print or PDF is by converting the repository XML to XSL-FO, using XSLT or other text-to-text conversion tools. XSL-FO (FO = Formatting Objects) [22] is an XML-based language for describing the layout of paginated documents. ... Unfortunately, XSL-FO does not support mathematical notation. However, Design Science is working with vendors of XSL-FO formatters to combine our MathPlayer MathML formatting technology with their products to create a comprehensive output solution."

The W3C MathML software list
http://www.w3.org/Math/Software/mathml_software.html

Categories include:

* Browsers
* Browser plugins, scripts and extensions
* Editors
* Scientific Computation
* Composition and Rendering Engines
* Converters
* Authoring Systems
* Stylesheets to/from MathML
* DTDs and Schemas using MathML
* Components and SDKs
* Research Projects
* Accessibility

Putting mathematics on the Web with MathML
http://www.w3.org/Math/XSL/

Including MathML in Web pages

In order to maximize the number of platforms it will be viewable on, a document should be written using the rules below.

1. Create the page using XHTML with inlined MathML.
2. Add a stylesheet processing instruction.

--------

Some now believe that XHTML+MathML is THE math web publishing standard. Most if not all of the STM publishing client side software (Scientific WorkPlace, Mathematica + Publicon, Maple, MS Word + MathType, WebEQ, SciWriter, and XmetaL + MathFlow) have an option to publish as XHTML+MathML.

MathType 5.0's MathPage provides a facility to export a Word doc into XHTML+Presentation-MathML. This is precisely the same functionality that we currently provide in the CNX word importer. The CNX word importer does 80% of its job well, the remainder not so much. We could easily spend multiples of the work we have already put into the word importer just to address the last 20%. I wanted to investigate the quality of XHTML code MathPage generated. My assumption was that since Design Science had made a revenue producing product (MathType 5.0) that they would have had to do the due diligence to get their XHTML export acceptable to customers.

The MathPage exported XHTML does look very nice in the browser (a claim we can not always make).

The MathPage exported XHTML does not unfortunately look as good in a simple text editor. Some structural information is missing from the XHTML, like in lists. The structural information is essential in converting the XHTML into CNXML. I saw cases where the CNXML importer did a better job with the structure than MathPage.

MathPage did transform all of the image files to file types that can be displayed on the web.

Formulator MathML Weaver 3.7 is a standalone WYSIWYG MathML editor that can produce either Presentation or Content MathML. Formulator is also relatively inexpensive at $20 with academic discount.

With reading the fine manual, I was able to create Presentation and Content MathML. Formulator provided an expression view, a MathML tree view, a MathML markup view and finally a HTML view. The MathML can be edited via the first three views.

After creating several equations without the manual, I did read the manual, a pdf that I downloaded from from the Formulator site. I found the documentation both good and thorough.

How would Formulator integrate into the CNXML author workflow?

1. MS Word authors could switch out the Presentation-MathML with Content-MathML create in Formulator, as one of their many copy edit steps post importing.

2. New authors could create Content-MathML in Formulator. If the author's starting point is MS Word, the MathML equations would be developed in separate documents and work flow steps. If the author is writing the CNXML directly, again the MathML would be created and maintained separately.

Separate MathML editing is obviously not the preferred "one stop" solution from the author's perspective.

SciWriter 2.0 is a Windows stand alone XHTML+Presentation-MathML editor which is relatively inexpensive, $49 for a single academic license. SciWriter stores its document in XHTML+Presentation-MathML (.xml file).

Text styles include Paragraph, Heading{1,2,3,4,5,6}, List, Ordered List, Title, Abstract, and Footnote. These styles appear to be mostly a subset of CNXML which implies that the xform (at least at the conceptual level) from SciWriter XHTML to CNXML should be doable.

The XHTML generated from SciWriter is minimalistic and straight forward. Translating to CNXML appears to be doable.

SciWriter also has some styles associated with the math called Theorem Environments which include Acknowledgement, Algorith, Axiom, Case, Claim, Comment, Conclusion, Condition, Conjecture, Corollary, Criterion, Definition, Example, Explanation, Exercise, Lemma, Notation, Problem, Proof, Proposition, Remark, Solution, Summary, and Theorem. Not all of these have counterparts in CNXML. Translating into CNXML will likely remove some of the semantic meaning.

IMO SciWriter may be a good fit for our project, for author who looking to add content with math from scratch. Given the minimal set of text style, new non-math authors might also find SciWriter appealing.

Importing just the XHTML+Presentation-MathML may not be a complete one step solution, if we leave behind the separate image files.

In our existing Scientific Writer import pathway, the image files have to be added by hand after the XHTML has been imported.

A comprehensive, one step solution would be to bundle the XHTML and image files in a zip file and import the zip file.

As an example, this the XHTML generated by SciWriter for a stand alone figure which we would want to xformed into <figure> + <media> CNXML:

<div class="s4s-table-center">
<table class="s4s-figure">
<tbody>
<tr>
<td align="center">
<img width="50%" alt="WallaceAndGrommet" src="brian_files/WallaceAndGrommet.jpg" />
</td>
</tr>
<tr>
<td class="s4s-figure-numbered" align="center">
<span class="s4s-figure-number">Figure 1.2: </span>[Wallace and Gromit]</td>
</tr>
</tbody>
</table>
</div>

To get the desired presentation in XHTML a table was used with a row for the image and for the caption. A XSL xform could key off of the XHTML node class names to differentiate this table from a real table. The XHTML node class names are specific to the exporter, i.e. SciWriter.

I think it is a safe generalization that each of the different XHTML exporters have their own pattern of XHTML usage. Each XHTML exporter would likely then need its own CNX importer.

XXE allows a standalone MathML file to edited. The XXE UI provides a tree view of the MathML and contextually knows which nodes can be added in the tree.

I also took a CNXML module, both with and without MathML, and edited it in XXE. I was able to edit both via the tree view. XXE also knew contextually what CNXML and MathML elements could be inserted where.

Finally I used XXE to edit a Simplified DocBook file. XXE had WYSIWYG editing for Simplified DocBook. FWIW XXE supports WYSIWYG Simplified DocBook editing via an plug-in (optionally provided by XXE).

Exchanger is not WYSIWYG and tree view editor, more of a smart text editor.

For DocBook files, Exchanger has a feature ("Insert Fragment") which will ease the editing pain by allow the user to easily add a DocBook tag and and end tag, based on what is possible from the DTD.

For MathML files, I could not get the "Insert Fragment" feature to work.

Review of XMLmind XML Editor 3.5
http://www.winwriters.com/articles/xmlmind/index.html
http://www.hyperwrite.com/features/XMLmind_review.html

Review of Cladonia Exchanger XML Editor ver 3.2
http://www.winwriters.com/articles/exchanger/index.html

XXE WYSIWYG DocBook editing is not the same as Word WYSIWYG editing. Some styles selections in Word are driven to get the right presentation. Style selections in XXE require the end user to understand the DocBook structure and thus the semantics.

XXE WYSIWYG DocBook editing still does not rule out the end user abusing the structure to get the right presentation.

(A motivating example for the above is that in Word the end user can center a list by enclosing the list of note with one or more single item lists. Each new enclosing list pushes the list of note closer to the center of the page.)

A truism may be that an XML author necessarily will need to be more conscious of the document structure.

From a pro OpenOffice.org and ODF blog ...

http://www.robweir.com/blog/2007/04/math-markup-marked-down.html

The magazine Science says ...

"Because of changes Microsoft has made in its recent Word release that are incompatible with our internal workflow, which was built around previous versions of the software, Science cannot at present accept any files in the new .docx format produced through Microsoft Word 2007, either for initial submission or for revision. Users of this release of Word should convert these files to a format compatible with Word 2003 or Word for Macintosh 2004 (or, for initial submission, to a PDF file) before submitting to Science."

"Users of Word 2007 should also be aware that equations created with the default equation editor included in Microsoft Word 2007 will be unacceptable in revision, even if the file is converted to a format compatible with earlier versions of Word; this is because conversion will render equations as graphics and prevent electronic printing of equations, and because the default equation editor packaged with Word 2007 -- for reasons that, quite frankly, utterly baffle us -- was not designed to be compatible with MathML. Regrettably, we will be forced to return any revised manuscript created with the Word 2007 default equation editor to authors for re-editing. To get around this, please use the MathType equation editor or the equation editor included in previous versions of Microsoft Word."

MathType and Design Science may live to see another day.

The magazine Nature says ...

"We currently cannot accept files saved in Microsoft Office 2007 formats. Equations and special characters (for example, Greek letters) cannot be edited and are incompatible with Nature's own editing and typesetting programs."

Strong words indeed from Science and Nature.

The author of the blog (Rob Weir) had this to say ...

"The choice to invent a new "Open Math Markup Language" rather then use the well-established existing standard, MathML, appears to be a serious flaw."

http://www.texmacs.org
http://www.texmacs.org/Samples/texmacs.pdf

"Above all, TeXmacs can be used to write structured documents with mathematical formulas. As the name suggests, we have been inspired by the TeX-LaTeX system [Knu84, Lam94, GMS93] from the typesetting point of view and the emphasis on content rather than presentation. However, we do believe that presentation is important during the writing phase. Much like high quality typesetting allows the reader to concentrate on what he is reading, a good editor should allow the author to concentrate on what is written and not on how it is written. In particular, TeXmacs does not rely on TeX-LaTeX, but has been written from scratch to be both structured and wysiwyg (what-you-see-is-what-you-get). This makes the program more efficient to learn and use than TeX-LaTeX, without sacrificing its major advantages."

---

Redux

1. WYSIWYG MathML editor
2. Exports XHTML+MathML and LaTeX
3. Creates structured documents
4. Emphasis on content rather than presentation
5. Runs on both Windows and Linux (where the Windows app is a Linux port)
6. LaTex commands can be entered instead of WYSIWYG
7. Positioning itself as a scientific office suite