-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Mathjax backlog
We collect potential features. This is not a discussion area but a presentation area for review. Each feature should be accompanied by a short description outlining its purpose and functionality (possibly a user story).
Authors and Readers want to use the MathJax user interface in their native language. MathJax currently uses a number of English language strings in its UI, namely the MathJax Menu and the various messages (processing, error etc). To support global use of MathJax, a full localization of the UI allows MathJax users to flexibly decide on the locale and allows translators to contribute easily and efficiently.
Authors want to specify the UI language depending on the language of their content. Authors want to load translations they supply themselves, just like configuration options in general.
Readers want to be able to set the UI to their language of choice. Readers want to be able to copy&paste math even if they don't understand the surrounding language.
Developers want to use MathJax outside the DOM for testing. MathJax depends on the DOM and parts of its functionality does not make sense outside the DOM. We want to enable MathJax outside the DOM to the extent possible and provide APIs for servers-side javascript implementations.
Authors want to know how fast MathJax should be. Authors and Developers want to track down performance bottlenecks.
We want to be able to test speed enhancements.
Users want their AT tools to pick up MathJax-generated content just as well as regular MathML.
AT vendors want to use a robust API to seamlessly integrate with MathJax rendering. This currently includes User preference negotiation, Highlighting, Sync-Highlighting and copy & paste.
Open source solutions (like Benetech's prototype or possibly ChromeVox) want to integrate into MathJax to provide math speech text and other data for passive AT on mobile platforms.
Authors want the convenience of TeX packages in MathJax.
Authors want to easily input commutative diagrams.
Authors want easy ways to input diagrams like xypics, pstricks and tikz.
Users want documentation for writing TeX input extensions.
Authors don't want to worry about very large equations locking up the browser while rendering. Simileraly, community driven content can't afford to have a page lock up because of "vandalism" with huge MathML equations. Compare: [#425], [#409]