GNOME Bugzilla – Bug 340736
Outputbox can't receive Japanese output from external command
Last modified: 2009-12-25 17:22:54 UTC
Outputbox function uses regex in its source code, so they can't handle Japanese output from external command. On CVS HEAD, it is fixed ago, not yet for stable versions because simple fix was not provided. I present here small patches for some files. If it is acceptable, please include it in stable release.
Created attachment 64857 [details] [review] patch against configure.ac, bluefish.h and outputbox.c of 1.0.5 This is the patch I present.(1/2)
Created attachment 64858 [details] [review] patch against configure in 1.0.5 official archive This is the patch against configure out of box 1.0.5 archive. (2/2) If you use autoconf, (1/2) is enough and this is not necessary.
Can you provide a simple way to reproduce the issue? Is it still valid for the stable series (1.0.7 or latest revision of the bluefish_1_0 branch)?
I will recheck... Done. Hm, I can reproduce it on 1.0.7 on Debian. I installed bluefish_1.0.7-5_i386.deb from Debian official apt line. I noticed that when I start bluefish under ja_JP.UTF-8 locale there is no problem while under ja_JP.EUC-JP I can reproduce it. So the way reproduce it is, 1. Start bluefish under ja_JP.EUC-JP locale, $ LC_ALL=ja_JP.EUC-JP bluefish & 2. Add to output perser following checker. "po file syntax checker" pattern is: ([a-zA-Z0-9/_.-]+):([0-9]+): (.*) #1 is for filename #2 is for line number #3 is for output. command is: msgfmt -c -v '%s' 3. load a po file. This time I used one at: http://hp.vector.co.jp/authors/VA014481/bluefish/po/01-16-2005.ja.po 4. Call the filter from Outputbox menu, Menubar External -> Outputbox -> po file syntax checker 5. You see some characters are displayed in Outputbox. ASCII characters are normal, but Japanese characters are badly changed and I can't read them.
Changing the version to 1.0. I have not fixed this in the 1.0 branch of SVN. Not tested, but I believe this bug does not effect the current development branch of SVN.
I agree it is only for 1.0 branch. I tried some more and found some change of the result. If I change command to: 2>&1 msgfmt -c -v '%s' | nkf -w At 2. of comment #4, I get some of Japanese caracters readable but remaining characters are lost! For unstable version, on this way, things go well. I think regex routine used in outputbox.c in 1.0 branch are not good at handling UTF-8 converted Japanese characters. nkf is one of encoding conversion filter, like as iconv is, and 2>&1 is necessary as output from msgfmt -c comes from stderr.
is this a bug actually in bluefish? if I understand correctly, when you start using the ja_JP.UTF-8 locale all goes well, however not when using ja_JP.EUC-JP. But the second locale was not created with UTF-8 support, am I correct? so the normal behaviour would be to _not_ display UTF-8 chars. Bluefish uses UTF-8 iirc, so I think this is expected.
(In reply to comment #7) > is this a bug actually in bluefish? I think I can say "this is a bug of bluefish." Jorge wrote comment #7 from developers point of view. And from the point of view his comment is right. Are those the things user should know about? I hope so, but there is Japanese translation of menu already, so Japanese users may expect they can use Japanese language in outputbox readily also. And more, there is the way to fix this problem. At least some note should be anywhere. It is the reason I wrote it on my web page: http://hp.vector.co.jp/authors/VA014481/bluefish/outputbox.html
Bluefish 2.0.0-rc1 has been released. This is the first release in the 2.x series. Upgrading to the 2.x releases is recommended. Bugs in the old 1.x branch are unlikely to be fixed. If you can reproduce this bug against the 2.x branch please reopen the bug.