- From: <juanrgonzaleza@canonicalscience.com>
- Date: Mon, 17 Jul 2006 05:55:33 -0700 (PDT)
- To: <www-math@w3.org>
Neil Soiffer wrote: > > Juan, > > Your email has so many misstatements, falsehoods, and quotes taken out of > context, it is hard to know how to reply, especially since you continue > to repeat them and disregard, misstate, or misunderstand what people > have said to you. > Maybe I am loosing the whole point, but in that case my criticism would be simply ignored by people reading this list and i would stand alone in the net. If my criticism is not correct, then you would not worry because MathML will remain unafected and, in a near future, all people will use MathML for mathematics as today we use HTML for text. The problem is that you are who is misunderstanding i am saying as will be noted below. > <blockqoute> > In canonical science today, I see that CSS renders equals or even better > than MathML for examples I tried. For instance, the simple fraction > renders nice in CSS and distort in MathML. > </blockqoute> > <blockqoute> > Curiously I offered examples of math rendered with MathML and with CSS and > most of people choosed the visual CSS rendering. I will provide more and > more examples. > </blockqoute> > Assuming you are referring to the examples in [1], David Carlisle pointed > out in [2] that you didn't install the fonts and ignored the warning that > the fonts weren't installed. Hardly an honest comparison! > Your refusal to admit that this is even a > problem in your reply [3] is an example of how poorly you understand > math notation. 1) as I already said in my reply to Carlisle in [1], I did not install the special fonts because I was comparing pure MathML and CSS (not MathML + special fonts). Your emphasis remember me XSL folks comparisons of CSS with full XSL instead _just_ CSS vs XSL-FO or _just_ CSS + JS vs. XSL. As already said in my reply adding special fonts, the MathML root renders correct but the CSS rendering continues being *the same*. 2) The usage of special fonts (no designed for the web) is not a good thing. This has been addressed in a number of papers and talks. The Mozilla rendering engine is polluted with CM metrics and future fonts will need of a rewriting of the full engines. Interestingly, this data is never commented by MathML folks. I already wrote about all that and cited two folks with interesting commments in [1]. 3) It was claimed from several MathML folks that special fonts ***are*** needed for the rendering because technical motives of rendering math. Therefore the root cannot be rendered without special fonts at the MathML side because technical motives. Well, that is not all correct. i) the CSS approach is able to render the simple root without the special fonts, and ii) others approaches to rendering of math (e.g. SVG approaches) do not need of special fonts for rendering of roots. Therefore, there is no problem to explain to people that special fonts are not needed in alternative approaches. Unlikely the MathML (Gecko engine) approach, which need of special fonts and special version for each new font, the CSS approach will work for any font (present or future) that users or authors like. 4) Before questioning the honestity of someone, please reply why MathML folks rudely critize any alternative approach (e.g. Carlisle criticism "the integral sign is too bold”) whereas the same effort is not addresed to critize some of rendering of tools cited in the MathML site. Some MathML software are generating symbols are rendered more bold still (really the rendering is ugly even for non-mathematicians) but nobody critize that. The rendering quality of some SVG-MathML approaches cited in the MathML site is lower than via CSS is being promoted here, still I never see a MathML folk critizing the MathML approaches. Note also Carlisle's emphasis on that the + in the example sited in [1] was too high in the CSS rendering. Well how can you claim that my comparison was not honest, whereas you are completely unable to i) Read i wrote that a+b was rendered using simple version of CSS rendering, without tokenization (this will be observed once i submited the code to the blog), but in a more advanced approach yuo can align the + in a separate way ii) and recognize that the same criticism to + symbol is not being adressed to [http://www.antennahouse.com/product/mathml.htm] see also [http://www.antennahouse.com/product/img/mathml_sample.pdf] listed at the MathML site here [http://www.w3.org/Math/Software/mathml_software_cat_composition_engines.html#Iantenna_house_xsl_formatter]? Why the "failure" or "limitation" X is rudely critized when is present in the CSS approach to render mathematics, but the same X is not even commented when generated by a MathML software? Please explain this with great care. Explain to users why the "+" in x + a / b done via CSS (remember that can be improved) in [1] can be critized by a MathML folk, but the "+" in m + n &neq; 0 in [http://www.antennahouse.com/product/mathml.htm] see also [http://www.antennahouse.com/product/img/mathml_sample.pdf] is not critized. Please explain with great care in what way this is honest and a comparison CSS vs. MathML instead CSS vs. (MathML + special CM fonts) is dishonest. Explain with great care why some of software listed in the MatHML site can offer a rendering quality poor that obtained today from pure CSS approach but ***only*** the CSS approach is both critized and strongly rejected. > > If you are saying most people choose CSS over MathML for rendering math, > you are starting with a hypothesis that you have not backed with data. Pardon? I said "look this screenshots" and asked "what do you prefer?" and people said. > Robert Miner[4] gave a long list of users of MathML that you either > disparage without > providing meaningful data or by quoting people out of context. He pointed > out that > usage of MathML in large-scale publishing workflows have increased 100% > per year for > the last 3 or 4 years. And you ignore any comment about that. Including other people has said about the acceptance of MathML off-line and rejection on-line (remember that MathML was designed for the web). > These are hard numbers that indicate MathML is not only > alive, but is thriving. And you take your own data and ignore any other data pointing in the contrary way, including Google Trends and 2006 data on statistics on TtH and TtM dowloads. You also ignore that many people in the WHATWG waited no support for MathML in next (X)HTML5 and claimed for an alternative approach, but that data may be of no interest for you and then its validity questioned. But whereas I am citing data and statistics from third parties with no a priori economic interest in MathML, you and Miner are citing data from Design Science. Data is just a list to consumers and says nothing about trend or global percentages. > MathML is used in almost every major math accessibility project these > days. [7] gives > a list of some of them. Look at the conference proceedings for ASSETS and > ICCHP for > more projects. Your sweeping claims with respect to inaccessibility of > MathML are > without basis in fact. Again another off-topic. Since you carefully ignore that I am critizing the spreading on the Internet of incorrect presentational code and you carefully ignore a review of some of the code (obtained from real world) I am using as illustration. Please what is the accesibility of codes (extracted from real world) I have listed in canonical science today in many posts? At least people working in acessibility programs (e.g. AudioMath) is able to recognize in public that MathPlayer is limited, or that presentational MathML is not really designed for accesibility (only content Markup can be complete) and they the choosing for AudioMath was based in the fact almost none MatHML tool (none browser) support full content MathML (and full accesibility) of presentational. You also ignore any other data like for instance that MathML code is being spreaded in the internet is not using the special entities for accesibility, are using tricks for rendering prescripts or tensors, and elements of matrices... You also ignore the remarks done by external specialists on the experimental status of accesibility for MathML. Again the analysis from (some) MathML folks is not balanced. > parens. However, as Partick Ion showed [9], this trick is currently > limited to > Firefox. Until CSS actually adds properties to render math well (and the > browsers > actually add the support), it really isn't a viable option. But at contrary that you both George and I am able to see strengths and limitations of CSS, whereas you only can see limitations at the CSS side with abolutely no criticism on MathML, neither on the spec, nor in current support of MathML in browsers nor in the code generated from the tools. We are able to see current limitations with the CSS approach and are able to say, what CSS properties are today only supported by this browser. For instance was i who suggested the use of some Gecko moz-CSS extensions to George some time ago for the rendering of fractions and some other stuff. However, at my best current knowledge no MathML folk critizes the support of MathML in Firefox. And one may heard the criticism from external people. E.g. let me cite Luca Padovani thoughts: <blockquote> As a matter of fact, despite of its modular architecture, Mozilla’s implementation of MathML suffers from a number of severe problems: </blockquote> <blockquote> Mozilla is not able to fully implement MathML formatting semantics. [...] </blockquote> Our approach is much more pragmatic and balanced. We offer an alternative and people will chose they consider viable in function of their needs. Many people is today considering viable CSS and not viable MathML in despite of so many propaganda you devote to the criticism of CSS approach. Note also as the XML-MAIDEN site is able to recognize limitations of approach whereas citing bugs, whereas corresponding MathML site devote more emphasis in supposed advantages of MathML than in real status. You are also ignoring any other technical comments at respect of rendering via CSS were said and alternative ways to render matrices. No more I can do then since you are not hearding. > Rather than bashing MathML, your time and everyone else's time would be > more > effectively used if you spent your efforts working towards improving the > CSS > implementations in browsers you care about. Indeed, maybe you would have > time to get > around to showing the > world how wonderful your solutions are by getting your promised website > update [10] > finished and being "the first official body" to use CSS to render math. Is this irony? What is the problem with alternative approach? If MathML is so powerfull, render so good, is so popular as you state and the websites using MatHML are accesible and all that, what is then the problem? People would masively reject the CSS approach and in a few years it would be just a historical curiosity... Why are several MathML folks wasting so many time on bashing the CSS approach or inventing myths on (they believe) cannot be rendered via CSS instead promoting the approach, developing a solid CSS-Math module improving weakness of CSS 2.1 for mathematical rendering and promoting the CSS approach togheter p-MathML or SVG? > > Neil Soiffer > Senior Scientist phone: 562-433-0685 > Design Science, Inc. http://www.dessci.com > "How Science Communicates" > MathType, WebEQ, MathPlayer, Equation Editor, TeXaide > > > > [1] http://canonicalscience.blogspot.com/2006/07/rendering-mathematics-in-html-via-css.html > [2] http://lists.w3.org/Archives/Public/www-math/2006Jul/0003.html > [3] http://lists.w3.org/Archives/Public/www-math/2006Jul/0007.html > [4] http://lists.w3.org/Archives/Public/www-math/2006Jul/0054.html > [5] http://www.w3schools.com/browsers/browsers_stats.asp > [6] http://www.dessci.com/en/company/press/releases/031216.htm > [7] http://www.w3.org/Math/Software/mathml_software_cat_accessibility.html > [8] http://geocities.com/chavchan/temp/matrix.xhtml > [9] http://lists.w3.org/Archives/Public/www-math/2006Jul/0056.html > [10] http://lists.w3.org/Archives/Public/www-math/2006Jul/0061 > Juan R. Center for CANONICAL |SCIENCE)
Received on Monday, 17 July 2006 13:23:43 UTC