Long term strategy for math on wikipedia

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

Re: Long term strategy for math on wikipedia

Tei-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Tei-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
@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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

praveenp
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Matthew Flaschen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
@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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Mark
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

praveenp

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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Mark
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
@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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

praveenp
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
Reply | Threaded
Open this post in threaded view
|

Re: Long term strategy for math on wikipedia

Peter Krautzberger
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
12