[OGo-Users] OgO Bug 789 - any progress?

[Helge Hess]

On 28.01.2008, at 17:45, Albrecht Dre=DF wrote:
>> This should be a bug in one of the header generators in SOPE/sope-=20
>> mime/NGMime.
> Ah!  Good hint!  I could already fix the wrong qp stuff, which now =20
> should strictly follow RFC 2045, RFC 2047 and RFC 2822.

Great! :-) Please add the patch to the bugreport.

> There I saw that national chars will /always/ be iso-8859-15 =20
> encoded, which basically limits the use of this lib to Western =20
> Europe, and companies shouldn't have any employees from Easter =20
> Europe, Russia or the far east... ;-)

Yes, non-latin1 is problematic with OGo/libFoundation since the latter =20=

does not fully support Unicode strings.
[It does support Unicode NSString's to some degree, which is why the =20
mailclient mostly works with that, but SOPE/OGo itself has quite a few =20=

places where Unicode does not work due to the lF limitation.]

> No idea how strings are passed downstream to =20
> NGMimeAddressHeaderFieldGenerator, but shouldn't *every* string in =20
> OgO be utf-8?


See above. For OGo this is mostly transparent. What encoding an =20
NSString is in, doesn't really matter for the application layer.

OpenStep works a bit different to other environments (like Java) where =20=

*all* Strings are always stored in some specific encoding. In OpenStep =20=

you get an API (NSString), and the internal encoding depends on =20
various aspects (read up on 'class clusters' if you like).

Basically, if you see some code which calls -cString and then walks =20
over the results, there is a good chance that the code is b0rked wrt =20
to Unicode. In this case it needs to be rewritten for -getCharacters: =20=

or -dataUsingEncoding:, depending on the task at hand. We also have =20
some charset support methods in NGExtensions (which rely on iconv).

Greets,
   Helge

PS: such questions are better moved to the developer mailing list.
--=20
Helge Hess
http://www.helgehess.eu/=