Dear all,

today I did some changes to simplify the math plug in a little bit and
as a preparation to the LaTeXML integration:
Please review and comment at:
https://gerrit.wikimedia.org/r/#/c/28824/

Best regards
Moritz
PS: I had some problems with the commit messages. They were not
accepted so the text is lost.
What I basically did that I separated the code of the divers ways of
rendering into separate classes that extend a common base class.


On Mon, Oct 15, 2012 at 12:13 AM, Moritz Schubotz
<[email protected]> wrote:
> HI DJ,
>
> first of all thanks a lot for your helpful comments.
>
> On Sun, Oct 14, 2012 at 10:31 PM, Derk-Jan Hartman
> <[email protected]> wrote:
>> On 14 okt. 2012, at 17:45, Moritz Schubotz <[email protected]> wrote:
>>
>>> Summary: I'm looking for people to discuss about the parsing of math.
>>
>> The last person who really did some work on the extension was Brion Vibber. 
>> Almost all of the (limited) work that has gone into the extension over the 
>> last 1,5 year was actually based on the efforts of User:Nageh on the English 
>> wikipedia and his MathJax userscript. Beyond these MathJax changes, the 
>> extension has not seen much developer involvement for quite some while.
>>
>>> I came up with a proposal for a new version of the rendering of the
>>> <math> tag. I proposed to use LaTeXML to convert the LaTeX expressions
>>> in the math tag to MathML. If the browser is not capable of displaying
>>> MathML I use MathJaX to display the MathML output in the browser.
>>> My implementation (the LaTeXML branch) has only a few very little
>>> differences in contrast to the master branch. I have the feeling that
>>> the php code of the math extensions could be improved. For example I'd
>>> suggest to put all the texvc related stuff to another class.
>>> Furthermore I was thinking about an asynchronous rendering of the
>>> formula, which would speed up page loading time especially for major
>>> edits.
>>> At
>>> http://wiki.physikerwelt.de/images/text_math_search.pdf
>>> you find the draft of a paper where I describe in detail what
>>> I changed and why it is an improvement. The paper will appear soon in
>>> the postconference proceedings of CICM2012.
>>> Now I want to figure out, who is working on the development of the
>>> math extension, and who wants to discuss with me about our ideas.
>>> I'm open to any kind of suggestions and questions.
>>
>> Discussion is always welcomed and in this case probably best on the 
>> mailinglist.
>>
>> You seem to propose switching our current texvc -> image converter (by some 
>> users extended by using MathJax) with a LaTeX -> MathML presentational 
>> renderer that would use MathJax as a backup. The renderer would also output 
>> Content MathML to make the content easier to index and search. In general I 
>> would support this, definitely morally.
>
> I see MathJaX rather as a renering engine that supports browsers that
> do not such a good job in displaying MathML, rather than a fall back
> alternative.
>
>>
>> There are however some problems here as well.
>> - If a browser does not support MathML and not support (have enabled) 
>> Javascript, you would see nothing reading the article.
>>
>
> MathML is also capable of producing images. However this feature is
> more designed for the rendering of whole documents rather than for
> small latex snippets. So this would require a little customization.
>
>> - Browser support for MathML is still spotty. It would be nice if we can 
>> gather some actual numbers on this. There are apparently also significant 
>> bugs in rendering implementations. I believe this is one of the reasons that 
>> the default of MathJax is HTML+CSS now, and not MathML.
>>
>> - You are determining support serverside right now ? This would require 
>> fragmenting the cache when we move forward.
>
> I'm nor sure if I understand, what you mean by that. The math table
> becomes much larger as it is if you use texvc, since the matml column
> contains all the mathml code which is not really optimized with regard
> to space.
>
>>
>> - I think that currently a large group of users would fall into your MathJax 
>> group. Especially those with older browsers. However, we don't particularly 
>> like MathJax for that usergroup. It is incredibly slow on the client side 
>> and this greatly affects the userbase with less capable computers (of which 
>> we have quite a lot). This is one of the main reasons why we are not 
>> particularly pushing for this solution as a default right now (let alone as 
>> the primary backup method). I would seriously consider just skipping MathJax 
>> (at least by default) and just show images for the fallback option.
>
> MathJaX is slow if you want to display LateX stuff. If you want to
> display MathML with the help of MathJaX- that's what I propose-
> MathJaX is reasonably fast.
>>
>> - In order to provide proper MathML support, a proper font is required. Many 
>> Operating Systems do not yet have this font support. This is something that 
>> possibly could be solved with WebFonts, but will require a bit of work.
>>
>> - MathML does not, I believe, provide everything that is possible with 
>> texvc. This is another issue that we are currently seeing with MathJax, 
>> though we (Nagheh actually) has added most of them to MathJax by now. For 
>> MathML the solution seems not so simple however. This probably means we 
>> either need to phase out part of what we currently support (always 
>> complicated) or fragment the implementation for these particular situations.
>
> This would be really interesting to see which are those things, that
> can not be displayed with MathML.
>
>>
>> - I'm not aware of the current quality of LaTexML. Is there some information 
>> about the 'completeness' of the capabilities and quality of the 
>> implementation? Comparisons with other implementations ? That would be 
>> useful information.
>
> I'll provide some information soon.
>>
>> - Outputting both Presentational and Content MathML into the HTML will 
>> significantly increase the page size.
>
> This is true. I saw that in my experiments.
>
>>
>> - LaTeXML will have to be reviewed by one of the developers of the security 
>> team.
>>
>
> Yes. I think the major advantage of LaTeXML in contrast to texvc is
> that it can be run on a separate machine, with very restricted rights.
>
>> These would be the issues that I think would require assessment and solving 
>> at some point before a full solution can be deployed on Wikipedia. But of 
>> course, we can just start and expose the functionality at a later time.
>>
>> DJ
>>
>>
>> P.S. Seems that MathJax 2.1 will be released soon: 
>> http://www.mathjax.org/2012/10/01/news/mathjax-v2-1-beta-now-available-on-the-cdn/
>> _______________________________________________
>> MediaWiki-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> Thanks again for the feedback.
>
> Best regards
> Moritz
>
> --
> Mit freundlichen Grüßen
> Moritz Schubotz
>
>   Telefon (Büro):  +49 30 314 22784
>   Telefon (Privat):+49 30 488 27330
>   E-Mail: [email protected]
>   Web: http://www.physikerwelt.de
>   Skype: Schubi87
>   ICQ: 200302764
>   Msn: [email protected]



-- 
Mit freundlichen Grüßen
Moritz Schubotz

  Telefon (Büro):  +49 30 314 22784
  Telefon (Privat):+49 30 488 27330
  E-Mail: [email protected]
  Web: http://www.physikerwelt.de
  Skype: Schubi87
  ICQ: 200302764
  Msn: [email protected]

_______________________________________________
Wikitext-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitext-l

Reply via email to