To elaborate a bit, this was just an example. More generally, we should use the substitution described here:

• signature.asc833 BDownload

Le 08/02/2017 à 19:13, Physikerwelt a écrit :

Physikerwelt added a subscriber: fredw.
Physikerwelt added a comment.

@Jdlrobson https://phabricator.wikimedia.org/p/Jdlrobson/ @fredw
https://phabricator.wikimedia.org/p/fredw/ is still actively maintaining the
package as far as I know... how would you change the selector?

Adapting the CSS and updating the extension would be straightforward,
hopefully this can be done in a backward compatible way (i.e. the new
version of the addon would still work will previous versions of mediawiki).

Le 13/10/2016 à 11:58, Physikerwelt a écrit :

However, I think we should enable MathML without plugin (at least for some known
good browser / OS combinations).
@fredw https://phabricator.wikimedia.org/p/fredw/ What are your thoughts on that?

I don't think things have changed much since the last time you asked.
This will require coordination between various actors, so we should
probably discuss that in the MathML association.

Just a note: some people use CSS to force native MathML to be displayed
(in a user stylesheet, addon etc) so the optimization of not loaded SVG
images still makes sense for them.

Le 24/04/2016 20:32, Edokter a écrit :

@fredw, the current release version (45) still uses the internal font stack, which is why I find it odd we override it in the first place. But if the internal stack is removed, we may as well leave it.

I think the rule was added in MediaWiki before
https://bugzilla.mozilla.org/show_bug.cgi?id=947654 was fixed. The
internal stack is unlikely to be removed soon (except if in the very
long term all text fonts get a math companion and then Gecko can switch
to math font "automatically").

Note that I was rather talking about that add-on:
https://addons.mozilla.org/en-US/firefox/addon/mathjax-native-mathml/

On
https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Common.css#Schriftgr.C3.B6.C3.9Fe_f.C3.BCr_MathML,
there is a reference to
https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js
and to the x-math properties.

Note that this should not be needed if the math font style is consistent
with the one of the text font (e.g. Latin Modern with Latin Modern
Math). The percent is a bit arbitrary and won't work for everybody.
Unfortunately very few standard fonts have a math companion and few math
fonts are available on OS at the moment...

Also, note that one can use CSS to select between MathML, SVG or PNG:

menclose updiagonalstrike represents some content that is struck out and
this can be exposed as it into the accessible tree. ATs do not need any
heuristics to transmit that presentation to the user and following's
Abraham Nemeth idea it is then up to the user to deduce the mathematical
meaning. This is the best you can do with presentation MathML to make
things accessible. As a comparison, MathJax's solution is really a
visual-only hack: a zero-width BIG SOLIDUS followed by the content.

Note that this is already fixed in Debian testing. I'm note familiar
with Ubuntu process and how they import Debian's packages but the next
release Ubuntu 16.04 LTS will be published next April:
https://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Ubuntu_16.04_LTS_.28Xenial_Xerus.29

This is a bug in the Latin Modern Math version distributed by Ubuntu.
You should ask your distro maintainer to upgrade to version 1.959. See
https://bugs.launchpad.net/ubuntu/+source/lmodern/+bug/1502701. For now,
you can install the latest version from the official web site.

I think unicode-math is also based on David Carlisle's unicode.xml so that should be the same commands. (but please check)

I don't have preference, but please check http://ctan.org/pkg/unicode-math and their GitHub repo.

Again, there are two bugs here:

I checked the http://www.mathmlcentral.com/Tools/FromMathML.jsp to generate a png from the first mathml input and it looks about right.

See https://phabricator.wikimedia.org/T106890#1483157 for how force an increment of scriptlevel (btw, it would probably more convenient if the scriptlevel attribute was allowed on the mtable element...)

Any updates here https://bugzilla.mozilla.org/show_bug.cgi?id=1187682 seems to be stalled.

I removed my comment about Windows line spacing bug has it is fixed in Gecko 41. Latin Modern Math should now work on all platforms. For details, see https://lists.w3.org/Archives/Public/www-math/2015Sep/0031.html

If you are talking about the "SVG fallback" of the MathML mode, then that is expected: different CSS properties are necessary to change the color of SVG paths. This does not happen in when "MathML" is really used since it just inherits the text colors.

Why is SVG fallback now broken for Chrome-like browsers?

In T99369#1484437, @Pkra wrote:

Finally, I realize we have a history and I don't want to start a fight. But @fredw, could you please *not* speculate about MathJax technology or opinions of MathJax team members? That can mislead people (just like inaccurate comments about Firefox MathML support can). If there's a question about how MathJax or MathJax-node works, we're happy to answer it.

In MathML the size reduction of \begin{smallmatrix} compared to \begin{matrix} is only about 75%. In the SVG mode its more like 65% and in PNG mode its close to 50%. It looks like the font size is not decreased at all, whereas in other modes a smaller font is used.

In T106890#1483182, @Physikerwelt wrote:

Just to be sure to chatch the right one you mean this https://github.com/mathjax/MathJax/issues/839 bug?

Not beforehand, but if you search "displaystyle" on the MathJax github issue or on the MathML mailing list, you should be able to find it.

In T106890#1483149, @Physikerwelt wrote:

@fredw: So to fix this problem we could include

math {
  line-height: normal;
}

To our custom math.css?

Regarding the font-size itself: this seems to be a bug in MathJax. If I set <mstyle scriptlevel="+1"> around the <mtable>, I get the expected text size reduction in Gecko.

line-height: normal also improves the linespacing of https://en.wikipedia.org/wiki/E8_%28mathematics%29 but I'm not sure what's expected for the font-size.

So I'm wondering whether it's a bug in Gecko or whether the style on the Wiki page is interfering with the native MathML rendering...

Here is what I get for https://en.wikipedia.org/wiki/Hecke_operator using Gecko:

What is stopping us from using MathJax to generate HTML/CSS and send that to the browser?

@SalixAlba: Thank you for your comment.

I think it was https://phabricator.wikimedia.org/T74806

Moritz: I think I already reported this bug in the past. IIRC, it was due to the fact that mathoid puts space in the source code around the math output...

As I read the comments, it seems that people have limited knowlegde & distorted information about the MathJax / KaTeX / MediaWiki / Browser developments and, sadly, know almost nothing about the technical implementation details... so I'm not sure it is very efficient to try arguing or countering the falsehoods about MathML. Instead, I'll just write one post with a few (hopefully helpful) remarks on MediaWiki math and then go back to doing more constructive work for math rendering on the Web...

I don't know what you mean by "how MathJax looks now and how it should look like". As said in the first comment, it's not a problem with the visual rendering but with the way the generated MathML, which has bad semantics and so makes things hard for assistive technologies.

Does anyone know about this special notation for limits? This looks a TeX hack to achieve a purely visual distinction for "alternative limits style".

So since this bug was confusely used by the MathJax team to justify their refusal to provide MathML in the DOM by default in order to help assistive technologies, I'd like to clarify the issue: