And if the implementers of rendering engines will simply "paint"Out of interest, it seems that Microsoft's Uniscribe, in several versions up to and including the latest (not generally released) version 1.468.4015.0, does in fact seem to do this. I have tried rendering
instances of U+034F so that they become available to the font
side of the rendering equation, then it should be relatively
simple, as for the Biblical Hebrew point sequence cases, to
get the <lamed, patah, CGJ, hiriq> sequences to display properly.
יְרוּשָׁלַ͏ִם
(Yerushala(y)im with CGJ) with different versions of Uniscribe (on Windows 2000). In each case CGJ is rendered as a square box in each of several fonts. This behaviour indicates that actually Uniscribe treats CGJ as a regular paintable character, but it is not implemented in the specific fonts. So, it seems that if the font designer makes the very simple changes which John Hudson mentioned, "ligating" CGJ with the preceding character, the CGJ solution to the Hebrew problem can be implemented very simply, with no changes to rendering software and simple changes to fonts.
So where is the serious problem with this solution? I don't see one. Nor do the President and the Technical Director of the Unicode Consortium. Perhaps the only problem was a misunderstanding of the properties of CGJ, which I hope has now been resolved.
And where, for that matter, is the "host of people [who] will fight that proposal"? I hope they will now realise that the ogre they are fighting is in fact, if not a handsome prince, at least quite harmless.
-- Peter Kirk [EMAIL PROTECTED] http://web.onetel.net.uk/~peterkirk/
