Created attachment 158340 [details] OOXML docx with Both Pictures Missing Area Fill The background fill of MSO images in OOXML documents is lost on import. Steps to reproduce: 1. In Word insert image 2. Format Picture -> Solid Fill 3. Save 4. Open in Writer 5. Right click on Image -> Properties -> Area Expected Results 1. The fill color from Word Actual Results 1. No fill Note that the .doc format correctly imports this attribute.
Created attachment 158341 [details] MS binary .doc correctly imported
Created attachment 158342 [details] Similar Line Border Correctly imported in OOXML Unlike the Area Effect, the Line Effect is correctly imported in OOXML.
Created attachment 158343 [details] Screenshot Comparison of Word vs Writer
Created attachment 158344 [details] OOXML .pptx Files correctly import Area Atrribute Oddly, this is a Writer specific OOXML issue
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed these logs: warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1267: unknown element xsi:type http://www.w3.org/2001/XMLSchema-instance warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1267: unknown element xsi:type http://www.w3.org/2001/XMLSchema-instance warn:oox:7570:7570:oox/source/docprop/docprophandler.cxx:321: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:7570:7570:oox/source/docprop/docprophandler.cxx:321: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:7570:7570:oox/source/docprop/docprophandler.cxx:321: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:7570:7570:oox/source/docprop/docprophandler.cxx:321: OOXMLDocPropHandler::startFastElement: unknown element 2749 warn:oox:7570:7570:oox/source/docprop/docprophandler.cxx:321: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1267: unknown element w15:val http://schemas.microsoft.com/office/word/2012/wordml warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1195: unknown attribute vid={4A3C46E8-61CC-4603-A589-7422A47A8E4A} warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1267: unknown element wp14:editId http://schemas.microsoft.com/office/word/2010/wordprocessingDrawing warn:oox:7570:7570:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 3973 warn:writerfilter:7570:7570:writerfilter/source/dmapper/WrapPolygonHandler.cxx:171: WrapPolygonHandler::lcl_attribute: unhandled token: 91309 warn:xmloff:7570:7570:sax/source/fastparser/fastparser.cxx:1267: unknown element wp14:editId http://schemas.microsoft.com/office/word/2010/wordprocessingDrawing warn:oox:7570:7570:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 3973 warn:writerfilter:7570:7570:writerfilter/source/dmapper/WrapPolygonHandler.cxx:171: WrapPolygonHandler::lcl_attribute: unhandled token: 91309 warn:legacy.osl:7570:7570:oox/source/helper/storagebase.cxx:67: StorageBase::StorageBase - missing base input stream warn:sfx.view:7570:7570:sfx2/source/view/viewfrm.cxx:3210: SID_SIDEBAR state requested, but no task pane child window exists for this ID! warn:sfx.view:7570:7570:sfx2/source/view/viewfrm.cxx:3210: SID_SIDEBAR state requested, but no task pane child window exists for this ID! Don't know if it may be a dup. At least, I found a similar bug on xlsx
(In reply to Luke from comment #2) > Created attachment 158342 [details] > Similar Line Border Correctly imported in OOXML > > Unlike the Area Effect, the Line Effect is correctly imported in OOXML. "doc" format here, not "docx".
Created attachment 158356 [details] Similar Line Border effect Correctly imported in OOXML .docx Unlike the Area Effect, the Line Effect is correctly imported in OOXML.
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: cd85546a2fbdade42f80fd3b6bd650791db9f32d CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: tr-TR (en_US.UTF-8); UI: en-US Calc: threaded and back to Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Reproduced in: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38 Calc: threaded
Already in 3.5.0.3.
repro 7.6+ We do read case A_TOKEN(srgbClr):, but it gets lost somewhere... I think we always assign transparent white b/c nFillColor is only -1 xGraphicObjectProperties->setPropertyValue(getPropertyName( PROP_BACK_COLOR ), uno::Any( GraphicImport_Impl::nFillColor ));
Reading the fill from the source in oox is correct. It gets lost in writerfilter/source/dmapper/GraphicImport.cxx If I add the following in https://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/GraphicImport.cxx?r=3eb90b33#865 and the needed #include <com/sun/star/drawing/FillStyle.hpp> at the top, then I get the shape fill color. But this is not a complete solution, because it does not consider FillGradient, FillTransparenceGradient, FillTransparence and not theme colors. But is shows that GraphicImport.cxx is likely the correct place to fix the error. drawing::FillStyle eFillStyle; aAny = xSourceGraphProps->getPropertyValue("FillStyle"); if ((aAny >>= eFillStyle) && drawing::FillStyle_SOLID == eFillStyle) { util::Color aFillColor; aAny = xSourceGraphProps->getPropertyValue("FillColor"); if (aAny >>= aFillColor) { xGraphProps->setPropertyValue("FillStyle", uno::Any(drawing::FillStyle_SOLID)); xGraphProps->setPropertyValue("BackColor", aAny); xGraphProps->setPropertyValue("FillColor", aAny); } } Another question is, why xGraphProps do not have these properties from the beginning.