This is even more bizarre that I had first thought. Having set the default codeset in the Tool Output window to use UTF-8, this doesn't - as I mentioned in my previous post - have any effect on what shows as the actual codeset as it appears under `Right click | Document tab' on the Tool Output `Document'. It remains as ANSI. However, if I close down TextPad and then reopen it and check again without any other intervening action, it shows the codeset for the Tool Output correctly as UTF-8 enabled. However (x2), if I then run my tool (gcc-4.4.3 compiler) the output is incorrectly rendered still and a second check on the codeset of the Tool Output window shows that it has reverted to ANSI - and this, even though the compiler is producing its output in UTF-8!
I don't think there's anything else that I can do to correct this as it seems that it is a bug in TextPad. For information I have found a workaround, but its not ideal.
My setup is TextPad 5.3.1 running on windows Vista with the locale set to `en_GB.UTF-8'. The tool I'm trying to run is the GNU gcc-4.4.3 compiler which, since version 4.0, will output in UTF-8 if it is running in a UTF-8 capable environment, which it is here. (See
http://gcc.gnu.org/gcc-4.0/changes.html for details.) This suggests that if I `downgrade' my locale to lose the UTF-8, then gcc will output in plain ANSI. And, sure enough, if I add `LANG=C.cp1252' directly to TextPad's environment variables (Configure | Preferences... | Environment Variables) then I can at least make sense of the output from gcc. However, as I say, it's not ideal since it presumably switches off all UTF-8 support in TextPad, though at present I'm not doing any work in unicode.
Is anyone else having similar problems? I have picked up that `Anton' was encountering the same kind of thing with tool output, which he reported in September of last year (
http://forums.textpad.com/viewtopic.php?t=10207).
Regards
S