BITAND, BITOR, BITXOR, BITRSHIFT, BITLSHIFT are written as _xlfnodf.* in Excel
export because Excel doesn't have them. So far we weren't able to properly
read that in again and the #MACRO? error was generated as function result.

* removed XOR entry again from sc/source/filter/oox/formulabase.cxx
  saFuncTableBiff5
* changed XOR entry in sc/source/filter/excel/xlformula.cxx saFuncTable_Odf
  from ocNoName to ocXor to have it written as _xlfnodf.XOR
* changed description of function in Function Wizard

Change-Id: I994119c0520658775d07f776237d31a03f53ab52

Change-Id: I0d345b2cf60f49e0e6b72724251c1f6d30529dce

Change-Id: Id68521b92f572366a68f35c09387a7ed45a835ff

Change-Id: I1b12a923e8c045c7ebca8c0b77b8135d3e072ac9

Change-Id: Idd938980b91ec8b822a92dfd7013a20fe5b6f498

Change-Id: Ia10bac649cc078f6ef39002d280dcff7e5d0b06d

Change-Id: I8dbe60b85d0a330e3b2b5f54984b561fe9be05be

Change-Id: I4fa7b45062b0058427f77cf9dc0abebd6b26fb49

FT_CHARFMT and LB_CHARFMT shared the same resource id (cherry picked from commit 125cecd8fa6036986f1d442bc7d902b547c11e75)

Change-Id: If7edb301fa90a49d79fc5322a7c19ee2591f5494

Change-Id: I389ef70c76a3a9c837ad5406c417804ad77be948

Change-Id: Ica8076b7e21c5188a3126faf32d16904deecf212

Change-Id: Ia0bc37f81b7213b20fc5093beb46d7a05b1ac931

The border widths are tripled on import, because that is effectively
what SetWidth does for DOUBLE borders; set a divisor of 3 similar to
e2ffb713
70a6a4d4

Change-Id: I40b175bedc1ed2d564be126bf9e6870b43474aba

Change-Id: Ia117e1db43b29eda2f87bf1b1f26d580006e4b8b

Change-Id: I2a4cc2c903f469898df9c739658ce25523199fbb

Change-Id: I96606cc97afb4fab6af45b116c265b1b3c584e00

Change-Id: Ib77d62d6bb9070877943cd686791c9e634718c79

Change-Id: Ibbf777e57af6b98611cb5dce5a31517de80305b7

Change-Id: I17ec5a54b0088b56bd8c8431eb255626dbb1fac8

Change-Id: I91ed2c018218c68665471be146dc82f9dbfd34ad

The vector::back() does not return a value but a reference, hence this
is invalid.

Change-Id: I8624b649deb8fb4de0d1d8af1288068acc80cef2

Change-Id: I0f869af4fd497461fc06897540d3be0a6703f00e

...by using system libsqlite3.dylib instead of nss one (see comment in
nss/makefile.mk for details).

(dmake knows neither < nor ! in conditional expressions, that is the reason for
the strange .IF .ELSE ... .END constructs.)

Change-Id: I5abe0f74ad55aac06b91163751bb8145b759b9ca

gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
com/sun/star/uno/Sequence.hxx:178:10: error: assuming signed overflow does not
occur when assuming that (X - c) > X is always false [-Werror=strict-overflow]

Change-Id: Ibbc2f3533097ad379e1707f77039c675a0d00133

Change-Id: I51ba83c5356f2eb33ed09f6516de9f004678bc8f

Change-Id: I1d126eb10bfebc747d4bb6d153b80abe73a1e81e

Change-Id: Ib1d98173f2dd29a59ce49bbe93ff563d5bb913a0

Note that this Document class is work in progress and the code hasn't
ever been run yet even. Not used by the DocumentLoader test appp
currently.

Change-Id: Ibb285d455f31d9bda43133f3a289fc4564b83d47

Render directly to a direct ByteBuffer allocated on the Java side.

Change-Id: I2d66e4146df77e92260918a78ef22cd9b8c95384

Change-Id: I8dd16850a35cd2de7260dcbe9a8aa7afae2294be