Apache OpenOffice (AOO) Bugzilla – Issue 119125
Break and Convert actions in AOO Draw corrupt imported SVG
Last modified: 2017-05-20 11:42:13 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 https://issues.apache.org/ooo/show_bug.cgi?id=119123) 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.
Created attachment 77364 [details] Firefox-logo.svg
Created attachment 77365 [details] GIMP_Icon.svg
But the "svg_graph.svg"attached file saved from Gnumeric application after "Break" isn't corrupted
Created attachment 77366 [details] svg_graph.svg
The same problems both import and "Break"/"Convert" with the OpenOffice.org logo (attached "openofficeorg-application-logo.svg")
Created attachment 77367 [details] openofficeorg-application-logo.svg
Created attachment 77368 [details] svg ellipse with gradient fill I think, that there are at least two problems (1) The gradient is wrong. (2) Breaking the svg should not result in a bitmap, but in an ellipse, which has this bitmap as background, with a proper offset.
ALG: Adding myself to CC
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.
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?
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)
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).
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.
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...
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_BMPSCALEPART_ACTION (118) #define META_BMPEXSCALEPART_ACTION (121) #define META_MASK_ACTION (122) #define META_MASKSCALE_ACTION (123) #define META_MASKSCALEPART_ACTION (124) #define META_GRADIENT_ACTION (125) #define META_WALLPAPER_ACTION (127) #define META_TRANSPARENT_ACTION (142) #define META_EPS_ACTION (143) #define META_REFPOINT_ACTION (144) #define META_TEXTLINECOLOR_ACTION (145) #define META_TEXTLINE_ACTION (146) #define META_FLOATTRANSPARENT_ACTION (147) #define META_GRADIENTEX_ACTION (148) #define META_LAYOUTMODE_ACTION (149) #define META_TEXTLANGUAGE_ACTION (150) #define META_OVERLINECOLOR_ACTION (151) At least META_FLOATTRANSPARENT_ACTION will lose some geometry, thus I look now if I could add it to the old dismantling...
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...
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.
verify on win7-64bit and Ubuntu 10.04 32 bit on AOO3.5 r1387022,pass