A formatter like this is not supposed to check if the format is known
or not. The code calling these formatters can introduce new (sub) formats
any time. What a formatter like this should do then are two things:
* If it's some HTML format, always return HTML.
* If you really can't identify the format, do a sensible fallback.
This currently blocks introducing a new format in Wikibase.
Bug: T46727
Change-Id: I585069e8f2ba33ec657ca4d514c6d502fe0f5ba3
This version (for MediaWiki 1.31) has some changes since previous versions:
By default the math rendering service from the Wikimedia Foundation located at
https://wikimedia.org/api/rest_v1/
will be used for math rendering.
Therefore php-curl is required.
cf. https://www.mediawiki.org/wiki/Manual:CURL
Consult https://www.mediawiki.org/wiki/Extension:Math for further information and advanced settings.
Attributes of the <math /> element:
attribute "display":
possible values: "inline", "block" or "inline-displaystyle" (default)
"display" reproduces the old texvc behavior:
The equation is rendered with large height operands (texvc used $$ $tex $$ to render)
but the equation printed to the current line of the output and not centered in a new line.
In Wikipedia users use :<math>$tex</math> to move the math element closer to the center.
"inline" renders the equation in with small height operands by adding {\textstyle $tex } to the
users input ($tex). The equation is displayed in the current text line.
"inline-displaystyle" renders the equation in with large height operands centered in a new line by adding
{\displaystyle $tex } to the user input ($tex).
For testing your installation run
php tests/phpunit/phpunit.php extensions/Math/tests/
from your MediWiki home path.
== Logging ==
The math extension supports PSR-3 logging:
Configuration can be dona via
$wgDebugLogGroups['Math'] = [ 'level' => 'info', 'destination' => '/path/to/file.log' ];