On 8 Jan 2001, Owen Taylor wrote:
> What I'm suggesting is:
>
> - Use the system iconv when it exists and is sufficiently good
>
> - Use support included with Perl, or an external library such as libiconv otherwise.
>
> "sufficiently good" could even mean "has the exact same mapping tables as
> Perl". It would certainly mean including things like the CJK mapping tables.
>
> This is the approach that Pango and GTK+ take, and works fine. I
> don't really see any reason for when I'm running Perl/GTK+ for it to
> load up two copies of the Japanese mapping tables, just because there
> is some other operating system that doesn't have Japanese mapping
> tables in its libc.
A significant problem is supporting umpteen vendor's 'iconv's. Yes - some
systems have reasonably good support through iconv (although, from what
I've seen, the current support in the Unicode::* + Jcode modules far
exceeds any known system vendor's 'iconv' support. It really is
incredibly extensive - check out Unicode::MapUTF8::utf8_supported_charset
sometime.). But detecting that support and confirming that Vendor X's
implementation isn't broken seems a quagmire to me.
It seems like precisely one of those things that will become the subject
of many bug reports 'fails on vendor X', 'borken encoding Y on vendor Z',
'failed to link 'iconv' on vendor Q system S'. Yes - it bothers people to
load redundant encoding tables but it seems wrong to me to implement a
'system tuning' hack that will probably benefit only a small number of
highly clued individuals and cause more that a few problems in maintenance
and installation over the long haul for everyone else.
--
Benjamin Franz
... with proper design, the features come cheaply. This
approach is arduous, but continues to succeed.
---Dennis Ritchie
