Bug #12475 for Tk: Tk 804.027 Enrty widget encoding problem (unicode)

Sat Apr 30 08:24:48 2005 Guest - Ticket created

Subject:

Tk 804.027 Enrty widget encoding problem (unicode)

OS: Windows XP Professional SP2 EN Perl: ActivePerl 5.8.6 Tk: 804.027 (bundled with ActivePerl) There is a "display" problem in Entry widgets. When you hardcode a non-ASCII text and display it any widget with "use encoding 'iso-8859-9'". Everything is fine. But when you type from the keyboard they are not displayed correctly inside Entry. I've looked at the source and saw that if the encoding can not be determined, a hard coded value "iso-8859-1" is used and it looks like this is causing the problem. It looks like this bug is present only on win32 platform(s), since everything is fine under Linux (perl 5.8.3, Tk 804.027, Mandrake Linux 10.0). I' ve tested this with Turkish encoding, but someone also reported that it is present with Polish encoding. And I think that it is broken for all encodings. I can not supply a patch, since I don't know C.

Mon Oct 23 19:08:17 2006 SREZIC [...] cpan.org - Correspondence added

On Sat Apr 30 08:24:48 2005, guest wrote: Show quoted text

> OS: Windows XP Professional SP2 EN > Perl: ActivePerl 5.8.6 > Tk: 804.027 (bundled with ActivePerl) > > There is a "display" problem in Entry widgets. When you hardcode a > non-ASCII text and display it any widget with "use encoding 'iso- > 8859-9'". Everything is fine. But when you type from the keyboard > they are not displayed correctly inside Entry. I've looked at the > source and saw that if the encoding can not be determined, a hard > coded value "iso-8859-1" is used and it looks like this is causing > the problem. > > It looks like this bug is present only on win32 platform(s), since > everything is fine under Linux (perl 5.8.3, Tk 804.027, Mandrake > Linux 10.0). > > I' ve tested this with Turkish encoding, but someone also reported > that it is present with Polish encoding. And I think that it is > broken for all encodings. > > I can not supply a patch, since I don't know C.

Can you supply a small but complete example exhibiting the problem? Regards, Slaven

Mon Oct 23 19:08:18 2006 The RT System itself - Status changed from 'new' to 'open'

Sat Apr 28 11:00:18 2007 burak [...] cpan.org - Correspondence added

tk.pl works fine without any input. The attached graphic has 2 pictures in it. The first one shows the state in the first run of the code (i.e.: no input from the keyboard) and the last one shows the state after keyboard input. Btw, nothing changes, if I remove the Encode codes and put a use encoding "iso-8859-9"; at the top of the program. "ü" is displayed correctly, since it has a place in the latin-1, but others are wrong. It looks like, Tk (or this Entry widget) falls-back to latin-1 if it can't determine the encoding. I didn't test that with your new releases yet and in fact I quit using Tk for a while since it seemed like a dead and buggy module :) On Mon Oct 23 19:08:17 2006, SREZIC wrote: Show quoted text

> Can you supply a small but complete example exhibiting the problem? > > Regards, > Slaven >

use 5.008; use strict; use warnings; use Tk; use Encode; my $mw = MainWindow->new; $mw->Entry(-text => decode("iso-8859-9", "ðüþ") )->pack; MainLoop;

Download tk.png
image/x-png 4.5k

Tue May 22 15:31:04 2007 SREZIC [...] cpan.org - Correspondence added

From:

SREZIC [...] cpan.org

On Sat Apr 28 11:00:18 2007, BURAK wrote: Show quoted text

> tk.pl works fine without any input. The attached graphic has 2 > pictures in it. The first one shows the state in the first run of the > code (i.e.: no input from the keyboard) and the last one shows the > state after keyboard input. > > Btw, nothing changes, if I remove the Encode codes and put a use > encoding "iso-8859-9"; at the top of the program. > > "ü" is displayed correctly, since it has a place in the latin-1, but > others are wrong. It looks like, Tk (or this Entry widget) falls-back > to latin-1 if it can't determine the encoding. > > I didn't test that with your new releases yet and in fact I quit using > Tk for a while since it seemed like a dead and buggy module :) >

I cannot reproduce the problem on my system. I see the three characters as expected (g with some accent above, ue, s-cedilla), I can focus the entry and edit the contents. It could be that the problem only occurs on Windows systems (I have FreeBSD+xorg here) or is really a bug in Tk804.027 and fixed in Tk804.027_500 (which is installed on my system). Regards, Slaven

Tue May 22 16:32:53 2007 burak [...] cpan.org - Correspondence added

From:

BURAK [...] cpan.org

On Tue May 22 15:31:04 2007, SREZIC wrote: Show quoted text

> It could be that the problem only occurs on > Windows systems

I mentioned that in my first post on RT: Show quoted text

> It looks like this bug is present only on win32 platform(s), > since everything is fine under Linux (perl 5.8.3, > Tk 804.027, Mandrake Linux 10.0).

Thu Jul 05 17:50:51 2007 SREZIC [...] cpan.org - Correspondence added

On Tue May 22 16:32:53 2007, BURAK wrote: Show quoted text

> On Tue May 22 15:31:04 2007, SREZIC wrote:

> > It could be that the problem only occurs on > > Windows systems

> > I mentioned that in my first post on RT: >

> > It looks like this bug is present only on win32 platform(s), > > since everything is fine under Linux (perl 5.8.3, > > Tk 804.027, Mandrake Linux 10.0).

OK. Then it's interesting whether this problem occurs only in ActivePerl (since they are maybe patching both Perl and Tk) or also in standard perl + standard Tk like Strawberry Perl or Vanilla Perl. Regards, Slaven

Wed Nov 07 03:37:41 2007 SREZIC [...] cpan.org - Correspondence added

I tried the test script with current Strawberry Perl + Tk-804.027_501 under Windows XP with Turkish keyboard layout and it seems fine to me. Both the already displayed characters and newly typed in characters look OK. Regards, Slaven

Wed Nov 07 03:37:43 2007 SREZIC [...] cpan.org - Status changed from 'open' to 'resolved'