From: Khaled Hosny (khaledhosny@eglug.org)
Date: Mon Jun 28 2010 - 06:03:39 CDT
On Sun, Jun 27, 2010 at 10:00:18PM -0700, Asmus Freytag wrote:
> The one argument that I find convincing is that too many
> implementations seem set to disallow generic combination, relying
> instead on fixed tables of known/permissible combinations.
Only if you consider Microsoft "too many", AFAIK, only Microsoft's
Uniscribe does such, stupid in my opinion, behaviour.
> In that situation, a formally adopted character with the clearly
> stated semantic of "is expected to actually render with ANY
> combining mark from ANY script" would have an advantage. List-based
> implementations would then know that this character is expected to
> be added to the rendering tables for all marks of all scripts.
>
> Until and unless that is done, it couldn't be used successfully in
> those environments, but if the proposers could get buy-in from a
> critical mass of vendors of such implementations, this problem could
> be overcome.
>
> Without such a buy-in, by the way, I would be extremely wary of such
> a proposal, because the table-based nature of these implementations
> would prohibit the use of this new character in the intended way.
There are so many issues with MS implementation(s), for example you can not
combine any arbitrary Arabic diacritical marks on any given base
character. I don't think Unicode need to invent workaround broken vendor
implementations, interested parties should instead pressure on that
vendor to fix its implementation(s).
Regards,
Khaled
-- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
This archive was generated by hypermail 2.1.5 : Mon Jun 28 2010 - 06:07:53 CDT