Long term strategy for math on wikipedia

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Long term strategy for math on wikipedia

Peter Krautzberger
Hi everyone,

There have been a couple of conversations recently and I am hoping to
combine them into a discussion towards a long term strategy for math on
Wikipedia.

To get things rolling, I've added a few topics below which a strategy could
address.

Perhaps a disclaimer: I manage the MathJax project. Also, I've tried to be
brief but I may have compressed too much.

Peter.


(1) math output

Currently, low resolution PNGs are the default and registered users have an
option for MathJax (except on mobile). MathML3 is the web standard for math
and part of HTML5 and epub3.

    Does Wikipedia want to adopt MathML output in the long term?

MathML is still facing a chicken-and-egg problem: little browser support
means little content means little browser support etc. While it's been in
use for over a decade, most MathML is hidden on intranets (technical
documentation) and behind paywalls (publishing). But there's clearly demand
-- e.g. MathJax CDN gets 65 million unique visitors per month.

Wikipedia's long term adoption of MathML would help this crucial web
standard for education and research since browser vendors will see the
content on the open web.

But a web standard is not a value in itself -- luckily MathML has real
advantages.

* accessibility

The few existing math accessibility tools (MathPlayer, ChromeVox, FireVox)
only work with MathML. Modern accessibility features like synchronized
highlighting (for learning disabled readers) is basically impossible with
image rendering.

* rendering quality

Image renderings are not only inaccessible, they lack quality and
flexibility. Reflow, CSS, alignments are the classic problems. Static
images could be improved via SVG but even these would not be accessible or
participate in line breaking. MathML integrates naturally into HTML.

* dynamic content

Math and science are becoming native on the web -- data and markup is not
forced into image renderings anymore, instead dynamic and interactive
content is finally showing up.

These don't fit into the current authoring and rendering solution on
Wikipedia. MathML would be a critical first step towards richer scientific
content.

* editing

Editing math is an obstacle for Wikipedia users. The GSoC project for math
in VE has a lot of potential to lower the barrier. But a live preview is
not very feasible with server side image generation.

(2) math input

wikitext is human readable and serialized so MathML does not seem to fit.
But TeX-syntax is robust and powerful to create any MathML construct. Texvc
has limitations (unicode support, graphical and dynamic content), but the
syntax could be extended to overcome these and to produce dynamic content
(mathapedia is a nice example).

An extended TeX-like syntax might serve as a safe abstraction for tools
like d3.js, processing.js, ensuring that Wikipedia content is not dependent
on specific rendering solutions. The same holds for physical, chemical and
biological markup.  Such TeX extensions do make backwards compatibility to
real TeX/LaTeX more difficult.

(3) First steps towards a transition.

Client-side, only Firefox has decent support, so a polyfill like MathJax
would be needed for a while. Performance, especially on mobile, would need
a thorough investigation.

Server side, there are a number of tools for converting TeX to MathML, in
particular the recent work by Martin Schubotz towards integrating LaTeXML
(a fully featured LaTeX to XML converter); there's also BlahTeX and MathJax
via js-runners.

The question regarding new forms of content and wikitext might be important
for both client and server side solutions.

To pull in the entire community, something like bug 48036 (easier MathJax
opt-in) would be great. It would allow people to vote with their feet and
tell us continually if the benefits of MathML are worth the cost.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

MZMcBride-2
Peter Krautzberger wrote:
>There have been a couple of conversations recently and I am hoping to
>combine them into a discussion towards a long term strategy for math on
>Wikipedia.

Hi.

This mailing list is good for discussion, but for long-term strategy, I
imagine you want an RFC: <https://www.mediawiki.org/wiki/RFC>.

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Quim Gil-2
On 07/18/2013 05:31 AM, MZMcBride wrote:
> Peter Krautzberger wrote:
>> There have been a couple of conversations recently and I am hoping to
>> combine them into a discussion towards a long term strategy for math on
>> Wikipedia.
>
> Hi.
>
> This mailing list is good for discussion, but for long-term strategy, I
> imagine you want an RFC: <https://www.mediawiki.org/wiki/RFC>.

Yesterday I recommended Peter to post here in this list.  :) I think it
is good to test the waters and get a first round of feedback.

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Risker
On 18 July 2013 08:10, Quim Gil <[hidden email]> wrote:

> On 07/18/2013 05:31 AM, MZMcBride wrote:
>
>> Peter Krautzberger wrote:
>>
>>> There have been a couple of conversations recently and I am hoping to
>>> combine them into a discussion towards a long term strategy for math on
>>> Wikipedia.
>>>
>>
>> Hi.
>>
>> This mailing list is good for discussion, but for long-term strategy, I
>> imagine you want an RFC: <https://www.mediawiki.org/**wiki/RFC<https://www.mediawiki.org/wiki/RFC>
>> >.
>>
>
> Yesterday I recommended Peter to post here in this list.  :) I think it is
> good to test the waters and get a first round of feedback.
>
>
There is also some related discussion on the Flow portal.[1] It might be an
idea to pull all of this information together.

Risker

[1]
http://www.mediawiki.org/w/index.php?title=Talk:Flow_Portal&offset=20130718154450&lqt_mustshow=30657#Maths_30340
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
>
>
> >> This mailing list is good for discussion, but for long-term strategy, I
> >> imagine you want an RFC: <https://www.mediawiki.org/**wiki/RFC<
> https://www.mediawiki.org/wiki/RFC>
> >> >.
> >>
> >
> > Yesterday I recommended Peter to post here in this list.  :) I think it
> is
> > good to test the waters and get a first round of feedback.
> >
> >
> There is also some related discussion on the Flow portal.[1] It might be an
> idea to pull all of this information together.
>
> Risker
>
> [1]
>
> http://www.mediawiki.org/w/index.php?title=Talk:Flow_Portal&offset=20130718154450&lqt_mustshow=30657#Maths_30340
>


Thanks for pointing out the Flow discussion.

I'd be happy to write an RFC.

Peter.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Matthew Flaschen-2
On 07/18/2013 12:52 PM, Peter Krautzberger wrote:
> I'd be happy to write an RFC.

That's an option, but it's perfectly reasonable if you want to talk it
out more and let it crystallize some.

Matt Flaschen


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
I'm wondering if the lack of reactions so far is positive or negative. So
let me try to elicit more responses.

Here are three problems I see down the road.

1) A switch to MathML output will come with a performance loss.

Without a polyfill, rendering quality will be lost. With a polyfill,
rendering speed will be lost. MathML polyfills are especially difficult
because they have to replace browser rendering (e.g. they force lots of
layout activity).

2) TeX/LaTeX compatibility might be lost.

"Native" content (e.g. <maction> or even subexpression links) has no
counterpart in TeX. Conservative extensions of TeX can easily enable this
kind of content but backward compatibility will be lost.

3) Supporting MathML might seem risky.

It's easy to only see the current limitations of MathML -- poor browser
experience, poor rendering quality, and browser vendors have shown little
to no interest. While the better comparison might be early HTML with its
limitations, a similar success story is not automatic.

While I do not think any of these are critical problems, I'd be interested
to hear from people who think otherwise.
Peter.




On Thu, Jul 18, 2013 at 3:43 PM, Matthew Flaschen
<[hidden email]>wrote:

> On 07/18/2013 12:52 PM, Peter Krautzberger wrote:
> > I'd be happy to write an RFC.
>
> That's an option, but it's perfectly reasonable if you want to talk it
> out more and let it crystallize some.
>
> Matt Flaschen
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

praveenp
As a user, I like to see more effective server rendered pngs as
default, just because they are simply client independent.

And also: https://bugzilla.wikimedia.org/show_bug.cgi?id=48032

praveenp

On Monday 22 July 2013 06:23:37 AM IST, Peter Krautzberger wrote:

> I'm wondering if the lack of reactions so far is positive or negative. So
> let me try to elicit more responses.
>
> Here are three problems I see down the road.
>
> 1) A switch to MathML output will come with a performance loss.
>
> Without a polyfill, rendering quality will be lost. With a polyfill,
> rendering speed will be lost. MathML polyfills are especially difficult
> because they have to replace browser rendering (e.g. they force lots of
> layout activity).
>
> 2) TeX/LaTeX compatibility might be lost.
>
> "Native" content (e.g. <maction> or even subexpression links) has no
> counterpart in TeX. Conservative extensions of TeX can easily enable this
> kind of content but backward compatibility will be lost.
>
> 3) Supporting MathML might seem risky.
>
> It's easy to only see the current limitations of MathML -- poor browser
> experience, poor rendering quality, and browser vendors have shown little
> to no interest. While the better comparison might be early HTML with its
> limitations, a similar success story is not automatic.
>
> While I do not think any of these are critical problems, I'd be interested
> to hear from people who think otherwise.
> Peter.
>
>
>
>
> On Thu, Jul 18, 2013 at 3:43 PM, Matthew Flaschen
> <[hidden email]>wrote:
>
>> On 07/18/2013 12:52 PM, Peter Krautzberger wrote:
>>> I'd be happy to write an RFC.
>>
>> That's an option, but it's perfectly reasonable if you want to talk it
>> out more and let it crystallize some.
>>
>> Matt Flaschen
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

C. Scott Ananian
As a(nother) user, I have been very pleased to see unicode-complete fonts
gradually make the use of images for non-roman orthography gradually
disappear.  When I see non-English text on a page, greek letters, or simple
expressions with super- and sub-scripts, I can generally highlight, style,
and copy-and-paste it.  This is a huge win.

I would hope that the *long term* direction of math is in the same
direction, even if *short term* some users would like to see better
image-based renders.
 --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Derk-Jan Hartman
> I'm wondering if the lack of reactions so far is positive or negative.

It's negative, it shows that few people have the confidence to think they
have something worthwhile to contribute on this niche area. :(

Output:
I'd love to support MathML as primary direction, but I still see huge
problems there. These problems are mostly in browser and OS support.

I'm in favor of Wikipedia 'taking lead' in this, icw. a fallback strategy.
The best fallback strategy is likely images. MathJax is nice for Math fans,
but for a large part of our casual users a total nightmare to load, so I
would not favor that for anything other than opt in.

Besides that, the biggest problem I see is in symbol consistency. If STiX
would get their act together and focus on what is important, then this
problem likely would have been solved already about 3 years ago.

So what I would actually propose for the short term (next few years) in
case we really want to go the direction of MathML is the following:
1: img tag + --data-math=formulaID in HTML
2: script to detect MathML support in browser
3: script retrieves MathML DOM from API using formulaID
4: script replaces img with MathML

Script can have opt-in for MathML + MathJax.
It's not optimal, it's slow, it possibly won't be indexed by Google, but
it's a small step forward in a way that works, and importantly, without
bothering too much the people who really just don't care about it. Of
course it would require something like LatexML to drive the MathML
generation.

If successful, we can switch to including both MathJax AND img's into the
HTML, using JS/CSS to reveal MathML for browsers that support it. And then
hopefully in about 10 years or so (Yes I really think it will take that
long) we can remove the img mode.

Input:
I don't think we should get away from TeX in the immediate future. I do see
us replacing texvc however at some point. texvc is outdated and hard to
maintain. If someone would hand us an improved Tex -> PNG renderer with
proper glyph support, we would jump ship in a heartbeat I presume. There is
actually quite a bit of cleanup work we could do on texvc itself. The
problem there is mostly that it requires you to be fluent in a gazillion
things (ocaml, math, latex, php, mediawiki, image conversion, server
configuration).

DJ



On Mon, Jul 22, 2013 at 6:05 PM, C. Scott Ananian <[hidden email]>wrote:

> As a(nother) user, I have been very pleased to see unicode-complete fonts
> gradually make the use of images for non-roman orthography gradually
> disappear.  When I see non-English text on a page, greek letters, or simple
> expressions with super- and sub-scripts, I can generally highlight, style,
> and copy-and-paste it.  This is a huge win.
>
> I would hope that the *long term* direction of math is in the same
> direction, even if *short term* some users would like to see better
> image-based renders.
>  --scott
>
> --
> (http://cscott.net)
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

C. Scott Ananian
On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman <
[hidden email]> wrote:

> So what I would actually propose for the short term (next few years) in
> case we really want to go the direction of MathML is the following:
> 1: img tag + --data-math=formulaID in HTML
> 2: script to detect MathML support in browser
> 3: script retrieves MathML DOM from API using formulaID
> 4: script replaces img with MathML
>

It's worth thinking about future-editor issues as well.  Perhaps rendering
MathML client-side into a <canvas> is a better transition strategy -- it
would lead to a more responsive editor than having to do a server call
every character to update the render.

I haven't really looked into this -- are there any good javascript math
renderers?  (Compiling the TeX implementation in C into client-side
JavaScript using emscripten might even be an option.)
 --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Max Semenik
On 23.07.2013, 19:30 C. wrote:

> On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman <
> [hidden email]> wrote:

>> So what I would actually propose for the short term (next few years) in
>> case we really want to go the direction of MathML is the following:
>> 1: img tag + --data-math=formulaID in HTML
>> 2: script to detect MathML support in browser
>> 3: script retrieves MathML DOM from API using formulaID
>> 4: script replaces img with MathML
>>

> It's worth thinking about future-editor issues as well.  Perhaps rendering
> MathML client-side into a <canvas> is a better transition strategy -- it
> would lead to a more responsive editor than having to do a server call
> every character to update the render.

> I haven't really looked into this -- are there any good javascript math
> renderers?  (Compiling the TeX implementation in C into client-side
> JavaScript using emscripten might even be an option.)

MathJax - the one we're using:)



--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
@praveenp do you know if bug 48032 is fixable with texvc?

@Derk-Jan could you give some background on your "MathJax is a nightmare"
comment? Have their been specific reports or complaints? Or is this
something specific out of development (like the float issue)? It seems
MathJax is slower on Wikipedia than on other sites. Wikipedia's MathJax
configuration is definitely not optimal, and it seems the integration into
MediaWiki isn't either. I agree that the best first step is to replace the
PNGs on the fly -- that's almost trivial and has no risk attached.

@Scott MathJax basically implements the TeX algorithm. But somebody also
converted pdftex with emscripten https://github.com/manuels/texlive.js/.
I'm guessing you'd have to expect a similar overhead for any other TeX
variant.

Peter.




---------- Forwarded message ----------
From: Max Semenik <[hidden email]>
Date: Tue, Jul 23, 2013 at 8:38 AM
Subject: Re: [Wikitech-l] Long term strategy for math on wikipedia
To: Wikimedia developers <[hidden email]>


On 23.07.2013, 19:30 C. wrote:

> On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman <
> [hidden email]> wrote:

>> So what I would actually propose for the short term (next few years) in
>> case we really want to go the direction of MathML is the following:
>> 1: img tag + --data-math=formulaID in HTML
>> 2: script to detect MathML support in browser
>> 3: script retrieves MathML DOM from API using formulaID
>> 4: script replaces img with MathML
>>

> It's worth thinking about future-editor issues as well.  Perhaps rendering
> MathML client-side into a <canvas> is a better transition strategy -- it
> would lead to a more responsive editor than having to do a server call
> every character to update the render.

> I haven't really looked into this -- are there any good javascript math
> renderers?  (Compiling the TeX implementation in C into client-side
> JavaScript using emscripten might even be an option.)

MathJax - the one we're using:)



--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Derk-Jan Hartman
On Tue, Jul 23, 2013 at 11:34 PM, Peter Krautzberger <
[hidden email]> wrote:
>
> @Derk-Jan could you give some background on your "MathJax is a nightmare"
> comment? Have their been specific reports or complaints? Or is this
> something specific out of development (like the float issue)? It seems
> MathJax is slower on Wikipedia than on other sites. Wikipedia's MathJax
> configuration is definitely not optimal, and it seems the integration into
> MediaWiki isn't either. I agree that the best first step is to replace the
> PNGs on the fly -- that's almost trivial and has no risk attached.
>

The float issue is irrelevant to this.

1: Wikipedia pages are complex. Thousands of nodes per page content and
often rather deep, all of which needs to be considered for MathJax.
2: We have multiple scripts that need to look at 'a lot of nodes'. MathJax
is not alone.
3: MathJax is simply complex. They are complex scripts, with a lot of
computations.
4: Wikipedia pages are a complex canvas. Every finished mathjax rendering
reflows the page. (which is a good idea actually in the case of MathJax,
but probably taxing the system)
5: MathJax does not currently make use of our ResourceLoader, because it
uses it's own scriptloaders. This however requires quite a few URL
connections (one of RL's primary function is script request bundling). I'm
not even sure if we can make it use ResourceLoader (the autostart of the
main MathJax script might be problematic here....). Also keeping all file
registrations in sync definitely would require a script or something to
keep it maintainable.

And last of all, we simply have a lot of people using the software for whom
a few kilobytes of traffic might already be noticeable on their
connections. The amount of complaints we in general get for adding
Javascript is already considerable, and those scripts are magnitudes
(factor 100x) smaller than MathJax, so i'm sure we would get a lot of
negative response from parts of the community.

There is definitely some room for improvement, but I doubt it will become
magnitudes faster within a few years.

DJ



> ---------- Forwarded message ----------
> From: Max Semenik <[hidden email]>
> Date: Tue, Jul 23, 2013 at 8:38 AM
> Subject: Re: [Wikitech-l] Long term strategy for math on wikipedia
> To: Wikimedia developers <[hidden email]>
>
>
> On 23.07.2013, 19:30 C. wrote:
>
> > On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman <
> > [hidden email]> wrote:
>
> >> So what I would actually propose for the short term (next few years) in
> >> case we really want to go the direction of MathML is the following:
> >> 1: img tag + --data-math=formulaID in HTML
> >> 2: script to detect MathML support in browser
> >> 3: script retrieves MathML DOM from API using formulaID
> >> 4: script replaces img with MathML
> >>
>
> > It's worth thinking about future-editor issues as well.  Perhaps
> rendering
> > MathML client-side into a <canvas> is a better transition strategy -- it
> > would lead to a more responsive editor than having to do a server call
> > every character to update the render.
>
> > I haven't really looked into this -- are there any good javascript math
> > renderers?  (Compiling the TeX implementation in C into client-side
> > JavaScript using emscripten might even be an option.)
>
> MathJax - the one we're using:)
>
>
>
> --
> Best regards,
>   Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

C. Scott Ananian
It seems like many of those issues could be worked around if mediawiki/core
kept a simple "uses math markup" boolean for each page.  All the overhead
of MathJax could be eliminated unless it was actually needed.  Further, the
javascript could be wrapped in a big if clause, so if the browser supported
MathML natively, mathjax could similarly be skipped.  This provides a
future path to fastness as browsers improve.
  --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Brad Jorsch (Anomie)
On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian
<[hidden email]> wrote:
> It seems like many of those issues could be worked around if mediawiki/core
> kept a simple "uses math markup" boolean for each page.  All the overhead
> of MathJax could be eliminated unless it was actually needed.

This is already be the case. MathJax is loaded by a small RL module
that itself is only loaded on pages containing the <math> tag.

You can test this easily enough: create a page with "<span
class="tex">$ E = m c^2 $</span>" and it won't be MathJaxed. Then add
a <math> tag and it suddenly will be.


--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Tei-2
In reply to this post by Derk-Jan Hartman
On 23 July 2013 11:20, Derk-Jan Hartman <[hidden email]> wrote:
>> I'm wondering if the lack of reactions so far is positive or negative.
>
> It's negative, it shows that few people have the confidence to think they
> have something worthwhile to contribute on this niche area. :(
>

I read this as a invitation for more random feedback. Even if is not
100% worthwhile :P

So heres something, a plan:

Two styles of rendering. The formulas that are simple and are embedded
in paragraph, are rendered using HTML  with a magical MathML to HTML
converter.
Complex formulas are rendered as a PNG image,  a scripts autoload
"something better" if the user click on the image.
The user can opt-in to render as MathML or render to canvas with js
automatically with the complex formulas.


--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
@Derk-Jan your 1-5 are all standard problems that can be resolved. I think
if we sat down together (MathJax and MediaWiki devs), they could easily be
sorted out. I don't think they are as complicated as you make them sound.

Regarding the load and perceived speed, I would suggest to let users decide.

@Oscar that's the idea of bug
48036<https://bugzilla.wikimedia.org/show_bug.cgi?id=48036> To
test the user experience try this
bookmarklet<https://gist.github.com/pkra/5500316>

Peter.


On Wed, Jul 24, 2013 at 8:19 AM, <<"tei''>>> <[hidden email]> wrote:

> On 23 July 2013 11:20, Derk-Jan Hartman <[hidden email]>
> wrote:
> >> I'm wondering if the lack of reactions so far is positive or negative.
> >
> > It's negative, it shows that few people have the confidence to think they
> > have something worthwhile to contribute on this niche area. :(
> >
>
> I read this as a invitation for more random feedback. Even if is not
> 100% worthwhile :P
>
> So heres something, a plan:
>
> Two styles of rendering. The formulas that are simple and are embedded
> in paragraph, are rendered using HTML  with a magical MathML to HTML
> converter.
> Complex formulas are rendered as a PNG image,  a scripts autoload
> "something better" if the user click on the image.
> The user can opt-in to render as MathML or render to canvas with js
> automatically with the complex formulas.
>
>
> --
> --
> ℱin del ℳensaje.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

C. Scott Ananian
In reply to this post by Brad Jorsch (Anomie)
On Wed, Jul 24, 2013 at 11:16 AM, Brad Jorsch (Anomie) <
[hidden email]> wrote:

> On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian
> <[hidden email]> wrote:
> > It seems like many of those issues could be worked around if
> mediawiki/core
> > kept a simple "uses math markup" boolean for each page.  All the overhead
> > of MathJax could be eliminated unless it was actually needed.
>
> This is already be the case. MathJax is loaded by a small RL module
> that itself is only loaded on pages containing the <math> tag.
>
> You can test this easily enough: create a page with "<span
> class="tex">$ E = m c^2 $</span>" and it won't be MathJaxed. Then add
> a <math> tag and it suddenly will be.
>

That's great.  Is there anything the parsoid team could do to make math
work better?
 --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Moritz Schubotz-2
Dear all,

thanks for posting this discussion. There is a roadmap for the Math extension at
http://www.mediawiki.org/wiki/Extension:Math/Roadmap

I want to to improve the math rendering in Wikipedia and want to get
the best solution that is possible.
Since MathML is the w3c standard for displaying mathematical content
at the browser I did not question that.
I could not find any evidence why texvc, that is not even defined...
there is just an ocaml script that is hardly maintained that defines
what is texvc and what not... would be better. As a researcher I'm of
course always open to hear convincing argument why mathml should be
replaced by texvc..maybe with some guidance to do client side
rendering somehow uniform.

One of my research results is that the two layers of MathML
presentation and content mathml are a good starting point. However a
semantic layer would be helpful to enrich the mathematical equation
for practical use.

A little study on tex to Mathml converters showed that LaTeXML is the
best converter out there that produces relatively good but still poor
Content MathML. So I was working on the integration of LaTeXML to
Mediawiki with support of MathJax for browsers that do not handle
MathMl out of the box.
In contrast to the normal terrible slow rendering speed of MathJax
when used in texvc mode MathJax is able to convert MathML to SVG
really quick. So you can get even high quality math output with e.g.
Chrome.

However, a picture says more than 1000 words and a demo says even more
than an picture.
By this means there is a demo of english wikipedia aviailable at
https://wikitech.wikimedia.org/wiki/Nova_Resource:Math
that compares the rendering options available in the near future at wikipedia.

comments are highly welcome

Best
Moritz



On Wed, Jul 24, 2013 at 11:42 PM, C. Scott Ananian
<[hidden email]> wrote:

> On Wed, Jul 24, 2013 at 11:16 AM, Brad Jorsch (Anomie) <
> [hidden email]> wrote:
>
>> On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian
>> <[hidden email]> wrote:
>> > It seems like many of those issues could be worked around if
>> mediawiki/core
>> > kept a simple "uses math markup" boolean for each page.  All the overhead
>> > of MathJax could be eliminated unless it was actually needed.
>>
>> This is already be the case. MathJax is loaded by a small RL module
>> that itself is only loaded on pages containing the <math> tag.
>>
>> You can test this easily enough: create a page with "<span
>> class="tex">$ E = m c^2 $</span>" and it won't be MathJaxed. Then add
>> a <math> tag and it suddenly will be.
>>
>
> That's great.  Is there anything the parsoid team could do to make math
> work better?
>  --scott
>
> --
> (http://cscott.net)
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Mit freundlichen Grüßen
Moritz Schubotz

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12