From: Peter Constable (email@example.com)
Date: Thu Oct 16 2003 - 17:13:25 CST
> -----Original Message-----
> From: Peter Kirk [mailto:firstname.lastname@example.org]
> I wonder if anyone involved in this is speaking from real experience.
> Peter, I don't think your old company actually tried to implement such
No, but my new company has.
> I have heard that your new company
> has tried it and has claimed that for Hebrew the performance hit is
> unacceptable. I am still sceptical of this claim.
Well, you're more than welcome to create an implementation that
demonstrates otherwise and share it with us :-).
> Presumably this was
> done by adding a reordering step to an existing rendering engine. But
> was this reordering properly optimised in binary code, or was it just
> bolted on to an unsuitable architecture using a high level language
> designed for the different purpose of glyph level reordering?
I don't know the details; I suspect it was done within a finite-state
> If, as you agree in principle, this is an issue which goes to the core
> of Unicode, should you not be prepared to take some small performance
> hit in order to conform properly to the architecture?
There's more to life in the real world than conformance to a theoretical
principle, and unfortunately most of us live with constraints as a
> If it is unavoidable to call the same routine (for sorting or any
> purpose) multiple times with the same data, the results can be cached
> that they do not have to be recalculated each time.
That's the kind of thing that would be up to a calling application, not
the rendering engine.
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
This archive was generated by hypermail 2.1.5 : Thu Jan 18 2007 - 15:54:24 CST