Tk Source Code

When compiling Tk 8.6 against Tcl 9.0 headers, a number of testcases fail, e.g.:

entry.test

==== entry-3.7 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

# Tcl_UtfAtIndex(): utf at end
    .e insert 0 "ab乎"
    .e bbox end

---- Result was:
19 5 7 13
---- Result should have been (exact matching):
19 5 12 13
==== entry-3.7 FAILED

==== entry-3.8 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

# Tcl_UtfAtIndex(): utf before index
    .e insert 0 "ab乎c"
    .e bbox 3

---- Result was:
26 5 7 13
---- Result should have been (exact matching):
31 5 7 13
==== entry-3.8 FAILED

==== entry-3.10 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

.e insert 0 "abcdefghij乎klmnop"
    list [.e bbox 0] [.e bbox 1] [.e bbox 10] [.e bbox end]


---- Result was:
{5 5 7 13} {12 5 7 13} {75 5 7 13} {117 5 7 13}
---- Result should have been (exact matching):
{5 5 7 13} {12 5 7 13} {75 5 12 13} {122 5 7 13}
==== entry-3.10 FAILED

Note that the width of th 乎 character is measured as 7 pixels, while it really should be 12 pixels. The problem looks to be the function Tk_MeasureChars() in tkUnixFont.c, since the xft variant in tkUnixRFont.c gives the right result.

Yes (in the Tcl repository).

The merged fix is in [0384d3314c68797b].

Great, many thanks Jan, that was not easy!

Fixed in Tcl 8.7 and 9.0 now. Related failsOnXQuartz constraints in Tk removed. So, this ticket can be closed.

@fvogel, thanks for the idea, creating this bug-370b1ff03e branch. I did some more experimenting on it: It turns out the tableEncoding is the problem, not the utf-8 encoding (both are used in tkUnixFont.c).

Solution is on-the-way soon ;-)

Great, that was a good idea!

on my side I have created a Tk bug-370b1ff03e branch in which I have removed the failsOnXQuartz constraints in entry.test and spinbox.test. On the mac, with clang, this branch builds against your Tcl bug-370b1ff03e branch,

The results at CI is that the tests pass on the mac with clang and XQuartz. This proves the problem reported in the present ticket indeed is in Tcl, not Tk.

Found something! I decided to do a bisect on Tcl 8.7 (keeping Tk 8.7 the latest version), and found out that the commit starting this trouble is this one: dd396e24b7b556fa

I don't understand it yet, but reverting this commit brings back the 乎 in the entry widget.

See 522899ab24cba7bb. This fixes the problem, but re-introduces the original problem. So, we're not done yet, but it's another step!

Well, forget about the test. The following script should show the 乎 character (whatever that is) in the entry, but it does not.

  package require Tk
  pack [entry .e]
  .e insert end 乎

It shows a question mark instead.

Only with 8.7, not with 8.6, and only on the mac with --disable-xft --disable-aqua.

(Then when measuring the width of the displayed character of course the test fails.)

The fact the requested character does not display is the problem we have to solve. (It's only after this is fixed that we should focus on the test.)

Now you understand why I'm completely lost with this ticket.... Something is wrong, either in the code either in the testcase. But the clues conflict....

I had a look at this a bit more. Definitely, when running:

  package require Tk
  pack [entry .e]
  .e insert end 乎

in 8.7 on macOS built with XQuartz with --disable-aqua --disable-xft the content of the entry does not show the 乎 character: it is replaced by a question mark.

Then, configuring the entry through .e configure -font {{DejaVu Sans} 12}, one gets the correct display of 乎.

So this issue seems to be that the default font (TkTextFont) cannot show the required character in this specific build. For the records, [font actual TkTextFont] returns "-family helvetica -size 10 -weight normal -slant roman -underline 0 -overstrike 0". Is this a problem when trying to show a 乎 character?

Next good question: why is this not a problem with 8.6...? The entry uses the same default font (TkTextFont) and font actual on this returns the same thing as with 8.7 except the size (9 instead of 10).

Thanks for the feedback. I'm a bit confused now: Earlier you said "I noticed this on MacOS with aqua", but now you state it can be shown only with --disable-aqua I'm not following you. Anyway, I have just tried, I can reproduce as well with --disable-aqua.

Also, it's not just happening when compiling Tk 8.7 against Tcl 9.0 headers, but also when compiling Tk 8.7 against Tcl 8.7 headers. However it does not happen with Tk 8.6 against Tcl 8.6 headers, and this does not point the finger to the test itself.

Having a quick look: With 8.7 the entry renders .e insert 0 "ab乎" by "ab?", i.e it replaces the third character by a question mark. With 8.6 the entry renders the same string by the expected "ab乎". Again, this does not point the finger to the test but to the code.

Another observation, probably unrelated to the failures discussed in this ticket: the tests are constrained by the "fonts" constraint, which is set to true (in constraints.tcl) if some dimensions of the entry widget are obtained when the font used is {Helvetica -12}. But the failing tests use another font: {Courier -12}. Depending on the replacement font selected this is a door open for troubles.

Yes, I can still produce it locally. But it should be "--disable-aqua --disable-xft" (otherwise it is not really built with XQuarz. My result now (after removing the constraints):

==== entry-3.7 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

# Tcl_UtfAtIndex(): utf at end
    .e insert 0 "ab乎"
    .e bbox end

---- Result was:
19 5 7 13
---- Result should have been (exact matching):
19 5 12 13
==== entry-3.7 FAILED

==== entry-3.8 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

# Tcl_UtfAtIndex(): utf before index
    .e insert 0 "ab乎c"
    .e bbox 3

---- Result was:
26 5 7 13
---- Result should have been (exact matching):
31 5 7 13
==== entry-3.8 FAILED

==== entry-3.10 EntryWidgetCmd procedure, "bbox" widget command FAILED
==== Contents of test case:

.e insert 0 "abcdefghij乎klmnop"
    list [.e bbox 0] [.e bbox 1] [.e bbox 10] [.e bbox end]


---- Result was:
{5 5 7 13} {12 5 7 13} {75 5 7 13} {117 5 7 13}
---- Result should have been (exact matching):
{5 5 7 13} {12 5 7 13} {75 5 12 13} {122 5 7 13}
==== entry-3.10 FAILED

==== entry-5.8 ConfigureEntry procedure FAILED
==== Contents of test case:

.e configure -width 0 -font {Helvetica -12}
    .e insert end "0123"
    update
    .e configure -font {Helvetica -24}
    update
    winfo geom .e


---- Result was:
62x37+5+0
---- Result should have been (exact matching):
62x37+0+0
==== entry-5.8 FAILED

Most likely it's related to the fonts available in XQuarz, so I suspect it's a problem in the testcase, not in the Tk code.

Can you still reproduce this?

I can't, on macOS Ventura, Tk built with XQuartz --enable-aqua --disable-xft

(note: when testing, don't forget to remove the constraints on the entry tests :-))

Indeed, I meant Tk 8.7 with Tcl 9.0 header.

However, I noticed this on MacOS with aqua, assuming that it would fail on any --disable-xft. But - indeed - it doesn't fail on Ubuntu. Investigating further .....

> When compiling Tk 8.6 against Tcl 9.0 headers...

Isn't this expected to fail? For me it does not build (Linux).

Did you perhaps mean: "When compiling Tk 8.7 against Tcl 9.0 headers..."? Indeed you mention "8.7" in the Version field.

In any case, I'm surprised I can't reproduce with the 'main' Tcl branch and 'main' Tk branch built with --disable-xft.