Created attachment 111858 [details] .odg file to reproduce the bug Steps to reproduce: - open the attached .odg file - select the graphic - export it to svg - open the exported .svg file => the graphic is truncated
Created attachment 111862 [details] SVG exported from 4.4.0.1 @Frederic, Thanks for posting, but not seeing an issue with Windows 7 sp1, 64-bit en-US and a current build of master Version: 4.4.0.1.0+ Build ID: 9ca0a30de75b0b563c95c6ff8863b1c4f7ed1c6b TinderBox: Win-x86@51-TDF, Branch:libreoffice-4-4, Time: 2014-12-25_11:49:22 Locale: en_US Have attached resulting SVG export from that version. Please provide details of your version of LibreOffice and OS. Perhaps a screen clip of the SVG showing what is being truncated.
Comment on attachment 111858 [details] .odg file to reproduce the bug adjusted MIME type
Comment on attachment 111862 [details] SVG exported from 4.4.0.1 4.4.0.1 rather than 4.5.0 master
Created attachment 111863 [details] .odt file with the .svg image imported
I use 4.3.4.1 on debian 7.
@Frederic, Can not reproduce on Widnows 7 sp1, 64-bit en-US with Version: 4.3.4.1 Build ID: bc356b2f991740509f321d70e4512a6a54c5f243 The .ODG opens and the exported SVG is fully formed and inserts correctly into a Writer .odt. Perhaps have a go with a clean user profile? Simply, move or delete the old one. Ref here: https://wiki.documentfoundation.org/User_Profile
I have tried with a clean user profile but the problem is still there. I am now on Debian 8 with LibreOffice 4.3.3.2. Maybe this is a linux-specific bug?
On Fedora 21, 32-bit w/LXDE No issues with exported SVG being cropped with current master Version: 4.5.0.0.alpha0+ Build ID: c3087d969671e62182eb049850479e77190ccff4 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-22_02:33:12 Locale: en_US nor with 4.3.6.2 release RPM Version: 4.3.6.2 Build ID: d50a87b2e514536ed401c18000dad4660b6a169e So, it could be an issue unique to your Debian distro. Will bump the QA and Users ML
Frederic, Any reason you are "selecting" poritions of the graphic? Normally, the whole ODG will be exported by default, adjust margins and image size using page settings and then simply export. So, it could be processing the "selected" checkbox that is causing the miscue. And, yup, just verified that on a Windows build of 4.4.2.1 pre-release. So suspect that to be the case on all the builds, setting NEW and adjusting summary.
STR 1. Create a graphic in Draw or use https://bugs.documentfoundation.org/attachment.cgi?id=111858 2. File -> Export: select type as SVG 3. verify SVG is full extent of Draw image 4. result -- correct bounding box for graphic and full extent of image. 5. As compared with... back in Draw, use same graphic 6. select graphic (left mouse drag to encompass entire graphic), results with 8 frame handles showing at edges of image and all Draw elements included--shown in Status bar. 7. File -> Export: select type as SVG select checkbox "selection" 8. result - SVG does not encompass full extent of selected graphic --Expected-- since the full graphic is selected, the resulting export to SVG would contain at least the same bounding box extents for the image portion as the full drawing exports. Instead portions of the graphic are being truncated, not all draw elements have been included in the new SVG.
V Stuart Foote, I am exporting only the selection to avoid margins. I am happy to see somebody is able to reproduce the issue.
Sorry, reading back my initial description, I now see I forgot to mention that I checked the "selection" option in the export dialog.
No, my fault. I routinely resize my Draw page and eliminate margins reducing size of the graphic down to what I want it to be--and then exporting the entire ODG. That works. What is not correct, and which I didn't consider is when selecting some number of Draw elements and then exporting just that selection. That is your usage but for the entire graphic, but would be an issue for any use case of some subset of Draw elements. Selection and export to SVG should honor the bounding/extent of what was selected. Export of selection to WMF, EMF, BMP all are correct--just the export to SVG is truncating right edge and bottom of extent. You can work around it as I'd been saying--but it is not otherwise correct handling (I suspect problem is in the creation of the SVG from the selected Draw elements, since the other vector formats are correct).
My system is Debian Wheezy 7.8 derivative as follows: $ inxi -Fxz System: Host: mx143 Kernel: 3.16.0-0.bpo.4-686-pae i686 (32 bit gcc: 4.6.3) Desktop: Xfce 4.12.0 (Gtk 2.24.10) Distro: MX-14.3 Symbiosis 03 December 2014 Machine: Mobo: ECS model: H61H2-CM v: 1.0 Bios: American Megatrends v: 4.6.4 date: 10/21/2011 CPU: Dual core Intel Pentium G620 (-MCP-) cache: 3072 KB flags: (lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10376 clock speeds: max: 2600 MHz 1: 1695 MHz 2: 1614 MHz Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller bus-ID: 00:02.0 Display Server: X.Org 1.12.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1440x900@59.9hz GLX Renderer: Mesa DRI Intel Sandybridge Desktop x86/MMX/SSE2 GLX Version: 3.0 Mesa 8.0.5 Direct Rendering: Yes Running LibreOffice version as follows: Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: en_US I duplicated the steps to reproduce: - open the attached .odg file - select the graphic - export it to svg - open the exported .svg file => the graphic is truncated and produced the attached truncated .svg graphic. I selected the graphic only without selecting the whole page. Geeqie refused to open it, Chrome crashed while Mirage opened the truncated graphic. Please advise any further tests or trials. Regards.
(In reply to Richard from comment #16) > Please advise any further tests or trials. > Regards. Thanks. Only thing might be to confirm that export of the complete ODG, i.e. no selection of Draw elements, results in correctly formed SVG showing entire page and margins. Also, might check that WMF or EMF export when selecting Draw elements is well formed--suspect it will be.
Created attachment 114276 [details] truncated graphic produced from Debian 7.8 truncated graphic for comment by Richard.
Created attachment 114277 [details] truncated *.emf export
Created attachment 114278 [details] truncated *.wmf graphic
@Richard, * So, looking at the WMF and EMF attachments, https://bugs.documentfoundation.org/attachment.cgi?id=114277 https://bugs.documentfoundation.org/attachment.cgi?id=114278 both are correctly exported vector renderings of the selected Draw elements on Debian. And the issue is isolated to export filtering of selected Draw elements into SVG. Thanks.
@Stuart, My apologies, no. Both images are in error. Confused with other work I was doing at the time for the school. :( **Both** images, the *.emf and the *.wmf were truncated. If you can delete them, they are not germane to the discussion, since they are just forms for the school psycologist. :(
(In reply to Richard from comment #22) > Both images are in error. Confused with other work I was doing at the time > for the school. :( > > **Both** images, the *.emf and the *.wmf were truncated. > But they are not, they are both correct in extent. In each the selected Draw elements, only with no margins, are rendered into useable vector images on export to WMF or EMF--exactly what is selected is what is rendered.
OK, wrong choice of words. :) Both images are not the same images that I exported. They somehow got picked up when I selected the my exported images. I'll try again to upload the images that I exported, not the ones of the Spanish psychologist of reasons. The original in the odg exported correctly as a PNG. but incorrectly when exported as SVG, EMF, WMF The SVG that the OP uploaded is truncated also, but not in the ODG. Uploading my PNG of the image in the ODG. and also the truncated exports of SVG, WMF and WMF.
Created attachment 114279 [details] PNG correctly exported, shows the original image in the ODG
Created attachment 114280 [details] SVG truncated by export from ODG to *.SVG
Created attachment 114281 [details] EMF truncated by export from ODG to *.EMF
Something weird is happening when I try to upload. Some of them represent the correct file I'm trying to upload; others, that silly MOTIVOS form from the psychologist. What I actually saw is as follows: 1. The "SVG exported from 4.4.0.1" as above represents the original graphic in the ODG. 2. The "PNG correctly exported", shows the original image in the ODG, is the same as the original. Export from Draw functions correctly to PNG. 3. The "truncated graphic produced from Debian 7.8" represents the truncation that I saw when exporting the original image to SVG, to EMF and to WMF. So far, only PNG exports correctly. Apologies for the upload problem, may be my connection. I got an upload error a few times and restarted Chrome; something must have stayed in the cache?
Responding to request on libreoffice-qa mailing list... Able to reproduce truncation in recent master 4.5.0.0 build running on 32 bit Ubuntu 12.04. Did select all and exported selection to SVG [checked the box and selected SVG file type]. Reopening the SVG in Draw shows the full graphic, but it is missing the text labels above the cylinders. Opening the SVG in Firefox shows a partial image that (exactly?) matches the truncated SVG in attachment #4 above -- https://bugs.documentfoundation.org/attachment.cgi?id=114276 In other words, the exported SVG shows the upper left corner of the original and includes the text labels. Perhaps more interesting and useful: The export to SVG process printed over 50 of the following warnings in the soffice terminal/shell window... warn:legacy.osl:6220:1:filter/source/svg/svgwriter.cxx:3559: SVGActionWriter::ImplWriteActions: unsupported MetaAction # Hope that helps.
*** Bug 90017 has been marked as a duplicate of this bug. ***
This seems to have been tangentially fixed on bug 56467 by http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a4e9138281bd0a4be59031357c1bf52134d007a (The two are not otherwise related, so let's not duplicate one onto the other) As investigated on bug 90017, the issue was introduced by http://cgit.freedesktop.org/libreoffice/core/commit/?id=f864c09a9d6bc2c28b30b32c6a0825b5628826b2
(In reply to Matthew Francis from comment #31) > This seems to have been tangentially fixed on bug 56467 by > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=0a4e9138281bd0a4be59031357c1bf52134d007a > (The two are not otherwise related, so let's not duplicate one onto the > other) > > As investigated on bug 90017, the issue was introduced by > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=f864c09a9d6bc2c28b30b32c6a0825b5628826b2 Reopening and back to NEW Unfortunately, just checked recent daily on Windows 7 sp1, 64-bit, en-US Version: 4.5.0.0.alpha0+ Build ID: 3c6fd5a59b08cec8705a31d17a60204acf6b7173 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-29_02:04:01 Locale: en_US and with the patch included http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a4e9138281bd0a4be59031357c1bf52134d007a export to SVG (with Selection checked and a selection made) is now completely empty. Suspect something is very off with the bounding viewBox of the selection at this point. Export of the full canvas to SVG works otherwise.
(In reply to V Stuart Foote from comment #32) That's unfortunate if so, but are you sure it's related? Since that commit, Linux has exported the bug docs from both this bug and bug 90017 correctly (as selections) Could this be a different, Windows specific bug introduced at a different time - I don't have Windows, so no way I can check
(In reply to Matthew Francis from comment #33) > That's unfortunate if so, but are you sure it's related? Since that commit, > Linux has exported the bug docs from both this bug and bug 90017 correctly > (as selections) > > Could this be a different, Windows specific bug introduced at a different > time - I don't have Windows, so no way I can check Reasonably sure it got clobbered with the commit. Bisect looking at parallel /A installs from TB62, pulled a few to bracket the commit. Some elements in SVG are rendered -- but truncated Version: 4.5.0.0.alpha0+ Build ID: 0b0dbd64bb589a6f0ab981f9740fff1dc500a055 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-23_23:15:13 Locale: en_US Version: 4.5.0.0.alpha0+ Build ID: 8c3cf9dd48e40604867d3a28bddaccd65142df17 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-27_15:15:18 Locale: en_US and no elements are visible in the SVG Version: 4.5.0.0.alpha0+ Build ID: 02bea75dd6bc91759e987fafb5dccec6ce92b0c2 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-28_00:30:19 Locale: en_US Version: 4.5.0.0.alpha0+ Build ID: 3c6fd5a59b08cec8705a31d17a60204acf6b7173 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-29_02:04:01 Locale: en_US
Sorry, here is the cgit pull for the bisection. http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8c3cf9dd48e40604867d3a28bddaccd65142df17..02bea75dd6bc91759e987fafb5dccec6ce92b0c2 The "tdf#56467: improve export of formulas to SVG" patch kind of stands out as related.
(In reply to V Stuart Foote from comment #32) > export to SVG (with Selection checked and a selection made) is now > completely empty. Suspect something is very off with the bounding viewBox of > the selection at this point. Export of the full canvas to SVG works > otherwise. This was incorrect. With the patch applied: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a4e9138281bd0a4be59031357c1bf52134d007a The selection export to SVG is not empty--it just does not render correctly when viewed with FireFox or Inkscape. The extent and bounding of the selection export to SVG is correct. But, as in bug 56467#c10, the viewer used does matter. There is some additional work needed--looks like there is now an extra tspan TextPosition class being embedded into the selection export to SVG that causes FireFox and Inkscape issues. Other viewers seem more tolerant. But, otherwise the extent and bounding of a selection exported to SVG is now correct. Back to Resolved Fixed
*** Bug 90432 has been marked as a duplicate of this bug. ***
Just made a duplicate bug report and immediately after discovered this issue. Anyway, I should bring up one observation from my report, that seems to be the reason for the rendering issues when clipped svg-pictures are viewed with FireFox or Inkscape. The "clip-path"-attribute in the root svg-element is redundant, because the element: <g id="id1" class="Slide" clip-path="url(#presentation_clip_path)"> , contains it also. I think it should not be in the root element. If you remove it from the root svg-element, the picture is displayed correctly in Firefox and Inkscape.
See discussion by devseppala in https://bugs.documentfoundation.org/attachment.cgi?id=114579 @Christina R., would devseppala's note from comment 38 (and bug 90432) also be applicable to work still needed for bug 56467? Back to NEW.
In an effort help to solve the Inkscape and Firefox issue looked at the SVG specification: http://www.w3.org/TR/SVG11/masking.html#InitialClippingPath I struggle to understand it all, but it would seem that setting the initial clipping path is something of an special case. While clip-path is a valid property of the svg-element, the specification does seem to suggest that the clip-property should be used instead of the clip-path to set the initial clipping path. "To set the initial clipping path to the bounds of the ‘viewBox’, set the bounds of ‘clip’ property to the same rectangle as specified on the ‘viewBox’ attribute. (Note that the parameters do not match. ‘clip’ takes values <top>, <right>,<bottom> and <left>, whereas ‘viewBox’ takes values <min-x>, <min-y>, <width> and <height>.)" However, I played a little with the clip-property and it seemed to have no effect with Firefox. I'm not sure if the current way is wrong, but removing "clip-path"-attribute from the root svg-element does make the picture show up correctly in Firefox and Inkscape.
Chr. Rossmanith committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1e9bbd1bf0eda05c8474c49581fdaeace6689ae1 tdf#56467 / tdf#88117: SVG export further improved It will be available in 5.0.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.
@Christina, this looks correct now on master, Inkscape and Firefox now correctly rendering exported SVG. Will you be backporting to 4.4? On Windows 7 sp1, 64-bit en-US Version: 4.5.0.0.alpha0+ (x64) Build ID: 6ab69492b7dfb0ef0016f442e7b249c2723a5110 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-11_16:54:51 Locale: en_US
Chr. Rossmanith committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4542e5bd0a9b3838794c72becd1f7caa41846c07&h=libreoffice-4-4 tdf#56467 / tdf#88117: SVG export further improved It will be available in 4.4.3. 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.
Chr. Rossmanith committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5e66bd5702b626bf170b46bbaa3c0eacb45de9c tdf#56467 / tdf#88117: SVG export further improved It will be available in 5.0.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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]