Let's default to 12x36 cells.

Change-Id: Ic39739ec036a6e5867d31b7e05b6da12ce2e46d2
Reviewed-on: https://gerrit.libreoffice.org/16413Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

(cherry picked from commit 54106fae)

Conflicts:
	sw/source/core/text/frmform.cxx

Change-Id: I8ff1647bdf8c46d395c398c97b97066d7b128cdb

Change-Id: I0f775bdfaf6a098be25d053f87b1bcf86d533297
(cherry picked from commit a5fe6ea0)

Change-Id: I07b3a7768def547a34cbcdd8966157065605d5fb
(cherry picked from commit d3456256)

Change-Id: I1931ec139798d2f2eb956fd0590ab98ce1a65c3c
(cherry picked from commit 0c33e10b)

Change-Id: Ie57e1f5abc91286662804e7528afd062d1427fee
(cherry picked from commit 9829d6ab)

Change-Id: I6dfceb02b57d886dd8025520e5ed21a2ad46a5b1
(cherry picked from commit 8af39740)

Change-Id: I8964701bf5b1ecdb11851d7cc8540175e007dd2b
(cherry picked from commit d7eacc57)

Change-Id: I3bc993b00940732fd9ca26ccec7d025c8558516a
(cherry picked from commit b13fbaf6)

Change-Id: I4fb6c42da0c5defa1d5da4cf6f3a13d11388c88d
(cherry picked from commit 08b3b6ed)

Change-Id: Icbc5e9a42cc7e7693c6584461505a3233046272c
(cherry picked from commit 1a2705d1)

Change-Id: Ife6c7404079aa1ae10d5c2bdbe77629e0689b167
(cherry picked from commit c369f864)

Change-Id: I7acd380d2e199f042dca61d95596c3bc63c6a206
(cherry picked from commit cec17a46)

Change-Id: If36b6fdda54dfbe6e4eea14883d659302a1db6be
(cherry picked from commit 85cd7a6c)

Change-Id: Ib506b912752a16c514958896aa16b310f8e09200
(cherry picked from commit 7b632947)

Change-Id: Id9e9aa312d8fd4e0d776b41c9cca8073fa57b6fa
(cherry picked from commit 3b7c803b)

Change-Id: If861aa0a579eb953cd2fc7b790b3514ab1d0ffd0
(cherry picked from commit d7dd8bb3)

If the caller has a vcl::RenderContext already, use it. Otherwise just
use GetOut() on the shell in the caller for now.

(cherry picked from commit 702cb2b2)

Conflicts:
	sw/source/core/crsr/viscrs.cxx

Change-Id: I8070dd3d6622d211885067514d6eb728716830ee

Change-Id: Iccadf6cd95a0ed9f9ba365d117d819f065193e60
(cherry picked from commit 5cfc0e38)

Change-Id: Id6bd21deda59a6eecfff39907d967b78b881a1e6
(cherry picked from commit 74768909)

Change-Id: I70218bc41df0d56ab42d652aa7ac51733dc06f4b
(cherry picked from commit 71dba79c)

Fix provided by Abhimanyu Singh

Change-Id: I5d87aa76517b1cf9d7464f43b9be236de0e92039
Reviewed-on: https://gerrit.libreoffice.org/16452Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit d2d18465)

Reported by by Abhimanyu Singh

Change-Id: I02bd2a2b85b9d55f0b237d3a1141801245473cd2
Reviewed-on: https://gerrit.libreoffice.org/16453Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 64b636b8)

Reviewed-on: https://gerrit.libreoffice.org/16456Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit c301d8c8)

Change-Id: I120c33bf726150506d282e972facd4dca0db83aa

I took example from https://mail.gnome.org/archives/commits-list/2013-June/msg06434.html

Reviewed-on: https://gerrit.libreoffice.org/16432Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 25befc0a)

Change-Id: I5fb090c3245848c92238f34259f1a2f77f9080c7

Change-Id: I96dbe2c1213c78da1114f9270953334a38c7b2ae
(cherry picked from commit 6a01c784)

the dread msword column limit

Change-Id: Icbf7fc396de62286d523516da815dabf62336567
(cherry picked from commit 20e64b60)

Change-Id: I1a74a5f1877bfa72818ff0a38788eafe77eea581
(cherry picked from commit 89c85a4b)

the curious case of ooo72950-1.odt which has no nodes in the first line of the
table as seen from the visual layout perspective seeing as the table is split
over two columns with the second column portion of the table higher than the
left column portion

Change-Id: I38526bf80ff8cef1688aa5f5f686e437c4a3d6e5
(cherry picked from commit f81c775b)

digging into the crash on export of kde216114-1.odt
reveals various horrors

Change-Id: I0d24fe303d561a00a08098b306d10fd8273af928
(cherry picked from commit b04e1e79)

Change-Id: I9490d888ad148caecba034ef12b7398ae5c66a3f
(cherry picked from commit 169cd9f6)

Change-Id: I78478de91473681fd8d836293dabe7b790dda516
(cherry picked from commit 80fbd731)

the enhanced-path contains decimal points so the
last element is a double not an integer

Change-Id: I90be76a2d4cb90ee7a904aa72fe65770c675fc53
(cherry picked from commit aeb52a85)

This old-school table has three rows in it, but the second row is of 0 height
so is indistinguisable from the third row by layout positioning, so the
WW8TableNodeInfo view of the table is that it has two rows, and the comparison
of being on the last row is done with the m_xTableWrt->GetRows view which
considers it to have 3, so the table end marks are never output.

add a new finalEndOfLine property that the WW8TableNodeInfo sets on the last
end of row of the table as it sees it, which should resolve this.

old style tables are a cess pit, which is why they were replaced

Change-Id: I996aa59a338a594487f49ec0f228af3fb3032d15
(cherry picked from commit 6f9b3532)

This is more of the horror where the table in the frame has its cells out of
visual sequence, extend the previous fix of this kind to accept cells within
the original unmodified selected range

Change-Id: I6e8220f712fe9de5d4b98fb3cb5ed67e3762e929
(cherry picked from commit 60f8dd78)

Change-Id: I76d50a135153a7022b481e4025f9b5f948ce7efa
(cherry picked from commit fce7587b)

This is a horror where the table in the frame has its cells out
of visual sequence, so the last row appears before the last node
so on hitting the last node we have to really jump backwards to
a previously skipped set of nodes to find the end of the table

Change-Id: I93545e0c425267647d5f048c3bd95fe0cfddf8f3
(cherry picked from commit 89a28f54)

only bump m_nFieldsInHyperlink if the field isn't erased
from the stack

Change-Id: Idb75d087f6fa3ce3cd399623d8ace1e7f3899b5c
(cherry picked from commit 77df4faa)

Change-Id: I94a11bd24ccbc550c9fa555b1a0b5493ccd9f904
(cherry picked from commit 9d0c6308)

no logic change at all, justs makes it clear the dubiousness
of this unconditional increment

Change-Id: I32e3cb2c45b1b45826a59642c33ab850d698c206
(cherry picked from commit 6d50c6cc)