GNOME Bugzilla – Bug 149452
line width seems incorrectly initialized
Last modified: 2004-12-22 21:47:04 UTC
This bug is related to the use of gnome_print_setlinewidth. It seems the linewidth member of gnome print context is incorrectly initialized. If you draw severals lines with the following linewidth: 1.0 1.0 10.0 1.0 1.0 The first two lines won't have the same width as the last two. Apparently, as soon as we call gnome_print_setlinewidth with a width != 1.0, line width is correct. For example, as a workaround for this bug in gnumeric charting, I have a call to gnome_print_setlinewidth (ctx, 0.1). Bug occurs wathever the output is (screen or postscript).
Created attachment 30256 [details] Example in gnumeric chart without workaround All the lines and outlines are 1.0 width, exept the thickest one. Axis are drawn first, then polygons.
Created attachment 30257 [details] Same, with workaround
Well, this may not be an issue of intialization but of what gnome_print_setlinewidth is really doing. THe main code is: if (!GP_GC_EQ (width, ctx->linewidth)) { ctx->linewidth = (fabs (width * ctx->ctm[0]) + fabs (width * ctx->ctm[1]) + fabs (width * ctx->ctm[2]) + fabs (width * ctx->ctm[3])) / 2; ctx->line_flag = GP_GC_FLAG_CHANGED; } which by itself is already nonsense. GP_GC_EQ simply determines wheter the current line width and the new width are identical within epsilon. BUt then we are setting the new linewidth to a somewhat differnt value. So if linewidth starts with 1.0, nothin happens as long as we are trying to set it to 1.0, but after we have changed it to 10.0 then setting it to 1.0 will really set it to fabs (ctx->ctm[0]) + fabs (ctx->ctm[1]) + fabs (ctx->ctm[2]) + fabs (ctx->ctm[3])) / 2 which may not be 1.
Created attachment 30332 [details] [review] compare the transformed values Thanks andreas. This should fix that problem. I've applied this to head.
but apparently did not close the bug.