- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 9 Jun 2006 13:43:27 +0300
On Jun 8, 2006, at 21:21, <juanrgonzaleza at canonicalscience.com> wrote: > 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. Substitute "business problem" if it helps. It is not an issue of who has the most money but an issue of how money incentives affect priorities. My point was that math rendering tends to be addressed by a guy with a mission rather than companies if the companies decide, on business grounds, to prioritize their todo lists differently. For example, TeX and Gecko-MathML were both created using the guy with a mission model. For IBM it is about complementarities big time. When IBM funds the development of software that doesn't generate a direct revenue stream for them, they calculate that such software being inexpensively available boosts the demand for what Global Services sells. So to get IBM to pay for MathML support in browsers, you need a convincing case that the expense would be more than covered by the new business enabled for Global Services. (Also, IBM is big enough to experiment with stuff like techexplorer without betting the whole shop.) For Design Science it is about complementing their priced products as well. Without MathML support in browsers, there'd be no use for the WebEQ and the Web side of MathType. Hence, Design Science distributes MathPlayer for $0. MathML support--content MathML support in particular--would be complementary to Wolfram's products. Actually, a piece of critical code that enabled MathML on Mac in Gecko was contributed by a Wolfram employee. (I don't know whether he did it on his own time or on company time.) So why isn't Wolfram taking care of getting content MathML support implemented in browsers with round-trippability with Mathematica? I don't know. Perhaps they feel it is not their responsibility. Perhaps they have estimated that Mathematica sales wouldn't get enough of a boost because of it to justify the cost. As for XML-MAIDEN, I don't think it solves the problem. Stretchy characters are a salient feature of math typesetting and CSS just does not do stretchy characters. In such a case, I think it is better for markup to have rendering features that are not expressible in CSS than to stick with what CSS can do. (You can't specify Web Forms 2.0 widgets in CSS 2.1, either.) >> 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. Well, from Gecko we know that MathML is implementable at least to the degree implemented in Gecko. :-) Anyway, just because something doesn't succeed in a decade does not mean that there are intrinsic technical flaws. There are other possible factors as well, and there are examples of technically elegant solution not making it because of unfavorable business incentives, externalities, learning effects, etc. It is a big mistake to assume that technical elegance is sufficient for success on the Web. > Well, always that anyone say me that math is for some little ones I > always > reply then why MSWord has an equation editor? If I am not totally mistaken, the equation editor is licensed from Design Science which earlier also licensed equation editors from the same codebase for WordPerfect and AppleWorks. The cost of developing the equation editor did not need to be covered by Word license sales alone. Moreover, if I've understood the business model correctly, the light version that is included in the price of a Word license is supposed to get the users hooked so that those who find the version insufficient go to Design Science and buy the full MathType. > Curiously history says contrary. History says that Microsoft was > interested in providing native MathML support for MSIE and initially > joined to MathML WG MS joining WGs doesn't mean that they intend to implement in immediate future. > but due to technical problems they after rejected native support Do you have a reference for that? Difficulties beyond lacking the XHTML infrastructure? By the way, MS is reusing MathML in their XML format for Office 12. (ODF also reuses MathML.) > Mozilla has attempted to support MathML and even most simple tests > fail. Not as far as I can tell. Perhaps your simple is too complicated. :-) > 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. Perhaps I overlooked something, but I followed your links and I did not see an Opera layout engine developer saying that MathML cannot be supported in Opera on desktop for technical reasons. I did, however, see * White Lynx disapproving of MathML and pushing his own stuff * Moose eventually conceding that MathML cannot be rendered using CSS alone. (No surprise there.) * Jonny Axelsson and Hixie alluding to Opera not having a business case for MathML (at this time). > 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. It is good to have two interoperable implementations before a spec goes final. >> Hmm. Freaky economic problems are nowadays solved with Google >> money. :-P > > Have you asked them about support of MathML? I did! For search, I presume? >> 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. TeX4ht can manage some MathML output. It doesn't support any language that has not been specified yet. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Friday, 9 June 2006 03:43:27 UTC