GNOME Bugzilla – Bug 322042
Buggy RTL support in ellipsized gtklabel labels
Last modified: 2011-02-04 16:10:53 UTC
Distribution/Version: fedora core 4 Run the sample code. Once in an RTL locale (e.g. fa_IR) and then in an LTR locale (say en_US). The text in the statusbar is not shown in the RTL mode.
Created attachment 55027 [details] Sample code to demonstrate the bug
The text does show up, but only if reduce the window width to about 100. This seems to be the same problem as in bug #169390.
Although the last comment in bug #169390 seems to describe *this* bug, these two bugs don't seem to refer to the same problem. At least not quite directly.
Created attachment 57958 [details] A shorter sample, using gtk_label_set_ellipsize This is a shorter sample code to reproduce the bug. If you set the size to (100, 100) you can see the label, but resizing the window results label going out of area.
Ok, seems like regardless of locale, gtklabels are misaligned if and only if they contain rtl text and ellipsize is set (to whatever START/MIDDLE/END.) It looks like a +/- issue somewhere, or double charging the X offset...
Created attachment 57961 [details] [review] Fix. 2006-01-23 Behdad Esfahbod <behdad@gnome.org> * gtk/gtklabel.c (get_layout_location): Fix misalignment of RTL text in ellipsized GtkLabel: use layout width if set, otherwise fallback to ink extents width. (#322042)
Committed to gtk-2-8 branch too. Should be in 2.8.12
Reopening, since the patch does not work for all cases and breaks aligning ellipsized labels (see #332604). For ellipsized labels the width of the layout is set to the allocation.width of the label. The alignment/position of the layout in the label is calculated incorrectly, since this width value is being used where we actually need the width of the ink rect (which happened previously and works fine for LTR). Note that the width of the layout still equals the allocated width of the widget and drawing the layout with an xlign of 1.0 goes fine, since we just move the layout to the right. However this goes wrong for RTL text, since the text is drawn at the right side of the layout. If we move the layout to the right, the text is drawn outside the area of the label. A way of fixing this would be to move the layout to the left instead of to the right in this case. To get this right, we'll have to figure out which direction the text in the layout uses. Some questions: - Would this be the right approach? - What's the best way to figure out the direction of the text in the layout? - What would be the right behaviour if there's text with different directions in the layout?
Ok, in fact shortly after committing this patch I gave the problem more thought (in the context of bug 328456). The fix is really simple, though I've not tested yet. When we get the ink rect, we've got to further offset the layout by (-rect.x, -rect.y). That's really all. There's one catch to this though, if the layout contains both RTL and LTR text (and autodir is on, which is the default), we don't get centered text, instead RTL text is aligned to right, LTR to left. This is because ink-rect is now returning full width. This only happens with multi-paragraph labels, which should be easy to ignore?
Behdad, any update on this ?
From my testing, with the patch in 332604 committed now, this bug can be closed.