Tk Source Code

solaris 2.9 sun c compiler build of tk 8.5 cvs head;
test suite displayed via exceed 10.0.0.12 on a win xp
system.

textDisp.test

==== textDisp-27.7 SizeOfTab procedure, center
alignment, wrap -none (potential 
numerical problems) FAILED
==== Contents of test case:

    .t delete 1.0 end
    set cm [winfo fpixels .t 1c]
    .t configure -tabs {1c 2c center 3c 4c 5c 6c 7c 8c}
-wrap none -width 40
    .t insert 1.0
a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
    set width [expr {$fixedWidth * 19}]
    set tab $cm
    while {$tab < $width} {
        set tab [expr {$tab + $cm}]
    }
    # Now we've calculated to the end of the tab after
'a', add one
    # more for 'bb\t' and we're there, with 4 for the
border.  Since
    # Tk_GetPixelsFromObj uses the standard 'int(0.5 +
float)' rounding,
    # so must we.
    set tab [expr {4 + int(0.5 + $tab + $cm)}]
    update
    set res [.t bbox 2.23]
    lset res 0 [expr {[lindex $res 0] - $tab}]
    set res

---- Result was:
-36 18 7 13
---- Result should have been (exact matching):
-28 18 7 13
==== textDisp-27.7 FAILED

Fully agreed.

I have just tried on a different Linux box (Debian 6.0 Squeeze), with Tcl/Tk 8.6.1 compiled from source. This test textDisp-27.7 in exercised and does NOT fail on this platform.

Closing as Wont Fix.

Since it appears to be something that is purely dependent on the font setup (which we just don't control), I'd suggest either fixing the test or closing as Wont Fix. Fixing the test would require using font measure to work out what the font metrics really are so that the sizes expected would be those that ought to be calculated. Theoretically, that would allow switching to using any font then, not just Courier -12, but the possibility of kerning affecting things (especially for non-fixed-width fonts) would be just a little bit scary.

I'm inclined to just close this. It's not a bug in Tk so much as in the experiment test itself.

The test calculates the horizontal distance in pixels between a tab stop and a character bounding box in a text widget.

This is indeed based on a font specified at the beginning of textDisp.test:
set fixedFont {Courier -12}

On Windows:
  font actual {Courier -12} returns:
  -family {Courier New} -size 9 -weight normal -slant roman -underline 0 -overstrike 0
  font measure [font actual {Courier -12}] returns: 7

On OpenSolaris:
  font actual {Courier -12} returns:
  -family Courier -size 12 -weight normal -slant roman -underline 0 -overstrike 0
  font measure [font actual {Courier -12}] returns: 10

Not the same font family, not the same font size, and especially not the same font width. Then, counting how many tabstops (placed as an amount of space in centimeters on screen) are needed to cover a given number of characters is a recipe for test failure. Unfortunately that's what this test is doing.

So that's the reason why the test fails: the expected font is not available under OpenSolaris, and as you said, the X server is replacing the requested font by a slightly different beast.


Now textDisp.test is a constrainted test. It will run:
  . on Windows
 or
  . when a pre-screen in constraints.tcl indicates the fonts in a [text] have sizes that are expected (i.e. when [testConstraint fonts] == 1 )

On Solaris this pre-screen does not fail, i.e. one has: [testConstraint fonts] == 1

This is assessed in constraint.tcl as follows:

    # constraint to see what sort of fonts are available
    testConstraint fonts 1
    destroy .e
    entry .e -width 0 -font {Helvetica -12} -bd 1
    .e insert end a.bcd
    if {([winfo reqwidth .e] != 37) || ([winfo reqheight .e] != 20)} {
        testConstraint fonts 0
    }
    destroy .e
    destroy .t
    text .t -width 80 -height 20 -font {Times -14} -bd 1
    pack .t
    .t insert end "This is\na dot."
    update
    set x [list [.t bbox 1.3] [.t bbox 2.5]]
    destroy .t
    if {![string match {{22 3 6 15} {31 18 [34] 15}} $x]} {
        testConstraint fonts 0
    }

Read: Only {Helvetica -12} and {Times -14} are checked in [testConstraint textfonts] whereas {Courier -12} is used the "textfont"-constrained test textDisp-27.7

Conclusion: the pre-screen is wrong. It should evaluate the constraint against -font {Courier -12} instead.
I had already arrived at that same point in another ticket:
http://core.tcl.tk/tk/tktview?name=857686bb3d

What surprises me is that a lot of other tests should probably fail under OpenSolaris. There are ~135 tests in textDisp.test that are "textfont"-constrained.

Changing constraint.tcl so that {Courier -12} is used instead of {Times -14} will lead to skipping more than 130 tests under OpenSOlaris. Is it really the right thing to do. Perhaps after all. dgp said in the ticket I'm refering to above that on his platform all those ~135 tests are skipped because the local fonts in use fail the pre-screen.

Opinions?

What is the test testing/calculating?
A bounding box around a text widget ?
Based on some font?
Could this be because whatever X server is running chooses slightly different fonts ?

OK, that was a bit hard to get working, but here we are.

test setup:
- OpenSolaris 2009.06 running as a virtual machine on top of a Windows box
- ActiveTcl8.5.7.0.290198-solaris-ix86-threaded package (OK, it's old but I had nothing better at hand and it's still older (April 2009) than the OP's report in the present ticket)
- Downloaded constraints.tcl and textDisp.test from latest core-8-5-branch
- Ran wish8.5
- In wish, sourced a text file constituted by the concatenation of contraints.tcl and textDisp.test

Result: textDisp-27.7 DOES fail indeed.

The obtained result is however different from the OP's results:

---- Result was:
-9 18 7 13
---- Result should have been (exact matching):
-28 18 7 13
==== textDisp-27.7 FAILED

> Yes I understand that.

My apologies. I thought that you had missed this when you simply said 'testing on Windows' as that is a quite different setup.

> I [...] will not buy Exceed just for that reason.

Also understandable. I added Larry Virden's mail back as the contact in case/hope that he still has the configuration or similar enough that he can re-test.

> If textDisp-27.7 does not fail under _OpenSolaris_2009.06_
> then the logical action is to close this ticket. Agreed?

I can agree to that.

Correction:

I _could_perhaps_ download Solaris 11.2 _IF_ I provide Oracle with a lot of details regarding myself that I don't see a reason to provide to them. They want me to open an account at Oracle and so on. No way.

So I can try OpenSolaris instead. Even if this OS project is now discontinued it turns out I have Solaris 2009.06 installed among my virtual machines collection.

So: If textDisp-27.7 does not fail under _OpenSolaris_2009.06_ then the logical action is to close this ticket.

Agreed?

Yes I understand that.

I'm willing to analyze this issue but I will not buy Exceed just for that reason. Apparently I could get an evaluation version of Exceed, which could allow me to check this. However trying to reproduce in practice is much more complicated (get Exceed, make the X11<->Windows setup and so on) than just ask the OP if he still sees this issue or not.

BTW, if this is an Exceed issue, then isn't it an Exceed bug? I mean: close this one, open a ticket at Exceed site then.

What I can perhaps do is to try the test suite under Solaris (in a virtual machine because I don't have such a Linux box at hand). I have found I can download Solaris 11.2 here:

http://www.oracle.com/technetwork/server-storage/solaris11/downloads/install-2245079.html

But that's the only thing I can do I think to dig into the present ticket. If textDisp-27.7 does not fail under Solaris 11.2 then we should conclude this is an Exceed bug unrelated to Tcl/Tk (or perhaps this bug vanished since reporting time 8 yesars ago!), and the logical action is to close this ticket.

Might be an Exceed issue.
Note that the report was for remote display of an X11 wish on Windows.
Not native windows.

Does this still happen?

I don't see this test failing on Windows.

Logged In: YES 
user_id=15949
Originator: YES

this identical behavior continues to manifest with the beta tcl/tk 8.5 cvs head.