- From: Řistein E. Andersen <html5@xn--istein-9xa.com>
- Date: Sat, 17 Jun 2006 13:30:52 +0200
On 16 Jun 2006, at 2:27PM, White Lynx wrote:
>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?
>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.
>Some of ISO-12083 constructs that can not be encoded in MathML either.
Some of which probably should be added to MathML, but that is another issue.
>>font-family:[cursive] seems like a natural fallback mechanism for script.
>Ok. But are Fraktur and caligraphic fonts actually marked as such?
>How browser will identify them?
As far as I know, no standard mechanism exists to indicate font classification. It is up to the browser to find (or let the user choose) appropriate fonts to use for general font-families like serif and cursive.
>>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.
The current proposal does not seem to include the following elements of ISO-12083:
- <overline> and <undrline> [sic] (could be useful - feasible in CSS?)
- <fence> with arbitrary delimiters (possibly not a good idea)
- <box> (unnecessary?)
- labelled arrows <subform> (what is this?)
- spacing (intended to be handled without explicit mark-up)
- character transformation _elements_ (fonts intended to be handled via Unicode or 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.
Is anything else missing? How well does presentational MathML cover ISO-12083?
--
Andersen
Received on Saturday, 17 June 2006 04:30:52 UTC