Why should it be a performance hit for modern Hebrew? Most modern Hebrew is unpointed, which means that it has no combining characters, and so any reordering routines would never be triggered. In rare cases there may be single combining characters, but as John Cowan realised there is no need to call a sort routine to sort a single character. The sort routines need only be called when they are needed.
My understanding is that at least the rendering systems I'm most familiar seem to be pretty much all or nothing: you either pass a string to a script engine or you don't. If the string is passed to the script engine, that engine goes through its steps. Having the engine decide whether or not to go through a particular step would seem to be an extra step, i.e. an even bigger hit on performance. In Uniscribe, for example, there is a single engine for Hebrew: if you make changes to the engine to facilitate Biblical Hebrew, what is the impact on processing speed, and is it acceptable if your primary user group do not benefit from the change because they're using modern Hebrew. Note that I don't claim to know what the impact is, I'm just trying to understand why engineers I've spoken to about this are unhappy about the idea of adding extra processing steps to existing engines that work well for the majority user community.
John Hudson
Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED]
I sometimes think that good readers are as singular,
and as awesome, as great authors themselves.
- JL Borges
