#2897 Ttk label does not show multiline text if widget clipped

obsolete: 8.5.9
closed-fixed
8
2012-06-11
2011-04-28
No

Given a ttk label widget with two text lines like:
"ABCDEF
ABC"
The widget is packed in such a way, theat the x space is not sufficient and the last character of the first line is not shown.
In this case, the output is:
"ABCDE
"
thus the second row is empty.
IMHO it should be:
"ABCDE
ABC"

Test code:
% pack [ttk::label .l -text [string repeat 1234567890 10]\nrow2\nrow3]
% wm resizable . 1 1
Resize the window in x direction until the first text line is clipped.

Platform: Windows Vista Pro 32 bit
wish 8.5.9 self compiled with MSVC6

Discussion

  • juergen gohlke

    juergen gohlke - 2012-02-09

    The bug can also be reproduced in (self compiled) Tk 8.5.11 on Linux Centos 5.7 with X Protocol Version 11, Revision 0, Release 7.1.1 xorg-x11-server 1.1.1-48.76.el5_7.5.

    In addition, when one line is too long for the widget space on the screen, that line and all following lines are invisible.

    test: pack [ttk::label .ttklabel -text first\n[string repeat "word " 80]\nlast -anchor w -justify left] -side top

     
  • Donal K. Fellows

    I suspect that the issue is in the pattern of drawing used for pieces of text; there's a similar issue when dealing with ttk::entry widgets where there is text at the right edge of widget from typing. (I notice this from time to time in tkchat.)

     
  • Jeff Epler

    Jeff Epler - 2012-04-03

    The comment in ttkLabel.c seems very apropos:
    149 /*
    150 * Clip text if it's too wide:
    151 * @@@ BUG: This will overclip multi-line text.
    152 */
    153 if (b.width < text->width) {
    154 lastChar = Tk_PointToChar(text->textLayout, b.width, 1) + 1;
    155 }
    in just a few minutes of testing with the block removed, it appears that the impact is to let the text be rendered into parts of the widget where it should not go (e.g., in a button the text goes closer to the border on the right hand side than on the left), but this may be a less bad result than losing text altogether.

     
  • Donal K. Fellows

    Bumping prio; this is actually quite a serious usability problem (especially with entries, where enlarging the widget to hold the content isn't a practical solution at all).

     
  • Donal K. Fellows

    • priority: 5 --> 8
     
  • Jeff Epler

    Jeff Epler - 2012-04-03

    I found in the history of tile that this hack was added for treeviews, where text must not overflow into the subsequent column.

    I've created a patch that addresses the issue for me:
    http://emergent.unpythonic.net/files/sandbox/3294450.patch

    A new "-clipped" configuration option is added for text elements; it defaults to 0 (do not clip), and may be set to 1 where the clipping is required. For Treeview Cells, Items and Headings, -clipped 1 is now specified. It may be preferable to default -clip to 1 and set it back to 0 for places where it's OK not to clip (e.g., labels, buttons, and so on) to reduce the impact of the changed behavior on other users of the text element that reside out of the Tk tree.

    This is a git patch, but it should apply with "patch -p2 < patchfile"

     
  • Donal K. Fellows

    I've fixed this, not with jepler's patch (which didn't *actually* fix the problem) but rather by getting the clipping right. There is now precise clipping to the space available.

    Fix applied to 8.5 branch and trunk. (Downside: ttkLabel.c now includes tkInt.h, but that's IMO entirely acceptable to get this nasty bug squelched.) Still looking at related issue in ttk::entry (which is very frustrating when a character is supposed to partially overlap the border).

     
  • Donal K. Fellows

    • assigned_to: jenglish --> dkf
    • status: open --> closed-fixed
     
  • Donal K. Fellows

    Should now be better in entries too.

     
  • Donal K. Fellows

    Hmm, not convinced I've improved the handling in entries; they're _seriously_ strange on the inside.

     
  • Donal K. Fellows

    OK, the problem with entries (apart from the need to render one more character than before) was really that their text was being rendered by Xft in my testing setup. Unlike all the other font renders used by Tk, the Xft-based one doesn't use the GC to find out the clipping area, so the clipping was being ignored on that (sub-)platform only. All the others (well, probably; haven't tested Windows) were working correctly!

    Added a special hack to convey the clipping in a way that Xft can understand.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks