.. _configure-MMLorHTML: ************************************************ The MMLorHTML configuration options (Deprecated) ************************************************ .. warning:: This extension has been deprecated in MathJax v2.6. The options below control the operation of the MMLorHTML configuration file that is run when you include ``"MMLorHTML.js"`` in the `config` array of your configuration, or when you use one of the combined configuration files that ends with ``_HTMLorMML``. They are listed with their default values. To set any of these options, include a ``MMLorHTML`` section in your :meth:`MathJax.Hub.Config()` call. For example .. code-block:: javascript MathJax.Hub.Config({ MMLorHTML: { prefer: { Opera: "MML" } } }); would set the ``prefer`` option so that the Opera browser would prefer MathML to HTML-CSS output (while leaving the settings for other browsers unchanged). Note that if you use the ``MMLorHTML.js`` configuration file, you should **not** specify an output processor in the `jax` array of your configuration; `MMLorHTML` will fill that in for you. .. describe:: prefer: { MSIE: "MML", Firefox: "HTML", Safari: "HTML", Chrome: "HTML", Opera: "HTML", other: "HTML" } This lets you set the preferred renderer on a browser-by-browser basis. You set the browser to either ``"MML"`` or ``"HTML"`` depending on whether you want to use the `NativeMML` or `HTML-CSS` output processor. Note that although Opera and Safari do process some MathML natively, their support is not sufficient to handle the more complicated output generated by MathJax, so their settings are ``"HTML"`` by default. Although Firefox does support a large subset of MathJax, it does not implement all the features needed by MathJax, and so it is also set to ``"HTML"`` by default (this is new in v2.0). Note that users can still use the MathJax contextual menu to select a different renderer after the default one has been chosen by ``MMLorHTML.js``. MathJax produces MathML that models the underlying mathematics as best it can, rather than using complicated hacks to improve output for a particular MathML implementation. When you make the choice to use the NativeMML output processor, you are making a trade-off: gaining speed at the expense of quality and reliability, a decision that should not be taken lightly.