The problem is that we wrote the size of the shape itself, while VML wants the
bounding box here. The WW8 export ignores the rectangle given in
EscherEx::Commit(), uses SdrObject::GetSnapRect() instead and later refines the
position by using the point got in WW8AttributeOutput::OutputFlyFrame_Impl(),
see PlcDrawObj::WritePlc().
Do the same in the VML export, i.e. ignore the Rectangle we get in
VMLExport::Commit() and use SdrObject::GetSnapRect() + the point given
in DocxAttributeOutput::OutputFlyFrame_Impl() instead.
Change-Id: I5adbdf205792c87f92c1ddf1cf674f87e11eb54e
mso-position-horizontal, mso-position-horizontal-relative,
mso-position-vertical and mso-position-vertical-relative
With this, the watermark in the bugdoc is almost in place, if you ignore
the missing rotation.
Change-Id: I8d3d834089e734654fcbbb0fb6166b4d7e01f80f
...instead of its export-only part com.sun.star.comp.oox.ExcelFilterExport (for
which even a new-style service com.sun.star.oox.ExcelFilterExport has been
introduced recently, but all of this should probably go away again; that this
filter is used explicitly is probably a rare enough scenario to not warrant a
dedicated new-style service).
The modified code in ShapeExport::WriteOLE2Shape is triggered e.g. with a
Presetation, insert a Spreadsheet as an OLE Object, and save as "Office Open XML
Presentation (.pptx)."
Change-Id: Id2645972caaec5265eed645c9c6e2c308a4d079d
* subversion/main/filter/inc/filter/msfilter/escherex.hxx
* subversion/main/filter/source/msfilter/escherex.cxx
[]check whether one shape is default shape of ppt by shape type
* subversion/main/svx/inc/svx/msdffdef.hxx
* subversion/main/oox/source/drawingml/customshapegeometry.cxx
* subversion/main/svx/source/customshapes/EnhancedCustomShapeTypeNames.cxx
[]add definition and declaration for tear drop
* subversion/main/svx/source/customshapes/EnhancedCustomShapeGeometry.cxx
[]the content of tear drop shape which incudes "path, adjust value, handle"
Patch by: Ma Bingbing <jiazema@gmail.com>
Suggested by: Wang Zhe <kingwisemmx@gmail.com>
Found by: Zong Dongjun <zongdongjun@gmail.com>
Review by: Wang Zhe <kingwisemmx@gmail.com>
(cherry picked from commit 26218ac2472838d63485c3c6b4dc2f1aa0bdd0f6)
Conflicts:
filter/inc/filter/msfilter/escherex.hxx
oox/source/drawingml/customshapegeometry.cxx
svx/inc/svx/msdffdef.hxx
Change-Id: I8347832bc842cca8b944c28e807af7f45a7da5b0
Excel just removes the chart during import. Additionally we should work
on only exporting the data label information for points that really
contain data labels.
Change-Id: I80aef8effe27c729feb69c25c319ca129dc961a5
Different MSO versions behave differently in respect to the default
values. 2007 is not compliant to OOXML and is what our export filter
expects, 2010+ are compliant to OOXML and therefore our charts look
awful.
Change-Id: If301d878a1603ed9835884cfbb9ed9c902526ba0
Excel does not like our data label export and removes the charts during
import. I could not figure out what is wrong as the files are valid.
Change-Id: I92458803a48bff1436e7c47ca29d27e487c0642b
We have no way to determine whether the lengend touches the chart area
so let us use no overlay for now. That should be much more in line of
the most use cases.
Change-Id: Idecb0113e47a3f7c925ff8c45238152406ce8954
The current formula size/250*7 is just a guess based on some test docs.
If someone has an idea how to translate them please tell me.
Change-Id: Ibdd27d52d545ac96882c128485c48a3116eb4467
Except for the data label issue my test file looks good now. There are a
few more small issues that I should take care of but it looks nice
already.
Change-Id: I4a6097baefe26088d0246f6335246a211ba143eb
My simple test file is finally valid but is still now shown in Excel.
There must be another bug in our exporter.
Change-Id: Ib55e5b32edc3a556e9081b3008df539275dc289b
This does not work yet as we have several validation errors in our
exported OOXML chart doc. I have to clean them up before the documents
are accepted by Excel.
Change-Id: I0bba64a9c6cab489199c8e6f04158fea7b953d0a
