Re: [Wikitech-l] GSoC/OPW Proposal Updates: VisualEditor Mathematical Equation Plugin

[Peter Krautzberger]

Looks good. I left a comment.


On Thu, May 2, 2013 at 10:04 AM, Jiabao Wu  wrote:

> Hey all,
>
> I have made a big change to my proposal in accordance to community's
> responses.
> I'd like to invite feedback on this new proposal,
>
> http://www.mediawiki.org/wiki/User:Jiabao_wu/GSoC_2013_Application
>
> I know the VisualEditor team and everyone else are all very busy as its
> almost
> closing in to the final submission date, but comments still would be great,
> either before or after that deadline.
>
> A short summary of my approach to VisualEditor Mathematical Equation Plugin
>
> > step 1: make a node handler in visual editor to allow user to type in
> LaTex
> > code in a box and display it underneath in real time, which is similar to
> > Aloha Editor suggested by Peter.
>
> > step 2: update the GUI to have symbols and function buttons, which allow
> user
> > to click the buttons and insert the latex code of the symbol or function
> in
> > the editing box
>
> > step 3: allow users with latex experience to edit math in VisualEditor
> like
> > in Google Docs (this has been moved to optional currently, but still very
> > likely to be able to make it.)
>
> Those changes are applied to my synopsis, deliverables, and timeline.
>
> Thanks!
>
> jiabao
> ___
> 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

[Wikitech-l] MathJax opt-in for all visitors

[Peter Krautzberger]

Hi,

Here's an idea somebody suggested to me.

I would like to propose a way for any visitor to opt-in to MathJax on the
fly. (Oh, maybe I should add a disclaimer: I work for MathJax.)

This would be simply a button on pages with math that would switch MathJax
on (and possibly off via a cookie).


I believe this has some advantages.

* All users can get better math rendering but are not forced to have it
* Wikipedia would become accessible to all math-capable screen readers
(I've heard complaints that user registration is not not very accessible).
* Users get to vote with their feet -- usage data could indicate if MathJax
rendering quality is worth it.

I think this idea would be relatively simple to implement. Since the math
images already contain their own TeX code as alt-text, MathJax can replace
the images on the fly.

Excuse my poor javascript skill, but something like the following

$('img.tex').wrap(''); // this will allow
MathJax to replace the images with its rendering on the fly
$('.MathJax_Preview').after(function() {
  tex = $(this).find('img').attr("alt"); //grab the TeX code
  return " " + tex + "" ; //add the script
behind the MathJax_preview TODO handle display style
});
$.getScript('
https://c328740.ssl.cf1.rackcdn.com/mathjax/2.1-latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML');
//run MathJax

should be an approximation.

Of course, this should really use Wikipedia's MathJax configuration file. A
real solution also should handle displaystyle math -- I couldn't figure out
how Wikipedia handles this in the images but the MathJax side would simply
need 

Re: [Wikitech-l] MathJax opt-in for all visitors

[Peter Krautzberger]

Thanks for all the feedback!

Matthew -- yes, the CAPTCHA bug is what I had in mind. IIRC navigating to
the MathJax option as a registered user was also complicated. Thanks for
creating the bug to track this proposal.

MZMcBride -- yes, I'm aware of it. This idea is specifically for
unregistered users

Niklas -- our upcoming release will have a full localization. Our beta came
out today, see http://www.mathjax.org/mathjax-v2-2-beta-now-available/.
We're hoping we get hosted on TranslateWiki team. Alternatively, we'll put
something up on Transifex.

Derk-Jan -- good point. I think an on/off button would be very useful. But
I'm not sure it's necessary to stop the rendering since the code I
suggested will replace the images only by the rendered equation. So from a
reader's perspective, there's no interruption. (Try the code as a
bookmarklet to see what I mean.)

Praveenp -- not sure how the two issues are related. I've commented on the
bug thread for some background on MathJax.


On Fri, May 3, 2013 at 8:13 AM, praveenp  wrote:

> I would like to see Server rendered png issues fixed before this. Simple
> images are better for various devices and browsers. But it will be better
> to allow users to force technology, if no other simple solutions possible.
>
>
> On Friday 03 May 2013 12:59 PM, Niklas Laxström wrote:
>
>>
>> What is the state of MathJax i18n currently? Before we show it to lots
>> of users it should be translatable.
>>
>
> MathJax available in Math extension is not completely capable to handle
> non-latin scripts. ( See this bug we filed yesterday:
> https://bugzilla.wikimedia.**org/show_bug.cgi?id=48032)
>
>
> -Niklas
>>
>>
>> --
>> Niklas Laxström
>>
>> __**_
>> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC: next steps

[Peter Krautzberger]

Congratulations!

Peter.


On Tue, May 7, 2013 at 2:01 PM, David Cuenca  wrote:

> Excellent news! Congratulations to everyone involved!
>
> Cheers,
> David
>
> On Tue, May 7, 2013 at 4:36 PM, Parth Srivastav
> wrote:
>
> > Hi Quim
> >
> > Great news, Congrats to the entire team
> >
> >
> > On Wed, May 8, 2013 at 2:03 AM, Rahul Maliakkal  > >wrote:
> >
> > > Hi Quim
> > >
> > > Great News, Youve struck Gold. Cheers to WMF :)
> > >
> > >
> > > On Wed, May 8, 2013 at 12:57 AM, Harsh Kothari <
> > harshkothari...@gmail.com
> > > >wrote:
> > >
> > > > Hi Quim
> > > >
> > > > This is fantastic news. Your efforts paid off. Congrats to all. :)
> > > >
> > > > Cheers
> > > > Harsh
> > > >
> > > >
> > > > On Wed, May 8, 2013 at 12:51 AM, Pragun Bhutani 
> > > > wrote:
> > > >
> > > > > That's really good news! Thanks for sharing, Quim. I'm looking
> > forward
> > > to
> > > > > the next steps now. :)
> > > > >
> > > > > Cheers everybody!
> > > > >
> > > > > On Wed, May 8, 2013 at 12:14 AM, Siebrand Mazeland (WMF) <
> > > > > smazel...@wikimedia.org> wrote:
> > > > >
> > > > > > That's awesome, Quim. Thanks for all your efforts, support,
> > > > encouragement
> > > > > > and guidance so far.
> > > > > >
> > > > > > The best is yet to come! May you enjoy many more alcohol-free
> > drinks
> > > in
> > > > > > celebration of future milestones passed.
> > > > > >
> > > > > > Cheers!
> > > > > >
> > > > > > Siebrand
> > > > > >
> > > > > >
> > > > > > On Tue, May 7, 2013 at 8:40 PM, Quim Gil 
> > wrote:
> > > > > >
> > > > > > > Google just allocated slots and...
> > > > > > >
> > > > > > >
> > > > > > > On 05/05/2013 09:23 PM, Quim Gil wrote:
> > > > > > >
> > > > > > >> Based on the feedback received from the mentors we are
> > requesting
> > > > > > >>
> > > > > > >> 11 min
> > > > > > >> 21 max
> > > > > > >>
> > > > > > >
> > > > > > > ... WE HAVE GOT 21 SLOTS ALLOWED
> > > > > > >
> > > > > > > First: congratulations to everybody involved: mentors AND
> > students.
> > > > > This
> > > > > > > number reflects succinctly how much someone like Google trusts
> > you.
> > > > > > >
> > > > > > > Second: this relaxes a lot our selection process. Between this
> > and
> > > > OPW
> > > > > we
> > > > > > > can accommodate many good proposals.
> > > > > > >
> > > > > > > Third: still, we will keep standards high as we have done so
> far.
> > > > > Having
> > > > > > > 21 slots doesn't mean that we will take them blindly. We will
> > > > continue
> > > > > > > asking questions to mentors and students about the feasibility
> of
> > > > each
> > > > > > > proposal and we will consider accepted only those that have all
> > the
> > > > > > > foundations in place.
> > > > > > >
> > > > > > > Last but not least: remember the important point about
> > > > confidentiality.
> > > > > > > Now several projects might look pretty obvious candidates but
> > this
> > > > > > doesn't
> > > > > > > authorize anybody to leak / pre-announce our decisions made.
> > Google
> > > > is
> > > > > > > still the one that must announce all accepted GSoC projects
> > first.
> > > > > > >
> > > > > > > PS: and now, if you don't mind, I'll go get some sophisticated
> > > > > > > alcohol-free drink to celebrate. Salut!
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Quim Gil
> > > > > > > Technical Contributor Coordinator @ Wikimedia Foundation
> > > > > > > http://www.mediawiki.org/wiki/**User:Qgil<
> > > > > > http://www.mediawiki.org/wiki/User:Qgil>
> > > > > > >
> > > > > > > __**_
> > > > > > > Wikitech-l mailing list
> > > > > > > Wikitech-l@lists.wikimedia.org
> > > > > > > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
> > > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Siebrand Mazeland
> > > > > > Product Manager Language Engineering
> > > > > > Wikimedia Foundation
> > > > > >
> > > > > > M: +31 6 50 69 1239
> > > > > > Skype: siebrand
> > > > > >
> > > > > > Support Free Knowledge:
> http://wikimediafoundation.org/wiki/Donate
> > > > > > ___
> > > > > > Wikitech-l mailing list
> > > > > > Wikitech-l@lists.wikimedia.org
> > > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Pragun Bhutani
> > > > > http://pragunbhutani.in
> > > > > Skype : pragun.bhutani
> > > > > ___
> > > > > Wikitech-l mailing list
> > > > > Wikitech-l@lists.wikimedia.org
> > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Harsh Kothari
> > > > Engineering Trainee,
> > > > Physical Research Laboratory.
> > > > Follow Me : harshkothari410 
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@li

[Wikitech-l] Long term strategy for math on wikipedia

[Peter Krautzberger]

Hi everyone,

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

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

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

Peter.


(1) math output

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

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

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

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

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

* accessibility

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

* rendering quality

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

* dynamic content

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

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

* editing

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

(2) math input

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

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

(3) First steps towards a transition.

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

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

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

To pull in the entire community, something like bug 48036 (easier MathJax
opt-in) would be great. It would allow people to vote with their feet and
tell us continually if the benefits of MathML are worth the cost.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Long term strategy for math on wikipedia

[Peter Krautzberger]

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


Thanks for pointing out the Flow discussion.

I'd be happy to write an RFC.

Peter.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Long term strategy for math on wikipedia

[Peter Krautzberger]

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

Here are three problems I see down the road.

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

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

2) TeX/LaTeX compatibility might be lost.

"Native" content (e.g.  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
wrote:

> On 07/18/2013 12:52 PM, Peter Krautzberger wrote:
> > I'd be happy to write an RFC.
>
> That's an option, but it's perfectly reasonable if you want to talk it
> out more and let it crystallize some.
>
> Matt Flaschen
>
>
> ___
> Wikitech-l mailing list
> 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

Re: [Wikitech-l] Long term strategy for math on wikipedia

[Peter Krautzberger]

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

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

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

Peter.




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


On 23.07.2013, 19:30 C. wrote:

> On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman <
> d.j.hartman+wmf...@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  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

Re: [Wikitech-l] Long term strategy for math on wikipedia

[Peter Krautzberger]

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

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

@Oscar that's the idea of bug
48036 To
test the user experience try this
bookmarklet

Peter.


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

> On 23 July 2013 11:20, Derk-Jan Hartman 
> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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''>>>  wrote:

> On 24 July 2013 21:12, Peter Krautzberger
>  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
> 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

Re: [Wikitech-l] 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 mathjax-...@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''>>>  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;   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
>  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''>>> 
> wrote:
> >
> >> On 24 July 2013 21:12, Peter Krautzberger
> >>  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
> 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

Re: [Wikitech-l] 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
wrote:

> On 07/21/2013 08:53 PM, Peter Krautzberger wrote:
> > 2) TeX/LaTeX compatibility might be lost.
> >
> > "Native" content (e.g.  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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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  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.  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
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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

Re: [Wikitech-l] 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  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  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.  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 visu