Tk Source Code

Using the following script, reduce the window size.
The right adjusted text simply disappears from the display.

(Could both centered and right adjusted wrapping algorithms (for text) be much simpler?)

package require Tk

set fixedFont {"Courier New" -12}

frame .f -width 100 -height 20
pack .f -side left
text .t -font $fixedFont -width 40 -height 10
pack .t -expand 1 -fill both

.t configure -wrap char -highlightthickness 0 -borderwidth 0 -padx 0 -pady 0

.t delete 1.0 end
.t configure -width 40 -padx 0 -highlightthickness 0 -border 0
update
.t tag configure x -tabs [list 280]
.t tag configure y -tabs [list 280 center]
.t tag configure z -tabs [list 280 right]
.t insert 1.0 "left\tabcdef\n"
.t insert end "center\tabcdef\n"
.t insert end "right\tabcdef\n"
.t insert end "1234567890123456789012345678901234567890\n"
    .t tag add x 1.0 2.0
    .t tag add y 2.0 3.0
    .t tag add z 3.0 4.0

Thank you for your feedback. I agree, we can close this ticket because what it reports has been fixed.

Regarding the remaining tabs handling we already have two other tickets: [a34b49f8c6] for textDisp-2.26 and textDisp-24.24, and [6a78781cc3] for textDisp-27.10, which are the last failing tests for me with revised_text, at least on Windows.

> Shouldn't this ticket be closed?

I think it can be closed now. One of the problems with tabbing is the fact that it was never properly implemented in legacy widget, and the revised version has already implemented some improvements, but without an overwork of the whole tab handling there is no proper way to fix complicated (new) tabbing problems. I will do an overwork of tab handling in a later version, IMO the current version is okay so far. There is only one known open problem at this time, reported by a friend, and after a fix of this problem it is finished for the time being.

Shouldn't this ticket be closed?

Is there anything else to fix triggered by the present discussion that doesn't have it's own ticket elsewhere?

Mac OS X: As expected, just the two known failures 3.1 and 24.11.1 (has its own ticket).

Thanks, compiler warning is eliminated with [af10305c].

I think you fixed 27.8 better also.

The updated test file is in ticket: 44e92d896eb31b8c
I just attached the very latest.

Passes all tests on linux! 

Tests ended at Sat Aug 19 00:58:01 PDT 2017
all.tcl:        Total   396     Passed  346     Skipped 50      Failed  0
Sourced 1 Test Files.
Number of tests skipped for each constraint:
        10      nonPortable
        36      textfonts
        1       win
        3       yscrollposition

Very late here.  I will test on Mac OS X tomorrow.  I expect one failure.

One compile warning I saw:

/home/bll/tcl/tk/unix/../generic/tkTextDisp.c: In function ‘ComputeSizeOfTab’:
/home/bll/tcl/tk/unix/../generic/tkTextDisp.c:56:30: warning: ‘min’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 # define MAX(a,b) (a < b ? b : a)
                              ^
/home/bll/tcl/tk/unix/../generic/tkTextDisp.c:13311:9: note: ‘min’ was declared here
     int min;
         ^

With [79b3bf7e52] these test cases should pass, I cannot test under Linux because of the textfonts constraints - I get different results -, but it looks okay.

Tests 26.13, 26.13.2 (these two are 'not enough space' checks) and 27.7 (-wrap none) are failing now.

The displayed text is overlapping.

Test 27.8 passes.

I can tell just from the way the wrapping looks and feels (I have not looked at any code) that the original design was not optimal.  A big mess.

And _someday_ all this needs to be made to work with -justify right so right-to-left languages will work properly.

Because of any accident I've lost some changes with last commit, so this couldn't work properly, I'm sorry. After some tests I decided to do another overwork of the tab computation, the newer handling takes care of fixed size fonts. But with current layout algorithm an optimal solution is not possible, this requires a complete rework, because line wrapping with wrapped text was never developed, the developer of the legacy widget has forgotten this. But I think that the current version [69597ce0] provides quite good results, so far as I have tested.

Mac OS X:

Test 3.1 has a one pixel difference (I am not worried about this test), 24.11.1 fails as known, 27.8 is failing in the exact same manner.

Looks good.

This error:

2017-08-17 09:05:38.705 tktest[15899:1714951] tkMacOSXDraw.c:746: DrawCGImage(): Mismatch of sub CGImage bounds

Appears in tests 4.5 (x6), 4.6 (x1), inbetween 4.6 and 4.7 (x1) (probably due to the geometry reset), 24.16 (x11), 24.17 (x11).

I'm still getting some strange results for 27.8
All other tests are passing:

all.tcl:        Total   396     Passed  345     Skipped 50      Failed  1
Sourced 1 Test Files.
Files with failing tests: textDisp.test
Number of tests skipped for each constraint:
        10      nonPortable
        36      textfonts
        1       win
        3       yscrollposition

I did a make clean, fossil pull, fossil update, re-built both tcl and tk.

bll-tecra:bll$ fossil status
repository:   /home/bll/tcl/tk/../tk.fossil
local-root:   /home/bll/tcl/tk/
config-db:    /home/bll/.fossil
checkout:     1a631f0cdf0aa4cb6cc64f828e88aa95180d0c37 2017-08-17 10:44:01 UTC
parent:       0c5839c90f620c26fd2bd45d2e046a672031df09 2017-08-16 18:43:10 UTC
leaf:         open
tags:         revised_text, tip-466
comment:      Bugfix [0421e91b58]: Line break in right adjusted text (right
              tab) working again. (user: gcramer)
EDITED     tests/textDisp.test
EDITED     tests/textWind.test

See attached pics: t27-8-[ABC].png

In [1a631f0cdf] I solved the problem with line break in right adjusted text (27.8).

I've committed [0c5839c90f], tabstyle wordprocessor is working again, it needs a different handling when wrapping lines.

Tests that need to be added:
- make sure wrapped left-tab text only wraps to two lines (see comment below)
- 27.10.1 : numeric tabs with wrapping, as 27.10 is now a basic numeric alignment test.

Right.  Sorry, my brain is stuck on tabs.

24.24 is fixed.
25.1 is passing.
26.3 is fixed, passing.
26.4 is fixed, passing.
26.14.2 is failing, -tabstyle wordprocessor no longer works.
27.8 is failing, character wrapping for a right adjusted tab without enough 
   space is not working.  The wrapped text does not show.
   If I adjust the width of the window, the 
   positioning is recalculated and the wrapped text shows up
   (sometimes incorrectly).

    .t delete 1.0 end
    .t insert 1.0 a\t\txyzzyabc\n
    .t tag delete x
    # the 100 tab stop prevents the text from fitting into
    # the first line.
    .t tag configure x -tabs {100 left 140 right}
    .t tag add x 1.0 end
    # second z, second y
    list [.t bbox 1.6] [.t bbox 1.7]

27.10 is fixed, passing
Any others not mentioned are passing.

I don't know what you mean. I think you are talking about the following script (a simplified version of your script below):

text .t -font {"Courier New" -16} -width 40 -height 1
pack .t -expand 1 -fill both
.t tag configure x -justify center
.t insert 1.0 aa\tbb\tcc\tdd\n x

I have attached "centered-Linux.png", this is the result under Linux, the line is perfectly centered, and this requires leading space.

24.24 (centered text) is still getting some leading space before the 'aa'.
See attached picture.  That first line should be static, but when the width
is adjusted, the leading space changes size.  And there shouldn't be leading
space at all before the 'aa'.

Don't know why the final \t is in there...leftovers from the original.

I've committed [f760ba990e] with an improvement when centering tabbed text.

About your test case: the final "\t" at end of line gives a weird looking result, but the result seems to be okay.

In test 25.1, the bbox calculation for the second tab is including the width of the first tab also.  The failure is correct.

I currently have 24.24, 25.1, 26.1, 26.1.2, 26.3, 26.4, 26.13, 26.13.2, 26.14.2, 27.1,  27.1.1, 27.7, 27.8, 27.10 failing.   I will work through these and either correct the test or describe the problem here.

---

(Before when adjusting the width of the window using the first test in this ticket, centered text would wrap on the half-character, the wrapping looks better now.   Before, it looked like four different algorithmic paths were being used for the different tab justifications.)

---

Centered tabs are currently broken.
This is test 24.24.

If the width of the window is adjusted, you can see that the tab stops are not fixed in place at all for the centered text.

package require Tk
set fixedFont {"Courier New" -12}
frame .f -width 100 -height 20
pack .f -side left
text .t -font $fixedFont -width 20 -height 10
pack .t -expand 1 -fill both
update

    .t delete 1.0 end
    .t tag configure x -justify center
    .t insert 1.0 aa\tbb\tcc\tdd\t\n
    .t tag add x 1.0 end
    # extra stuff just so I see where things are...
    .t tag configure y -justify left
    .t insert 2.0 aa\tbb\tcc\tdd\t\n
    .t tag add y 2.0 end
    .t insert end \n12345678901234567890\n
    # end extra stuff...
    # should be:
    #        t       t
    # 12345678901234567890
    # aa    bb      cc
    # dd
    # first a, first d
    list [.t bbox 1.0] [.t bbox 1.10]

Yes, was broken due to a side effect, and unfortunately we have no test cases for this. Because of any accident before doing last commit the numeric adjustment was also not working well, both problems are fixed with [6a985947a6]. My fix has reverted the change of the behavior for centered text, and I must confess that currently I'm not sure about this behavior.

Francois: what do you mean to line wrapping of centered text.

Center and right tabs with character wrapping look much better.
Left justified tab wrapping is currently broken (attached pic).

The whole tab handling has been overworked, because the legacy widget did not implement line wrapping when tabs are involved. With [e1566eb2e] all the test cases (under Linux) are passing again.

Tests 26.3, 26.4, and 27.8 are fixed to use the corrected computation.

26.13 and 26.13.2 are broken, they have overlapping text.  The computation when there is not enough room (and replace with a single space) is not working right.

Here is a small script (26.13):

package require Tk
set fixedFont {"Courier New" -12}
frame .f -width 100 -height 20
pack .f -side left
text .t -font $fixedFont -width 40 -height 10
pack .t -expand 1 -fill both

    .t delete 1.0 end
    .t insert 1.0 "abc\txyz\tqrs\txyz\t0"
    .t tag delete x
    .t tag configure x -tabs {10 30 center 50 right 120}
    .t tag add x 1.0 end
    # x q x 0
    list [lindex [.t bbox 1.4] 0] [lindex [.t bbox 1.8] 0] \
            [lindex [.t bbox 1.12] 0] [lindex [.t bbox 1.16] 0]

Tests 26.3, 26.4, 26.13, 26.13.2, 27.8, 27.10 are failing.
I think there's a separate ticket for numeric alignment (27.10).
I will work on the other tests and figure out if the test computations are incorrect with the fixed code.

Re: ring item in tout commit log:

From the fossil timeline, click on the commit hash.
Click on "Edit" link in the commit page (last item in the "Other Links" line).
You can then change the commit log.

Fixing this bug was easier than seeing this bug. As I tried the third time I saw the problem with the right justified text. I've committed [94c02600c1] with a fix.

Francois: As I committed the fix I have attached the wrong item. How do I change this?

> Francois: what's the behavior under Windows?

I see what Brad is reporting: The right adjusted text simply disappears from the display, when the user reduces the window width using the mouse. This is on Windows and Linux Debian 8 at least.

I did a second try, now I compiled with clang instead of gcc, but the result is the same, I cannot reproduce this, under my system it works fine, so currently it's impossible to me fix it. I'm curious about the test under Windows.

This is on linux.  See attached pic.

I cannot reproduce this behavior under Linux, although I have tested with an emulation of context drawing, the lines will be wrapped properly. Is this a kind of Mac-only-problem?

Francois: what's the behavior under Windows?