- From: <juanrgonzaleza@canonicalscience.com>
- Date: Tue, 18 Jul 2006 00:24:19 -0700 (PDT)
- To: <www-math@w3.org>
Bruce Miller wrote:
>
> Exactly: Compare a properly installed MathML with a properly
> installed CSS.
> And then, you say, CSS is out? Well, you're welcome to your conclusion.
Well, since some people dislike installation of special fonts, since that
installation of MathML fonts can be awkward in linux machines [*] and
since current Mozilla engine is polluted by CM metrics and this will be
problems when future STIX fonts was available, a more general comparison
-with and without fonts- is desirable.
In so one way users can obtain an accurate idea of one would wait from the
CSS side and from the MathML side with and without font assistance.
Developers can also obtain a more accurate idea of posibilities of CSS for
render math.
>
> Oooh, that's _soo_ unfair: MathML gets to have DTD's and entities!!!!
No comment from my part, since you would finalize with another
misunderstanding.
> In fact, as I recall, you were promising to develop one.
> Clearly, as you imply, the input syntax itself must be trivial;
> it must only be because MathML is so bad that keeps you from delivering.
Well, I explained reasons on why the _original_ CanonMath program for
MathML was abandoned. Sorry to say this, the rest of your thoughts are a
bit outdated. Take next p-MathML fragment
<mrow>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mn>3</mn>
</mrow>
<mo>=</mo>
<mi>β</mi>
</mrow>
It can be directly _duplicated_ as
[::mrow
[::mrow
[::mi a]
[::mo +]
[::mn 3]]
[::mo =]
[::mi β]]
in current approach i am working now. This approach presents some
similarities with recent GLOSS input syntax by Richard Kaye:
mrow
mrow
mi[a]
mo[+]
mn[3]
mo[=]
mi[&beta;]
> Here's a proposal:
> Develop your math input syntax along with conversions to
> Good representations like XML-Maiden or span+CSS w/ or w/o JS
> or whatever. Then, put a clothespin on your nose if you must,
> and develop the converter to horrible, nasty MathML.
>
> When you've done that, I'm sure the community will happy to
> look at your work. I'm looking forward to it.
>
> --
> bruce.miller@nist.gov
> http://math.nist.gov/~BMiller/
Once known your previous messages and replies, I would not wait a
different proposal from you. I would be glad to accept it, but with below
modifications along with a gentle plea for your active participation in
the development of the proposal.
<warning>Next stuff is for purely recreational purposes, but contains data
from real usage of MathML on the web and quotes from authors that
<emph>would be considered by the MatHML WG when developing the MathML 3
specification</emph></warning>
<warning>Next points contain techniques and approaches violating the most
basic web design guidelines and even common sense. Therefore they are not
recommended for real usage in the encoding of mathematics or in online
publishing. <comment>But who matter? After all no MathML folk has still
critized those points here or in public articles, at contrary they are
carefully unnoticed in public! Of course, the same points are condemned
when appearing in alternatives to MathML... </comment></warning>
1) I will use a LaTeX-like (I will choose one from the MathML software
list) as input syntax.
<blockquote source="from draft of a paper by other author sent to me the
day 24 may 06 may be in press">
One possibility is to use a LATEX-to-MathML converter, such as TtM or one
of the other text-based syntaxes for MathML (many of which use a syntax
similar to LATEX). I have rejected these for my own personal use because:
(a) LATEX source code does not contain enough information for any system
to infer the correct output; (b) any use of macros in LATEX can obfuscate
or break the translation process; and (c) such translators never seem to
work on my own documents, possibly because of macros, different fonts, or
something else. However, as they say, your mileage may vary.
</blockquote>
2) Authors and datas will be encoded using <h3>, like in academic articles
generated by the HERMES project (MathML software list) anyone can access
on-line. We will call that semantic approach, as in the HERMES site
containing the docs.
3) Tensors will be simulated via combinations of <msubsup> and <mrow> as
in Distler blog. This derives in a wrong markup structure, very weak
accesibility, and appreciable lose of quality in visual rendering.
4) Pre-supercripts will be simulated as
<msup><mrow></mrow><mi>script</mi></msup><mi>base<mi>
copying the way of several MathML tools. In the meantime, we write a serie
of propagandistic papers emphasizing as wrong TeX is when encoding
pre-scripts –of course, in the best w3c MathML tradition, the irony that
above code is just a verbose version of the TeX encoding critized will be
no remarked-.
5) Rendering quality for roots will be similar to that from XSL-MathML
formatters (MathML software list), but only after dowloading and
installing 5 font families at the client side, 4 families at the server
side, and 2 extra for security (but if you lose some family) in an
intermediate server sponsored by a known CAS provider.
Each family will be distributed in an independent way and browsers engines
will be polluted by font metrics in each case, obligating to full
rewriting of the engine each time user want install and use a new font
(this is based in Gecko relationship with CM and future STIX fonts). As
usual in certain communities any alternative to rendering ot roots will be
rudely critized as "lacking the adequate rendering quality".
6) Client side options will be permitted. For instance, the client can
choose between (option A) a good visual rendering of ds^2 but structurally
encoded as 2s ds (as several popular MathML tools are doing) or (option B)
encoding like (some current MathML tool I also cited here)
<msup><mi>ds</mi><mn>2</mn></msup>
and then the “ds” rendered with a virtual TeX-quality but, ups sorry, in
an ugly roman. No worry with that since that the lack of rendering quality
will be only noticed for alternatives (as appears to be usual in many
MathML folks). Note: this is a radiography ot reality, since still none
MathML folk has critized the rendering quality of some samples of MathML
are being spreaded over the internet, whereas the same folks blame on
alternatives.
7) At least 30 different ways to encode \dot{q} will be permitted
(including the dozen or so already available on MathML today and listed at
this mailing list). We will propose 15 different ways for the encoding of
any mathematical fragment beyond two tokens.
Thanks to this, the different number of ways to encode medium size
mathematical equations will be of order 10^20, loosing any advantage from
using a “standard”. A game called “What Math?” will be developed and
listed also at the w3c MathML software list. The basic idea is that the
player may adivinate different ways to encode the same equation in MathML.
For instance, how many encodings of (a+b) can we find today between the
different MathMl tools?
8) We will propose 8 news entities focused to increasing accesibility, but
wait that most of tools would ignore them (this is copied from the MathML
software list). For instance, something like f(x) _would be_ encoded in
p-MathML like
<math>
<mrow>
<mi>f</mi>
<mo>⁡</mo>
<mrow>
<mo>(</mo>
<mi>x</mi>
<mo>)</mo>
</mrow>
</mrow>
</math>
by accesibility issues (and others) but most of tools (visit MathmML
software list) will encode as plain (and possible combinatorics)
<math>
<mi>f</mi>
<mo>(</mo>
<mi>x</mi>
<mo>)</mo>
</math>
A real example extracted from a popular site at the internet is
<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
<mi>V</mi>
<mo stretchy="false">(</mo>
<mi>t</mi>
<mo stretchy="false">)</mo>
<mo>=</mo>
<msup>
<mi>e</mi>
<mrow>
<mi>B</mi>
<mi>t</mi>
</mrow>
</msup>
<mi>V</mi>
<mo stretchy="false">(</mo>
<mn>0</mn>
<mo stretchy="false">)</mo>
</math>
The site has been called “nice” by the w3c MathML group and is actively
publicized.
Our objective here will be that accesibility of the code was poor still
than using GIF + ALT, which is not very different from many current MathML
websites and docs.
9) Some tools generate extraredundant mrows and even something so trivial
as \fract{1}{n} is today encoded in a redundant way. Examples of the code
generated by MathML tools were discussed here and in other sites. I do not
will repeat.
Extra mrows generate serious problems with Gecko engines but we will
ignore the Mozilla recommendation (as some MathML tools _are_ doing) and
will add at least an extra mrwo for each token (we recommend six nested
mrows for guarantee the collapse of rendering engines when procesing large
documents). For instance,
<math>
<mrow><mi>f</mi></mrow>
<mrow><mo>(</mo></mrow>
<mrow><mi>x</mi></mrow>
<mrow><mo>)</mo></mrow>
</math>
10) <font> was considered harmfull in the past and deprecated in the
(X)HTML community. We could ignore the trend (as Mark appears to suggest)
introducing a redundant <mstyle> element in *each* MathML equation as is
done in the ASCIIMathML approach (also listed at the MathML list).
11) The rendering performance of the only native MathML browser has been
studied and reported by some people (not at the MathML WG, of course)
<blockquote>
For sure, Mozilla is not an option for the mathematical library provided
by HELM and MoWGLI. These days, on a high-end machine, an average theorem
in the HELM library
takes from 10 to 20 minutes to render in Mozilla.
</blockquote>
We wait -thanks to point 9 of above- that 20 minutes can be easily
transformed to 60 or more. Whereas users wait the rendering of some
formulae, we could introduce a new tag <madvertisement> that would contain
advertisements, presented to the user whereas wait.
A special license for usage of the new tag <madvertisement> will be
promoted. This opens the way for companies to demand royalties each time
that <madvertisement> was used online. Past patent policies from the w3c
were rudely rejected [**] but the spec would explain why ISO 12083 was
fatally flawed (the internation ISO standard did not contained a similar
tag).
[*] MSOR Connections 2006, 6(1), 1-3.
[**] W3C patent plan draws protests
[http://news.com.com/2100-1023-273752.html]
Juan R.
Center for CANONICAL |SCIENCE)
Received on Tuesday, 18 July 2006 07:24:52 UTC