Created attachment 47241 [details] test-eps-export.odg Downstream bug may be found at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/172779 OOo bug may be found at: http://openoffice.org/bugzilla/show_bug.cgi?id=76048 1) lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 2) apt-cache policy libreoffice-draw libreoffice-draw: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages apt-cache policy unoconv unoconv: Installed: 0.3-6 Candidate: 0.3-6 Version table: *** 0.3-6 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages 100 /var/lib/dpkg/status 3) What is expected to happen in LibreOffice Draw via the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/172779/+attachment/225258/+files/test-eps-export.odg && unoconv --listener && unoconv -f eps test-eps-export.odg && lodraw -nologo test-eps-export.odg test-eps-export.eps is that the two files look the same. 4) What happens instead is the .eps has white margins on the right and the bottom of the page, cropping the content. WORKAROUND: Select all the content and then export the selection.
[Reproducible] with "LibreOffice 3.4.0RC1 – WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:11)]". Same bad results with OOo 3.1.1: When I open exports with GhostView, I always see a much too big top margin, and export of complete page is truncated. OOo 3.1.1 also shows the "too big top margin" problem (when opened with GhostView), but no truncations when all page will be exported, with that version I do not see any difference between page export and selection export. With OOo 1.1.4 I see no difference between page export and selection export. Additional information: When I open the export results with LibO (only level 1 exports will be shown) no too big top margin (as visible with GV) will be visible.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Inappropriate NEEDINFO reverted to NEW
The bug is still reproducible with LibreOffice Draw 4.2 beta2 on Debian testing(“Jessie”) x86_64. The same behavior is for .png and .gif export with transparency (see bug 63334).
*** Bug 78981 has been marked as a duplicate of this bug. ***
I observe the same bug on Debian wheezy with the package version 1:3.5.4+dfsg2-0+deb7u2 It is more frustrating because the EPS thumbnail looks OK and the problem is only visible when you check the exported EPS itself. If the EPS is being exported for some third party (like a printing company) and the user doesn't open it themselves they may not realize it is bad.
Created attachment 110241 [details] test kit ODG drawing with and without margins and exported images An old filter issue. Still present in LODev 4.5.0.0alpha0+ affecting Draw export filter for .EPS, .PNG and .GIF, where image filter is mis-handling the margin details in calculating image size, and the margin values are then masking the image details on right and bottom edges. If Draw page setup is adjusted to 0.00" margins, then no cropping of the exported images (as .eps, .png or .gif) occurs. Other image format export filters render full image at 96dpi for whole draw document page including any margins. Test kit with examples attached.
*** Bug 63334 has been marked as a duplicate of this bug. ***
*** Bug 80362 has been marked as a duplicate of this bug. ***
Image types handling transparency seem to be affected with this sd filter issue.
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a68a7b831a5d1756ea9428e12bb89f69dc30950f fdo#37682 paint the right area It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
David Tardon committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a87db12c78d073dbfea50c833c25360285787054&h=libreoffice-4-4 fdo#37682 paint the right area It will be available in 4.4.0.0.beta3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On Windows 7 sp1, 64-bit en-US with Version: 4.5.0.0.alpha0+ Build ID: 629a705c127661111c54e14035b55850e36c2167 TinderBox: Win-x86@39, Branch:master, Time: 2014-12-10_07:01:18 Locale: en_US Verified fixed, margins are honored and images correctly sized, also checked examples from the duplicate bugs. All correct now. bug 63334 -- https://bugs.freedesktop.org/attachment.cgi?id=77674 bug 78981 -- https://bugs.freedesktop.org/attachment.cgi?id=99437 bug 80362 -- https://bugs.freedesktop.org/attachment.cgi?id=101533 Thanks David!