SvXMLImport::LO_4x does not mean 4.0+ any more.
(regression from 92cb21ebeda98c5193c50c4cf7ef3d60611c2a52)
Change-Id: Ib444762c2d6e4d051e99962eaff1b1ed34af983a
Default mime-type for all media objects:
"application/vnd.sun.star.media"
The problem of missing mime-type detection
still exists. For now only glTF model has
a concrete type.
Change-Id: I4dca26c1c47a564579bbed926bffa3aa5eda6c04
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
geometry import when no width and no height are given
(cherry picked from commit 4e04ad3623f2ab4693dcd50a9934fc836e190a6f)
Conflicts:
xmloff/source/draw/ximpcustomshape.cxx
Change-Id: I2589fd28dcbdf767d324f84e0a2342370ad6f061
These have changed a few times, notably in LO 4.0 with commit
895890563cb0cc5fa872bdfd06918a46cdda172d and AOO 4.0 with commit
c0eb5e7772c848806db8ab461f77f9549c1d8b2b; unfortunately historic OOo and
current AOO do not write the values into ODF files, whereas LO 4.x does
(probably by accident, since 45d3577bc5726eee44f491fd30a7f11dc428431a
by design).
Try to set the defaults depending on the generator; since the defaults
are not specified by ODF they are implementation defined anyway so this
should be OK.
Change-Id: I1270d6e0cdeea5cb493724a0998f661a0cf644f1
In case the underlying UNO object supports that, which is the case for
Writer. Export was already working before.
Change-Id: I4676c8349ebe1959da004d6e1a024a342da45049
at import and creation
(cherry picked from commit 0f11a9d487744af6c50e9f1d547c22cd4bdeab48)
Conflicts:
sd/source/core/EffectMigration.cxx
sd/source/ui/dlg/animobjs.cxx
sd/source/ui/unoidl/unoobj.cxx
Change-Id: Ib498bf718d40501cbab71a700342343df68a6ee9
but radiant in AOO core
(cherry picked from commit 23b2b0b395537f4b5d0226f9ebb19dc38029ee55)
Conflicts:
xmloff/source/draw/xexptran.cxx
Change-Id: I66cd482b2b237ca008c31b7738f9ea21502f3d45
The pool defaults for svg:stroke-color and draw:fill-color were changed
and while previously (effective, manually overridden) defaults were
written into ODF files, this was lost with the change; restore that.
(regression from c0eb5e7772c848806db8ab461f77f9549c1d8b2b)
Change-Id: Ibcd863260976aa42116175c7f19cb33760af986f
and draw:glue-point it is necessary to move the GluePoints from the last
draw:image where they were automatically imported to the surviving one if these
are different
(cherry picked from commit c011af1087411a9bacd29cd479c807e698b2e92c)
Conflicts:
xmloff/inc/xmloff/xmlictxt.hxx
xmloff/source/core/xmlmultiimagehelper.cxx
xmloff/source/draw/ximpshap.cxx
xmloff/source/draw/ximpshap.hxx
Change-Id: I8f6c875767e9cbfee74838742401356df002b051
examining svx/source/unodraw/unoprov.cxx "Geometry" is a
indeed a drawing::PolyPolygonBezierCoords for the BezierShapes
and a drawing::PointSequenceSequence for the PolyShapes
regression since e44335abe006d05f0f915279605a03ef084116d6 because after
223f6b631c1b087754c0f9051fb55f029f2503ce we started getting
drawing::PointSequenceSequences in maPath which is the wrong type for the
argument to property "PolyPolygonBezier" for those shapes. Which led me to
incorrectly assume that the all PolyPolygonBezier properties were named
"PolyPolygonBezier" which isn't the case.
so reverting the non maPath hunks of e44335abe006d05f0f915279605a03ef084116d6
Change-Id: I013a66778d11a472fc4567e53a9e17e73e2b91ce
