From: Frank Yung-Fong Tang (ytang0648@aol.com)
Date: Tue Dec 02 2003 - 19:25:44 EST
Peter Kirk wrote:
> On 02/12/2003 14:19, Frank Yung-Fong Tang wrote:
>
> >
> > 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.
"a barrier to proper internationalisation" ?
My opinion is reverse, I think it is a "strategy to proper
internationalization". Remember, people can always choose to stay with
ISO-8859-1 only or go to UTF-8 with MES-1 support for European market.
UTF-8 with MES-1 support does not mean other characters won't work in
their product, but instead, it mean other charactrers are not Quality
Assuranced in their products.
This is not a new approach. For example, while MS add Unicode support,
they ALSO define WGL4. That basically tell people all the characters in
WGL4 will be able to render in all the Windows system after Win98 (not
sure about 95). It does not mean other characters will not be able to
render in Win98 or later. It only mean those characters could be render
"out of the box".
> 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.
You only look at the issue from the developer point of view. But how
about QA? How are you going to QA the whole Unicode? You also need to
look at the issue from an end-user point of view, or the "working out of
box" point of view. How could the end user know what kind of function
they are going to get WITHOUT extra efforts.
If you are a QA engineer who is working on a working out of box product,
how are you going to prepare your test cases? If you are a product
marketing person who is going to write a product specification about a
cell phone which do not allow user to download fonts, how are you going
to spec it out?
>
> 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.
You are assuming a product which is does not need to work "out of box".
If that is the case, you can ALSO think Windows 2000 work for surrogate
since you can install or tweak the register to make it work with
Surrogate. You can ALSO think Windows 95 can support Complex Script
since you can INSTALL Uniscribe on it, right?
>
> 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
> peter@qaya.org (personal)
> peterkirk@qaya.org (work)
> http://www.qaya.org/
>
>
-- -- Frank Yung-Fong Tang Šýštém Årçhîtéçt, Iñtërnâtiônàl Dèvélôpmeñt, AOL Intèrâçtívë Sërviçes AIM:yungfongta mailto:ytang0648@aol.com Tel:650-937-2913 Yahoo! Msg: frankyungfongtan
This archive was generated by hypermail 2.1.5 : Tue Dec 02 2003 - 20:13:47 EST