On Jun 8, 2006, at 21:21, <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
