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/
msg09924/pgp00000.pgp
Description: PGP signature
