GNOME Bugzilla – Bug 588076
Gnumeric fonts stopped working on upgrading gtk+ 2.17.2 -> 2.17.3
Last modified: 2009-07-24 21:27:36 UTC
Please describe the problem: Please see bug 588025. Basically fonts in Gnumeric have stopped working for the spreadsheet cells when I upgraded. The gnumeric folks think that it's a gtk+ issue. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Without further data, hard to say. Always easy to pass the blame...
I've got everything built with debugging symbols. Any suggestions where to look?
No idea, offhand. Just tried gnumeric here, and it works fine for me.
I just reverted to gtk+ version 2.17.2. Things work as before. This is expected, but does confirm that it was the gtk+ change that triggered the problem (and not some other change).
It is not unlikely that 2.17.3 causes your problem. After all, it contains the csw merge, which is a pretty fundamental change. However, I don't see the problem with current git (there have been some csw fixes post-2.17.3). Alex, do you think this could be a csw issue ?
"Without further data, hard to say. Always easy to pass the blame..." Well, when you change only X and things break, chances are that X is related to the problem.
Its not unlikely that some rendering may disappear, as there is a lot of changes wrt clipping and if the clipping goes wrong things will disappear. However, its not something I would expect to happen, although I don't know the details wrt how gnumeric renders its cells. I don't have gnumeric installed atm and the network is to slow to download it here so I can't test it myself. Does it only happen with text?
I got gnumeric 1.8.4 installed, and I don't see this problem either.
I'm running gnumeric-1.9.9. It seems to happen only with text, specifically with the text in the cells. Button labels are fine. I'll attach a screenshot. David
Created attachment 138119 [details] Screenshot showing problem The A1 cell should show 123. In addition the rows labels are all blank--they shoud be 1, 2,.... Other text is fine.
The missing text in in a foocanvas, far, far larger the 32k that xlib supports. If gtk+ still emulates 2G pixel coordinates, something might be up there. Pure speculation, though.
We don't emulate 32bit coords/sizes on native windows anymore (i.e. for a toplevel), but for non-native children we do everything in 32bit on the client, so there is no need for the old emulation code. Still, it could be related to window size somehow, as thats not tested as much.
I just tried gtk+ 2.17.4; not surprisingly, the problem is still present.
Gnumeric still doesn't work with gtk+ 2.17.5 .
Not need to comment on every bug we didn't fix, for every release we do. If this bug gets fixed, it will be closed, and you will notice. Thanks for cooperating in keeping my bugspam at an acceptable level.
The issue is not present in gnumeric-1.8/goffice-0-6 No obvious changes in either code base (foocanvas, gnm-pane, item-grid).
reproduced in gnumeric master with gtk-trunk Seems related to the increase in max sheet size coupled with the client-side windowing patch 1.8 : foo_canvas_set_scroll_region (... x2=1,000,000, y2=6,000,000) at foo-canvas.c:3027 1.9 : foo_canvas_set_scroll_region (... x2=1,600,000, y2=1,536,000,000) Shrinking GNM_PANE_MAX_Y back to 6e6 restores things. Additionally, cell content and row headers, re-appear around row 52050 or so(one needs to scoll past it, the go back up to see the headers disappear). The Y coordinates don't seem like any familiar magic numbers. $3 = {x = 0, y = 884878, width = 60, height = 17}
There may be another patch involved that fixed the misplacement of certain tooltips.
That had to do with bug #586590.
Setting GNM_PANE_MAX_Y to 394264450 breaks, but 394264449 works. 394264450 in binary is 10111011111111111111110000010, thats got bit 29 set which is pretty large, but its not really an "even" binary power, so it seems weird. It seems to affect text mostly, but also the "column selection rectangles" seem to be missing some parts.
The pane window gets positioned at y = 126, which means that y + height == 394264576 == binary 10111100000000000000000000000. That makes slightly more "sense" in terms of magical numbers, but still kinda weird.
Could this be a signed/unsigned int problem? Also, grepping the gnumeric sources shows (in src/gnm-impl.h) that #define GNM_PANE_MAX_X 1600000 #define GNM_PANE_MAX_Y 1536000000 Should they be defined as unsigned, e.g., #define GNM_PANE_MAX_Y 1536000000U Also are you suggesting (comment #17) that setting GNM_PANE_MAX_Y to 6e6 fixes the problem?
RE: last part of comment #17: setting GNM_PANE_MAX_Y to 6e6 does indeed "fix" the problem.
Fixed by commit a504784b4b458d32e770cab3c0e48229552652a5
I applied the patch for a504784b4b458d32e770cab3c0e48229552652a5 to to 2.27.4 gtk+ tarball and rebuilt (reverting any changes I'd made to gnumeric). The problem is solved. Thanks!