Re: mml

Re: mml

[Hans Hagen]

nico wrote:
>
> - The bar above "x+y+z" does not cover the formula, and it still small 
> (mover2):
>
> <math>
>       <mrow>
>         <mover accent="true">
>           <mrow>
>             <mi> x </mi>
>             <mo> + </mo>
>             <mi> y </mi>
>             <mo> + </mo>
>             <mi> z </mi>
>           </mrow>
>           <mo> &#x000AF; </mo>
>         </mover>
>         <mtext> vs
>         </mtext>
>         <mover accent="false">
>           <mrow>
>             <mi> x </mi>
>             <mo> + </mo>
>             <mi> y </mi>
>             <mo> + </mo>
>             <mi> z </mi>
>           </mrow>
>           <mo> &#x000AF; </mo>
>         </mover>
>       </mrow>
>     </math>
>
The problem with this kind of situations is that the unicode spec 
permits / or is vague / or is messy with regards to things like bars 
over whatever; in this case you use a macron for something overline

one way to deal with it is to define additional entities (we already 
have \defineXMLentity [OverBar]    {\normalorfiller\hrule\hrulefill} etc 
for math) 

\usemodule[newmml]

\defineXMLentity[x000AF]{\normalorfiller\macron\hrulefill}

\startXMLdata
<math>
     <mrow>
        <mover accent="true">
         <mrow>
            <mi> x </mi>
            <mo> + </mo>
            <mi> y </mi>
            <mo> + </mo>
            <mi> z </mi>
         </mrow>
          <mo> &#x000AF; </mo>
        </mover>
    </mrow>
    </math>
\stopXMLdata

but then we miss the utf 8 encoded ones, so we then need to hook it into 
the utf handler i.e. redefine the macron there;

yet another option is to 'normalize the file' by preprocessing

this is something that needs discussion

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
-----------------------------------------------------------------

Re: mml

[Taco Hoekwater]

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.

For the macron, "accent=false" should only influence the vertical
placement, not its stretchiness.

Cheers, taco

Re: mml

[nico]

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.

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

Re: mml

[Taco Hoekwater]

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.

Greetings, Taco

Re: mml

[Hans Hagen]

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
-----------------------------------------------------------------

Re: mml

[Hans Hagen]

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?

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

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

(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)



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
-----------------------------------------------------------------

Re: mml

[nico]

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