patch for in tree iconv

[John-Mark Gurney]

Gabor Kovesdan wrote this message on Thu, Feb 28, 2013 at 08:38 +0100:
> Em 27-02-2013 22:38, Xin LI escreveu:
> >
> >
> >On Wed, Feb 27, 2013 at 1:32 PM, John-Mark Gurney <jmg at funkthat.com 
> ><mailto:jmg at funkthat.com>> wrote:
> >
> >    I've worked at fixing a few of iconv's locking issues, and I've
> >    attached
> >    this patch.  This should fix most/all of the locking related issues
> >    relating to the global lock...
> >
> Thank you, I have had this on my TODO list for a long time just haven't 
> got time for it!
> >
> >
> >    Though I ran the tests in tools/test/iconv, and it looks like the
> >    checked in reference conversion in ref are wrong...  The
> >    UTF-32 -> ASCII map (ref/ASCII-rev) has:
> >    0x00A3 = 0x626C
> >    0x00A5 = 0x6E6579
> >
> >    I'm pretty sure 0x626C and 0x6E6579 are not valid ASCII
> >    characters.. :)
> >
> >    w/ my updates, they are properly(?) mapped to 0x3F...  I'm not sure
> >    what they were w/o my changes...
> >
> Seems like a good solution. However, the ref tables were generated with 
> GNU libiconv (since the goal is a good compatibility) so we should also 
> track down why does it emit this.

It's because we generated the ref w/ //TRANSLIT, and our iconv doesn't
have an advanced set of characters for transliteration...  Heck, it doesn't
handle the difference between //TRANSLIT and //IGNORE...

-0x00A0 = 0x0020	Non-braking space -> space
-0x00A1 = 0x0021	inverted exclamation mark -> exclamation mark
-0x00A2 = 0x0063	cent sign -> c
-0x00A3 = 0x626C	pound sign -> lb

I'm "convinced" that the ref is right for proper transliteration...

So, do we need transliteration support?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."