Browser IDN display policy: opinions sought
michel at suignard.com
Sat Dec 10 04:58:56 CET 2011
John and all, concerning the following:
With Type A, these machines need to be configured one at a time, using different interfaces and conventions and sometimes going back to physical media. I wouldn't know how to configure my Android 2.2 phone to display Greek or Han (which I prefer to be able to see, even when I can't read the languages) while retaining Latin if I
This is not typically true. Display capabilities are much broader than other language processing abilities on most platforms. Recent Windows platform (at least since Vista) and the phone I am using (iPhone with iOS4) can represent many more writing systems than I am familiar with. And they don't require any user enabling. To a large degree the availability of font resources is a footprint issue on many of the devices which is more acute on smart phones and such. But even on those platforms there is a trend to display more and more of the Unicode repertoire. I was in fact pretty amazed at how much an iPhone can display (sorry no experience on other smartphones).
I don't think there is a difference between type A and B on that aspect. It may impact the choice of 'supported' language but adding more languages will not magically request the install of more resources, there are already typically installed. Keyboard entries and similar advanced language related processes is another story but none of that is required for IDN purpose.
Either in A or B mode you are facing the prospect of displaying over 100 000 characters with the added complexity of CJK variants and complex script shaping. It is always a compromise but it has nothing to do with A or B. Operating Systems tend to get away from the on demand install for language specific resources because of customer confusion.
Interesting discussion btw. I don't see ICANN at fault here. It is a very complex issue.
More information about the Idna-update