...
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.
Well, I don't claim to be able to rewrite anyone's script engine. But this just doesn't add up. All Hebrew script has to be passed to a script engine anyway for bidi processing etc. Within this script engine there is already special processing for combining marks, different from what is needed for base characters. In order to invoke this processing, there must be some kind of test of whether each character is a combining character. With unpointed Hebrew text, this test always fails and so the special processing code for combining marks is never run. So, if the extra complication of a reordering pass is added to this special processing, it cannot affect the performance when working with unpointed text.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
