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
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 <address@hidden>
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.
On 12.04.2012 11:54, Riccardo Mottola wrote:
On 04/07/12 11:44, Wolfgang Lux wrote:
Fred Kiefer wrote:
I tried to install the gnu libiconv and reconfigure base and now it
The problem, as explained by the reference attached to Stefan's email,
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.
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.
works without warnings.
Is this the only choice however?
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.