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.
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
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.
On 18 July 2013 08:10, Quim Gil qgil@wikimedia.org 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/RFChttps://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=20130...
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%3E
.
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=20130...
Thanks for pointing out the Flow discussion.
I'd be happy to write an RFC.
Peter.
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 mflaschen@wikimedia.orgwrote:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
- 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).
- 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.
- 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 mflaschen@wikimedia.orgwrote:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
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 cananian@wikimedia.orgwrote:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> 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
On 23.07.2013, 19:30 C. wrote:
On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> 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:)
@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 maxsem.wiki@gmail.com Date: Tue, Jul 23, 2013 at 8:38 AM Subject: Re: [Wikitech-l] Long term strategy for math on wikipedia To: Wikimedia developers wikitech-l@lists.wikimedia.org
On 23.07.2013, 19:30 C. wrote:
On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jul 23, 2013 at 11:34 PM, Peter Krautzberger < peter.krautzberger@mathjax.org> 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 maxsem.wiki@gmail.com Date: Tue, Jul 23, 2013 at 8:38 AM Subject: Re: [Wikitech-l] Long term strategy for math on wikipedia To: Wikimedia developers wikitech-l@lists.wikimedia.org
On 23.07.2013, 19:30 C. wrote:
On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian cananian@wikimedia.org 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.
On Wed, Jul 24, 2013 at 11:16 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian cananian@wikimedia.org 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
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 cananian@wikimedia.org wrote:
On Wed, Jul 24, 2013 at 11:16 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Wed, Jul 24, 2013 at 10:55 AM, C. Scott Ananian cananian@wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 23 July 2013 11:20, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com 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.
@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 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
Peter.
On Wed, Jul 24, 2013 at 8:19 AM, <<"tei''>>> oscar.vives@gmail.com wrote:
On 23 July 2013 11:20, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 24 July 2013 21:12, Peter Krautzberger peter.krautzberger@mathjax.org wrote: ..
@Oscar that's the idea of bug 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
:-O
This is pretty. And if it still affect the browser (small freezes wen the user is scrolling) maybe the javascript can be moved to a iframe or a "web worker", so it don't run on the main javascript thread. About re-layouts, can't smart use of "min-width min-height" avoid that? you already have the size of the png as reference.
Ok this is getting off-topic -- sorry -- but glad you like it :) Unfortunately, webworker isn't an option, we need the DOM. Using the PNG for size is an nice idea, but only saves one measurement, all others occur within the equation. IIRC, the basic problem is that browser are not reliable enough when it comes to em to pixel conversion; the only way to get those correctly is to layout&measure -- recursively, of course, building the equation bottom up. But you should talk to our devs if you need more information on MathJax internals.
Peter.
On Thu, Jul 25, 2013 at 7:40 AM, <<"tei''>>> oscar.vives@gmail.com wrote:
On 24 July 2013 21:12, Peter Krautzberger peter.krautzberger@mathjax.org wrote: ..
@Oscar that's the idea of bug 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
:-O
This is pretty. And if it still affect the browser (small freezes wen the user is scrolling) maybe the javascript can be moved to a iframe or a "web worker", so it don't run on the main javascript thread. About re-layouts, can't smart use of "min-width min-height" avoid that? you already have the size of the png as reference.
--
ℱin del ℳensaje.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
some mussing,
Why the exact size is needed? can't the formula be put inside a box big enough, so 90% of the time the browser don't have to re-layout all the page?. Its other re-layour happening here? maybe the MathJax build the formula incrementally and the browser try to render every iteration? If that where the case, then It would be solvable with visibility: none; <slow render magic happends here> visibility: normal; What DOM is required? all of it? .cloneNode is very fast at cloning DOM trees. Code can operate over a clone, then copy the result. If the code is not attached to the page, maybe nothing will be rendered until you .cloneNode back your new tree.
.cloneNode is faster than WeepingAngels :D
On 26 July 2013 04:04, Peter Krautzberger peter.krautzberger@mathjax.org wrote:
Ok this is getting off-topic -- sorry -- but glad you like it :) Unfortunately, webworker isn't an option, we need the DOM. Using the PNG for size is an nice idea, but only saves one measurement, all others occur within the equation. IIRC, the basic problem is that browser are not reliable enough when it comes to em to pixel conversion; the only way to get those correctly is to layout&measure -- recursively, of course, building the equation bottom up. But you should talk to our devs if you need more information on MathJax internals.
Peter.
On Thu, Jul 25, 2013 at 7:40 AM, <<"tei''>>> oscar.vives@gmail.com wrote:
On 24 July 2013 21:12, Peter Krautzberger peter.krautzberger@mathjax.org wrote: ..
@Oscar that's the idea of bug 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
:-O
This is pretty. And if it still affect the browser (small freezes wen the user is scrolling) maybe the javascript can be moved to a iframe or a "web worker", so it don't run on the main javascript thread. About re-layouts, can't smart use of "min-width min-height" avoid that? you already have the size of the png as reference.
@Oscar I'd rather not to hijack this thread any further. Could you take this to mathjax-dev@googlegroups.com?
@Martin thanks for your comments and the link to the demo!
Just one slight correction regarding MathJax. Converting & typesetting of TeX and MathML are basically identical in speed. But you're right that MathJax's SVG output is often faster than HTML (up to 25%).
Can somebody comment on the state of texvc? That seems to be an important question.
Peter.
On Fri, Jul 26, 2013 at 3:01 AM, <<"tei''>>> oscar.vives@gmail.com wrote:
some mussing,
Why the exact size is needed? can't the formula be put inside a box big enough, so 90% of the time the browser don't have to re-layout all the page?. Its other re-layour happening here? maybe the MathJax build the formula incrementally and the browser try to render every iteration? If that where the case, then It would be solvable with visibility: none; <slow render magic happends here> visibility: normal; What DOM is required? all of it? .cloneNode is very fast at cloning DOM trees. Code can operate over a clone, then copy the result. If the code is not attached to the page, maybe nothing will be rendered until you .cloneNode back your new tree.
.cloneNode is faster than WeepingAngels :D
On 26 July 2013 04:04, Peter Krautzberger peter.krautzberger@mathjax.org wrote:
Ok this is getting off-topic -- sorry -- but glad you like it :) Unfortunately, webworker isn't an option, we need the DOM. Using the PNG for size is an nice idea, but only saves one measurement, all others
occur
within the equation. IIRC, the basic problem is that browser are not reliable enough when it comes to em to pixel conversion; the only way to get those correctly is to layout&measure -- recursively, of course, building the equation bottom up. But you should talk to our devs if you need more information on MathJax internals.
Peter.
On Thu, Jul 25, 2013 at 7:40 AM, <<"tei''>>> oscar.vives@gmail.com
wrote:
On 24 July 2013 21:12, Peter Krautzberger peter.krautzberger@mathjax.org wrote: ..
@Oscar that's the idea of bug 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
:-O
This is pretty. And if it still affect the browser (small freezes wen the user is scrolling) maybe the javascript can be moved to a iframe or a "web worker", so it don't run on the main javascript thread. About re-layouts, can't smart use of "min-width min-height" avoid that? you already have the size of the png as reference.
--
ℱin del ℳensaje.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If texvc is the underlying program that generates pngs at servers, it fails. (eg: http://bug-attachment.wikimedia.org/attachment.cgi?id=12248, error: Parsing failed (lexing error)).
On Friday 26 July 2013 09:37:50 PM IST, Peter Krautzberger wrote:
@Oscar I'd rather not to hijack this thread any further. Could you take this to mathjax-dev@googlegroups.com?
@Martin thanks for your comments and the link to the demo!
Just one slight correction regarding MathJax. Converting & typesetting of TeX and MathML are basically identical in speed. But you're right that MathJax's SVG output is often faster than HTML (up to 25%).
Can somebody comment on the state of texvc? That seems to be an important question.
Peter.
On Fri, Jul 26, 2013 at 3:01 AM, <<"tei''>>> oscar.vives@gmail.com wrote:
some mussing,
Why the exact size is needed? can't the formula be put inside a box big enough, so 90% of the time the browser don't have to re-layout all the page?. Its other re-layour happening here? maybe the MathJax build the formula incrementally and the browser try to render every iteration? If that where the case, then It would be solvable with visibility: none; <slow render magic happends here> visibility: normal; What DOM is required? all of it? .cloneNode is very fast at cloning DOM trees. Code can operate over a clone, then copy the result. If the code is not attached to the page, maybe nothing will be rendered until you .cloneNode back your new tree.
.cloneNode is faster than WeepingAngels :D
On 26 July 2013 04:04, Peter Krautzberger peter.krautzberger@mathjax.org wrote:
Ok this is getting off-topic -- sorry -- but glad you like it :) Unfortunately, webworker isn't an option, we need the DOM. Using the PNG for size is an nice idea, but only saves one measurement, all others
occur
within the equation. IIRC, the basic problem is that browser are not reliable enough when it comes to em to pixel conversion; the only way to get those correctly is to layout&measure -- recursively, of course, building the equation bottom up. But you should talk to our devs if you need more information on MathJax internals.
Peter.
On Thu, Jul 25, 2013 at 7:40 AM, <<"tei''>>> oscar.vives@gmail.com
wrote:
On 24 July 2013 21:12, Peter Krautzberger peter.krautzberger@mathjax.org wrote: ..
@Oscar that's the idea of bug 48036https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 To test the user experience try this bookmarklethttps://gist.github.com/pkra/5500316
:-O
This is pretty. And if it still affect the browser (small freezes wen the user is scrolling) maybe the javascript can be moved to a iframe or a "web worker", so it don't run on the main javascript thread. About re-layouts, can't smart use of "min-width min-height" avoid that? you already have the size of the png as reference.
--
ℱin del ℳensaje.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 07/21/2013 08:53 PM, Peter Krautzberger wrote:
- 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.
That only applies if MathML becomes the definitive format/source code (which is currently TeX). If that happens, it will be well down the road.
Matt Flaschen
@Matthew Agreed, that's down the road (but I did call the thread "long term" :) ).
There is the question if texvc could (should?) be replaced. From what I understand it's a pain for people to set up (installing texlive, compiling texvc etc), and leaving it behind could help several internationalization bugs (like the one praveenp linked to previously).
Peter.
On Mon, Jul 29, 2013 at 8:14 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 07/21/2013 08:53 PM, Peter Krautzberger wrote:
- 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.
That only applies if MathML becomes the definitive format/source code (which is currently TeX). If that happens, it will be well down the road.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
1. From the perspective of being able to repurpose Wikipedia articles outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
2. From a wikitext-readability perspective, TeX-format equations are the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
-Mark
On Friday 02 August 2013 09:06 PM, Delirium wrote:
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
- From the perspective of being able to repurpose Wikipedia articles
outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
- From a wikitext-readability perspective, TeX-format equations are
the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
-Mark
What??!!?? sorry I didn't get a thing from this. :-)
Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/2/13 7:07 PM, praveenp wrote:
On Friday 02 August 2013 09:06 PM, Delirium wrote:
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
- From the perspective of being able to repurpose Wikipedia articles
outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
- From a wikitext-readability perspective, TeX-format equations are
the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
What??!!?? sorry I didn't get a thing from this. :-)
Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs.
I read Peter's point 2 as discussing the possible "native" use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then "TeX/LaTeX compatibility might be lost" doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely?
-Mark
@Mark Just to clarify. Personally, I don't think wikitext's math format should move away from a TeX-like input language. The point I was trying making was that a conservative extension would be useful if MathML becomes a desired output. It seems to me that texvc was specifically designed to prevent fully fledged TeX input, so I wonder if it wouldn't help everyone if wasn't required on the backend anymore, only that the syntax stayed backward compatible.
@paveenp I don't know what you mean by "unsupportably dependent". I am also not aware of "serious bugs". Could you be more specific?
Peter.
On Fri, Aug 2, 2013 at 10:40 AM, Delirium delirium@hackish.org wrote:
On 8/2/13 7:07 PM, praveenp wrote:
On Friday 02 August 2013 09:06 PM, Delirium wrote:
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
- From the perspective of being able to repurpose Wikipedia articles
outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
- From a wikitext-readability perspective, TeX-format equations are the
de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
What??!!?? sorry I didn't get a thing from this. :-)
Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs.
I read Peter's point 2 as discussing the possible "native" use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then "TeX/LaTeX compatibility might be lost" doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely?
-Mark
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've problems with browsers like IE (Mainly XP) and opera (ubuntu 12.04/Mint Maya), although I forgot exact version numbers. And also it takes each code points independently so it converts rtl language to ltr language, or breaks any ligatures etc. (Aren't they serious bugs?)
On Saturday 03 August 2013 12:34:56 AM IST, Peter Krautzberger wrote:
@Mark Just to clarify. Personally, I don't think wikitext's math format should move away from a TeX-like input language. The point I was trying making was that a conservative extension would be useful if MathML becomes a desired output. It seems to me that texvc was specifically designed to prevent fully fledged TeX input, so I wonder if it wouldn't help everyone if wasn't required on the backend anymore, only that the syntax stayed backward compatible.
@paveenp I don't know what you mean by "unsupportably dependent". I am also not aware of "serious bugs". Could you be more specific?
Peter.
On Fri, Aug 2, 2013 at 10:40 AM, Delirium delirium@hackish.org wrote:
On 8/2/13 7:07 PM, praveenp wrote:
On Friday 02 August 2013 09:06 PM, Delirium wrote:
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
- From the perspective of being able to repurpose Wikipedia articles
outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
- From a wikitext-readability perspective, TeX-format equations are the
de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
What??!!?? sorry I didn't get a thing from this. :-)
Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs.
I read Peter's point 2 as discussing the possible "native" use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then "TeX/LaTeX compatibility might be lost" doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely?
-Mark
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks, praveenp.
Could you clarify if the problems you've seen are MediaWiki, texvc or MathJax specific? I could only find 48032https://bugzilla.wikimedia.org/show_bug.cgi?id=48032 (MathJax should be fixed in the next release), and 48118https://bugzilla.wikimedia.org/show_bug.cgi?id=48118, from which I understand, RTL is not supported by texvc. MathJax currently does not support RTL but we plan to add it -- and, as I wrote, I'd be very interested to hear if texvc is still being developed.
MathJax does not deal with ligatures directly since ligatures are really text-mode, not math mode. So ligatures in text-blocks are passed through by MathJax and should not be broken. Again, I don't know what texvc does.
Anyway, more bug reports would be great so that issues can be investigated. I can't really comment if those are serious from a WMF pov. Peter.
On Tue, Aug 6, 2013 at 10:53 AM, praveenp me.praveen@gmail.com wrote:
I've problems with browsers like IE (Mainly XP) and opera (ubuntu 12.04/Mint Maya), although I forgot exact version numbers. And also it takes each code points independently so it converts rtl language to ltr language, or breaks any ligatures etc. (Aren't they serious bugs?)
On Saturday 03 August 2013 12:34:56 AM IST, Peter Krautzberger wrote:
@Mark Just to clarify. Personally, I don't think wikitext's math format should move away from a TeX-like input language. The point I was trying making was that a conservative extension would be useful if MathML becomes a desired output. It seems to me that texvc was specifically designed to prevent fully fledged TeX input, so I wonder if it wouldn't help everyone if wasn't required on the backend anymore, only that the syntax stayed backward compatible.
@paveenp I don't know what you mean by "unsupportably dependent". I am also not aware of "serious bugs". Could you be more specific?
Peter.
On Fri, Aug 2, 2013 at 10:40 AM, Delirium delirium@hackish.org wrote:
On 8/2/13 7:07 PM, praveenp wrote:
On Friday 02 August 2013 09:06 PM, Delirium wrote:
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
- 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.
If this means MathML as the canonical format, i.e. people write
MathML into articles directly, rather than it just being an output/rendering format, that gives me moderate worry:
- From the perspective of being able to repurpose Wikipedia articles
outside of a web context, TeX-format equations are nice for articles in the math/science sphere, since TeX-based publishing workflows are common in math/science, and equations are particularly tedious and error-prone to convert by hand, if that would end up necessary. Admittedly, in some workflows there's no real difference: you can import both MathML and TeX equations into MS Word with appropriate plugins (I haven't looked into whether the two import paths differ on compatibility). Perhaps as HTML-based print workflows improve this will drop off as an issue, but right now only a smallish proportion of people are using workflows based on something like PrinceXML, and the free-software alternatives to PrinceXML are further behind.
- From a wikitext-readability perspective, TeX-format equations are
the de-facto standard way of ASCII-fying equations, e.g. in plaintext emails, while MathML isn't written in a syntax any humans normally write. So using TeX as our underlying representation makes equations possible to edit in text form, at least for people who already professionally work in areas where that's common, while MathML equations virtually require a visual editor (unless the idea is to use something like ASCIIMathML?).
What??!!?? sorry I didn't get a thing from this. :-)
Current scenario is: In our current Math extension, textvc is simply unable to generate equations in png except Latin languages. Also Mathjax is heavily client dependent (Unsupportably dependent) and has its own serious bugs.
I read Peter's point 2 as discussing the possible "native" use of MathML tags, i.e. permitting people to write MathML into articles, rather than only using MathML as an alternate rendering path for texvc/MathJax/etc. If MathML is a render-only target, then "TeX/LaTeX compatibility might be lost" doesn't seem like it could be an issue. So unless I'm totally misreading, I took the discussion to be about allowing MathML in articles, which could break TeX compatibility since not all MathML tags can be rendered back into TeX equivalents. The two points above are my two concerns w.r.t. that suggestion. Am I misreading the suggestion entirely?
-Mark
______________________________****_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/****mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/**mailman/listinfo/wikitech-l <ht**tps://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
______________________________**_________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org