Change-Id: Iba0ad5ae72920f27e8a443a043c5891b102aee98

Change-Id: I9b4f9009c29276054ff94a427adf51c2094377b5

Change-Id: Ifad0a8ae01386db80a5eca9dfba8ee6841980139

Change-Id: I5b8c7901266ae73d95626e98116b9a3b43710642

Change-Id: I2e6e2a98bbaf515ececa75948d6b20bf9a093fe5

Change-Id: I6be5df685575c6909d4adfcee0ccc4fb0bd4b600

Change-Id: I6cab01b0b82f7b82fff617715c5af45d23c536fe

Change-Id: I8fe133dd8d1f759fbe21d47ae358c0b5451812b5

Change-Id: Idc58b314a0721507e80e7b0e6216f29090f1d347

Change-Id: I8be50fb82d1333731dae825b1785e981fe69adbd

Change-Id: I508aeee3176caea7e61ba95198233f14d3528de1

When building with MAC_OS_X_VERSION_MAX_ALLOWED <
MAC_OS_X_VERSION_10_7, <CoreData/NSFetchRequest.h> does #define
NSPersistentStoreRequest NSObject (i.e. as a dummy) and does not
import <CoreData/NSPersistentStoreRequest.h>.

But <CoreData/NSIncrementalStore.h> doesn't do anything similar, it
imports <CoreData/NSPersistentStoreRequest.h> unconditionally. So if
<CoreData/NSFetchRequest.h> has already been included by then, it will
end up quite confusing.

Change-Id: I9de6885ea444a73bf5fd50aa6a3d132b9fcc2f31

Change-Id: I1f9810b1230c4e3e5ca0571e5392297c1daf6a47

Change-Id: I8dcd71b73204d37d3125e38b6983af430fa4570c

Change-Id: I234c615d9d3386da2b244709add5c029b76d346c

rsvg_handle_new_from_data calls rsvg_handle_fill_with_data which itself calls
rsvg_handle_close on success, so we don't have to.

And older versions of librsvg (e.g. 2.16.1) don't protect against
rsvg_handle_close getting called twice, although new versions do,
so we crash on e.g. RHEL-5

Change-Id: I451075e50c9c2c7b07289356d7a92eb55db82f9f

Change-Id: I4d0d9df26de1ef52a808c82d89a8404c98ef7bc4

Change-Id: I6218be1f4afe22665ab85f7d731e1c1567bb2c8e

Create a table with a merged cell like in the screenshot in the
bug, with a SAL_DEBUG in SwTabFrmPainter::PaintLines the following
lines are painted:

debug: paint start
1 debug: start: 2749,1488 end: 12387,1488
2 debug: start: 2749,1945 end: 7567,1945
3 debug: start: 7567,1945 end: 12387,1945
4 debug: start: 2749,2015 end: 12387,2015
5 debug: start: 2749,2542 end: 7567,2542
6 debug: start: 7567,2542 end: 12387,2542
7 debug: start: 2749,1488 end: 2749,1945
8 debug: start: 2749,1945 end: 2749,2015
9 debug: start: 2749,2015 end: 2749,2542
A debug: start: 7567,1945 end: 7567,2542
B debug: start: 12387,1488 end: 12387,1945
C debug: start: 12387,1945 end: 12387,2015
D debug: start: 12387,2015 end: 12387,2542
debug: paint end

*11111*11111*
7           B
7           B
*22222*33333*
8     A     C
*44444*44444*
9     A     D
9     A     D
*55555*66666*

The problem is obviously that the Y coordinates of the lines 2, 3
and 4 differ; they should be on the same Y position.
The problem here is that logically horizontal lines must be painted
not centered but "below" the line, and It turns out that
SwTabFrmPainter::Insert cannot correct the positions properly to
do that, because it only looks at borders in a single cell.

When using the UI to set the borders, we get (for innner table borders)
only a bottom border in the cells, but no top borders, so the
top position of the logically vertical borders needs to be corrected
with the width of the bottom border of the cell _above_; a symmetric
correction of the bottom position to the top border of the cell below
is also necessary.

Fortunately if we just leave the positons alone in Insert then
TabFrmPainter will eliminate duplicate lines with equal positions
and so it's only necessary to correct the positions when actually
painting the line in wTabFrmPainter::PaintLines,
where we have the neighboring lines available.

Change-Id: Ia8519f6673db0f3a1ecaa68038896cac39609129

So use the avoid-ATSUI patch dependingh on (the newly added)
MAXOSX_SDK_VERSION, not MAC_OS_X_VERSION_MAX_ALLOWED.

It is not clear (to me at least) whether for instance building against
SDK version 10.7 but with MAC_OS_X_VERSION_MAX_ALLOWED=1060 ensures
the resulting binaries actually work on 10.6. Somebody should
check. If it doesn't work, we should add a check to configure.in that
the min-required and max-allowed values are not less than the SDK
version.

(If it would work even for MAC_OS_X_VERSION_MAX_ALLOWED=1040, we
would not need to require the increasingly obsolete Xcode 3 and 10.4
SDK for "official" builds.)

Change-Id: Ia7088a26024ed288db55fa734465138d44d2ae12

Change-Id: I3c1137bdb1186df773a92c34267b2324ad43ae7e

Change-Id: Ie355701716c7106ef2afd76ae8b6544a00ac474c

Change-Id: I79d71c682c07f49b70c6791953c000868bf65cd9

Change-Id: Ie8174ae4b7d2c02503f40fe1263076d924f2c9e2

When compiled with Clang on OS X, the OS X dynamic linker appears to be
confused about which FieldEntry destructor to call at runtime. In some
cases, the FieldEntry destructor in register/source/reflwrit.cxx is
called instead (both destructors have the same symbol name). This patch
avoids this problem.

Change-Id: I7d69894318cb8fda0a7c5a9b1c2ff3ca0d47a37c

some big hunks melting away now

Change-Id: Ic74870cad06a2322e98bf1a66287a9b29a7b003e

since 6d619839

Change-Id: I8c08088453027ab7aa0ca964262456475f767a5f

Change-Id: I38c92dad50fd13dcd32a07feed860eb60349c080

...instead of sal_Bool, to work around MSVC warning C4805: unsafe mix of type
'sal_Bool' and type 'bool'.

Change-Id: Ia3477539ccc23aa9daec49d633f023d414f2b4bf

...where a local variable in a nested class shadows a member of an outer class.
Fixed by renaming the relevant outer class members as "m..."

Change-Id: I6caa33914ff1060e08f66eadde879fb7b4e3e7cc

Change-Id: Idf923e4a1e81a2e2e9c7107e4b6725bd9eb33e38

Change-Id: Ib7d7860cd422b28b6987f94da0a9c664ff7dfde1

Change-Id: I51caaca911f71788940260bd63d3854526d7473f

Change-Id: Id384aeda51bcbba9aefdb242db386a30ae991c30

Change-Id: I127776bc0a1583107591c9a7abb7c2a5036c5839

Change-Id: Icf73d7fd29900a59652b32060e0d66db5c75ad32

Change-Id: I04cda5ba5b248ef7938d36b5af6003ac89642e42

Change-Id: Ie2c3dae7ebe3181cb8bb85869882a4eed4a07c14

Change-Id: I7c4cb1a5f31ba9e37a280af2243a13c57914cb2f