If there is a shape in Header or footer in a docx created in MSO-2010 that shape was
getting lost after RT(actually shape was there but it's properties were getting missed).
Root cause was : When LO processes Header it has msRelationFragmentPath= header.xml in
ShapeContextHandler::startFastElement() and searches for theme as there is No theme specific
to header or footer, aThemeFragmentPath becomes empty in that case.
This is because MS office shares same theme for both documentBody as well as Header or footer.
To fix Get Target for Type = "officeDocument" from _rels/.rels file this target is
"word/document.xml" for docx & to "ppt/presentation.xml" for pptx and use this Target for fetching correct theme.xml.
Tested group shapes in header/footer,previously was not getting rendred and not preserved
after RT.After this patch it's now working correctly.
Tested chart in header/footer previously chart colour was not coming properly
both during rendering as well as after RT.after this patch it's working correctly.
Reviewed on:
https://gerrit.libreoffice.org/10451
Change-Id: Id47008550da90c0d697b434b676765230e3258a7
ShapeContextHandler::getDrawingShapeContext mxDrawingShapeContext is set once and never reset.
So in a file which has numPicBullets and vml shapes in document.xml there is a problem.
First the fragment path is set as word/numbering.xml.
But when msRelationFragmentPath changes to word/document.xml,
mxDrawingShapeContext is not reset and hence the relationships are not resolved.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/10180
Change-Id: I4a1401103797972731257145430f2048b94a04bc
This allows having real shapes (like having rounded corners) and complex
content (like containing a table) at the same time.
WPS shapes are wrappers around drawingML markup in DOCX files, so this
only affects the DOCX import.
Change-Id: Iad1c1c61233be1c17efa1821e680927aa9587215
As in, for shapes which have textboxes. CppunitTest_sw_ooxmlsdrexport's
testFdo69636 is a reproducer for this problem.
Change-Id: I6575d21b0802ada7f334ca9fbbea796605708ddd
It's possible to write this tag in oox (so it represents the properties
of the shape) or in sw (so it represents the properties of the shape's
textbox). Do the previous, as the textbox is really just a container in
this use case, nothing more.
If we are at it, also fix the default value of <wps:bodyPr>'s l/r/t/bIns
attributes.
Change-Id: I0571b9d8ea7dc0acd5c61f3e28e18400d305eab3
DOCX shape import normally works by oox creating the shape, then
writerfilter handling the shape text. For drawingML shapes, having shape
text, this a bit more complicated, as there are shape properties after
the shape text as well.
ShapeContextHandler::endFastElement() assumed that shape text is only
possible on css.text.TextFrame shapes: also handle shapes having a
TextBox as well.
sw/qa/extras/ooxmlimport/data/mce-nested.docx is a reproducer for this
problem (group shape missing), when TextBoxes are enabled by default in
oox.
Change-Id: I7a412b31965cf363da0b0c7fcc732741f2037542
The original file contains two text boxes one contains image and the other contains chart.
Image in text box is not getting imported in LO which leads to no contents inside the a:graphicData tag which is causing the corruption.
Root cause is found in ShapeContextHandler::getShape.
mxChartShapeContext.is() returns true even when mnStartToken is not set as NMSP_dmlChart which is causing the issue.
I have added one more condition to handle this.
Change-Id: I6c567d7618b34c1a24f6809801e4460af6894c67
Reviewed-on: https://gerrit.libreoffice.org/9363
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
... during DOCX import of shapes with text, so that we don't crash when
the currently always active
setServiceName("com.sun.star.text.TextFrame") call is not present.
Change-Id: I5b005583ddcee81b9683e3b34e8f0a2e5faa4f95
Added support for linked textboxes for docx interoperability.
Reviewed on:
https://gerrit.libreoffice.org/9092
Change-Id: I7db4f5a1783afff53c64908d182788b262f5e863
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
Added support to grab-bag rels and associated Images for
data[i].xml, and drawing[i].xml.
Added UT for the same
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8362
Change-Id: I545825f67214f14037ab72b77764a07d575b8b5b
Translate component of parent shapes' transformation
have to be applied to children when there is no explicit
child transformation.
Note. Export also use this concept.
Change-Id: I51bd3325fb53ee250402326ee361c8f07038ed07
Just make sure that these two new lines match the style of the
rest of the file, which was so far consistent.
Change-Id: I6113753157fec7fd0e0dc988885b36b477c301b2
Currently we change shape type to textframe if a shape contains
text. Due to this shape information is not preserved when file
is saved.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7372
Change-Id: I7af3ce29f857d6fa2ceab0350937d91638361e7c
It seems that in Word, a zero parent transformation, like:
<a:chOff x="0" y="0"/>
<a:chExt cx="0" cy="0"/>
means the child shapes will have an absolute position / size. We
actually use this feature in the exporter, but so far the importer
didn't handle this.
Change-Id: I250784a3dddd23649e391b548fc128dfdf153614
The problem was that due to setting it to 18 in oox, the rectangle
didn't inherit the default 11 from the document.
Change-Id: I05c3b9c1d64eec58695e2039651a5f015df1f9e4
