Change-Id: I7dc6390b1061585054d1fa435414cae245122a1c

Change-Id: I0639b2c69f5f111e37e5566bf4cbea6719de8789

Change-Id: Ib971824a7f274334012b872acec65310535ad767

Unfortunately the page looks ugly ATM :-( - ideas appreciated.

Change-Id: If6c1cfc5f57c2ea58d46649bc34041674b4f5362

Change-Id: I84749158fb8dee3fec10869e0955177bbd917d59

Change-Id: I597d7dbef07479f66894c7fce5ee21f340b43120

Change-Id: I15bef4e0422261ec473263ac8fc239604146f864

Change-Id: Ib89a596f0e28cacc9ae180d23b9995e524c45b52

Data Table is in Data -> Table in Excel XP, and is under "What-if Analysis"
in 2007 and newer.

Change-Id: Iec1f944a8643bafb71341981bf94c6c536c63484

Change-Id: I7d8fea0a2fb8a73a5d108cc8b2ac36b7829f029c

vigra::copyImage89 does not handle copy areas in the same image so the
code checks whether the src and dst are same buffer and directs it to
scaleImage() which is very slow. The whole concept of pixel accessors
is a huge overhead in the case of direct pixel copy (vigra::copyImage
is also using pixel accessors). The idea here is to identify when
direct memory copy is applicable (when the format is an integral
number of bytes per pixel, src.size==dst.size, and
src.format==dst.format) and use direct memory block copy and not
pixel-wise copy. The result is 100x faster than the vigra
implementation. This direct copy is also handling the case when the
src and dst are same buffer by copy it from bottom to top when needed
and using memmove() instead of memcpy().

Change-Id: I8ec589463d6386db82777a916371a5ebbf9e2d50
Reviewed-on: https://gerrit.libreoffice.org/5707Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I24848a0ba55f41bfff577e3593f37f943812725a

Change-Id: Iecc42e79b72e99f9222ba2419226b0f655a5af7d

They are missing in 425d8fd1

Change-Id: Ia624fc2fcd5637b82f819f4b54d8dbcc288e185d

Change-Id: I42ffe7c32d249bdd9cfa03800e78c431df0bb52f

Change-Id: I696b550b495d1bf6549e3c54a3157d467a7ead8d

Change-Id: Icbbe9096c60def4687b137a37bfe86c4de9b3f22

Change-Id: Id6d67f820226da15d90b95aa047767926583cc2e

Change-Id: If30f1df55e426b32fd7ef1278fe5b1cf77823f87

Change-Id: I52741c344fc04b82db650927e4223dc325afabdf

Change-Id: I62162230b313c66872ef1b3e8b18070126169aa1

as opposed to buggily trying to build it ourselves from the path

Change-Id: Ibf44fac809a9cf12bc654a5a2f8ac8f00866b1a3

Change-Id: Ifd32f99f4ab1df1625464c2f269bc85f7283783f

xStorable is obtained from a XComponent,
so use the original instead of requerying
a XComponent from the XStorable.

Change-Id: Iec5ca6ddcf3eedd193ec04129ba9aa1d13af1d0e

Change-Id: I44500717109a026d7c71e6494daacbea1f224263

Change-Id: I6e1782674e66e5f744e307490ce6f417607d7f29

Project: help  73a4731805ca6d8ee9b33f52093e46d8a0703b16

Change-Id: Iec798b3db23883d34bfbaff0003330f013df1a3e

Change-Id: I441e23ab329a09cec7b28dfa743a63b4c834da8a

Change-Id: I34f527ff8e1e9819f4e6ac728efa1e31f8bc3d48

Change-Id: Ia474ee07b1bd411eae8cd1ddd55c4fa83dbd5f47

Project: help  1d8e9be32370edf1d58c176c059e5cbe7d799958

Change-Id: I3357ff4af0ac43950db94d1a009faeb4fb281dba

This reverts commit bcfb5f0e.
82a844a6 solves the root of the issue

Change-Id: Ie086cf59ae86a845e0b84e0ecba7f7e578d83783

Change-Id: I5353cffa12e7378e18fc38172c51257915d880b9

In UI localizations where the translation for such an entry is missing
the entire entry is omitted, causing the following entries to be shifted
by an offset and picking a wrong entry. Seems that rsc does not handle
this case properly.

Change-Id: I0efe1ac5d1f704ab2ba6919c4997caaca2153401

Change-Id: Ia3ea3fcf38512431fb99191f230450f26c7b3e2f

The old MsLangId::convert...() methods did implicitly fall back to a
known locale, this behavior is explicitly needed here to select a proper
completely known locale.

Change-Id: I350989f3af679890ddb0de964c2d107420331160

Change-Id: I26923469d08308233ce3fabe749806c16d75cecd