On Thu, May 28, 2009 at 12:36:05PM +0000, corvid wrote:

Johannes wrote:

...

On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote:

...

I tried looking at a stylesheet, but nothing displayed. It was a one-line document about 7k chars long.

It turned out that fltk::getwidth() calls XftTextExtents32() and the width comes back in a short, so it wrapped at 32k.

I chopped the line into 1k-long "words", and now I saw text, but once I made a line somewhere over 8k chars long, drawing would wrap and start at the beginning again. Everything looked all right in fltk::drawtext_transformed() as it called XftDrawString32()...

I have no idea whether this is something easy to deal with in some way, or a limitation in X...

Oh. This is extremely nasty. Yes, it is a limitation of X. And someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit coordinate space, but single drawing operations seem still to be limited in size, as they are directly mapped to their X counterparts.

The individual drawing requests weren't too big after splitting them up, so far as I could tell. I was trying

data = a_Misc_expand_tabs(Start + i - len, len); while (data->len > 1000) { char *s = dStrndup(data->str, 1000); DW2TB(dw)->addText(s, widgetStyle); dStr_erase(data, 0, 1000); dFree(s); } DW2TB(dw)->addText(data->str, widgetStyle);

where data had become a Dstr*.

That's fltk not checking the coordinates for 16bit overflow before passing it to XftDrawString32(). Of course one could argue that Xft should do that check. We probabely need to do it ourselfes in fltkviewbase.cc by adding checks for coordinates >= USHRT_MAX. But what is our general plan to fix these issues? I'd say in the long run we could try to make all the draw* methods in fltkviewbase.cc work properly with arbitrary int coordinates by breaking them down to equivalent (as far as the visible area is concerned) drawrequests with smaller coordinates. Cheers, Johannes