Mark> Furthermore, I don't know of any scheduled major-vendor
Mark> products that will have such general Unicode rendering
Mark> capability, or even any announced development effort along
Mark> these lines. This is because such capability is simultaneously
Mark> very difficult to implement, and of negligible economic
Mark> interest, since all scripts of current economic importance
Mark> already have all the characters they need incorporated into
Mark> Unicode in precomposed form.
Too true. I believe someone on a Unicode related list was once heard to
say that "... academic interests are over-represented" (taken a bit out
of context). But the sad fact is that academic interest is probably the
only reason these economically negligible scripts will be implemented
anywhere other than custom software developed by experts, ex-pats, or
The answer, in my opinion, is to create software that does not depend on
any particular OS or windowing system, and make it better than anything
OS vendors can provide. I just can not see OS vendors agreeing on and
implementing consistent and usable multilingual support within our
lifetimes. There are numerous international standards, but every vendor
seems to bless their customers with an interpretation of those standards
incompatible with everone elses implementation.
We were recently funded to provide software development tools with true
multilingual support and independent of OS. So we are going to do our
best to blow the OS vendors out of the water well within our lifetimes!
Maybe even within this millenium if our huge pool of talent (2 staff,
full-time and 2 graduate students, part-time) is inspired enough.
In understand your frustration with all this. Few outside commercial
companies can afford to really do anything significant with Unicode. My
opinion is that market forces influence the growth of Unicode more than
anything else, to the detriment of those that lack market force.
You can only expect sensitivity and understanding from the individuals,
no matter their allegiance; expect nothing but profit motive from
companies. The one pleasant, but glaring exception of Apple is duly
Mark> As I understand it, to the extent that "rendering engines" are
Mark> implemented to handle this aspect of Unicode, it is likely to
Mark> be on a script-by-script basis, since the typographical
Mark> problems tends to vary from case to case.
Indic scripts for example, are on a script-by-script AND font-by-font
basis unless your Indic support expects all Indic fonts to be arranged
in a particular fashion. Developing such support is time consuming and
can be annoying and frustrating, but provide one good example
implementation that is clear and the weekend coders will take it and run
Mark Leisher "A designer knows he has achieved perfection
Computing Research Lab not when there is nothing left to add, but
New Mexico State University when there is nothing left to take away."
Box 30001, Dept. 3CRL -- Antoine de Saint-Exupéry
Las Cruces, NM 88003
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT