GNOME Bugzilla – Bug 403403
Series lines are plotted with integer width
Last modified: 2007-03-07 21:12:01 UTC
When plotting a graph, the width (thickness) of series lines is rounded to the nearest integer. This does not give an accurate sense of what the graph will look like when exported to SVG, and gives you very little control over apparent line thickness on the screen. (1.4 is rounded to 1.0 on screen; 1.5 is rounded to 2.0.)
PS I suspect that the same is true for other graph attributes too, although I haven't tested this.
You're right rounding should not happen for series line width (except perhaps when using step interpolation). On the same subject, I think the actual line width for hairlines in PS/PDF/SVG export need to be increased a little.
Yes, that is how I ran into this (I had to manually increase the width of lines that were being printed out on a highres printer). There are a number of attributes that are exported with width zero (e.g. the border around the chart). Looks fine on screen e.g. in Acrobat Reader, but you print it and the line almost disappears. I don't remember what the default width for series is, but it's not thick enough. On a related note, the stroking of lines uses dashes that are far too long when plotting with non-default line widths (e.g. with a width of 2). You can't even distinguish most of the stroke styles in the legend. I think this scales linearly with stroke width.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.
Just checked out HEAD from svn, and I noticed that this works well, but the line width shown in the legend is thinner than the width shown in the graph. Additionally the legend still seems to be using integer stroke width. Otherwise it looks great.
That's the intended behaviour. Width of legend line samples are scaled in order to always shown at least 1.5 dash sequence, or to not exceed 0.5 of the legend text font size. We've already been using the same mechanism for legend markers. And line width is rounded for a better and sharp screen rendering. If we don't do that, they look blurry.
Luke, if you have some examples where the current legend rendering produce something not acceptable, don't hesitate to reopen this bug.
I understand the concern that two complete repeats need to be shown in the legend, and that the legend will end up quite wide for thicker lines if the legend versions are not drawn thinner. There are a few problems with this: -- The legend should show as nearly as possible *exactly* what is shown on the graph, so that it makes it easy to find a series by name or a name for a series. (This includes data point markers too, not just lines.) Not a problem when you have just one or two series, but it is confusing when you have many series and need strong visual cues to help you figure out which series is which. I will attach a screenshot of this. You can figure it out by counting dots and dashes, but the correlation doesn't jump out at you when there is a lot going on in the graph. -- In general the series lines in the legend just look spindly and wrongly-drawn because they don't match the graph. -- Printing and exporting to SVG currently works as I would expect it to (the legend lines show exactly what's on the graph). I hesitate to report this as a bug, because this gives me the graphs that I need :) However it is a bug by your definition. Also series lines are saved to the .gnumeric file with integer width, so there are still more things that need to be changed to float. (I would report this as a separate bug but it's not totally off-topic.)
Created attachment 83689 [details] Screenshot of gnumeric with more complicated chart
Created attachment 83690 [details] The chart exported as SVG and displayed in Inkscape.
By the way in the second attachment above, I made one change -- aligning the series lines vertically with the nearest pixel boundary. The lines don't look fuzzy that way. You can get away with most of the fuzziness by just aligning one edge of the line with the nearest coordinate boundary, you don't need to constrain the line width to be an integer.
Note that attachment 83694 [details] on another bug gives an example of why rounding line thicknesses (or, in general, displaying a different line on the chart and in the legend) is not a good idea. The first series looks very different in the legend and on the chart. (It's not a particularly good graph, because the first and third series look similar on the chart, and because the series overlap at different points, but the point is that the legend is supposed to give you a key to the series, so they should exhibit a high degree of visual similarity.)
>The legend should show as nearly as possible *exactly* what is shown on the >graph, so that it makes it easy to find a series by name or a name for a >series. (This includes data point markers too, not just lines.) The legend should show what's on the graph, but not necessarly at the same scale. >I will attach a screenshot of this. You can figure it out by counting >dots and dashes, but the correlation doesn't jump out at you when there is a >lot going on in the graph. I don't think this graph is a good example of an issue with legend line width. The relation between legend line and serie line is pretty obvious for me. But it looks like there's an issue with the line rounding here I'll try to fix. Could you attach the original gnumeric spreadsheet, please ? >Also series lines are saved to the .gnumeric file with integer width, so there >are still more things that need to be changed to float. (I would report this >as a separate bug but it's not totally off-topic.) Good catch. I'll fix that. >By the way in the second attachment above, I made one change -- aligning the >series lines vertically with the nearest pixel boundary. The lines don't >look fuzzy that way. You can get away with most of the fuzziness by just >ligning one edge of the line with the nearest coordinate boundary, you >don't need to constrain the line width to be an integer. Coordinate snapping + witdh rounding helps to keep black line black. >Note that attachment 83694 [details] [edit] on another bug gives an example of why >rounding line thicknesses (or, in general, displaying a different line >on the chart and in the legend) is not a good idea. Could you attach the orignal spreadsheet file ?
I hope the last fix I've just pushed completely fix this bug. http://svn.gnome.org/viewcvs/goffice?rev=1698&view=rev
Thanks, will try it out soon. I would like to offer one more suggestion -- can you have a scale setting for the graph legend, so that it is possible to have it displayed at 100% if necessary?
I just pulled down the latest from SVN and for some reason it's still saving with integer line width.
I've checked and it saves float line width. Please make sure you have correctly compiled and installed the latest version.
Created attachment 84121 [details] A sample file with correct float line width
Just tested it with the file you sent, and it is rounding to the nearest integer on save. I am building revision 15447 with jhbuild. This appears to be the most recent revision in SVN unless I'm missing something: $ svn info Path: . URL: http://svn.gnome.org/svn/gnumeric/trunk Repository Root: http://svn.gnome.org/svn/gnumeric Repository UUID: ec6d7d6d-c725-0410-81a0-85871e0155c4 Revision: 15447 Node Kind: directory Schedule: normal Last Changed Author: mortenw Last Changed Rev: 15447 Last Changed Date: 2007-03-06 11:28:28 -0500 (Tue, 06 Mar 2007) I just did a "make clean" and re-did the "jhbuild buildone gnumeric", but to no effect. Help->About gives v.1.7.9. Also: "jhbuild run gnumeric -v" gives gnumeric version '1.7.9' datadir := '/opt/gnome2/share/gnumeric/1.7.9' libdir := '/opt/gnome2/lib/gnumeric/1.7.9' so I know I'm running the version I just compiled.
The fix is in goffice. That's the one that needs un update.
Of course. Sorry for the oversight. It looks like everything works great now. Thanks for all your work on this!