![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Idris Samawi Hamid wrote:
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).
isn't it simplier then to disable otp's in math mode
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?
\appendtoks < reset otps > < intialize other sequence of thenm> \to \everymathematics
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.
i suppose that switching is fast, so using a different stack was what came on my mind first 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 -----------------------------------------------------------------