This is largely a fallacy. Most of these tables are not large (for
example, a brute-force SJIS table might be around 14k or
so), and they're only really necessary of your system character
representation is a direct encoding of ISO 10646.
>This is OK, as long as supporting NCRs > 255 is NOT required and FULL
>conformance is attained by supporting ISO 8859-1 NCRs. (But if a browser
>supports NCRs > 255, then they map to ISO 10646.)
NCR's should map to the ISO 10646 character, but the system
representation of that character is not fixed by the SGML standard,
meaning that we could perform the aforementioned mapping in the
abtract, and simply map all NCR's above 255 to something indicating an
unrecognised character.
>Otherwise we are requiring a lot of additional resources to support
>a feature that most people on this list have been saying will be
>rarely used. Users still want browsers to run well on resource
>limited systems, so requiring this for full conformance would be
>bad.
If you have been paying attention, I have repeatedly said, and Glenn
has also, that *no* changes are required to current browsers. There is
a desirable level of functionality, in which all in ISO 10646 are
displyed correctly (including NCR's), but that is not the *required*
level of functionality.
As we have said, making the document character set ISO 10646 is
largely an abstract thing that *allows* multilingual processing, but
does not *require* it.