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
