Actually I'm not sure what is your problem.
Which applications do you try?
It seems recently some of modules, GTK, Bonobo and GNOME session, uses goption.
When the application uses --help options, it includes the output of both
goption and popt.
goption has the current encoding but popt is UTF-8 then you may encounter the
problem.
Could you apply POPT_fprintf() for popt options only?
Thanks,
fujiwara
Robert Scheck wrote:
On Mon, 31 Dec 2007, Takao Fujiwara - Tokyo S/W Center wrote:
Is your problem fixed by replacing "char++" with POPT_next_char() ?
If it's right, I think POPT_fprintf() does need to be reverted.
I'm a bit clueless regarding the code. It's mostly Jeff's work and I hacked
the rest to get a "working" popt for Fedora. Replacing POPT_fprintf() by
the previous fprintf() seems to work around the problems, which ends from
my point of view in: POPT_fprintf() has problems with non-ASCII characters
when the locale isn't a UTF8 one.
Do you mean "ch++;" vs. "ch = POPT_next_char(ch)"? I can't see any big
difference there, as far as POPT_fprintf() vs. fprintf() brought visible
results to me only.
Greetings,
Robert
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List [email protected]
