Re: mml

[nico <nicolas.marsgui@libertysurf.fr>]

On Thu, 30 Mar 2006 23:02:10 +0200, Hans Hagen <pragma@wxs.nl> wrote:

> nico wrote:
>> On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater <taco@elvenkind.com>
>> wrote:
>>
>>> Hi nico/Hans,
>>>
>>> Hans Hagen wrote:
>>>
>>>>>          <mo> &#x000AF; </mo>
>>>>>
>>> The MathML spec specifically suggests the use of &OverBar; 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
>> &OverBar; 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