Re: [NTG-context] mml
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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater [EMAIL PROTECTED] 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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
nico wrote: On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater [EMAIL PROTECTED] 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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
On Thu, 30 Mar 2006 23:02:10 +0200, Hans Hagen [EMAIL PROTECTED] wrote: nico wrote: On Thu, 30 Mar 2006 10:18:32 +0200, Taco Hoekwater [EMAIL PROTECTED] 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 ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] mml
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
