I think this gets done for one of the more obscure mail encodings. Remember there was a time when mail transfer was only save for 7bits. In itself this isn't a problem.
On the road Am 13.04.2012 um 01:31 schrieb Stefan Bidi <[email protected]>: > Why is Pantomine trying to convert a Unicode representation to ASCII? Just > seems counter intuitive. Shouldn't it try to convert to UTF-8 or UTF-16, > instead? As the method name suggests you may be loosing information when > converting from UTF-7 to ASCII, and I can't see why Pantomine would want to > do some like that. > > I would bring this up with the GNUmail folks as a possible bug. > > On Thu, Apr 12, 2012 at 2:16 PM, Fred Kiefer <[email protected]> wrote: > On 12.04.2012 11:54, Riccardo Mottola wrote: > On 04/07/12 11:44, Wolfgang Lux wrote: > Fred Kiefer wrote: > > > For NSASCIIStringEncoding the code in GSFromUnicode() should never try > to use iconv. We have the conversion for this format hard coded. > Could you please add a breakpoint in this function and step through > it? I really would like to understand what goes on here. > The problem, as explained by the reference attached to Stefan's email, > is that NetBSD's iconv does not support the //TRANSLIT option that > GNUstep uses to implement lossy transformations (as you also can see > from the backtrace provided by Riccardo). I have no idea how we could > fix that in GNUstep, but on the other hand there is an easy solution > for Riccardo: Just install the gnu libiconv package on NetBSD and make > sure it gets used instead of the default one. > > I tried to install the gnu libiconv and reconfigure base and now it > works without warnings. > Is this the only choice however? > > No, I don't think so. But we should wait for Richard to decide whether the > current code is a bug or not. We have conversion code for > NSASCIIStringEncoding in place and should try to use that, when no iconv > conversion is found. > The other chance you have is to modify the code in > -[NSString(PantomimeStringExtensions) stringFromModifiedUTF7]. No idea why > this is converting the hard coded strings in such a complicated way. > > Fred > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
