Are you entering unicode directly into popt table strings?
If so, then use gettext(3) and a N_("...") wrapper.
There are still issues with unicode and alignment: popt does not use
wide characters (which were largely non-existent outside of M$ when
popt was written).
The remaining issues cannot be easily resolved (I've tried many things)
because popt also undertakes a UTF8 -> non-UTF8 conversion for GNOME
which makes WYSIWYG nearly impossible to test.
73 de Jeff
On Nov 24, 2013, at 11:24 AM, Robert Scheck wrote:
> Hello all,
>
> I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was
> reported at Red Hat Bugzilla. However this does not feel for me like a
> downstream thing but more relevant for popt upstream, thus relaying it:
>
> ----- Forwarded message -----
> Hi.
>
> Popt has apparently problems with unicode characters.
> I tried to include some in the descrip and argDescrip field of the
> option table, e.g.
> - either directly "foo“”bar"
> - or escaped "foo\u201c\u201dbar"
> and then using the auto help functionallity.
>
> popt reacts quite strangely sometimes it justs works and the characters
> are printed correctly, sometimes it however skips the unicode characters
> and all between them, but not necessarily for all the unicode characters
> used
> ie.
> "\u201cfoo\u201d bar \u201cbaz\u201d"
> may become
> bar “bar”
> when printed.
>
>
> Cheers,
> Chris.
> ----- End forwarded message -----
>
> Foreign references for this request are:
>
> - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666430
> - https://bugzilla.redhat.com/show_bug.cgi?id=811801
>
>
> Greetings,
> Robert
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
