Menu

#3059 text widget wrapping oddly

current: 8.6.0
pending-invalid
6
2013-02-16
2013-01-29
Talvo
No

I'm not totally sure if this is a bug or intended behaviour:

pack [text .t -wrap word -width 80]
.t insert end [string repeat "la " 28]
puts [.t count 1.0 "1.0 display lineend";# 77

The text widget wraps so that the second line contains "la la", despite the first line being only 77 characters long - long enough that the penultimate "la" would fit. This may well be deliberate - if the extra "la" was shown on the first line, it would mean that either the second line would start with a space (which never looks good), or that there would be no visual indication that the last word wasn't "lala" and it was wrapped per-char (which could be confusing). But a couple of people using an app have reported it as weird behaviour, so I thought I'd run it up the flagpole to you guys to double-check.

Discussion

  • Francois VOGEL

    Francois VOGEL - 2013-02-09

    The text widget is requested to have exactly 80 chars width.

    The font used is TkFixedFont (as returned by .t cget -font).

    As returned by font metrics [.t cget -font] , the metrics of this font is
    -ascent 12 -descent 4 -linespace 16 -fixed 1
    i.e. it is a fixed-width font.

    In this fixed-width font, one (and any) character has width 8 pixels (as returned by font measure [.t cget -font] "a")

    Now:

    % font measure [.t cget -font] [string repeat "la " 26]
    624
    % font measure [.t cget -font] [string repeat "la " 27]
    648

    i.e. the first 26 "la " strings plus the two letters "la" have total width of 640 pixels, which is exactly the width of the text widget (80 chars x 8 pix/char = 640 pixels).

    Now the code in tkTextDisp.c (TkTextCharLayoutProc) states that:

    if ((nextX < maxX) && ((p[bytesThatFit] == ' ')
    || (p[bytesThatFit] == '\t'))) {
    /*
    * Space characters are funny, in that they are considered to fit
    * if there is at least one pixel of space left on the line.

    It is not the case in your testcase: one pixel is missing to allow that space of the 27th "la " fragment to fit on the line.

    The fix would consist in allowing space characters to be included at the right of the line even if there is no remaining pixels at all, not even one, i.e. to change the test above to: if ((nextX <= maxX) ...
    This would indeed do the job (I have checked this).

    However, in such a case, as you mention it, there would be no visual indication that the last word wasn't "lala" and was wrapped per-char (which could be confusing).

    I think things should stay as they are. Any other opinions perhaps?

     
  • Francois VOGEL

    Francois VOGEL - 2013-02-09
    • assigned_to: hobbs --> fvogelnew1
    • priority: 5 --> 6
     
  • Francois VOGEL

    Francois VOGEL - 2013-02-16
    • status: open --> pending-invalid
     
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.