From: <juanrgonzaleza@canonicalscience.com>

Date: Sat, 15 Jul 2006 06:52:42 -0700 (PDT)

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

To: <www-math@w3.org>

Date: Sat, 15 Jul 2006 06:52:42 -0700 (PDT)

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

To: <www-math@w3.org>

Robert Miner said: > Hello All. > > Juan R wrote: > >> Whereas one can see an increasing interest in CSS, including printing > of >> books, there is not such one increasing in MathML. At contrary, > apparently >> nobody want print using MathML and there is a return to TeX bassed > systems >> (MathML to TeX conversors). > > This is false. Sorry Robert, but you are supporting your thought with a link to one page to your bussines containing links to publishers using some of your product in their workflow. Look http://www.google.com/trends?q=MathML%2C+CSS&ctab=0&geo=all&date=all It shows an increasing interest in CSS language (exactly I said previously). The plain line at thr bottom is MathML. Since the interest in MathML is so small here you cannot visually compare both therefore try with http://www.google.com/trends?q=MathML&ctab=0&geo=all&date=all and you can see that interest in MathML is vanishing (exactly I said previously). Try also with http://www.google.com/trends?q=MathML%2C+LaTeX&ctab=0&geo=all&date=all > Amongst professionals who deal with commercial publication of science, > technical and medical material, the growth of MathML has been steady and > marked. Based on Design Science sales records, MathML usage in > large-scale publishing workflows has been increasing at around 100% a > year for the last 3 or 4 years. This data is just as concrete as Ian > Hutchinson's download logs. You can see a selection of some of the > organizations using our tools for MathML in production at > http://www.dessci.com/en/products/mathflow/mf_cust.htm. In the Design Science’s page: i) It is not said for what MathML is used ii) It is not said what MathML is used: All? Content? Only presentation? iii) It is just becoming from publishers. iv) MathML is being mainly used off-line there. You can use anything off-line. For instance, I could use something so crazy like <my-math:fraction><style class="display"/>b<separator-for-fractions/>2</my-math:fraction> in my workflow and could transform it to/from p-MathML <mfrac><mi>b</mi><mn>2</mn></mfrac> v) The adoption of MathML in some publishers workflows is not because strengths of the markup but because the change to a full XML workflow. The benefits from an all-XML approach are supersed by any disavantage of MathML (some disavantages minimized in off-line usage) vi) How and when is MathML being used? E.g. Elsevier is using an in-house modification (not the w3c standard) and complementing it with other CEP markups and models. vii) The Design Science’s page does not present trends not global comparisons viii) Etc. > In many ways, our data likely gives a better indication of adoption > within the industry than the data about TtM, as TtM is more focused on > end user sales, and primarily end users in academia using TeX (where > most TeX usage is) at that. Remember that both TtH and TtM are using TeX as input syntax. Therefore, the same input syntax can be converted to MathML or not and as Prof Hutchinson, with last 5 years statistics shows, there is an increasing interest in do _not_ convert to MathML. > Keep in mind that Prof Hutchinson is a > physicist, who does TtM on the side as a hobby. By contrast, Design > Science sales tend to be large, business-to-business sales to enterprise > customers, with ongoing supprt. These are customers are typically > making major investments to upgrade their publishing workflows to XML. > They are overwhelmingly choosing MathML to represent mathematics. The > are only a handful of large, serious publishing operations that have > actually switched to XML for their production workflows that aren't > using MathML, and even in those cases, it is mostly because of backwards > compatibility, typically with TeX-based workflows, or in one or two > cases, ISO12083 math. See trends above and discussion after. Moreover, choosing MathML in a world where _only_ MathML has been, may be not a symptom of acceptance of MathML, is it? Would be interesting to see the acceptance of alternative approaches in that niche in future. I wait that MathML was abandoned in future by publishers. > It is easy to understand how you would be unaware of what is going on > amongst commercial STM publishers, and indeed, their requirements are > very different from those of the amateur or academic individual wishing > to hand author web pages for consumption of other similar individuals. Sorry but this is again incorrect. I have discussed technical points on STM with printing and search industries and do not recommend MathML. For instance, a known search engine for STM literature prefer another format than MathML for automated indeexing. Sorry but search matters. ACS and other bodies you cited use alternative or own indexing systems. I also know a bit the Elsevier’s workflow, that they chose MathML because fitting in an all-XML approach and how and where they are using an in-house modification (I do not know all modifications done) of the w3c MathML. <blockquote> Adopting common international standards has not been without problems. [...] In all these cases [Unicode, MathML, CALS] we were forced to modify the standards, with the risk of losing the benefits of adopting those standards. </blockquote> I also know in that ways MathML is not used in the CEP markup model. E.g. the LaTeX markup {}_a^bX is not encoded using MathML presentation but the own CEP basic markup <ce:inf loc="pre"> and <ce:sup loc="pre"> I also know that something like Rf = 0.45; IR: 3423 cm^{−1} (NH). is encoded like <ce:it>R</ce:it><ce:inf>f</ce:inf>=0.45; IR: 3423 cm<ce:sup>-1</ce:sup> (NH). In a </ce:formula> container in Elsevier academic articles. Therefore, the "statistics" about usage of MathML may be carefully examined. And I also know that Elsevier’s folks recognize the lack of support of MathML and claim. <blockquote> MathML [...] is not yet supported natively in the important browsers that Elsevier’s readers use, although we expect that to change in the near future. After some time in which readers switch to the newer version, we can assume that MathML can be rendered without problem. At present, however, we continue to supply stripins for the element mml:math. </blockquote> Therefore, Elsevier’s folks ***expect*** and ***assume*** and today are providing stripins to most of their users. Probably Elsevier’s folks are not browsers developers and are not aware of difficulties to correct and full implementation of MathML in browsers. Probably also Elsevier’s folks are not web designers and do not know of limitations and errors of usage of presentational markup on the web. > understand perfectly why you are frustrated about the difficulty of > authoring and viewing math in your canoncial science web pages, and why > this skews your viewpoint. However, from the point of view of > professionals who make their living from STM publishing, display in web > pages is merely one facet, and generally not a very critical facet, of > what they need to produce from their source documents. This is reason that usage of MathML in a XML workflow is mainly off-line. Therefore MathML -Math for the web- is being used mainly because fits in a XML workflow. > Most of the commercial and enterprise customers we work with place > strong emphasis on storing as much information as possible in their > source documents, to maximize their options going into the future. They > also prefer mature, standard solutions for which mature, supported tools > exist and that integrate with the rest of their workflow software. The > central requirement is generally the need to produce high-quality print > output via PDF. Many must deal with accessibility. Most are interested > in better information retrieval options. Almost all of them need strong > validation, and maximum flexibility in transforming data for a > wide-range of applications, from online assessment to symbolic > computation. Nothing of this except “standard” is really strengh of MathML (with limitations as that of Elsevier in-house modification in mind). Let me add some additional thouths about the strengh and advantages of MathML NSF/NSDL Workshop: Scientific Markup Languages Workshop. (National Science Foundation) June, 2004. The Workshop discussed the adoption and development of scientific markups among communities of scientists, publishers and vendors, and end-users. Let me quote part of thoughts about MathML (and just compare with great proclamations and distorted propaganda from many MathML folks, including the free propaganda at the 2006 MathML charter w3c page). <blockquote> There remain, however, a number of substantive issues with regard to MathML. </blockquote> <blockquote> MathML is still seen as somewhat experimental by many potential users in the math community. </blockquote> <blockquote> Mathematics notation is extremely complex, with new notation required routinely to deal with cutting edge research in the field. MathML is therefore recognized as inherently incomplete. </blockquote> <blockquote> The authors of MathML have explicitly targeted it for the expression of mathematical content up through the early undergraduate level (first-order calculus). Its utility for research mathematics, even with its explicit built-in extension mechanisms (e.g., as exploited in the EU funded OpenMath project), is still uncertain. </blockquote> <blockquote> MathML is also intentionally bimodal, containing sets of elements to describe separately the presentation of mathematics and the semantics of mathematics. Generally, early implementers have focused on one or the other but not both parts of the ML, resulting in asymmetrical implementations that don't always interoperate as well as might be desired. </blockquote> <blockquote> Adoption has been somewhat slow, in part because of the entrenchment of TeX within the research mathematics community. Additionally, although mathematics is recognized as key to many scientific disciplines, and there have been some attempts to incorporate or accommodate MathML markup rules within other domain-specific markup languages, there are examples of domain-specific markup languages (outside of pure mathematics) that include their own markup semantics for basic mathematics needed within the domain of interest, rather than borrowing from MathML as needed. </blockquote> However, we know statistics of people prefering TtH rather than TtM, when _both_ are using TeX as input syntax, therefore, the rejection to MathML is not because TeX popularity alone. <blockquote> On the positive side, there have been major inroads in getting the middle layer of the scholarly communication architecture to embrace MathML. While few if any research mathematicians author directly in MathML (a surprising number do author directly in TeX or the related LaTeX language), publishers (e.g., the American Institute of Physics and the American Physical Society) and vendors of computer algebra engines and related tools (e.g., Wolfram Research, Design Science, Maple) are incorporating MathML into their workflows and products. This is being done to provide a high level of interoperability between systems and potentially to provide (in the long term) an enhanced user experience for the consumers of mathematical content. </blockquote> <blockquote> In his introductory remarks about MathML, Robert Miner identified four likely long-term benefits of broader adoption and use of MathML: - facilitating cross-media publication, dissemination, and consumption of mathematics in an increasingly XML environment; - providing another way that developers of authoring systems, digital libraries, and related applications can leverage their XML investments; - meeting the legislative demand for better accessibility to content and educational resources containing mathematics; and, - enabling more robust and general-purpose interactive mathematics tools. </blockquote> However we can observe none of this benefits in many sites using MathML online: including academic journals, databases, educative sites, blogs... I have analized many of them in canonical science today and in future issues I will add more review and examples of real MathML markup is being served on the internet. <blockquote> In discussing the potential benefits that MathML might bring to bear on educational services and models of learning, there were multiple points of consensus as well as several open issues and uncertainties identified. </blockquote> <blockquote> There was a consensus that MathML is increasingly being seen as an attractive lingua franca for expressing and sharing mathematical content in an educational context, at least among tool builders and digital library developers. Early experimentation and the successful integration of MathML in math education software like Mathematica and Maple and in tools for the Web made available from Design Science and Integre Technical Publishing give concrete evidence that the dissemination, interchange, and exploitation of mathematical content at a level appropriate for many educational purposes can be accomplished effectively using MathML. </blockquote> Also other sites (and tools) using MathML just evidence the contrary. Do not forget that most of advantages are about FULL MathML not about the ugly presentational code is being spreaded over the internet. For instance, when claimed that MathML can encode content and help in education, or can be more accesible that images or TeX islands, I see not MathML folks explaining in media that p-MathML is being mainly served on the internet is both computationally unuseful and completely innaccesible. <blockquote> Interactive implementations designed for use by end-users in an educational context remain relatively immature and "hand-crafted" at this point in time, but show great promise. </blockquote> Promise, promise, promise... <blockquote> That said there remain several open issues as well regarding the potential of MathML to help meet educational needs for a better way to express mathematics in online documents and learning resources. </blockquote> <blockquote> The utility of MathML to enhance searching and improve accessibility of online mathematical content has not yet been proven. </blockquote> Well, I have extensively verified that accesibility of code contained in academic journals as Living reviews, blogs as Distler’s Musings, databases at NAG, journals of mathematics, educative projects as ASCIIMath, recent GLOSS system discussed at MSOR journal and many others is poor that when one uses an old HTML + GIFs + ALT model. Take the case of the giant publisher Elsevier. Imagine during and instant an idilic future where MathML is broadly adopted by all browsers. If in that idillic future, Elsevier begins to serve their scientific, technical, and medical articles on XML + MathML format for users’ consumption, the code for mathematics would be also more inaccesible than if encoded via GIFs + ALT. It is obviously time for a better approach. <blockquote> Searching of mathematically laden content by the mathematics it contains is a complex issue. It's not altogether clear whether the level of description implicit in content (semantic) and/or presentational MathML is sufficient to support robust searching on the mathematics contained in a resource. </blockquote> Well, I like experience. I did several studies on this when researching the posibilities for a STM workflow via MathML. Results are that MathML is not really working since the spec contain many holes. Already in this list we discuss dozens of different ways to encode something so simple as \dot{q} and differences in the output generated by different MathML tools. Search engines would be highly inefficient on search of mathematical fragments due to combinatorial nature of virtually infinite different markups generated by tools. Let me continue in this topic. Take stuff so simple as {}_a^bX, with a and b numbers and X letter. That would I type in a MathML search engine? What would I type for searching trivial stuff like E = mc^2 or (a + b)? Note I can type E=mc2 and some few variants in Google and the engine (no MathML support) is able to find HTML pages. I repeat, what would I type in an MathML search engine if am searching pages encoded in MathML? <blockquote> It's also not yet certain that readers and other accessibility tools will be able to exploit MathML effectively to make the mathematics embedded in a resource more accessible, though that seems a safer bet. </blockquote> <blockquote> While MathML is being adopted (at least experimentally) behind the scenes -- e.g., as an exchange format for interoperation between applications like Mathematica and Maple and in the editorial workflow of scholarly journals, it has not been widely adopted by the authors of educational and scholarly mathematical content. </blockquote> <blockquote> Research mathematicians continue to rely heavily on TeX, which though exclusively presentation oriented (really a specialized language for the typesetting of mathematics) is firmly entrenched. </blockquote> <blockquote> Educators continue to rely on cruder technologies (e.g., embedding mathematics as static images within HTML or presentation only markup within PDF documents) or exploit proprietary solutions such as Mathematica workbooks. </blockquote> <blockquote> There remains a bit of a "chicken and egg" problem in that authors are hesitant to adopt a new technology until it has proven its value, and it remains difficult to prove the value of MathML without a sufficient body of MathML content. </blockquote> Well, I have provide extensive review of why many (if not all) of MathML code is being generated in dozens of approaches, tools, and experiments: I) Structurally invalid. II) Several tools cannot communicate via MathML since code generate by some tools is not accepted by others. III) The code can be less accesible that using GIFs + ALT! IV) The code is not adequate for science and enginnering. For instance, something as _content_ MathML 2.0 code <math display="block" xmlns:mml='http://www.w3.org/1998/Math/MathML'> <mml:apply> <mml:eq></mml:eq> <mml:ci>E</mml:ci> <mml:apply> <mml:times></mml:times> <mml:ci>m</mml:ci> <mml:apply> <mml:power></mml:power> <mml:ci>c</mml:ci> <mml:cn type='integer'>2</mml:cn> </mml:apply> </mml:apply> </mml:apply> </math> _is_ not fully markup for any minimally acceptable scientific markup. V) The MathML markup is contrary to basic web design guidelines and repeat errors were avoided in HTML and others: e.g. <font> avoided in HTML whereas <mstyle> extensively used in MathML docs one find on the Internet. VI) MathML is CSS unfriendly, DOM unfriendly, HTML unfriendly, and even XML unfriendly. Doing implementation in browsers really difficult or imposible. <blockquote> Discussion of this issue led naturally into an extended discussion as to how MathML is now or might in the future engage the mathematics community. It is clear that MathML at this point in time is more appealing to organizations or institutions than it is to individual practitioners. As a non-proprietary, expressive, comparatively low-loss way to represent mathematics, MathML has clear attractions for long-term archiving and interchange of mathematics on a large scale. Hence its attractiveness to publishers and middleware tool developers. Several participants in the breakout session suggested that MathML may continue to develop as a largely or even exclusively back-end technology, used behind the scenes as a way to store and exchange mathematical content, but not necessarily as a format with direct impact on the author's or the end-user consumer's experience interacting with mathematical content. </blockquote> And once they discover why MathML is not really spreading on browsers (because technical problems rather than lack of interest), what are the limitations to presentational markup, why the p-code is more inaccesible that using GIFs + ALT, what are the irrational resources (memory and time) needed for a full paralell markup, and why content MathML is not very popular at research mathematicians and computer scientists and once they see that a full CSS-SVG approach will offer more advantages (e.g. via SVG you can render mathematical formulae, chemistry formulae, _and_ Feynman diagrams, via CSS you can render XML databases, HTML and XHTML _and_ mathematical formulae), then I we would observe a generalized abandon of MathML. Thanks to my research on the limitations of content MathML, research done by other authors, and some informal polls I see highly improbable that research mathematicians use content MathML, they would prefer something like so-called semantic LateX, which has proved to be more powerfull than content MathML for encoding mathematical “meaning”. The technique has been used with relative success in las edition integral table by Gradshteyn and Rhyzik (GR). No similar approach has worked using even OpenMath (the officially extension for content MathML) as reported by R. Fateman. > Thus, from the point of view of your typical STM publisher, the whole > subject of CSS styling of math markup of some kind for display in web > browsers is just one aspect of a much bigger problem. Use your favourite markup for content, structure, and storage, and CSS for rendering and printing, for instance. > If George (White > Lynx) is able to get his XML-Maiden stuff to the point where it works > really well on a variety of browsers, and it is reasonably stable and > well supported, that would be interesting. Nothing impede w3c for doing that. Errors of the past can be corrected and then mathematical markup would be used by publishers, individual authors, educative sites, online enciclopedias... > It would be one of many > output formats that would then be possible options for web display, > along with PDF, HTML+images, jsMath, AsciiMathML and the rest. Some, > maybe even many, serious content providers would start using it. The Center for CANONICAL |SCIENCE) will probably be the first official body doing use of CSS for rendering of mathematics. We abandon both p-MathML and c-MathML. The current version of the site [www.canonicalscience.com] is a fascinating example of a very very bad design. The XHTML + MathML approach never worked in the way I was waiting after reading great propaganda about MathML. The site is full of errors but is maintained as example that would NOT be done. The p-MathML code generated by some popular tool and after admended by hand (often the output is inefficient and I used a lot of tools listed in the w3c MathML site) is just accurate example of _structurally incorrect_, and _inacessible_ code (the XHTML is also very incorrect, but it was a continued experiment in DTDs, MIMES, extensions and other stuff) The XHTML code was never corrected because intensive research on MathML and XHTML capabilities and their alternatives and also an exercise in different publications models, navigation, and others. Of course, in the next future (official) website will be improved. Today you can see examples of very bad MathML code will be eliminated in next version of the site [http://www.canonicalscience.com/en/researchzone/canonical.xml] [http://www.canonicalscience.com/en/researchzone/nanothermodynamics.xml] [http://www.canonicalscience.com/en/researchzone/time.xml] and rendered as CSS (and I wait rendered by _any_ current browser). If CSS is improved with graphical capabilities as Mozilla foundation want then, in a future, chemistry, physics or biology will be also rendered in that way. > Before that, the Microsoft representative > to a previous Math Working Group went to the lengths of hiring a > consultant to look into the feasibility of render math using CSS and > JavaScript in IE5. Which again proves that lack of support of MathML in browsers is not mainly because lack of target or commercial issues. I have heard many times that Microsoft is not interested in math and reason that does not support MathML. I always asked if that is true, why then the equations editor equation in Word, and the support of MathML in Office XML? I also know that Microsoft was initially interested in native support of at least p-MathML in MSIE but abandoned the project. Now you verify they was also interested in CSS rendering of math. I have read that lack of economical interest is cause of the fiasco to introduction of MathML in browsers. E.g. Trevor Hawkes in MSOR connections 2002, 2(3), 16-18. He just ignores the technical difficulties for the implementation of MathML in browsers (implementation of math via CSS is however cheap). I wait that Microsoft becomes interested in CSS approach again. > We have worked closely with the CSS Working Groups My news are different, with no real communication between both groups and the project for CSS-Math in a delicate status. > But, it is huge leap to claim that XML plus CSS could replace MathML. > Until you can offer the industry a standardized markup language, with > multiple vendors of production capable tools, you don't have a viable > alternative to MathML. Until you can demonstrate accessibility, online > assessment, and symbolic computation, you don't have a viable > alternative to MathML. Nothing of this is really (in rigor) proven with MathML and one thing are theoretical or specially selected set of problems for illustration and other very different thing is real world, where MathML is very very far from those goals. > Until you can demonstrate the ability to produce > a variety of output formats from a single source, including professional > print-quality output that can be easily integrated into current > production workflows as well as HTML and XTHML output, you don't have a > viable alternative to MathML. That is trivial and/or done. > As I have pointed out consistently and repeatedly, your view of the > requirements for a math markup language are entirely too narrow. XML + > CSS solutions for rendering math in web browsers have their place as an > output format. But it simply isn't a serious contender for meeting the > broader requirements for a math markup language, as they actually exist > in the world as opposed to within the limited scope of your canonical > science project. Well, precisely it is MathML is too narrow. > If you want to work -- really work -- on improving XML + CSS rendering > of math, then start doing it. There is plenty substantive technical > discussion taking place on the subject on this list. Go ahead and work > on really good rendering of scripts and stretchy fences, and all the > other problems. CSS already can compete with p-MathML even with limited support for CSS 2.1 (a standard was not specially designed for math but works!). Today, the CSS approach lets us accesibility, rendering quality, and acceptable printing (via good CSS formatters) whereas MathML accesibility is mainly inexistent, rendering quality is poor in practice than in theory, and printing sucks. > If you succeed, XML+CSS will inevitably become more important > relative to MathML, and you will achieve your goal more effectively than > any number of postings bashing MathML will ever accomplish. Hum! Why can Neil (MathML WG) bash that TeX is not CSS or DOM friendly and therefore would not be used on the web whereas he does not note that MathML is not CSS or DOM friendly? Why can Wolfram Research (MathML) bash that TeX does not differentiate dx (differential) from dx (d times x) whereas is not noticed that MathML is being served in the internet does not differentiate? I remember here Carlisle and others recommending the use of <mi>d</mi> or <mo>d</mo> for the differential, instead the special character popularized by Wolfram Research. Why can official MathML FAQ bash that ISO-12083 is presentational and therefore was not reused for math on the web whereas is not noticed that none browsers supports content MathML, and almost all of the tools and code is being served on the internet is based inp-MathML (is still more presentational than ISO 12083)? Why can MathML folks bash that LaTeX has not adequate model for prescripts and use a trick, whereas is not noticed like the IteX approacht simulate prescripts using a similar approach (at contrary the w3c claims that IteX approach is "nice")? Why can MathML folks bash the low accesibility of GIF based approaches (so extended in educative sites) whereas is not noticed that p-MathML code spreading in ASCIIMath, publishers, journals, enciclopedias, blogs and so on is more inaccesible? Why can D. Carlisle (MathML) bash that integral sign rendered via CSS in canonical science today is too bold whereas is not noticed that some signs generated by XSL-MathML formatter listed at the w3c MathML tool list are more bold still (really the rendering is ugly)? Why can Paul R. Topping (MathML WG) bash that criticism to the unusual verbosity of MathML is a non-issue and that extra size of MathML code would not be an issue for something like mathematical notation because in its own words "It is hard to imagine mathematical notation making a large fraction of any dataset", whereas is not noticed that the own MathML specification introduces an special markup for saving Mb in full MathML encoding? Why can MathML folks bash any alternative approach with "you will fail", "I suspect it will fall", "your approach will be ignored", and others beatiful "positive" responses whereas, for instance, Prof. Hutchinson’s reply "My guess is that it won’t. But with luck it will gradually become more widespread" to the question "Will MathML 'take off' and take over web mathematics publishing?" is received with certain hostility? Why can MathML folks critize plugins-based approaches to render mathematics on the web but sistematically fail to explain to public that MSIE renders MathML when using an third-party plugin? Why can MathML folks argue (without real rationale) that CSS approach only would work for simple math whereas do not noticing the unusual difficulty to render K-12 math with MathML? Why can Robert Miner (MathML WG) write in a AMS article over the advantages and promises of Hermes LATEX-to-MathML translator, but after that same author does not notice that examples contained in the HERMES project site contains MathML documents are often structurally invalid, render ugly (in some ocassions), cannot be searched (because lack of standarization of the markup generated), and are completely inaccesible (with GIFs + ALT old approach doing it better)? Why is not noticed that articles contained in the HERMES site are encoding authors and datas as headings of level 3 whereas evangelizing about supposed advantages of MathML for a semantic web? Why can Robert Miner (MathML WG) bash about lack of structure for scripts in the TeX encoding and evangelize about the two child model of p-MathML whereas never write an AMS article explaining to readers as IteX approach (and many others) are simulating presuperscripts as <msup><mrow/>"script-here"</msup>"base-here"? At least in TeX one already know that base is not well defined, but most (if not all) of people would feel disturbed when discover that using IteX (or other tools) one is generating code is so inefficient and structurally incorrect as the TeX code they heard was no suitable for online math... Why...? > > --Robert > > Robert Miner > Director, New Product Development > > Design Science, Inc. > 140 Pine Avenue, 4th Floor > Long Beach, California 90802 > USA > Tel: (651) 223-2883 > Fax: (651) 292-0014 > robertm@dessci.com > www.dessci.com > ~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor, > TexAide ~ Juan R. Center for CANONICAL |SCIENCE)Received on Saturday, 15 July 2006 13:53:17 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:58 GMT
*