Re: popt-1.13 release
On Fri, 11 Jan 2008, Takao Fujiwara - Tokyo S/W Center wrote: > Actually I'm not sure what is your problem. > Which applications do you try? Using POPT_fprintf(), all umlauts are broken when doing "[EMAIL PROTECTED] rpm --help" or "[EMAIL PROTECTED] kudzu --help". Whenever an umlaut should be displayed, it isn't and the rest of the line as well. Instead the next line is displayed. So it looks like to me, that POPT_fprintf() has problems with non-ASCII characters when the locale isn't a UTF-8 one. See http://rpm5.org/community/popt-devel/0038.html and following of this thread (e.g. http://rpm5.org/community/popt-devel/0043.html). Maybe you can then see what my problem is. > 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? I've no matter about the goption/popt handling at all, I'm just seeing this problem with popt 1.13 on a konsole without GNOME, Bonobo or whatelse. Greetings, Robert __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
On Jan 11, 2008, at 2:49 AM, Takao Fujiwara - Tokyo S/W Center wrote: 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? In principle POPT_fprintf could be applied for popt options only. The context of "popt options only" is extremely difficult to identify however, because popt behvaior is driven by application data. No matter what, I'm not going to be accepting patches for popt such as POPT_fprintf (or the Solaris signed character "fix") without explicit regression tests in the future. And I'm likely to revert to Robert Scheck's patch for the next version of popt as that seems to be closest to being explicitly identified as "working". 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
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 popt-devel@rpm5.org
