As raised on c.l.t by Adrian Davis:
It seems there may be a (minor) bug setting the font for a (Tk/ttk)
label widget, which causes an "expected integer ..." error.
It appears to happen only in a very specific circumstance...
When all of the following are true:-
*) The "-family" option name contains a hyphen/dash.
*) The "-family" option appears first in the list.
*) All of the "-size", "-weight", "-slant", "-underline" and "-overstrike" options are specified.
For Example...
.mylabel configure -font {-family sans-serif -size 12 -weight bold -slant roman -underline 0 -overstrike 0}
...Doesn't work. But...
.mylabel configure -font {-family times -size 12 -weight bold -slant roman -underline 0 -overstrike 0}
.mylabel configure -font {-size 12 -family sans-serif -weight bold -slant roman -underline 0 -overstrike 0}
.mylabel configure -font {-family sans-serif -size 12 -weight bold -slant roman -underline 0}
...All work Ok.
I found this using Tcl/Tk 8.5.7 on Solaris 10.
This has been reproduced under WinXP using ActiveTcl 8.5.3 and Ubuntu
using ActiveTcl 8.6b1.1
(See thread: http://groups.google.co.uk/group/comp.lang.tcl/browse_thread/thread/aa2a4f206c139c42?hl=en#\)
WORKAROUND: Make sure that the "-family" option doesn't appear first
in the list.
Best Regards,
=Adrian=
Occurs on Windows as well. The following test will reveal the issue:
test font-4.12 "font command: bug #2791352" -body {
font actual {-family sans-serif -size 12 -weight bold -slant roman -underline 0 -overstrike 0}
} -returnCodes ok -match glob -result *
The fault is in tkFont.c:ParseFontNameObj where we attempt to decide if this is a XLFD name or a set of font options. What happens is we get confused by the hyphen that is not prefixed with a space and decide that we've been given a XFLD name. This then fails to parse and so we try and treat is as {Family size ...}.
The simple fix seems to be to exclude XLFD if the string begins with "-family ". This assumes that no X fonts exist called -family -* though.
As the XLFD spec doesnt exclude spaces in the font parts I've fixed this by trying to parse as a type 5 description if it is detected as a XLFD but fails the parsing.
Added tests to check for this condition.
Committed to 8.6 HEAD
Applied to 8.5 branch.