- From: David Carlisle <davidc@nag.co.uk>
- Date: Mon, 10 Aug 1998 13:47:23 +0100
- To: kostya_silver@yahoo.com
- CC: www-math@w3.org
> But if I read this (made by WebEq) > <mo>⟨</mo> > I will know nothing about stretching of '<' and '>'. The MathML recommendation isn't very explicit (to put it mildly:-) about what exactly the definition of the entities should be. in the tables that I announced on this list last week, I have <!ENTITY langle CDATA "〈" -- u+3008 left angle bracket MMALIAS lang--> <!ENTITY LeftAngleBracket CDATA "〈" -- u+3008 left angle bracket MMALIAS lang--> ie they are both declared as CDATA pointing at the unicode character. this means that after passing through an SGML parser (ie __before__ the style sheet sees the data) the two inputs ⟨, ⟨ 〈 or any other method of entering that character will all have been normailsed to the same thing. My version of the operator dictionary does key on things like ⟨ (or at least it will once it's all written) but since the dsssl source is also passed through the SGML parser before being passed to the style engine, this will similarly be normalised. So... Given that in order to cope with things lime "max" they keys have to be character strings, I would not like to see the type changed to numbers for the other operators. > For single characters and &Entities; we should supply unicod numbers. I read the report as meaning that it is always a character string, understood in XML encoding thus "⟨" as it appears in the operator dictionary is a __single__ character, just entered as an entity in a 7bit encoding to make it more readable to a human reader who may not have a reader with a sufficiently full unicode font. David PS I should say of course that I have no knowledge as to what was intended by whoever wrote the table. I, like you, am just someone on the outside trying to implement this stuff!
Received on Monday, 10 August 1998 08:45:36 UTC