On 24 July 2013 21:12, Peter Krautzberger
<[hidden email]> wrote: .. > @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> > :-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 [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
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''>>> <[hidden email]> wrote: > On 24 July 2013 21:12, Peter Krautzberger > <[hidden email]> wrote: > .. > > @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> > > > > :-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 > [hidden email] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > Wikitech-l mailing list [hidden email] 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 <[hidden email]> 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''>>> <[hidden email]> wrote: > >> On 24 July 2013 21:12, Peter Krautzberger >> <[hidden email]> wrote: >> .. >> > @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> >> > >> >> :-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 [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
@Oscar I'd rather not to hijack this thread any further. Could you take
this to [hidden email]? @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''>>> <[hidden email]> 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 > <[hidden email]> 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''>>> <[hidden email]> > wrote: > > > >> On 24 July 2013 21:12, Peter Krautzberger > >> <[hidden email]> wrote: > >> .. > >> > @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> > >> > > >> > >> :-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 > [hidden email] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > Wikitech-l mailing list [hidden email] 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 [hidden email]? > > @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''>>> <[hidden email]> 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 >> <[hidden email]> 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''>>> <[hidden email]> >> wrote: >>> >>>> On 24 July 2013 21:12, Peter Krautzberger >>>> <[hidden email]> wrote: >>>> .. >>>>> @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> >>>>> >>>> >>>> :-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 >> [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 |
In reply to this post by Peter Krautzberger
On 07/21/2013 08:53 PM, Peter Krautzberger wrote:
> 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. 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 [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
@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 <[hidden email]>wrote: > On 07/21/2013 08:53 PM, Peter Krautzberger wrote: > > 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. > > 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 > [hidden email] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > Wikitech-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
In reply to this post by Peter Krautzberger
On 7/22/13 2:53 AM, Peter Krautzberger wrote:
> 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. > 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 _______________________________________________ Wikitech-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
On Friday 02 August 2013 09:06 PM, Delirium wrote: > On 7/22/13 2:53 AM, Peter Krautzberger wrote: >> 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. >> > > 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 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 > [hidden email] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [hidden email] 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: >>> 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. >>> >> >> 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?). > 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 [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
@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 <[hidden email]> 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: >>> >>>> 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. >>>> >>>> >>> 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?). >>> >> 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 > [hidden email] > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > Wikitech-l mailing list [hidden email] https://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 <[hidden email]> 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: >>>> >>>>> 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. >>>>> >>>>> >>>> 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?). >>>> >>> 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 >> [hidden email] >> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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 |
Thanks, praveenp.
Could you clarify if the problems you've seen are MediaWiki, texvc or MathJax specific? I could only find 48032<https://bugzilla.wikimedia.org/show_bug.cgi?id=48032> (MathJax should be fixed in the next release), and 48118<https://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 <[hidden email]> 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 <[hidden email]> 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: >>>>> >>>>> 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. >>>>>> >>>>>> >>>>>> 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?). >>>>> >>>>> 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 >>> [hidden email] >>> https://lists.wikimedia.org/****mailman/listinfo/wikitech-l<https://lists.wikimedia.org/**mailman/listinfo/wikitech-l> >>> <ht**tps://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> >>> > >>> >>> ______________________________**_________________ >> Wikitech-l mailing list >> [hidden email] >> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> >> > > ______________________________**_________________ > Wikitech-l mailing list > [hidden email] > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > Wikitech-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/wikitech-l |
Free forum by Nabble | Edit this page |