On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater wrote:

Hi nico/Hans,

Hans Hagen wrote:

...

...

<mo> ¯ </mo>

The MathML spec specifically suggests the use of ‾ instead of a literal accent character in situations like this.

The problem is that it is also specified to which unicode character is mapped the entity (http://www.w3.org/TR/MathML2/isodia.html). Actually ‾ is U00AF. So, the behaviour should not be different when using an entity name and the corresponding unicode value. Imagine some XML tool processing an original XML mathml code containing an entity name, and simply expanding the entity according the MathML DTD. I think that processing the original and the expanded code should give the same result. Of course, using entity names instead of unicode values is better for readibility and maintanability, but IMHO it is not a solution to the question. Regards, BG

Taco Hoekwater wrote:

nico wrote:

...

So, the behaviour should not be different when using an entity name and the corresponding unicode value. Imagine some XML tool processing an original XML mathml code containing an entity name, and simply expanding the entity according the MathML DTD. I think that processing the original and the expanded code should give the same result.

I just reread that bit, and you are right (of course you knew that already, sorry).

Unfortunately, the use of bare character entities makes it quite a bit harder to implement mathml. Essentially, the top-level mathml element would have to redefine (and remember, for embedded non-mathml) lots and lots of 'normal' tex stuff.

indeed (preprocessing such an xml doc makes sense then) somehow i got the impression that many of those standards are not written with an implementation in mind Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Thu, 30 Mar 2006 23:02:10 +0200, Hans Hagen wrote:

nico wrote:

...

On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater wrote:

...

Hi nico/Hans,

Hans Hagen wrote:

...

...

<mo> ¯ </mo>

The MathML spec specifically suggests the use of ‾ instead of a literal accent character in situations like this.

The problem is that it is also specified to which unicode character is mapped the entity (http://www.w3.org/TR/MathML2/isodia.html). Actually ‾ is U00AF.

the messy part is that

- a macron has no stretch - an overbar has stretch

so, while there is a lot math stuf (now) in unicode, the macron is used for an overbar which is rather strange; do they also 'misuse' the underscore for underbar etc?

I guess that in MathML stretchiness is more systematic and should apply to most characters, provided that they can stretch (http://www.w3.org/TR/REC-MathML/chap3_2.html). In this doc it is said: "By default, most horizontal arrows and some accents stretch horizontally."

now an implementation needs to adapt to math or text (or just gamble since it may be that i want a non stretchable macron over x+y+z); my guess is that as a result, many implementations are more complex than needed

From my little window (since I don't know how it works internally) I would say that in mathml stretchiness is required in things like <mover> or <munder>, if the character allows it, and depending on stretch attribute. But it's sure that it does not make things easier.

(btw, in pure text, it's still not clear if the macro glyph sould be chosen or a stretchable hrule)

What is not clear to me is if unicode explicitely allows a combination of a non spacing mark (accent) and a *group* of characters. In the specification I've only seen that it can apply to a base character. If it can apply only to one character, a glyph seems enough.

(i think that one problem of unicode/xml/mathml is that it is used in typesetting systems but not in all aspects is designed (or used) to facilitate high end results; therefore a 24/32 bit tex still needs to provide much detailed control)

Yep! Regards, BG