GNOME Bugzilla – Bug 742982
Incorrect rendering of axis label
Last modified: 2018-05-22 14:15:37 UTC
Created attachment 294607 [details] .xlsm file to reproduce the problem Steps to reproduce: - open the attached .xlsm file - observe the Y-axis label on the left => "Taux" "de" "C-" and "G" are on 4 different lines, while it should be on the same line.
Note also on the same example that the lines are drawn on the chart for each serie, while there is no line when opened in XL.
Note also that the font size for the title of the chart is 18 in XL while it is 10 in gnumeric.
Note also that the chart title and axes titles are in bold in XL but they appear in normal font in gnumeric.
Note also that the legend has no outline in XL but it has one in gnumeric.
Created attachment 294608 [details] screenshot of the chart as it appears in gnumeric
The chart import from xlsx is far from perfect.
The Y-axis title problem does not appear to be related to import. The "Display on several lines if needed" flag is checked. For some reason that makes us put only one word per line here.
I think the problem is in gog_text_view_render which does: double w = text->allow_wrap? view->residual.w: -1.; This is correct for text that isn't rotated. For text that is rotated 90 degrees (either way), residual.h would be right, I think. For rotation that isn't axis-parallel, it's a bit trickier. The smaller of the restriction imposed by h and w.
Created attachment 294624 [details] [review] Proposed patch Something like this.
Independently, we should probably be writing go_sinpi (foo / 180) instead of sin (foo / 180 * M_PI) The former will not have rounding errors for foo=90, for example. We could make a go_sindeg to avoid having that 180 in several places.
Note that this bug is closely related too bug #705313 "Improve chart import from XLSX".
Created attachment 294702 [details] Graph as seen in XL2010 Reference image
Regarding font size: the file does not, as far as I can tell, specify the font size (or any font properties for that matter) to be used for the title. That means, I believe, that whatever we do it won't be actually wrong.
Hmm, I understand the issue, but the patch is not correct, (it is actually correct for both horizontal and vertical text, but not for oblique which is a much more complicated issue). Seems I did not do things correctly when I introduced manual widths for labels. The manual width is for the non rotated width, so the width after rotation must be evaluated in all cases. The layout code clearly needs a lot of attention, not sure things can be fully fixed without breaking the API.
Can pango even fully handle the problem of restricting an arbitrary rotated layout to a axis-parallel bounding box? That would require lines with different lengths. What my patch does ought to be correct for the 0,90,180,... cases as well as the single-line cases. Should we commit that (with a comment saying that the general cases isn't right)?
Morten, your patch would break the multiline labels in gnumeric because we can just set the width, not the height. The best place to fix such an issue is in the importer, at least for now. The more I think about it, the more I believe that the chart code would benefit from an almost complete rewrite, but that would need new blood.
On the git version as of today, I saw that the axis rendering has improved since it is no longer displayed on several lines. However, it is now rotated 180°, so there seems to be a regression.
Created attachment 295511 [details] screenshot of the graph guru with Y axis label rotated 45°
Again the situation has improved since the text of the Y axis label is now displayed correctly. However, I noticed a problem: when the text is rotated 45°, it exceeds its frame. See attached screenshot.
This is known. Rotated text is going to be a bit rough around the edges for a while.
I don't see any issue with this .xlsx file anymore. Maybe we can mark the bug as fixed?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/270.