The second parameter has to be the absolute end position, not the size
from the start position.

Change-Id: I310ec52697d0521a82810889f6fe861471279645

Change-Id: I096282ebb9a10d212affbab32aaa49ca1815b1a7

Change-Id: I7b9c5554e38a25dd4ff6980e6ae0d1eff241a746

This makes it much simpler, and less error-prone.

Change-Id: I21dbe0d2bb4a71fc2ac738a5ffb03e4d959d91a5

Change-Id: Ieaa9bd0e4f8117e3bc7ceccc68d6f37daac61440

Change-Id: Ib7ca5c04ec057dbce958d580ad3b7d52d19ed21f

Change-Id: Ia70d1dfde53e13e7d40e7cb8fa09dc401570aa93

Change-Id: I8d2bd7616e0428e4e881ef0dc1012c4973e636a9

So that I can put some integrity check code in there to test the
integrity of cell storage.

Change-Id: I0cc141ea74c27db1a014390b7abf807220e7be9f

Change-Id: I5408cdd87f06423a6bb287c855237878859da880

i.e. restore the logic of setting the colors of imported escher patterns like
we always did in the past. Stripping that out seems risky in the absence of
definite test-cases.

Change-Id: I16bbb451b053fd04a5154602f8f38ed799e21286

Completely changed XFillBitmapItem to work with GraphicObject, removed XOBitmap
class, adapted all usages (also the pretty old 8x8 pixel editor).

All Bitmap fill styles will now accept transparent bitmaps as fillings in all
variations (tiled, etc.). LoadSave is no problem, ODF defines graphic as
content for fill.  Backward means that OOs before this change will use a white
background of fill with transparent, same as the fallback all the time when
using a transparent fill.

This is also a preparation to e.g. offer SVG or Metafiles as fill style.

Conflicts:
	cui/source/tabpages/backgrnd.cxx
	cui/source/tabpages/tparea.cxx
	cui/source/tabpages/tpbitmap.cxx
	filter/source/msfilter/msdffimp.cxx
	filter/source/msfilter/svdfppt.cxx
	sc/source/filter/excel/xiescher.cxx
	sd/source/ui/func/fupage.cxx
	svx/inc/svx/dlgctrl.hxx
	svx/inc/svx/xbitmap.hxx
	svx/inc/svx/xbtmpit.hxx
	svx/inc/svx/xtable.hxx
	svx/source/customshapes/EnhancedCustomShape2d.cxx
	svx/source/dialog/dlgctrl.cxx
	svx/source/svdraw/svdograf.cxx
	svx/source/tbxctrls/fillctrl.cxx
	svx/source/unodraw/XPropertyTable.cxx
	svx/source/xoutdev/xattrbmp.cxx
	svx/source/xoutdev/xtabbtmp.cxx

Change-Id: Id838bfbacc863695d078fb3cf379d1c0cd951680

tbh this is somewhat of an optimistic attempt to swap start and end borders
if needed. I am not at all sure though that I am dectecting the RTL-ness
of a cell in the correct way. There are some comments in the code in any case
that reflect my uncertainty ( hopefully they will be of use if/when some tweak
is needed )

Change-Id: Ic3099fbab08e46899ca311c81edbcad9bf5ab2a6

Change-Id: I0778cf44a1f4e920e723c17c34f6de4f8eed2342

It won't work, ne_debug_init() will be called always (in non-release builds).

This reverts commit b6f6c3a2.

Change-Id: If72f3c1e0d7a14779074d898c4d1eb0fe8f07871

Change-Id: If8d7c210e437a041f3202c09f3d26d621b5af748

Change-Id: I74d02b86664263519b4758511d885e35a8c9a78d

Change-Id: I3ec10c31139c369ff6950ada57ee3d3f4e8f2d34

Change-Id: I05d9fdd234374924c7876d2c123656495016b0ea

Change-Id: Id9362d05ddae2066f2fa289640f447393d7cda84

Instead of #if OSL_DEBUG_LEVEL>0.

Change-Id: I2329de4deff4687fb1249c47f2e24eaf6ea6a248

Change-Id: I61ef0e13a38ebb82becf56ec8ae9e083571d2e53

Change-Id: I06667cbb1fe24356bb24b7781258ef2c194f0e4d

Change-Id: Icda3d24a67c8bbe5aafcf5c917d0f930e534c6be

Change-Id: I7c3df5e82e05dc494e05a15a5f64b9f25b034f74

Part of fix for bnc#805901. (No locking of documents edited through WebDAV.)
Seems to work, can it really be this simple...

I am a bit unsure if any explicit UNLOCK operation happens, but WebDAV locks
typically time out relatively quickly, don't they? And WebDAV implementations
(often/always?) have the possibility for a user to force open a lock.

Change-Id: Ia32d8b1517361f702b4f469d9f1aa17de6d7ba54

Change-Id: I379f8bd780f40169ed7c70c7c5a28277091b978e

Change-Id: Ib5327fe5a88036f718f90cc0e05f287dc1573d03

Change-Id: I40a2e6ea708aa037172bc6e9f9882c88f1d486c3

Part of fix for the WebDAV https server authentication problem noticed when
fixing bnc#805901.

Change-Id: Ic54c59bdadaf34cdba32949400d5da69712017f3

Change-Id: I4acb7ab1aeba31bfeedd4dfbcd76d6bf517b8944

...which started to fail reproducibly at least for me with recent commits, with

[...]
> checking: [sc.ScCellRangeObj::com::sun::star::beans::XTolerantMultiPropertySet] is iface: [com.sun.star.beans.XTolerantMultiPropertySet] testcode: [ifc.beans._XTolerantMultiPropertySet]
> LOG> Execute: setPropertyValuesTolerant()
> LOG> starting required method: getPropertyValuesTolerant()
> LOG> Execute: getPropertyValuesTolerant()
> LOG> starting required method: getDirectPropertyValuesTolerant()
> LOG> Execute: getDirectPropertyValuesTolerant()
> Method getDirectPropertyValuesTolerant() finished with state OK
> LOG> getDirectPropertyValuesTolerant(): PASSED.OK
> Method getPropertyValuesTolerant() finished with state OK
> LOG> getPropertyValuesTolerant(): PASSED.OK
> ValueChanger don't know type class com.sun.star.table.TableBorder2
> warn:legacy.osl:19841:96:sc/source/ui/unoobj/fmtuno.cxx:197: lclResolveGrammar - unspecified grammar, using GRAM_PODF_A1
> warn:legacy.osl:19841:96:sc/source/ui/unoobj/fmtuno.cxx:197: lclResolveGrammar - unspecified grammar, using GRAM_PODF_A1

causing a SIGSEGV at

> #24 <signal handler called>
> #25 0x00002aaacd9b310b in ScBaseCell::SetScriptType (this=0x0, nNew=8 '\b') at lo/core/sc/inc/cell.hxx:104
> #26 0x00002aaacdc86a9f in ScTable::InvalidateTextWidth (this=0x2aaad80d9e00, pAdrFrom=0x2aaacd16ac00, pAdrTo=0x2aaacd16abf0, bNumFormatChanged=true, bBroadcast=false) at lo/core/sc/source/core/data/table5.cxx:1200
> #27 0x00002aaacdabb18a in ScDocument::InvalidateTextWidth (this=0x2aaad88a19f8, pAdrFrom=0x2aaacd16ac00, pAdrTo=0x2aaacd16abf0, bNumFormatChanged=true) at lo/core/sc/source/core/data/documen8.cxx:440
> #28 0x00002aaacd982d94 in ScAttrArray::ApplyCacheArea (this=0x2aaad81d5380, nStartRow=0, nEndRow=4, pCache=0x2aaacd16ac70, pDataArray=0x0) at lo/core/sc/source/core/data/attarray.cxx:825
> #29 0x00002aaacd9cdaa2 in ScColumn::ApplyPatternArea (this=0x2aaad80d9e00, nStartRow=0, nEndRow=4, rPatAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/column.cxx:450
> #30 0x00002aaacdc638cf in ScTable::ApplyPatternArea (this=0x2aaad80d9e00, nStartCol=0, nStartRow=0, nEndCol=3, nEndRow=4, rAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/table2.cxx:2174
> #31 0x00002aaacdad93ce in ScDocument::ApplyPatternArea (this=0x2aaad88a19f8, nStartCol=0, nStartRow=0, nEndCol=3, nEndRow=4, rMark=..., rAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/document.cxx:4204
> #32 0x00002aaacdaddeef in ScDocument::ApplySelectionPattern (this=0x2aaad88a19f8, rAttr=..., rMark=..., pDataArray=0x0) at lo/core/sc/source/core/data/document.cxx:5232
> #33 0x00002aaace0c46ab in ScDocFunc::ApplyAttributes (this=0x2aaad8910f70, rMark=..., rPattern=..., bRecord=1 '\001', bApi=1 '\001') at lo/core/sc/source/ui/docshell/docfunc.cxx:1267
> #34 0x00002aaace268e02 in ScCellRangesBase::setPropertyValuesTolerant (this=0x2aaafa235fb0, aPropertyNames=uno::Sequence of length 97 = {...}, aValues=uno::Sequence of length 97 = {...}) at lo/core/sc/source/ui/unoobj/cellsuno.cxx:2933
> #35 0x00002aaabc674df6 in gcc3::callVirtualMethod (pThis=0x2aaafa236018, nVtableIndex=3, pRegisterReturn=0x2aaad8b94820, pReturnTypeRef=0x2aab601513a0, bSimpleReturn=false, pStack=0x2aaacd16b240, nStack=0, pGPR=0x2aaacd16b2c0, nGPR=4, pFPR=0x2aaacd16b2f0, nFPR=0) at lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:119

Change-Id: I4cf6386f903e2681033bd63005141f71feb13ad7
Reviewed-on: https://gerrit.libreoffice.org/2740Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

for gdk_screen_get_primary_monitor but osl_getAsciiFunctionSymbol does the
right thing

Change-Id: Ibf1a17724a9393d95c4fbe0d26aa82148eea33a9

we go to some effort to determine the right value of ret
and then throw it away and return 0

regression since 4a7e3482

Change-Id: I652cfbe44fdab6560c1c8dc8fe25d6211b5357cb

Change-Id: I4bf2d72ba14f5293c2f9aa8eb3a34fedefa03939

Change-Id: I3a3a8dbf5e15d3d3e882b1f7b9a17c6f985afd9c

Change-Id: I786227d89cc441990d6bdce0acf872a73be51a7c

Change-Id: I3ec724037fae49e7e29115e5e4814c48a98e7c0d

Change-Id: Icf489a49c547a93458aeef1c70ba699181a47c38