- From: <juanrgonzaleza@canonicalscience.com>
- Date: Sat, 15 Jul 2006 06:52:42 -0700 (PDT)
- 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 UTC