Changed quite some places of SdrObjCustomShape usage to use
references instead of pointers, thus forcing to more secure
handling. Changed some test and change methods, even found a
memory leak by doing so.
Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7
With GraphicURL property on shapes (XShape) we transported the
external or internal URL to the model, which also included the
GraphicObject uniqueID style URLs. This changes that - now we
always use "Graphic" property and transfer XGraphic to and from
graphic filters. "Graphic" property is already present for XShape
so it wasn't needed to add it.
Filters changed are: OOXML (oox), ODF (xmloff), RTF and
binary MS (esherex).
Also start using originURL on Graphic which now transports the
URL of the external (linked) graphic/image if it was created that
way.
Change-Id: Ic338c60b7cfaaae354cf1e1ca3ae7a6373220230
Reviewed-on: https://gerrit.libreoffice.org/49648
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
As we want to get rid of GraphicObject URLs for the more robust
image life-cycle handling, it was necessary to change the way
bitmap table stores and handles images, so that they always
store a Graphic object (wrapped in UNO object that provides the
XGraphic and XBitmap interface).
In addition this changes loading and saving from ODF (xmloff) and
OOXML (oox) filters so they don't depend on GraphicObject URL
anymore, but load or save directly to / from XGraphic or XBitmap.
Change-Id: I2b88e10056e7d6c920249d59188f86b1a5a32d21
Reviewed-on: https://gerrit.libreoffice.org/49074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I8fd61e3220a4b9e08d4f97acde28600f31d448ca
During export chart into .xlsx file,
the information about size of legend was not saved.
Example of proper size:
<c:w val="0.41459448854442293"/>
<c:h val="0.23161616722845749"/>
another issue was hardcoded "layoutTarget" which
was always "inner":
<c:layoutTarget val="inner"/>
also properties regarding default text style was not preserved:
<c:txPr>
<a:bodyPr/>
<a:lstStyle/>
<a:p>
<a:pPr>
<a:defRPr sz="900" b="0" i="0" u="none" strike="noStrike" kern="1200" baseline="0">
<a:solidFill>
<a:schemeClr val="tx1">
<a:lumMod val="65000"/>
<a:lumOff val="35000"/>
</a:schemeClr>
</a:solidFill>
</a:defRPr>
</a:pPr>
<a:endParaRPr lang="pl-PL"/>
</a:p>
</c:txPr>
With this patch all these issues was resolved, and in case
of layoutTarget "outer", the field is not availble at all,
according to specification.
Change-Id: I2c9b7a112bdd911542b5273e660222d7fefa2d88
Reviewed-on: https://gerrit.libreoffice.org/47358
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
This solution comes with a few limitations. The bullet isn't centered in
Powerpoint and has to be between 25% and 400% of the size of the first
character in the paragraph. This isn't optimal, but should produce
acceptable results under most circumstances.
Change-Id: I6c37169282aa351b81d78e06678424203b78f6d7
Reviewed-on: https://gerrit.libreoffice.org/44911
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
they were defined in escherex.hxx as SHAPEFLAG_*
and in msdffimp.hxx as SP_*.
Added include for escherex.hxx to msdffimp.hxx.
Filled the missing flag bits.
ShapeFlag::Deleted is not used at the moment.
Convert ADD_SHAPE macro to lambda.
Fix horizontal/vertical mixup in RtfSdrExport::AddLineDimensions.
Comments for flag Connector were wrong. The flag applies to shapes
which ARE connectors.
MSO definition: "connector: A line that is used to connect two
or more shapes and that remains connected to those shapes."
So Rectangles and such with Connector flag don't make sense.
Change-Id: I735de00110411b280a302840dc0fcdfac5156399
Reviewed-on: https://gerrit.libreoffice.org/41754
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Shapes were deformed because flipping wasn't considered when removing
the rotation. Also WriteShapeTransformation needs information about
flipping to convert the angle correctly.
Change-Id: I7d485e93c00e02b9ec6c73ad6ae2876e5bc6360a
Reviewed-on: https://gerrit.libreoffice.org/41462
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
* Inline anchored VML shape had wrong vertical position
** In MSO inline shapes are positioned to the top of the baseline
* During export all shape ids were the same (shape_0)
** VML shapes used to be exported only as fallback,
I guess that's why it did not cause any issue before.
** Override the shapeid generator with a new one, which
actually generates unique shapeids.
Change-Id: I752f39d092d0b61d91824141655dae662dbeafbc
Reviewed-on: https://gerrit.libreoffice.org/41319
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
* Use the same structure for export what MSO uses
** Position and size information are exported as VML shape properties
** Different handling of inline and floating controls (pict or object)
** Do some changes on VML shape export to match how MSO exports these controls
** Write out activeX.xml and activeX.bin to store control properties
** Use persistStorage storage type defined in activeX.xml
* Drop grabbaging of activex.XML and activeX.bin
* Cleanup control related test code
Change-Id: I38bb2b2ffd2676c5459b61ec2549c31348bab41c
Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/41256
Tested-by: Jenkins <ci@libreoffice.org>
...as found by an improved loplugin:oncevar (to be pushed later). The code's
effectively been like that ever since its introduction in
a41687b62b "New files from
xlsx-shared-oox-chart-export-part1.diff", and (as Bubli states) is apparently a
poor copy/paste from xmloff/source/chart/SchXMLExport.cxx. The equally-unused
[m]sTableNumberList had previously been removed with
f9cd73ebe1 "remove a few more unused variables".
Change-Id: I1e0e14b4d79cd34437b0061fc9ea3ce4d5636b31
Reviewed-on: https://gerrit.libreoffice.org/39756
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...that had been removed with 4b788a1238 "There
should be no need to distinguish between I32S and I64S" (which this commit
effectively reverts). I had erroneously assumed that the arguments to I32S and
I64S would only be of (signed) integer types, and that it would be irrelevant
that they are truncated to sal_Int32 resp. sal_Int64. However, at least
oox/source/export/drawingml.cxx called I32S with double values (for which there
is an OUString::number overload too), so the resulting strings could be rather
different.
Change-Id: Ib3887269fad0764740bc9ed3be91f67696a23b55
Reviewed-on: https://gerrit.libreoffice.org/37040
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...after 64b993e046 "finish deprecation of
O(U)String::valueOf()" replaced OString::valueOf with OString::number in their
bodies. (Change done in preparation of teaching loplugin:redundantcast about
C-style casts in macro bodies.)
Change-Id: Ifbb4725c496eed18a926fbabeaf4691ac98d9c5e
Reviewed-on: https://gerrit.libreoffice.org/35678
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead use the size last used for an a:rPr below the same WriteText()
call. I am not exactly sure about how this hangs together, but this
has the desired effect on the exported .pptx.
Change-Id: Ie03dcd0b31c15cff8488b22d7423c9f9ad1e2d68