From: <juanrgonzaleza@canonicalscience.com>

Date: Tue, 18 Jul 2006 00:24:19 -0700 (PDT)

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

To: <www-math@w3.org>

Date: Tue, 18 Jul 2006 00:24:19 -0700 (PDT)

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

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 GMT

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