Launchpad has imported 4 comments from the remote bug at http://qa.openoffice.org/issues/show_bug.cgi?id=105759.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-10-09T12:42:01+00:00 Mark Wilby wrote: Report uploaded from Bug #429232 on Launchpad. https://bugs.launchpad.net/openoffice/+bug/429232 When exporting to eps format image files. The clipping path for the image is set incorrectly. The correct clipping path is set at the beginning of the document body, but it is then replaces after a graphics save with a path that is not shifted by the (1000, 1000) offset for the general coordinate system. This path is followed by the correct one (for no apparent reason as it has already been set). However the clipping paths combine to cause the bottom strip and the far right strip of the image not to be drawn. Attached to oriiginal bug report (https://bugs.launchpad.net/openoffice/+bug/429232) are two eps files. The one called test.eps is the original and the one called testFixed contains a comment around the problem lines and comments out the problem so the image draws properly. The files are small, but simply search for "*****" Issue still exists issue with the new version in Ubuntu 9.04 with the ppa at https://launchpad.net/~openoffice-pkgs/+archive/ppa The problem that was around the following two lines 0 0 m 27692 0 l 27692 19005 l 0 19005 l 0 0 l eoclip newpath 0 1000 m 28693 1000 l 28693 20006 l 1000 20006 l 1000 1000 l eoclip newpath has been replaced with 0 0 m 27692 0 l 27692 19005 l 0 19005 l 0 0 l eoclip newpath So the output code has been modified, but the wrong line was removed. Actually, both lines are wrong, but the second one does no damage to the visible region. The clipping path above need to be translated by (1000, 1000) to work properly 1000 1000 m 28692 1000 l 28692 20005 l 1000 20005 l 1000 1000 l eoclip newpath This is set at the beginning, so its really not needed here. Assuming its there for some sort of performance reason, it should match the objects that are drawn in that group: I noticed that the incorrect cutting path is regenerated at the end of the file. Maybe this is in preparation for some other group of objects, but I don't know. Reply at: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/429232/comments/6 ------------------------------------------------------------------------ On 2009-10-12T08:17:45+00:00 Wolframgarten wrote: Reassigned. Please have a look at this. Reply at: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/429232/comments/7 ------------------------------------------------------------------------ On 2016-10-24T21:49:16+00:00 Knmc wrote: Need someone familiar with the draw code to see if this is still an issue Reply at: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/429232/comments/9 ------------------------------------------------------------------------ On 2018-11-26T18:51:26+00:00 Knmc wrote: No replies in over a yesr closing as obsolete Reply at: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/429232/comments/10 ** Changed in: openoffice Status: New => Expired ** Changed in: openoffice Importance: Unknown => Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/429232 Title: [upstream] openoffice eps export sets incorrect cutting path To manage notifications about this bug go to: https://bugs.launchpad.net/openoffice/+bug/429232/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
