You've jogged my memory (it was a while ago). I had to cpan install Tk on both the fc9 and 13 boxes. In both acses, the install had to be "forced" due to the number of test case failures (though they run ok, except for the font issue on fc13). I'll try your suggestion of not using the cpan utility.

Later: No change. The t/font.t said:

t/font.t .................. 1/34 Font Courier -12 still in cache.

I'll look into that, but don't think it's the problem. Will also try this test case on the working FC9 install for comparison.

Even later still...

On both the "working" Tk install (FC9) and "non-working" (FC13) install, the fonts.t test fails test 11 (Value of -size from fontActual (Times font).

However the "working" font.t test exits with a segmentation fault after test 24 (Core dump check (especially for XFT)) while the "non-working" install continues to the end of the test program, skipping tests 14..23.

Test 24 runs a test that causes a core dump with the Xft version of Perl/Tk, so it looks like the FC9 (working) version HAS XFT while the non-working one may not.

To confuse matters more, running the application from the FC9 box over a SSH connection to the FC13 box, the font problem disappears. If I read this right, it suggests that the problem lies with the X font setup on the X server in question, not Tk itself (ie, when the app is run remotely, it's using the local perl modules, but talking with the X system on the machine running the ssh session).

Listing the fonts (xlsfonts) gives about the same result on both machines. But the utility 'xfontsel' does no exist on the FC13 box (it is on the "working" FC9 machine), so I'm wondering if this is connected to the problem. Maybe some part of X has not been installed?