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
All other _FIND_* are explicitly not errors, and probably CWS npower10
forgot to adapt this assertion.
Change-Id: If721c275eb1bc31d76140898602b41e11c23d82e
Reviewed-on: https://gerrit.libreoffice.org/7863
Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>
* Doxygen spits out a lot of warnings about not being able to find
match function signatures, etc. This is because in some headers we
have a using namespace statement, in others it gets confused between
::Window and Window (!).
* Wrong use of tags:
+ Lots of @seealso - should be @see
+ Wrong usage of @overload - corrected with the right function
signature
+ HTML tags that doxygen doesn't recognize removed
Change-Id: I1c2eed941619b8764dbfcfc5ab38027518cdf261
And the actual label is put as *body* of the cell.
I'd prefer that the value be put as string-value attribute of the cell,
but since in the report definition the label is as body
(as opposed to as an attribute), it is easier that way.
We could move (actually *copy* for backwards compatibility reasons)
the label to an attribute of the rpt:fixed-content element
(similar to the rpt:formula attribute of rpt:formatted-text)
but it is not obvious this is completely desirable:
Indeed it would keep us from putting anything more complex than a string there
(which we don't do anyway now, but thinking of future extensibility here);
I'll leave the exploration of that idea to the indefinite future.
Change-Id: Ia0f7460718ee35a971117e2f79c0997e17e1095e
Marked ranges consist of 2-dimensional ranges plus selected sheets. So the
selected ranges themselves don't care about sheets.
Change-Id: I1c2dfab182282e6b32342b97227b3a7abfaf5179
LibreOffice is unable to properly import the custom gradient fills
defined in ooxml documents. To prevent data loss, we save the
original gradient fill definition in the shape interopgrabbag and we
write it back to the document on export.
In case the user has changed the fill properties of a shape, the
original fill will be discarded in favor of the new fill.
We have added a new ooxmlexport unit test to test this feature.
We have also added some missing transformations to the methods
getColorTransformationName and getColorTransformationToken in Color
class, and refactored some code in class DrawingML to the method
WriteColor( OUString, Sequence ).
Change-Id: Ie71f89eaa20313561aa9180ea33b76f3fb5e5df6
If the run is the start and/or end of the whole text string being laid
out, set corresponding HarfBuzz buffer flags as it will help HarfBuzz
e.g. place a stray combining at the beginning of a paragraph on a dotted
circle.
Change-Id: I05c9fa46b251a2ce4e716da33fb6edda680d2dd1
it's unused internally as far as I can see and has very incomplete (and surely
some wrong values) from some sort of mid 90s Euro-centric worldview
Change-Id: Ibce9e8b76545791ab59b9e11c6ff6e1f33afcb3c
