- From: Neil Soiffer <Neils@dessci.com>
- Date: Mon, 14 Apr 2008 13:14:11 -0700
- To: "David Carlisle" <davidc@nag.co.uk>
- Cc: juan@canonicalscience.com, public-html@w3.org, www-math@w3.org
- Message-ID: <d98bce170804141314k28611c20jbd384c4eabf41d32@mail.gmail.com>
On Mon, Apr 14, 2008 at 6:18 AM, David Carlisle <davidc@nag.co.uk> wrote: > > > > Performance issues when rendering MathML on Mozilla have > > been noticed by other people also. > > > ... > > a) the nature of the MathML documents in HELM, which have lots of > nested > > tables, and b) the implementation of MathML tables by means of the HTML > > table layout algorithm. > > The fact that (very) deeply nested tables laying out formal proof > terms triggers some slow behaviour in mozilla's HTML table > layout code doesn't seem that relevant to a discussion of what authoring > syntax should be used for mathematics in web pages. Presumably if you > used the kind of markup that you are suggesting, that even more directly > translates into css-styled html markup, a deeply nested table would > still end up being a deeply nested html table, with the same issues. > > David > > > Also, the last sentence undermines your claim that MathML is the problem: The same documents rendered by GtkMathView take from 2 to 3 seconds, also > achieving a higher quality rendering (using the same fonts). Same document -- that means it is an implementation issue. In the interests of fairness, it should be noted that GtkMathView comes from HELM, so they probably resolved any inefficiencies that Mozilla has in rendering deeply nested tables. Neil Soiffer Senior Scientist Design Science, Inc. www.dessci.com ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~
Received on Monday, 14 April 2008 20:14:45 UTC