GNOME Bugzilla – Bug 73119
The characters gets overlapped in GtkEntry widget.
Last modified: 2006-01-28 22:08:35 UTC
I am testing in the Gnome 2.0 platform. Everything is from current CVS HEAD. In a GtkEntry widget, the characters gets overlapped when the number of characters exceeds a certain limit(approx more than 8000 characters...) Repeatable: Always How to Reproduce: ----------------- Use the example program under gtk+/examples/entry/ (Note : Remove the max length set for the entry) The following error appears on the console: ------------------------------------------- entry (pid:20312): ** CRITICAL **: file pango-layout.c: line 1704 (pango_layout_get_cursor_pos): assertion `index >= 0 && index <= layout->length' failed entry (pid:20312): ** WARNING **: Invalid UTF8 string passed to pango_layout_set_text()
Did you just type characters until you got the error?
Yes , I just typed the characters & got the error.
Wed Mar 6 00:38:29 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkentry.c (gtk_entry_real_insert_text): Fix various problems when truncating the inserted text to fit into the GtkEntry size limit of 65kb. (#73119) Fixes the warnings about invalid UTF-8 and segfaults. Still misdraws ... partly this needs to be fixed in Pango... the problem here is that the length of the string drawn simply exceeds the 64k pixel coordinate space of X, so Pango needs to reject characters outside that coordinate space.
*** Bug 75933 has been marked as a duplicate of this bug. ***
Fixed for pangox and pangoxft. It's not clear to me whether the Win32 backend will need a similar fix or not; probably easiest just to check by simply inserting a lot of characters (C-a C-x C-v C-v C-v C-v and repeat...) and seeing if wrapping occurs. Fri Dec 6 23:07:58 2002 Owen Taylor <otaylor@redhat.com> * pango/pangoxft-font.c (pango_xft_real_render) pango/pangox.c (pango_x_render): Roughly clip glyphs into the X coordinate area to avoid wrap-around. (#73199)
The fix I went for, btw, was very simple -- just: PangoGlyph glyph = glyphs->glyphs[i].glyph; int glyph_x = x + PANGO_PIXELS (x_off + glyphs->glyphs[i].geometry.x_offset); int glyph_y = y + PANGO_PIXELS (glyphs->glyphs[i].geometry.y_offset); /* Clip glyphs into the X coordinate range; we really * want to clip glyphs with an ink rect outside the * [0,32767] x [0,32767] rectangle but looking up * the ink rect here would be a noticeable speed hit. * This is close enough. */ if (glyph && glyph_x >= -16384 && glyph_x <= 32767 && glyph_y >= -16384 && glyph_y <= 32767) We could do better here frequently ... GTK+ will know an much better clip (the paint region) in most cases. Not sure if adding API to do provide that information would make sense: - The the need to compute ink rectangles would slow down drawing in the case where there ends up being no clipping. (Which is common.) - But there is clipping in such cases as exposes of a text view -- the entire paragraph is always drawn. - Or maybe Xft should be doing the clipping? GTK+ already provides it with the clip rect; providing Pango with the clip rect in addition seems like doing extra work. (I note that ExtTextOut on Win32 takes an optional clipping rectangle)
Yup, similar problem occurs on Win32 backend, too. After pasteing in about 6000 characters into testgtk's Entry test, the entry doesn't display anything any longer. No warning messages, though. Will have to think about a suitable patch for pangowin32.c, it doesn't seem to be quite that straightforward.
Tor, can you update us on this?
Well, an GtkEntry widget certainly still starts behaving strangely on Win32 after you input ridiculously large amounts of text in it. (Checked against gtk 2.8 and Pango 1.10.) I don't see any ** CRITICAL ** messages any longer, though. WONTFIX?
WONTFIXing for now...