discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUmail on NetBSD


From: Stefan Bidi
Subject: Re: GNUmail on NetBSD
Date: Fri, 13 Apr 2012 10:03:44 -0500

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 <fredkiefer@gmx.de> 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 <stefanbidi@gmail.com>:

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 <fredkiefer@gmx.de> 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
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep



reply via email to

[Prev in Thread] Current Thread [Next in Thread]