From: "Patrick Andries" <[EMAIL PROTECTED]> > I'm looking for two mathematical characters. > 2) An angle operator (combining mark ?) looking like this _| , where > > a ) > n| a ) n occurrences of a > a ¯ means a ) > > n| > obviously a ¯ should all be written on a single line.
Suppose we note the operator with a functional syntax: n| fxp(a, n) = a ¯ This function can also be written using the functional notation of the power binary operation: n pow(a, n) = a So that: fxp(a, n) = pow(a, fx(n)) = pow(a, pow(a, pow(a, ...))) ;(with n applications of pow) So we have, for n > 1: log fxp(a, n) = a . pow(a, pow(a, ...)); (with n-1 applications of pow) a = a . fxp(a, n - 1) And thus fxp(a, n) = pow(a, a . fxp(a, n - 1)) Or using the operator notation: n - 1| n| ( a . a¯¯¯¯¯ ) a ¯ = a It seems clear that the fx(n) function introduced above acts as a functor, which could be noted as a unary operator _|, that modifies the argument n that follows it. I do not see it as a combining character, even if its glyph appears on the right side of its parameter n, as in fact it also has a left side where the exponent operator is used. It cannot be rendered the same way as textual characters because it implies a begin and end, and thus some sort of parenthesing, that requires a complex mathematical layout. If it was used with a linear text layout, one would write it like: a _| n, or: a _| (n - 1) which could be then possibly rendered as the following in HTML to remove the implied parentheses: a<sup>_| n</sup>, or: a<sup>_| n - 1</sup> With some rich layout (MathML-like) markup, it would be something like: <bin-op><param>a</param> <operator>_|</operator> <param>n</param> </bin-op> The placement of the operator is then not relevant for the Unicode semantic, and it is clearly not combining the same way as combining diacritics on letters. Also, the existing "power-n" characters are unified in Unicode using a compatibility decomposition into "<sup>n</sup>" where "<sup>" is considered as a layout markup used to replace a semantic binary operator "^" that should be present if such markup is removed. So the question is only its identification as a character "_|" that could be encoded for MathML usage, or in linear text. The exact rendering in a 2D layout would put it on the right and below a full expression, but in a linear text, we cannot encode 2D properties. If there such character "_|" in Unicode ? Yes. With mathematical properties? Yes. With the correct semantic? No. The existing semantic of this mathematical character means "not", and it is a unary character that will not be layout in MathML correctly by extending its glyph below and to the right of its arbitrarily long second argument. What could be its representatie glyph in the Unicode chart? it would be similar to representatie glyphs used for mathematical radicals or summations, ignoring the specific placement and layout constraints, so I think it should be something like "_|" aligned on the descent line of Latin/Greek letters, probably with a "m"-width, and an ascent line similar to the lowercase letters l and k. This glyph would be appropriate for use in linear plain text, and additional markup could give it a more specific layout while preserving visually its "mathematical-combining" semantic usable for generic notations. If this character is introduced for a notation, I think that other characters should be introduced as well for several types of surroundings: above, below, left, right, and their combinations. The isolated left and right are already encoded as a single mathemetical character "|". Other surrounding notations exist in some languages such as in Egyptian hieroglyphic "cartouches" (sorry this is the French word, there may exist another appropriate word in English), or in musical notations, using special BEGIN and END character pairs, acting as special parentheses (and that could be *rendered* in a 1D linear layout with "[" and "]" characters, possibly with an additional notation like "[Rahmes](cartouche)".) The specific layout of your proposed mathemetical operator cannot be specified by Unicode: it must go to the markup language specification, and Unicode will only show a representation appropriate for usage and encoding in plain text, and will leave the specific layout specification to MathML, if it accepts this character with its additional layout properties. -- Philippe.