Bug 88117 - Selected Draw elements are truncated in bounding and extent when exported to SVG
Summary: Selected Draw elements are truncated in bounding and extent when exported to SVG
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
QA Contact: Christina Rossmanith
URL:
Whiteboard: target:5.0.0 target:4.4.3
Keywords: bibisected, bisected, regression
: 90017 90432 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-06 16:15 UTC by Frederic Parrenin
Modified: 2015-12-17 08:43 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
.odg file to reproduce the bug (24.80 KB, application/vnd.oasis.opendocument.graphics)
2015-01-06 16:15 UTC, Frederic Parrenin
Details
SVG exported from 4.4.0.1 (88.00 KB, image/svg+xml)
2015-01-06 17:40 UTC, V Stuart Foote
Details
.odt file with the .svg image imported (52.13 KB, application/vnd.oasis.opendocument.text)
2015-01-06 17:58 UTC, Frederic Parrenin
Details
truncated graphic produced from Debian 7.8 (87.88 KB, image/svg+xml)
2015-03-23 16:45 UTC, Richard
Details
truncated *.emf export (121.27 KB, image/x-emf)
2015-03-23 16:57 UTC, Richard
Details
truncated *.wmf graphic (180.58 KB, image/x-wmf)
2015-03-23 16:58 UTC, Richard
Details
PNG correctly exported, shows the original image in the ODG (73.50 KB, image/png)
2015-03-23 18:09 UTC, Richard
Details
SVG truncated by export from ODG to *.SVG (87.88 KB, image/svg+xml)
2015-03-23 18:10 UTC, Richard
Details
EMF truncated by export from ODG to *.EMF (121.27 KB, image/x-emf)
2015-03-23 18:12 UTC, Richard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Parrenin 2015-01-06 16:15:12 UTC
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
Comment 1 V Stuart Foote 2015-01-06 17:40:40 UTC
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 2 V Stuart Foote 2015-01-06 17:44:27 UTC
Comment on attachment 111858 [details]
.odg file to reproduce the bug

adjusted MIME type
Comment 3 V Stuart Foote 2015-01-06 17:46:07 UTC
Comment on attachment 111862 [details]
SVG exported from 4.4.0.1

4.4.0.1 rather than 4.5.0 master
Comment 4 Frederic Parrenin 2015-01-06 17:58:56 UTC
Created attachment 111863 [details]
.odt file with the .svg image imported
Comment 5 Frederic Parrenin 2015-01-06 17:59:26 UTC
I use 4.3.4.1 on debian 7.
Comment 6 V Stuart Foote 2015-01-06 20:46:09 UTC
@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
Comment 7 Frederic Parrenin 2015-03-23 09:45:00 UTC
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?
Comment 8 Frederic Parrenin 2015-03-23 09:45:44 UTC
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?
Comment 9 Frederic Parrenin 2015-03-23 09:47:02 UTC
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?
Comment 10 V Stuart Foote 2015-03-23 14:41:59 UTC
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
Comment 11 V Stuart Foote 2015-03-23 15:06:15 UTC
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.
Comment 12 V Stuart Foote 2015-03-23 15:20:17 UTC
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.
Comment 13 Frederic Parrenin 2015-03-23 15:29:54 UTC
V Stuart Foote,

I am exporting only the selection to avoid margins.
I am happy to see somebody is able to reproduce the issue.
Comment 14 Frederic Parrenin 2015-03-23 15:31:46 UTC
Sorry, reading back my initial description, I now see I forgot to mention that I checked the "selection" option in the export dialog.
Comment 15 V Stuart Foote 2015-03-23 15:51:15 UTC
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).
Comment 16 Richard 2015-03-23 16:36:53 UTC
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.
Comment 17 V Stuart Foote 2015-03-23 16:42:59 UTC
(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.
Comment 18 Richard 2015-03-23 16:45:45 UTC
Created attachment 114276 [details]
truncated graphic produced from Debian 7.8

truncated graphic for comment by Richard.
Comment 19 Richard 2015-03-23 16:57:01 UTC
Created attachment 114277 [details]
truncated *.emf export
Comment 20 Richard 2015-03-23 16:58:31 UTC
Created attachment 114278 [details]
truncated *.wmf graphic
Comment 21 V Stuart Foote 2015-03-23 17:27:06 UTC
@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.
Comment 22 Richard 2015-03-23 17:37:45 UTC
@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. :(
Comment 23 V Stuart Foote 2015-03-23 17:47:42 UTC
(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.
Comment 24 Richard 2015-03-23 18:06:28 UTC
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.
Comment 25 Richard 2015-03-23 18:09:31 UTC
Created attachment 114279 [details]
PNG correctly exported, shows the original image in the ODG
Comment 26 Richard 2015-03-23 18:10:52 UTC
Created attachment 114280 [details]
SVG truncated by export from ODG to *.SVG
Comment 27 Richard 2015-03-23 18:12:43 UTC
Created attachment 114281 [details]
EMF truncated by export from ODG to *.EMF
Comment 28 Richard 2015-03-23 18:30:25 UTC
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?
Comment 29 LeMoyne Castle 2015-03-24 00:55:52 UTC
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.
Comment 30 Matthew Francis 2015-03-30 09:54:45 UTC
*** Bug 90017 has been marked as a duplicate of this bug. ***
Comment 31 Matthew Francis 2015-03-30 10:03:58 UTC
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
Comment 32 V Stuart Foote 2015-03-30 14:16:39 UTC
(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.
Comment 33 Matthew Francis 2015-03-30 14:29:30 UTC
(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
Comment 34 V Stuart Foote 2015-03-30 15:24:41 UTC
(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
Comment 35 V Stuart Foote 2015-03-30 15:36:02 UTC
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.
Comment 36 V Stuart Foote 2015-03-31 14:08:16 UTC
(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
Comment 37 devseppala 2015-04-03 11:44:11 UTC
*** Bug 90432 has been marked as a duplicate of this bug. ***
Comment 38 devseppala 2015-04-03 12:37:36 UTC
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.
Comment 39 V Stuart Foote 2015-04-03 13:47:42 UTC
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.
Comment 40 devseppala 2015-04-06 13:02:24 UTC
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.
Comment 41 Commit Notification 2015-04-11 11:23:14 UTC
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.
Comment 42 V Stuart Foote 2015-04-12 18:24:26 UTC
@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
Comment 43 Commit Notification 2015-04-14 20:32:13 UTC
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.
Comment 44 Commit Notification 2015-04-16 21:11:03 UTC
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.
Comment 45 Robinson Tryon (qubit) 2015-12-17 08:43:15 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]