I found the problem: In uni2cuni.otp the numbering handling does two things: It DOES isolate non-numerals as separators within a given expression. So placing an Arabic letter between two numbers 5792ر684 processes fine; each individual number gets reversed. But the otp makes exceptions for the following punctuation: + - . If we get rid of those exceptions the separator problem will go away. But then math will be messed up. The problem is that the + - . are ambiguous; sometimes they have a mathematical significance; sometimes a separator significance. We need the exception for math (generally done the usual l-r way) but don't need it for separators (done in the r-l way). What I could do is define two filter sequences: UTFArabic and UTFArabicMath. Hans, could you do a conditional that calls up one in math mode and the other everywhere else? This is a stop-gap solution until we replace otp's with something smarter. Taco, Hans, let me know what you think before I work on this. It is really inefficient to have to define an entire ot stack just to change one otp. There must be a better way to abtract things so we can plug a given otp without redoing the entire stack. Best Idris -- Professor Idris Samawi Hamid Department of Philosophy Colorado State University Fort Collins, CO 80523 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/