- From: White Lynx <whitelynx@operamail.com>
- Date: Sat, 17 Jun 2006 17:15:43 +0400
Oistein E. Andersen wrote: > >>The proposal states that <op> should be used to mark resizable operators, > >>but this presumably does not mean that the size of such operators is actually >>intended to change. > > >It is intended to be larger. > > Yes, but the size is not intended to vary as a function of what follow the operator, is it? I would prefer to leave this issue up to style sheets, both kinds of behaviour make sense, so it is the matter of taste. >Since delimiters are not supposed to change meaning (matrix is matrix) issue is > >left up to style sheets. But if necessary appropriate attributes may be added to > >indicate delimiters explicitly, as you suggested. > > >>[matrix, det, vector => generalised matrix?] > > >This returns us to concept of ISO 12083 arrays. It makes sense, I just thought that > >more specific markup would be viable, but if necessary we can return to arrays. > > Column vectors and perhaps even binomial coefficients can be regarded as a special kind of matrices; > still, it is not necessarily a bad idea to provide specific mark-up for these. > > My main concern is that we should not make arbitrary limitations. Sometimes, different vector-like entities > are actually distinguished by their delimiters, as are e.g. a matrix, a determinant and a matrix norm. What if we will keep "cases" and "choose" elements as they are and will group matrices, determinats, vectors and similar stuff in one element like "matrix" or "array" with some attributes specifying fence styles, like you proposed. > >>I tend to believe that a few `unsupported' constructions should be included > >>anyway if this is necessary in order to cover ISO-12083 (or whatever standard [...] > >>might be chosen). > > >I would prefer not to include them explicitly. For example ISO-12083 allows any > >character as delimiter but of course not any charcater makes sense and not any > >characters is stretched by ISO 12083 implementations. > > That is a good point. Without any restrictions, the only possible complete implementation would > probably be one that deforms the characters used as delimiters in order that they fit into a rectangular > shape of a pre-defined ratio. And if we limit the choice, the problem is to avoid `unnecessary' limitations. Elsevier Math DTD limited choice to number of predefined values, in LaTeX number of stretchy delimiters is also finite, so listing them explicitly makes sense. > > The current proposal does not seem to include the following elements of ISO-12083: > - <overline> and <undrline> [sic] (could be useful - feasible in CSS?) Right, they have to be included, originally I expected to rely on appropriate HTML elements, but we lack overline in HTML so it has to be added to math proposal. > - <fence> with arbitrary delimiters (possibly not a good idea) Probably it is better to list number of delimiters explicitly like in LaTeX. > - <box> (unnecessary?) It can be added, if necessary. Functionality can be provided via CSS in any case, with or without box element. > - labelled arrows <subform> (what is this?) 'over' and 'under' elements can be used to put label above or below the arrow (also it will not stretch arrow). 'subform' is general purpose container like HTML 'span' used to group math expressions. > - spacing (intended to be handled without explicit mark-up) How? > - character transformation _elements_ (fonts intended to be handled via Unicode or CSS) 'i', 'b', 'tt' are in HTML, the rest can be achived via CSS. > A few other constructs have been omitted or modified, but without loss of expressive power, > e.g. <post> is probably better encoded as <fence> with one empty delimiter as this allows the > correct size to be found. Yes, post was merged with fence in one element. > Is anything else missing? 1. Secondary alignment (mark, markref) 2. Smart resizing of subexpressions with id, sizeid attributes 3. Embellishments model is not fully reproduced 4. Overlapping under/over lines (they are rarely used and mostly can be reproduced by using several under/over lines piecewise). > How well does presentational MathML cover ISO-12083? Shortages are similar to those listed above. The following things from ISO 12083 are not fully reproduced in MathML 1. Secondary alignment (mark, markref) In MathML there are attributes like "malignmark" that are used for alignment within mtable and are not sufficient to reproduce ISO 12083 functionality. 2. Smart resizing of subexpressions with id, sizeid attributes This functionality is not available in MathML 3. Embellishments model is not fully reproduced Thing like <subform>Base</subform><top>over</top><bottom>under</bottom><sup>super</sup><sub>sub</sub> can not be correctly expressed in MathML. In particular <msubsup><munderover><mi>Base</mi><mi>under</mi><mi>over</mi></munderover><mi>sub</mi><mi>super</mi></msubsup> is rather <subform><subform>Base</subform><top>over</top><bottom>under</bottom></subform><sup>super</sup><sub>sub</sub> while <munderover><msubsup><mi>Base</mi><mi>sub</mi><mi>super</mi></msubsup><mi>under</mi><mi>over</mi></munderover> is <subform><subform>Base</subform><sup>super</sup><sub>sub</sub></subform><top>over</top><bottom>under</bottom> thus <subform>Base</subform><top>over</top><bottom>under</bottom><sup>super</sup><sub>sub</sub> and many similar constructions are not available in MathML (the same applies to cuurent proposal). 4. Overlapping under/over lines -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Received on Saturday, 17 June 2006 06:15:43 UTC