Change-Id: Idbba5bb89bee4d88ed0306d5151e238a1bc19cec

Change-Id: I1b04fbf4d4562ff8e74f6ccdb2fd989d79cc869b

Change-Id: I25fef9590a34ec8d9aab182b3d267ae3cd649a87

Change-Id: I9f2e705fd603a7c8832c0f0772bee9f395380a0d

Original File contains two separate SDTs which are getting
nested during RT as follows:-

sdtStart [MARK] rPr [MARK] sdtEND RunSTART
          ==PREPEND==> sdtStart [MARK] sdtEND RunSTART rPr RunEND
Now Another SDT starts
sdtStart [MARK] sdtEND RunSTART rPr RunEND [MARK] sdtStart
          ==PREPEND==>  sdtStart [MARK] sdtStart sdtEND RunSTART rPr RunEND

So, in such cases wait before closing the earlier sdt, to avoid nesting. Thus the [MARK]
can be retained in the corrrect position, to start the new SDT and end the earlier SDT.

Reviewed on:
	https://gerrit.libreoffice.org/10803

Change-Id: Ia86f94c0587a5d44ab23391ea9ac38f86b5dd250

Change-Id: I8d7a54fac61a3072d4f34615e71e37c70dec4e50

Change-Id: I1cfd6d59e5569177d8ad23245435073d30fe1374

The caller is responsible to delete the buffers. Depending on bRenderbuffer either with glDeleteRenderbuffers or with glDeleteTextures.

Change-Id: I5ccbd49862c381abf04e812765cced485a083f89

The only thing that needs to be reimplemented is the pbuffer based
custom sprite rendering. We should use a FBO with a texture backend
for that. This will also save several OpenGL context switches!

Change-Id: I4aef33ae2499e44c8b5f41c296d8721cb94a37a1

Change-Id: I1af7e03a3e46f3cb49162be9351ce22f54d08c52

Change-Id: Ia02fb20d335e2172f607f13a0de78ea666d094f5

Change-Id: I6a3cdf840468d6508e8ffecdc50d79041b9b4797

Change-Id: Icc32c336495a1d0a29b24b976dd5f359d03a0bba

Change-Id: I00146441b1271d7a3c866ad58d1b3c72b845dc0c

Change-Id: Ib9e5801bc13ccf146ddd5aa79b7cd7d2a640e203

This one doesn't support label placement property either.

Change-Id: If1f17a135eabd810033644e27db6b1e5c049daff

Normal charts allow a variety of label placement options, but percent/stacked
charts only allow three variants, and exporting a wrong value would trigger
MS Office to think the file is corrupt.

Change-Id: I8bdc1dc072b29e8df2c506b6b16c61279df12045

Change-Id: Idebb56fc96828ec38d5c239c16e5b413a50c837f

Change-Id: Id143689f573e6f8585db9bc48a252e311ff0e721

Change-Id: Ie6438d67aa09fd1dfb746b4ac7ff34d6494ee453

Change-Id: Ib2b244f466d21835229a5a42e6decf4cf4aba653

Change-Id: Ifbcd602203708519f7b4416cf31d94d45b552556

Change-Id: Ib57c7846523f7b8b3b08d19355e10a47c778a524

Change-Id: I6a7b659b562218e4bdd1b1badf655f65266e8d85

Change-Id: I96c8ea50425ed82cbbd1f235bd778621956b59ba

Change-Id: I966c0d6e61e1815252a83e22d142837e26302b30

Change-Id: If505b45bd197fb24a2bacaf44cb46f84de8b61ff

Change-Id: Ia4c6486d2d54103951765ce3e273dece6f022372

If a picture anchored to character is dragged vertically, it can actually
jump to the left, even though X should stay the same. This change
basically reverts part of 5ddd93f4.
I haven't figured out how this GetBaseOfstForFly() actually works, but
I'm reasonably sure that the relative X offset introduced by it
in SwFlyAtCntFrm::SetAbsPos() is not undone anywhere in SwFlyFrm::ChgRelPos()
or otherwise acted upon, it simply causes relative X position change, even though
the absolute position remained the same.

Change-Id: Iabf4f4e4268711a36f02aa47ca9624f9007a22a6

(cherry picked from commit a02eb39b)

Change-Id: Id068928f77a6efed44da9b83ecbf547302826591

(cherry picked from commit 7c5e9b9b)

Change-Id: I570e92c78196895bef329eb308eeb68ffc5e23d3

These are used from svx and apparently some (buggy?) toolchains fail with
fmgridif.cxx:: undefined reference to `non-virtual thunk
 to WindowListenerMultiplexer::acquire()'

Change-Id: Iea0a6eab1ad7f69e4a732f763bc8dbc16bf1be1c

Placeholder type seems to be more relevant than index.

Change-Id: I9d6c6cad8e0a51b2385801f65d7d1c697ad7998e

Change-Id: I612ca7426b2b3de07d4afe1d78cd809f1f6b37bb

Change-Id: I8e504dfee81557a1965bb4bbce4ea975c13fe775

Change-Id: Icbb17f56643f7d89bf739b0f218b2ca8a6309d9a

Change-Id: Id7602dd19ac142dbe2680ddf7eab308a087e971a

If we export a wrong placement value, MS Office will flag the file corrupt and
the loading will fail.

Change-Id: I7ca1239cd390494c1181ecdb3310c5f88bb18f9b

Change-Id: I25cf48703a286470907ccc5415a0fab479aa4b8c

Change-Id: I6d0e2c099869120bdf594813468a3c5ba4bb46fd