Issue 119125 - Break and Convert actions in AOO Draw corrupt imported SVG
Summary: Break and Convert actions in AOO Draw corrupt imported SVG
Alias: None
Product: Draw
Classification: Application
Component: open-import (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC All
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2012-03-25 11:58 UTC by sorath
Modified: 2017-05-20 11:42 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Draw Break corruption SVG (382.61 KB, image/png)
2012-03-25 11:58 UTC, sorath
no flags Details
Firefox-logo.svg (44.54 KB, image/svg+xml)
2012-03-25 11:59 UTC, sorath
no flags Details
GIMP_Icon.svg (20.03 KB, image/svg+xml)
2012-03-25 11:59 UTC, sorath
no flags Details
svg_graph.svg (13.88 KB, image/svg+xml)
2012-03-25 12:14 UTC, sorath
no flags Details
openofficeorg-application-logo.svg (63.60 KB, image/svg+xml)
2012-03-25 13:01 UTC, sorath
no flags Details
svg ellipse with gradient fill (1.66 KB, image/svg+xml)
2012-03-25 13:55 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description sorath 2012-03-25 11:58:01 UTC
Created attachment 77363 [details]
Draw Break corruption SVG

Using AOO-3.4 (AOO340m1 (Build:9589) Rev. 1303653 22.03.2012) under Gentoo Linux

After opening (or also importing via Insert menu) all SVG files in Draw it represents as with merged layers and elements
(as discribed in

If user want to change some placement of layers and elements then ру must use "Break" or "Convert" context menu (see attached file "Draw Break corruption SVG").
After such actions the representation of most opened SVG files become corrupted.

Also for Firefox icon there is a corrupted colors (see also "Draw Break corruption SVG" attached)

Initial svg-logos are also attached below: Firefox-logo.svg and GIMP_Icon.svg.
Comment 1 sorath 2012-03-25 11:59:11 UTC
Created attachment 77364 [details]
Comment 2 sorath 2012-03-25 11:59:41 UTC
Created attachment 77365 [details]
Comment 3 sorath 2012-03-25 12:13:51 UTC
But the "svg_graph.svg"attached file saved from Gnumeric application after "Break" isn't corrupted
Comment 4 sorath 2012-03-25 12:14:11 UTC
Created attachment 77366 [details]
Comment 5 sorath 2012-03-25 13:00:54 UTC
The same problems both import and "Break"/"Convert" with the logo
(attached "openofficeorg-application-logo.svg")
Comment 6 sorath 2012-03-25 13:01:25 UTC
Created attachment 77367 [details]
Comment 7 Regina Henschel 2012-03-25 13:55:28 UTC
Created attachment 77368 [details]
svg ellipse with gradient fill

I think, that there are at least two problems
The gradient is wrong.
Breaking the svg should not result in a bitmap, but in an ellipse, which has this bitmap as background, with a proper offset.
Comment 8 Armin Le Grand 2012-03-25 15:24:08 UTC
ALG: Adding myself to CC
Comment 9 Armin Le Grand 2012-03-26 16:17:16 UTC
ALG: Taking over. Thanks for testing and the examples.

The Gradient is definitely wrong. Thanks Regina for the simple example; fixing this should fix the wrong imports.

The Break is more complicated and known. The method to construct SdrObjects from breaking graphical data is old and based on Metafiles and it does not take clip regions into account. Thus, currently the primitives from the Svg import (which are correct due to defining the paint) get converted to Metafile and then used. The gradients are defined using clip regions, you can see the result when these are ignored. This method needs to be rewritten based on primitives.
Comment 10 sorath 2012-04-08 08:30:21 UTC
Apache OpenOffice 3.4.0: AOO340m1(Build:9590) rev. 1309668

has wrong Gradient still.

Is it planing to correct it in the current AOO 3.4.0 release?
Comment 11 Armin Le Grand 2012-05-04 14:33:33 UTC
ALG: Started to work on this, the gradient just had some errors in handling it's painting, correcting this. Mainly the problem is that I interpolated for a gradient piece from e.g. 0.4 to 0.6 between this two, but the start and end color need to be interpolated between 0.0 and 1.0 of course.
Also added support for title and description in the primitive sequences as preparation to use these later e.g. when creating SdrObjects from these (but also in exports)
Comment 12 Armin Le Grand 2012-05-04 16:33:56 UTC
ALG: Looking at the conversion. As explained, conversion takes the old path over the metafile. Conversion to metafile is pretty good (try to convert to metafile in the context menu to see), but the old conversion to SdrObjects from these is bad (ImpSdrGDIMetaFileImport).
Comment 13 Armin Le Grand 2012-05-07 08:32:10 UTC
ALG: Added and committed the mssing files
A         svgio/source/svgreader/svgtitledescnode.cxx
A         svgio/inc/svgio/svgreader/svgtitledescnode.hxx
A         drawinglayer/source/primitive2d/objectinfoprimitive2d.cxx
A         drawinglayer/inc/drawinglayer/primitive2d/objectinfoprimitive2d.hxx
Please checkout for building. Sorry for inconveniences.
Comment 14 Armin Le Grand 2012-05-08 09:29:28 UTC
ALG: Added detection and taking care of clip regions for the Metafile to SdrObject dismatle in ImpSdrGDIMetaFileImport. This cannot be perfect since it's based on Metafile, but I got it working pretty correct. For all clipped geometries polygon based objects with the needed color get created, for bitmap fills the clipped bitmaps are used. Missing is the usage of clipped transparent bitmaps (BitmapEx). I'm currently checking this; fact is that the Item used for defining this (XFillBitmapItem) does not support BitmapEx, but uses a strange old XOBitmap class...
Comment 15 Armin Le Grand 2012-05-10 10:31:17 UTC
ALG: As written in the commit already: 

Completely changed XFillBitmapItem to work wit GraphicObject, removed XOBitmap class, adapted all usages (also the pretty old 8x8 pixel editor). All Bitmap fill styles will now accept transparent bitmaps as fillings in all variations (tiled, etc.). Load/Save is no problem, ODF defines graphic as content for fill. Backward means that OOs before this change will use a white background ofr fill with transparent, same as the fallback all the time when using a transparent fill. This is also a preparation to e.g. offer SVG or Metafiles as fill style.

Still missing is support for the following MetaActions in ImpSdrGDIMetaFileImport:

#define META_TEXTRECT_ACTION				(115)
#define META_MASK_ACTION					(122)
#define META_MASKSCALE_ACTION				(123)
#define META_GRADIENT_ACTION				(125)
#define META_WALLPAPER_ACTION				(127)
#define META_EPS_ACTION 					(143)
#define META_REFPOINT_ACTION				(144)
#define META_TEXTLINE_ACTION				(146)
#define META_LAYOUTMODE_ACTION 				(149)

At least META_FLOATTRANSPARENT_ACTION will lose some geometry, thus I look now if I could add it to the old dismantling...
Comment 16 Armin Le Grand 2012-05-11 14:13:25 UTC
ALG: Pretty bad bug identified which could translate MetaFloatTransparence actions in Metafile/primitive forth/back conversions. Looking now for a solution to convert MetaFloatTransparence actions to SdrObjects, will probably need to use bitmap conversions due to included tranparencies...
Comment 17 Armin Le Grand 2012-05-14 15:21:25 UTC
ALG: Various actions implemented, clipping added. Esp hard was mpSdrGDIMetaFileImport, but working now. Needed to hand-craft alpha addition for alpha in Metafile content and gradient of action. Also added better BitmapEx creation for convert to bitmap for draw objects. Also corrected fill style mappings.
Done so far.
Comment 18 liuping 2012-09-20 08:55:38 UTC
verify on win7-64bit and Ubuntu 10.04 32 bit on AOO3.5 r1387022,pass