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 firstname.lastname@example.org