After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645938 - image exported to .png is truncated
image exported to .png is truncated
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: Graphing / Charting
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jean Bréfort
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-03-28 13:09 UTC by Frédéric Parrenin
Modified: 2012-01-12 21:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the .gnumeric file to reproduce the problem (2.32 KB, application/x-gnumeric)
2011-03-28 13:09 UTC, Frédéric Parrenin
Details

Description Frédéric Parrenin 2011-03-28 13:09:26 UTC
Created attachment 184450 [details]
the .gnumeric file to reproduce the problem

Steps to reproduce the problem:
- open the attached .gnumeric file
- right-click the graph and go to 'export as image'
- choose png as format
- open the saved file with, e.g. eog
=> the right part of the image is truncated
Comment 1 Andreas J. Guelzow 2011-03-28 13:47:43 UTC
I would think that this is related to the size of the image: 5594 pixels wide.
Comment 2 Frédéric Parrenin 2011-03-28 13:49:43 UTC
The truncation depends on the chosen resolution for the image, so it is like there is a size-limit.
Comment 3 Andreas J. Guelzow 2011-03-28 14:04:26 UTC
The "resolution" just changes the size of the resulting png. It seems that the problem appears when the resulting width is over 15000.
Comment 4 Morten Welinder 2011-03-29 17:51:22 UTC
I have verified that the pixbug in-memory is wrong, i.e., saving is not
the culprit.  Current suspect:

#define GO_CAIRO_CLAMP(x) CLAMP((x),-15000,15000)
Comment 5 Andreas J. Guelzow 2011-05-23 14:12:16 UTC
Changing GO_CAIRO_CLAMP to -5000 to 5000 it is easy to see that this is indeed the culprit. (The purpose of GO_CAIRO_CLAMP is to avoid the cairo limitation of 16 bit coordinates. Perhaps this should be handled by scaling the coordinates rather than truncating them.
Comment 6 Jean Bréfort 2011-05-27 20:33:19 UTC
Scaling the coordinates for vectorial formats export makes sense. For bitmaps, I think the best is to not accept to export so large images.
Comment 7 Jean Bréfort 2011-05-27 21:06:01 UTC
Strange, changing GO_CAIRO_CLAMP(x) to just (x) makes things apparently work.
Comment 8 Andreas J. Guelzow 2011-05-27 21:24:25 UTC
Well, it looks to me like most of this is done in doubles anyways. So having large values one would just loose resolution which of course is hardly visible...
Comment 9 Jean Bréfort 2011-05-28 09:30:07 UTC
I'm not sure about that. The canvas use very large coordinates in extreme cases. I tested with 16M rows, 1000 pixels high each, and I did not see any resolution loss. I did not read all cairo code to see what was done using double or cairo_fixed_t coordinates.
Actually cairo_fixed_t is a 24,8 structure, not 16,16, so it seems it can support up to 8M pixels. Of course, I might be full wrong. Just the 15000 limit seems weird. 16 bits allow for 32K.
Comment 10 Andreas J. Guelzow 2011-06-16 17:59:56 UTC
I think we really should change this to 8M. The 15000 limit is to small!
Comment 11 Jean Bréfort 2011-06-16 18:08:03 UTC
Agreed.
Comment 12 Jean Bréfort 2012-01-12 21:45:55 UTC
Done, crossing fingers.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.