Mathjax-v2.2-feature-discussion.md

@@ -2,6 +2,8 @@ For the broader document see [[Mathjax v2.x potential features discussion]]
 
 ### Localization
 
+fredw: A priority for MathJax v2.2, since it is [blocker in Wikimedia](https://bugzilla.wikimedia.org/show_bug.cgi?id=35038)
+
 For the full requirements and discussion, see [[MathJax v2.x potential feature: localization]]
 
 Let's try to boil down how far we can address the requirements in v2.2
@@ -79,6 +81,8 @@ Apply to
 
 ### Fonts & Characters
 
+fredw: We will only consider STIX (and perhaps Asana) support in the list below.
+
 * Add [[STIX and Asana]] support
      * Create fontdata and webfonts
      * investigate potential for crowdsourcing fontdata generation
@@ -87,7 +91,7 @@ Apply to
 
 ### TeX input enhancements
 
-* incorporate Davide's amscd code.
+* incorporate Davide's amscd code. See [issue 420](https://github.com/mathjax/MathJax/issues/420)
 * investigate a LaTeX2e extra symbols extension. 
 * offer instiki syntax as input -> **not a priority** (instiki never exposes its TeX syntax but converts to MathML). fred: actually instiki just uses itex2MML and I think has an option to use blahtex. Both tools are open source so the syntax is known. peter: true but we should probably open up another section for "input processors"? fred: it's probably overkill to implement input processors for itex2MML or blahtex. They basically rely on the same LaTeX-like syntax as MathJax TeX input processor. Extensions to add LaTeX commands that are specific to these languages and not included in the default TeX input Jax sound more appropriate. peter: good point. I was also thinking about possibly different syntax, say maple, but that's out of the scope anyway. fred: OK, I was really only talking about instiki here (I guess it does not support maple), but opening a section for other input processor too is fine. I haven't seen requests from users for other input processors, though.
 
@@ -98,14 +102,15 @@ Missing features (from [the documentation](http://docs.mathjax.org/en/latest/mat
 * alignment groups in tables
 * right-to-left rendering
 * annotation-xml (to include non-mathml content, e.g., svg , (in particular in epub?))
+  fred: it is already supported, but we could improve the access to the data from the menu. See [[Usage-of-the-semantics-element]] and [issue 357](https://github.com/mathjax/MathJax/issues/357)
 * complete table attributes (e.g., columnspan and rowspan)
 
 Other topics
 * Improve line-breaking
-* Investigate Davide Carlisle's Content to Presentation xslt/javascript solution. 
+* Investigate Davide Carlisle's Content to Presentation xslt/javascript solution.  See [issue 404](https://github.com/mathjax/MathJax/issues/404)
     * fred: Perhaps we could do the conversion Content MathML => Presentation MathML in the MathML input Jax processor (maybe making this optional) and not necessarily using the XSLT (not sure whether it is available to all browsers). 
     * peter: sure, I don't know where it fits best. From what I can google, all our supported browsers do xslt 1.0 but I have no idea how performance is anyway. 
     * fred: if they all support XSLT 1.0 then I think it would be very easy to add a configuration option in the MathML input Jax to call David Carlisle's stylesheet before processing them. Given that content MathML is not a top priority, that would just give a convenient option for authors that need it on their pages without impacting other users. And we don't have to worry too much about performance or imperfect content to presentation mapping, I guess. The idea would be to modify the DOM to have: <math><semantics>[presentation MathML ouput]<annotation-xml encoding="application/mathml-content+xml">[content MathML input]</annotation-xml></semantics></math> (no need to create a new semantics if it already exists).
-* Encourage use of <mrow>+<mo> construction instead of <mfenced>. See https://groups.google.com/forum/#!topic/mathjax-dev/GIvpWSNJrgA/discussion
+* Encourage use of <mrow>+<mo> construction instead of <mfenced>. See https://groups.google.com/forum/#!topic/mathjax-dev/GIvpWSNJrgA/discussion and [issue 359](https://github.com/mathjax/MathJax/issues/359)
     * needs to be fleshed out after dev meeting: focus is on native MathML support. Switching will make NativeMML on Opera worse, but Opera is not on our target list and nativeMML is not suggested on Opera anyway.
     * We can also do this conversion in the NativeMML output for all browsers but Opera.
\ No newline at end of file