A better approach than asking "Does product X support Unicode 4.0" which in some way you can always get a NO answer is to
1. Define a smaller set of functionality (Such as MES-1, MES-2, MES-3A)
2. Ask 'Does Product X Support MES-1? Does Product X Support MES-2?...
I disagree - if we are talking about a system rather than a font. Supporting subsets is a dead end, and a barrier to proper internationalisation. It would be much better for developers to realise that from the start they need to build in support for the whole Unicode character set. Once Arabic, one Indic script and Plane 1 are supported, the rest is relatively easy; all the data required are in the UCD, and the shaping details can be left to the font. The alternative of bolting on ad hoc support for extra scripts later, when they become necessary, just causes extra work.
A product can thus claim to support Unicode 4.0 rather easily, if it makes the caveat that its font and perhaps keyboard support is limited to certain scripts. Users interested in more unusual scripts can then supply their own specialised font, or a general (but inexpensive) one like Code2000.
And I would think that MS Windows 2000/XP is quite close to being able to make this claim, as long as you ignore the outdated Character Map (a prime example of needless subsetting!) and use an alternative like BabelMap. For one big advantage of the approach I suggest is that an OS can even anticipate future versions of the standard, as long as no major new properties are added.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
