From: <juanrgonzaleza@canonicalscience.com>

Date: Thu, 8 Jun 2006 11:21:03 -0700 (PDT)

Message-ID: <3032.217.124.88.212.1149790863.squirrel@webmail.canonicalscience.com>

Date: Thu, 8 Jun 2006 11:21:03 -0700 (PDT)

Message-ID: <3032.217.124.88.212.1149790863.squirrel@webmail.canonicalscience.com>

Henri Sivonen wrote: > I think it is an economic problem rather than a technical problem. Yes, this may be reason that a single man was able to do math in a browser via XML-MAIDEN project in a few months, whereas dozens of others and even entire communities cannot do it even after of 10 years. Money may be also the reason of fiasco of IBM TeX approach to the web and of Wolfram fiasco to the web via Wolfram draft (remember?). George alone may be more rich that IBM, Desing Science, Wolfram Research, and others joined. > It follows that I don't think the slow adoption is *necessarily* > evidence of technical flaws. Then you know nothing of the history of math on the web. I would recommend you begin to revise history from the very beginning: HTML 3 Math, the first draft from the w3c. Attemtp to search why was completely rejected. > The part of population that is interested in mathematical typesetting > is very small in proportion to the population as a whole. As I > understood it at the time, that's why Netscape wasn't interested in > devoting developer time to MathML. I don't know how decision making > works at different browser companies, but I would hazard a guess that > from the point of view of Opera, Apple and Microsoft, the business > case for MathML is rather lousy compared to e.g. SVG, which is known > to have spec problems as well, which conflicts with CSS and which also > doesn't work in text/html. Well, always that anyone say me that math is for some little ones I always reply then why MSWord has an equation editor? Curiously history says contrary. History says that Microsoft was interested in providing native MathML support for MSIE and initially joined to MathML WG but due to technical problems they after rejected native support and just added some improvements to MSIE for suporting of third parties plugins. Mozilla has attempted to support MathML and even most simple tests fail. Opera developers were interested in mathematics but not in MathML because thecnical weakness of latter (see comments from developers in the links I provided), etc. I was interested in a full support for MathML in The Center for CANONICAL |SCIENCE) but I abandoned the project by thecnical issues (technical errors and weakness of MathML). Content MathML is not supported because problems again and even very recently it has been proved that something so simple as ?integral sin x from 0 to x? is not correctly encoded in MathML due to an incorrect desing. Then people wannot waste time and money with never-working-thecnologies. Because in the end you obtain an expensive technology that is poor that old cheap ones. > Hmm. Freaky economic problems are nowadays solved with Google money. :-P Have you asked them about support of MathML? I did! > FWIW, I completely agree with James Graham that automatic conversion > from LaTeX is *the* top-of-the-list requirement for any kind of Web > math. Remember that MathML has not achieved that still. > That already puts MathML ahead of > anything else that WHAT WG could come up with. I think that you simply do not know you are talking here. > If the WHAT WG really intends to address math, I think it would make > sense to start by interviewing Roger Sidje, Jacques Distler, Eitan M. > Gurari and Robert Miner to find out what they think are the problems > that need to be solved (if any). Robert Miner knows very well the limitations of MathML. Robert Miner has recognized in public that MathML design is not so good because has ?political issues? in the w3c committe. A pair of months ago he also publicly become interest in that would be changed in future MathML 3.0 for doing it CSS friendly and suitable for easy implementation in browsers. George offered him the short list of changes. Jacques Distler have attempted to offer mathematics in his blog using *presentaional* MathML 2.0. He has largely failed and provides us incorrect semantics, wrong structure, innaccesible and not searchable code, and incorrect rendering of mathematics during years. Moreover, he uses a very ugly approach based in a plugin for a IteX dialect is rather limited. For a small number of examples of very wrong (nonsensical) code Distler is serving to the internet can see my [http://canonicalscience.blogspot.com/2006/04/scientific-language-canonml-is.html] Some of incorrect formulas the was encoding via MathML 2.0 were better encoded in several geocities HTML pages by undergrad students. In fact, I curiously said that the element of line for 5D spaces could be better encoded using old but effective HTML code <SPAN>ds</SPAN><SUP>2</SUP> and Distler incorrectly thouhg that this was the way he would change the mathML code of his inefficient blog. In fact just a pair of days ago the change the code of element of line of (see above link for details) [http://golem.ph.utexas.edu/~distler/blog/archives/000635.html] to current <msup><mi>ds</mi><mn>2</mn></msup> that is a copy of my above HTML code. Unfortunately the code he generates now continues being structurally invalid, inacesible to people with disabilites, not searchable and rendering incorrectly. See my very recent post in MathML list for more details: [http://lists.w3.org/Archives/Public/www-math/2006Jun/0000.html] If after 10 years people spacialists as Distler are still unable to encode something so simple as (ds)^2 in despite of many efforts, time, money, plugins, special mimes, authoring tools, fonts, rendering engines, special fonts, two or three specifications, special markup, and devoted dialect of LaTeX... then... Curiously we can encode (ds)^2, rendering correctly, being structurally valid and accesible when taking alternative ways. Juan R. Center for CANONICAL |SCIENCE)Received on Thursday, 8 June 2006 11:21:03 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 13 April 2015 23:08:27 UTC
*