We do basically what Martin suggests, that is, when a string of text
comes in we identify the script runs in the string. If there are no
"complex script" runs in the string, then we simply pass back to the
core functions and everything continues as before. So the only
performance issue is in the identifying of script runs which is very
fast in our design. However, there is a very small performance hit for
this script identification. If you were to use a benchmarking program
you could measure it, albeit undetected by a general user. Also, we
don't do the script analysis unless the user has explicitly asked to
install the complex language support, so if you're not using any of the
complex language support, then you won't have any impact at all.
Thanks - Lori
> -----Original Message-----
> From: Martin J. Duerst [SMTP:mduerst@ifi.unizh.ch]
> Sent: Tuesday, August 05, 1997 12:14 PM
> To: Multiple Recipients of
> Subject: Re: MS Language Packs
>
> On Mon, 4 Aug 1997, Zhenbin Xu wrote:
>
> > Layout control for
> > FE characters certainly not so different from Western languages, but
> the
> > word wrapping rules are different. As regard to BiDi languages,
> things may
> > become more complicated, performance may not be satisfactory if
> every
> > controls handles a bunch of things which are not necessary for many
> users.
> > I guess Microsoft will separate the NT5 into two categories,
> according to
> > the direction of characters (LR, RL). Am I right? For those software
> need
> > the capability of handling languages including CJK and BiDi,
> specially
> > designed controls may still well be necessary. If considering
> support for
> > SE Asia languages, such as Thai, Indic scripts, will NT5 become
> > insufficient in this matter?
>
> Lori has already answered the more direct questions. Here some
> gereral remarks:
>
> It's an often heard myth that support of things such as CJK, BiDi,
> display of south Asian scripts, and so on, slows down performance,
> even for Latin, just by being available. This may be true for a
> very naive implementation, but not for something well done.
>
> It is very easy to show this with an example. BiDi processing is
> really not that easy. So you might guess that you loose a lot of
> time on it. However, it is easy to make this faster, in particular
> when you don't need it. Just check in the first pass of rendering
> a line whether there is any RTL character. If not, just leave the
> line as it is, and return. No need for actual Bidi processing.
>
> Also, one should be aware of the fact that to today's computers,
> user interaction, for example a fast typist, looks as if ony key
> code is comming in each month! So the computer has ample time to
> react, if it doesn't decide that it has to render a whole book
> when you input a single keystroke.
>
> So really an OS should automatically support a very long list of
> languages. The only disadvantage of such an approach is that it
> is usually not very well documented, so that it's extremely
> difficult to implement your own script if you have to.
>
>
> Regards, Martin.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT