There are two types of capitalization in DOCX:
-uppercase: <w:caps>
-smallcaps: <w:smallCaps>

Change-Id: I6a5d238bed68aa3fd3478a77cf1942f009480eb6

* 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

Change-Id: I4e3078ab29ff6ad2d89f68ef6413d2f3fb1fcb80

Change-Id: I86e069e14d82be311368662f5128b30a7d00be90

Change-Id: Ic8e56294a0f7527feac71516047b82e71ae0d50c

Change-Id: Icfcea4a4e86a85d67786d0a87d8d2eb665860e0e

Change-Id: I900a8956fd9eae330bf12829bc94c8b18b1c6513

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

Change-Id: I4a17e5f0f1c81c968c821467f326a1c9b06a85a9

Marked ranges consist of 2-dimensional ranges plus selected sheets.  So the
selected ranges themselves don't care about sheets.

Change-Id: I1c2dfab182282e6b32342b97227b3a7abfaf5179

Change-Id: Ia2f4828a91ad3c89f7867e0f2e0248f885d3fff7

Change-Id: I90a1d4b3ae2e6aff9a7926b5842bc85ac172683d

Change-Id: I8508f00f6af218605d1d43d3efcefbf545387ab8

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

Set fallback to DOCUMENT_FRAME role.

Change-Id: Ib83cd2f9881bcdec7b69a7660cf4166a612aaf60

Change-Id: Ic2182ffc76d63b966fc381dadb59af344dda945e

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

as preparation for converting the SvStream::operator>> methods on
primitive types

Change-Id: I62f134bced15c687d6e0d46924f56e8d1c3d95b9
Reviewed-on: https://gerrit.libreoffice.org/7798Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

See the referenced bug report for the reason behind it.

Change-Id: I4284807adaf82ae9581208a13ebd5071d36be5c7

Bug report: http://openscope.org/browse/OOO-837

Change-Id: I5c17ed6059107ec8fc12bf9f411e52b22f131065

Change-Id: I5b7c149f7f419ba18bd2cc59f4e77a0b61280caa

Change-Id: I4b8eba6d8353e4207cac4a8b24d2b9f0440ce9e6

Change-Id: I1f99b9377294de94c46943a0768d91cd51380a26

Change-Id: Ifadcddf0c6c0a0e33c80ac47dd64af6b56387d30

Change-Id: I434aeb97a32d4b70846c7b3a7c701f90f43bad8a

Change-Id: Ia44bc612e9128adfc9be0d44ea8368215de950ba

Change-Id: I1529e7d628984d9720dd1169816911a957df7a11
Reviewed-on: https://gerrit.libreoffice.org/7850Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I98a272e8cf009aa04bbd07ee333f9853e2a906d2

Change-Id: I855a7e260a9ad05d655d121dbed97597b21187d2

... from URE to NONE.

Change-Id: If43e07b88f2ab0e845f77d1f1a835627e5c48dd7

Change-Id: I68c5f5ac015e8c5d8efd60921f38eb31c6f8088d

Change-Id: I560a8eded4747a9332f5dac29009eafd3d6e68b7

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

Change-Id: I418cccac5181c9a4e41f0fd5e06af10a21714f48

Change-Id: I1ce125e459dfcf22adef85efac344ceb320812a2

Also make some adjustment in order to handle formula cell's "temp grammar"
correctly.

Change-Id: I6fdd5c67bb95e4de90ea71db624c9610c1e2febf

Change-Id: I08b43a6658a600398b434a0c90e0e16863402b33

Change-Id: I9dead89e990297abee185a8a64b0d2f4a86f5c70

This reverts commit ff8036df.

multiple build failures with namespace collisions etc

Change-Id: Ie8ac08feff518af3584a26957f07a60d95932c76
Reviewed-on: https://gerrit.libreoffice.org/7855Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

... via new scp2 macro LIBO_LIB_FILE_COMPONENTCONDITION.

(regression from 2feb756d)

Change-Id: I6ab30cc1c14c34bd7dc1325e3f98d972544e7eea