From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Mar 21 2006 - 20:01:10 CST
From: "Mike Ayers" <mayers@celequest.com>
> Andrew West wrote:
> > What
>> you seem to be saying is that every single MS product that relies on
>> Uniscribe for complex script rendering should have special code
>> written in to overcome the deficiencies of certain versions of
>> Uniscribe, even when the deficiencies did not exist when the code was
>> written. Wow!
>
> Yeah! How *dare* he imply that a software vendor take full
> responsibility for the end user experience of its products instead of
> shunting blame to a third party!
Who is that third party (regarding support of MS products by MS itself) that would write a later version of Uniscribe?
Are there non-MS alternate implementations of Uniscribe (something replacing USP10.DLL), or does Windows provides a way to register another text shaping and layout engine that would be used directly from the Windows text rendering APIs (in GDI/GDI+, Direct-X/Direct-Draw, and indirectly from User32's GUI components...)? Until now, I did not see any such API for pluggable engines.
Those applications that want another renderer must be written specially for this other renderer, and avoid using standard Windows components (all these components must be reimplemented/emulated, like in Qt for Pango, or in Java Swing/AWT for the Java's builtin text-engine).
This reimplementation can be extremely tricky, because this includes things that are also normally under the control of pluggable look and feels set by user (just consider the window decorations, such as its titlebar which should be able to display text in complex scripts, or the common menu bars, or the common file selector, input boxes and combos...) Then consider filenames, and how they will be rendered in the Explorer or in other applications that display an Explorer view (folder windows, desktop icons, dynamic Favorite menus....). Finally consider the case of the icon bar which is harder to integrate than just the window titlebars.
Note that in all this, I don't consider the case of text input, which consists of a keyboard driver and is much simpler; I consider that the visual effect of input i.e. mouse selection and caret, or interpretation of function keys to perform word or cluster movements and selection is considered output, that may be under the control of the text engine, but not necessarily because applications can very easily intercept function keys to perform their own selection or caret movement in their message processing loop, including for components.
This archive was generated by hypermail 2.1.5 : Tue Mar 21 2006 - 20:05:32 CST