So that later SwWW8ImplReader can read these structures in a way similar
to bookmarks.

Change-Id: I8e5bc804832b944336701ac12fe6cb50e17c6b94

As commit b1cd83c6 (fix crash loading
ooo#93570-3.doc, 2014-07-04) notes, the way how we map WW8 CP indexes to
sw character positions is working only in the very simple cases.

However, to do that properly, we need a way to store the start position
of an annotation mark before we create it, so add a
RES_FLTR_ANNOTATIONMARK that can do so.

Change-Id: I7cb3564621803fef9a76edaac48773cab7649ee8

XclImpStream and elsewhere does an initial seek to the end, then a
tell to work out the true length of the stream. In order to let us
attempt to rescue data from the beginning of otherwise corrupt /
truncated streams, we should avoid setting an error here.

Interestingly, we also (probably) don't want to return the true length
of the valid data - as this is how SotStorage has worked historically.

Change-Id: Ie0ff0e183220b81871ae3bf83980a24b57ac8694

Change-Id: Ic11c397984602bf8a2e292bc901cd7bf71ad555d

to update layout after initial show when
contents change

Change-Id: I8edbe84fa366cdb04dbfe5e479dc01cbf04dbf4c

This is an epic dialog with lots of moving parts

Change-Id: I4e53580ac5b01f4a717d2fe594a18c8e83b45a6f

Project: help  45bd6c6e23810a5778b23b3bf1c2f30e37d0021c

Fixes build for iOS.

In theory, it is a bit unclear whether DISABLE_DYNLOADING means to 1)
not build any dynamic libraries at all, not even of bundled 3rd-party
libraries, or 2) not build any own dynamic libraries, including
dynamically loaded UNO components, while still building 3rd-party
libraries as dynamic. But in practice, a use case for the latter is
nonexistent, nobody uses --disable-dynamic-loading in their
autogen.input, and DISABLE_DYNLOADING is turned on automatically for
iOS and Android.

What we want for iOS, for an LO-based app, is to not build any dynamic
libraries at all, but produce a single executable. Correspondingly for
Android, at least currently, we want to produce a single dynamic
library.

Change-Id: I7af4c3e53b13439612bb57bbb0fc8b118bda96bd

Addition of CommandBars collection
Addition of CommandBar class

Change-Id: I28d5bc9e8ddeb7ef42d608e55a63762657dfbf51
Reviewed-on: https://gerrit.libreoffice.org/13700Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I4f8d7e2bec006e6d0a0041e2145aa0920f64aa57

Change-Id: Ifc0218b76f9b330185986bf4c7137f4f9a2f1081

Change-Id: I961603e3ea20aae4f12705c2656864dcbe8e1eca

Change-Id: If19f4067d53c2c614f6afcc0d6349db6ec2fd602

Change-Id: I7e8b7ed552a37c6d9c6ce7c75765267b343d508c

Change-Id: I8d34dd364de81c7adeddfd3a8ff0fb8c8b08a5d4

Change-Id: I9b3af4f66513fff437facd17c0758ee92ac5744d

Change-Id: If84d468d4bd55ed55ccd517d0b078d283a1a9c38

Change-Id: I84a2b6dd3f7045f1e95e6d45226797c33231552b
Reviewed-on: https://gerrit.libreoffice.org/13685Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I861a8f38adf8bb2bda193befe100ba535eef83ba
Reviewed-on: https://gerrit.libreoffice.org/13691Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I8289d728dd60f2fd127c01956990a01250d4e773

Change-Id: I5de4bce2632a94d0a94b4d8212525e9a35790ca0
Reviewed-on: https://gerrit.libreoffice.org/13689Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

So let's let this for Windows only

Change-Id: I1f76e03b0e3431a6954a75f5cb247ef1a1644a28

Change-Id: I8b62c0980275537adea7a4de44d4fe86995da92f

Change-Id: Ia70f96e1d31e71c56f03c828be0a4e49fff4b198

Change-Id: I363ac477d364a1b428ebe5181973ff28dc3f4a77

Change-Id: Ic41b981c989aec658e95889b72bd76ecacb13a9a

Change-Id: I8c52801178c5cf80398a19ebe40d336c69db8065

Change-Id: Iafd2db5d878857c517e79f84b8c9c6a806ccfe4b

Change-Id: I2510cd7faa48c0287498bdbc2511e29dbc62860a

This reverts commit c6e316f5.
The bug #i124452# was in AOO only, no need to fix it in LibreOffice.
Especially when the "fix" causes regression. The related fdo#76334
should be fixed one day, but that is a different issue.

Conflicts:
	xmloff/source/draw/ximpcustomshape.cxx

Change-Id: Ice0bf378f97e2caf0ee8386d0b5c0b8abcbcd1c2

Change-Id: I72c6e234ff999a6dbed48cc62fe7d39aeb798f35

Regression from:
20f8006e

It's not a good idea to create the arc first in small
resolution and scale it later, because the result won't
be smooth (e.g. in case of flowChartPunchedTape).

Both cloud and flowChartPunchedTape rendered well after
that change. It seems the problem in case of cloud
was with the arc tangent values which should be calculated
based on the ARCANGLETO's original values before scaling.

Change-Id: I0315afd0452108b6539b4b8ba271d1615810d985

Change-Id: Ia4165880b0b08b5ca26fe7004f961cd17b3d3e27

Change-Id: I36a6d22f87b0d96cdbdadd683cd3abeb12e28c77

Change-Id: Id52e58ad74a521f338204d0b4b21f776dc61ba08
Reviewed-on: https://gerrit.libreoffice.org/13678Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I84ee0c754118882734301bf1d34c15ba640a3889

Change-Id: Idb5df3a8dd89d56ae1b70b05d5c6baf01e27b569

Change-Id: Ie555a72519b251cea3bd98cdfbd6d93295dea079