Ludovic pointed out where my logic was going wrong. However, I'm still not sure if lossy conversion is needed here. If I understand UTF-7 correctly it simply encodes Unicode using ASCII. I might still be way off base here, though.
As for the issue at hand, I will mention that CF uses a lossByte instead of trying to convert to an equivalent character (usually '?', I would presume). An alternative might be to include a configure check for //TRANSLIT (as suggested by someone), use a table for the accented characters and an universal loss character for everything else. This isn't, by any means, a good solution since it will horribly fail on any non-Latin language. On Fri, Apr 13, 2012 at 1:15 AM, Fred Kiefer <[email protected]> wrote: > 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<https://lists.gnu.org/mailman/listinfo/discuss-gnustep> >> > >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
