Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 20th 2013

    I hope I don’t have to convince people here of the value of MathML. And I know that several people here are also on G+ so will have already read my post there about this. So I’ll keep it short here. One of the people who’s been working on MathML support in browsers has decided to spend some quality time on this and has started a crowd-funded project to try to get enough money to support the time he’d need to do this. This is not some fly-by-night programmer, this is someone who really knows the ins and outs of MathML support in browsers.

    If you have any spare cash lying around, send it to this guy. The link for his project where you can read far more is http://www.ulule.com/mathematics-ebooks/.

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeNov 21st 2013
    • (edited Nov 21st 2013)

    If that is going in the direction of having more browsers display the nLab math correctly, that would be great.

    I see and hear that plenty of people read the nLab with MathJax displaying its math. But that has some really bad side effects. One is that pages that are a bit longer take yet more time to display, because MathJax is chewing on them. This get’s to the point of making some nLab pages very tedious to load (such as “differential cohesion”) and for some it is such as to drive any sane user away (such as “geometry of physics”, which may take many minutes to display). Another bad effect of MathJax is that it does not display corretly for instance stacked arrows and indices on limits. Plenty of nLab pages just look broken with MathJax.

    Since at the same time, it seems that MathJax is becoming the default for reading math on the web, this is really bad for the nLab.

    • CommentRowNumber3.
    • CommentAuthorAndrew Stacey
    • CommentTimeNov 22nd 2013

    Yes, that’s the goal.

    • CommentRowNumber4.
    • CommentAuthorzskoda
    • CommentTimeNov 27th 2013
    • (edited Nov 27th 2013)

    Concerning the related thread on possible migration to gitit, also using MathML rendering, I came across the math example for gitit.

    The example page, http://gitit.net/Math%20Example says

    If you’re using Safari or Chrome, you may just see a jumble of symbols.

    I said to myself “This is strange, MathML was working in Chrome” (it applies to nnLab as well!).

    Then I looked at news and indeed saw a bad news for all of us (article discussed MathJaX vs. native MathML issues!):

    Google subtracts MathML from Chrome, and anger multiplies, Nov 5, 2013

    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeNov 27th 2013
    • (edited Nov 27th 2013)

    Also Opera doesn’t display MathML. At least mine doesn’t.

    • CommentRowNumber6.
    • CommentAuthorMark Meckes
    • CommentTimeDec 1st 2013

    Slightly off topic, but I recently upgraded to Safari 6.1, which various web sites claim still supports MathML, but the nLab and the Café are now displaying with MathJax for me.

    • CommentRowNumber7.
    • CommentAuthoradeelkh
    • CommentTimeDec 1st 2013
    • (edited Dec 1st 2013)

    Indeed, it should work in Safari according to http://caniuse.com/mathml. It seems to work for me on iOS Safari, so that’s surprising.

    • CommentRowNumber8.
    • CommentAuthorMark Meckes
    • CommentTimeDec 1st 2013

    It turns out that MathML does work if I disable JavaScript. So it appears that Safari is inappropriately going with MathJax first.

    • CommentRowNumber9.
    • CommentAuthorAndrew Stacey
    • CommentTimeDec 1st 2013

    The nLab and nForum test the browser for MathML support and send MathJaX depending on the results of the test. It may be that Safari isn’t reporting that it can handle MathML (or not in the way that the tests are expecting). I’ll look into it.

    • CommentRowNumber10.
    • CommentAuthorMark Meckes
    • CommentTimeDec 1st 2013

    Do you happen to know if the Café works the same way? That’s where I first noticed the issue. I’ve sent a bug report to Apple as well, but it wouldn’t hurt if you can help me submit a more informative one.

    • CommentRowNumber11.
    • CommentAuthorMarc Hoyois
    • CommentTimeDec 1st 2013

    @Mark You can right-click on any formula and select Math Settings > Math Renderer > MathML. This gets stored as a cookie. The first time you do this you get an alert box:

    Your browser’s native MathML does not implement all the features used by MathJax, so some expressions may not render properly.

    Switch the renderer anyway?

    Safari 6.1+’s MathML rendering is clearly not as good as the Javascript rendering, so it may not be a bug that the latter is used as default.

    • CommentRowNumber12.
    • CommentAuthorMark Meckes
    • CommentTimeDec 2nd 2013

    @Marc: Thanks for the information. I’ve never had any problem with the MathML rendering in recent versions of Safari, whereas MathJax is painfully slow for pages with even a moderate number of formulas. Safari 6.1 seems to have introduced some new “features” that make MathML more annoying even after you know how to turn it on.

    • CommentRowNumber13.
    • CommentAuthorAndrew Stacey
    • CommentTimeDec 2nd 2013

    Mark, I seem to be getting the opposite behaviour. The nLab on Safari is rendering with its default MathML renderer. I can’t figure out how to “right-click” to get MathJaX turned back on (indeed, as far as I can tell, Safari isn’t requesting MathJaX).

    • CommentRowNumber14.
    • CommentAuthorMark Meckes
    • CommentTimeDec 2nd 2013

    On my MacBook, I can get the “right-click” behavior with control-click.

    • CommentRowNumber15.
    • CommentAuthorAndrew Stacey
    • CommentTimeDec 2nd 2013
    • (edited Dec 2nd 2013)

    Ah, I had javascript disabled. Now it works. Thanks.

    Incidentally, the test that the nLab performs for whether to add the MathJax header or not is:

    if (!(Prototype.Browser.Gecko || navigator.userAgent.match(/MathPlayer/))) {
     var s = document.createElement('script');
     s.src = "http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=MML_HTMLorMML-full";
     document.querySelector('head').appendChild(s);
    };
    
    • CommentRowNumber16.
    • CommentAuthorUrs
    • CommentTimeDec 6th 2013
    • (edited Dec 6th 2013)

    I have some questions concerning this:

    On that website the person asking for financial support support writes the following:

    Obtaining perfect MathML support in layout engines and ensuring its integration in EPUB readers & ebooks is a very big project. In order to have something achievable in a reasonable time frame, I have selected two main goals:

    Create a collection of educational & scientific documents that will serve as examples & test cases for publishers and implementers.

    Improve rendering quality in WebKit and Gecko so that EPUB publishers can rely on it.

    First question: is it reasonable that half of the project is devoted to “collection of documents” to have examples? Is there any lack of example documents? Should creating/collecting them be more than a small lemma in a project to increase MathML support?

    Second question: this text makes the impression as if that person is about the only person on this planet planning to work on “Obtaining perfect MathML support in layout engines”. Is this right? If no, should this person not check what other teams are working on and connect to that? If yes, if there is really only one private and insecurely funded person left to counteract the general decline in MathML support, what are the hopes that this last straw, as it would then seem, will save us?

    • CommentRowNumber17.
    • CommentAuthorUrs
    • CommentTimeDec 7th 2013
    • (edited Dec 7th 2013)

    I have looked around a little bit, trying to find objective information on the prospects for math support on the web.

    I suppose this text here is worth reading:

    One of the recent topics mentioned there is discussed furthere in the article that Zoran already mentioned above:

    The quick summary is this: all the official browser developer teams ignore and in several cases actively disfavor MathML support. Where support (still) exists it is indeed provided by low numbers of unpaid volunteers. (Krautzberger’s article recounts how the removal of the support by Chrome was triggered by the one single person supporting the project, an unpaid volunteer, having to quit to make a living elsewhere.)

    • CommentRowNumber18.
    • CommentAuthorDavid_Corfield
    • CommentTimeDec 7th 2013

    Am I being dim? What did Shankland mean by this?

    But MathJax, however imperfect, could ultimately help MathML’s prospects. It provides a way to use MathML on the Web, and ultimately such usage is a major factor in whether browser makers support it. In other words, it could help solve the chicken-and-egg problem where browser makers don’t support a technology because it’s not used on the Web, but developers don’t use it on the Web because it’s not supported in browsers.

    • CommentRowNumber19.
    • CommentAuthorUrs
    • CommentTimeDec 7th 2013
    • (edited Dec 7th 2013)

    I guess it means that currently on all those browsers that don’t support MathML, it is MathJax that at least keeps the MathML content visible, for instance without MathJax many people wouldn’t be able to read the nLab unless they changed their preferred system setup.

    I understand that MathML is intended to be the optimal solution for math on the web, and probably in principle indeed it would be, but the evidence seems clear that something about MathML makes browsers not want to support it. Even if private volunteers like the one above write code, it seems increasingly unlikely, from what I read in the above links, that browsers are going to include this code. Chrome and IE are examples of browsers where the developer teams actively pushed away the MathML support that third parties did provide. If a small company like DesignScience is being rejected, I suppose single private persons will have a hard time.

    At the same time, it seems to me that all this discussion is at the wrong level for us, in that it concerns technology that should be behind the scences and not in the forefront. Because here what we as humans actually interact with is 1. we enter a LaTeX dialact, and 2. we see math formulas on the screen. I don’t really care what the process is called that takes us from 1. to 2. as long as it works for the generic user.

    In any case, I suppose we have to live with the prospect that by and large the nLab will be viewed with that intermediate technology being MathJax.

    Now, I notice that many math formulas on the nLab don’t come out right with MathJax, or at least they don’t come out the way that they used to come out by other means. Examples that I see include

    a)

    When stacking arrows as in \stackrel{\to}{\leftarrow} then the right pointing arrows come out much too short unless one explicitly uses “longrightarrow”. This is not the case for many pages on the lab, and they all look bad in MathJax.

    b)

    When typesetting limits, I am used to code such as

       \underset{\rightarrow}{\lim}_{n} X_n
    

    But with MathJax the subscript “nn” here overlaps completely with the arrow and becomes unreadable, contrary to how it used to come out. I need to experiment with this to find a way to make such code come out readable.

    c)

    The biggest problem with MathJax is that it makes pages that are a bit longer increasingly awkward, since the MathJax compiler takes so long to process it. The evident question here is: is it necessary that MathJax compiles the code anew every single time? Can a page not call MathJax on its content once and then store the output?

    • CommentRowNumber20.
    • CommentAuthoradeelkh
    • CommentTimeDec 7th 2013
    • (edited Dec 7th 2013)

    For a) you can use \rightleftarrows to produce \rightleftarrows.

    • CommentRowNumber21.
    • CommentAuthoradeelkh
    • CommentTimeDec 7th 2013

    For b), normally I use the macros \varinjlim/\varprojlim for this (e.g. \varinjlim_n X_n should work). However this requires the amsmath package which seems not be loaded on the nLab.

    • CommentRowNumber22.
    • CommentAuthorUrs
    • CommentTimeDec 7th 2013

    For a): I should have said that this appears a lot in discussion of adjoint triples and quadruples, where rightleftarrows is not sufficient.

    • CommentRowNumber23.
    • CommentAuthorRodMcGuire
    • CommentTimeDec 7th 2013

    I suppose this text here is worth reading:

    That post links to polyfil which gets bandied about in discussions of MathJax like solutions. I had assumed it had something to do with translating math into SVG polygons, but now I know that it refers to a UK spackling paste and means a browser patch or extension achieved through loading 3rd party JavaScript files, that makes the browser conform to the standards it doesn’t support.

    • CommentRowNumber24.
    • CommentAuthorTobyBartels
    • CommentTimeDec 21st 2013

    Yes, I would really like to see (c) implemented.