Menu

#2632 font specification error

obsolete: 8.5.7
closed-fixed
7
2009-05-13
2009-05-13
Pat Thoyts
No

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=

Discussion

  • Pat Thoyts

    Pat Thoyts - 2009-05-13

    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 *

     
  • Pat Thoyts

    Pat Thoyts - 2009-05-13

    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.

     
  • Pat Thoyts

    Pat Thoyts - 2009-05-13
    • milestone: 897104 --> obsolete: 8.5.7
    • status: open --> open-fixed
     
  • Pat Thoyts

    Pat Thoyts - 2009-05-13

    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

     
  • Pat Thoyts

    Pat Thoyts - 2009-05-13
    • status: open-fixed --> closed-fixed
     
  • Pat Thoyts

    Pat Thoyts - 2009-05-13

    Applied to 8.5 branch.