On Sat, Jun 01, 2002 at 02:20:15AM +0900, Dan Kogai wrote:
2) If not, would a Encode::ICU be wise?
I'm not so sure. But if I were the one to implement Encode::ICU, it
will not be just a compiled collection of UCM files but a wrapper to all
library functions that ICU has to offer. I, for one, am too lazy for
that.
That would be Text::Uconv's job, wouldn't it? Then Encode::ICU could just
interface to that module instead.
3) A number of encodings are in HanExtra but not their ucm repository,
namedly big5plus, big5ext and cccii. Is is wise to feed back to them
under the name of e.g. perl-big5plus.ucm?
You should in time and I should, too, because I have expanded UCM a
little so that you can define combined characters commonly seen in
Mac*. But I don't see any reason to be in hurry for the time being.
Understood.
In a related note:
http://www.li18nux.org/docs/html/CodesetAliasTable-V10.html
has spurred quite a bit discussion in Taiwan because of the mandated
standardization of Big5 => TCA-BIG5, and Big5-HKSCS => HKSCS-BIG5 (i.e.
the standard body first.) But it struck me as making lots of sense,
if in a rather rigid way.
Should Encode.pm probably add them to the Alias table, in the name of
'practical'? In particular, supporting CP-xxx (=> CPxxx) and ISO-646-US
(=> US-ASCII) should be rather beneficial.
/Autrijus/
pgpZwWLvmDu1s.pgp
Description: PGP signature