Change-Id: I7000df307920b1b04b81cc4c436009cf6b6548e0
Reviewed-on: https://gerrit.libreoffice.org/12282Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

I.e. the UNO bookmarks that are used for marking where each generated document
starts inside the one large single document.

Change-Id: I8069a3110cacd34b25aff6739ab248f490c3fa6a

UNO bookmarks have internals names and ignore this

Change-Id: I37baa4c9bcf9cec37f91e3b1d0fb2fad322ceda8

Change-Id: I2172d0185a2481700ffe152e58ebd5bd9c6a4fab

Change-Id: I8673810e8c04cd128a691ee1c1e8c4731108b605

Change-Id: Ibb8859908c8e73377e1ee20b041b9ae76955d076

Change-Id: Ia72d1b2827bfb38ab39d7d0df04908874d25e124

Since that makes SwDBManager::IsDataSourceOpen() return false because
of different data sources (than the one the document was tested with manually),
which prevents DocumentFieldsManager::UpdateExpFlds() from updating fields
properly.

Change-Id: I66f5f79d9fd39204eabb247aa92ec11acef56903

Change-Id: Ifa54445c8f46bb2ed5539870c5fce1a2e62beef7

When mailmerge uses a single document for all the generated documents, doing
a layout of this increasingly large document after every generated document
addition was getting slower and slower (no wonder). My recent changes should
have removed all needs for any layout in progress, so it should be enough
to just once calculate the final layout. The final layout still appears to be
needed, leaving it as it is to get layout done on the fly puts e.g. 2-page
documents on wrong starting page (maybe just invalidating something would fix
that).
Debug build shows warnings from vdraw.cxx about moving anchor from an invalid
page because of broken layouting, but those were there already before, so I
assume those are not really significant (or at least made worse by this commit).

Change-Id: I62601ad6dccaa008783d1ce34c9e4f66f9621a56

This removes another need for doing repeated and expensive layouts of the target
document.

Change-Id: Id78bc3ccc71c17e42f858dc9660866b9c94dea3a

Instead of page numbers, which
- was somewhat fragile (and broken, as it was actually off-by-one)
- required repeated re-layout of the increasingly large document, making
  mailmerge awfully slow. The re-layout is not removed by this commit, as
  it needs further checking whether it can be removed.
See the bugreport for details.

Change-Id: Ib09bd5f5a6a549c3d38ca40b0f32c0d2831fdd4c

why should css.util.NumberFormatsSupplier support XPersistObject and need
read/write support ?

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

Change-Id: I64716c9d087d1e9d3e76d14d555768af486e8982

... so all the import is in one source file not 3 tiny ones.

Change-Id: I239316ec54cab28a7af643372af33782f70e7040

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

Commit 74c5ed19 (DOCX import fix for
table with auto size, 2013-06-26) correctly recognized that in case the
width type is auto, that doesn't always mean text::SizeType::VARIABLE.

However, when the size is fixed, then we should simply not do anything,
and that'll lead to the right behavior (by setting the column separators
on each row), don't try to be smart and try to set
TablePropertyMap::TABLE_WIDTH here.

Change-Id: I997b88e5fa34bbabe7c6940879c81a1d62d69043

Change-Id: I8b246e198f3b19e65feffb196afdecb1755a0581

Change-Id: I41e9961ae797ac99fdfb1480e1a58dbe92178bb8

Change-Id: Ibf6093946ef1dec1a2ba202917da9e4562c10d3e

Change-Id: Ie413372ab1cfc7e38570fdf65c6daca8c2cc426b

and

coverity#706196 Use of untrusted string value
coverity#1244947 Use of untrusted string value

Change-Id: I5083aba2eff9e852a24513db431585922302b279

Change-Id: I03b8404f90b6a05189591d8e3423f32810057a47

and

coverity#1242727 Untrusted value as argument

Change-Id: Ibb212c39f43bcd3f0e0ddf973d1512ed0d7c2fc6

Change-Id: Ic79bd1931ee291746b6dae138b3181d4baddbe3e

Change-Id: Id5f2c8d199ffae4f23934ceb92184562d72c0b90

Change-Id: I2f104c64601b22ce3ef078295c7da3cb21a133f9

In practice, currently possible values are ASCII, but then this string
becomes part of URLs, which are in general no longer ASCII, and are
OUStrings. Instead of trying to guess the encoding of the string we get,
require callers to create an OUString right away.

A follow-up commit could adapt SfxTabDialog ctor,
SwFrmPage::SetFrmType() and SwFrmAddPage::SetFrmType() accordingly to
avoid the new introduced OUStringToOString() calls.

Change-Id: I087ed2bb341f5aca59e15e2ef4102556ca803363

Change-Id: Ibdee512a330d4520a32a56d2f1703dc2eab4981f

Change-Id: I5a01162d2925eede97f1cdc24aa876179b8b43b4

Change-Id: I771004b7ccab3344a67e827e45bc34c22ffa5f77

Change-Id: I848505b1d4ff03779b89a08d4aeefd6ea0ff205b

Change-Id: I532a1b059239b51009ea7025fb348dcd865748ff

Change-Id: I6f9049f6b5261f6099e97c7f10d6ab6ea7eaab9b

Change-Id: Iddf7cad771d271e848ba3abc1c144b9c313cdb99

Change-Id: I7508ee67a10b43686600b41dd58c1a8a5aa90c51

Change-Id: I0082d75aa2c00daa35d8d72e44fbb6da161f9774

Change-Id: I6a166a1691e39e21a4d765ca7dd0a7fcfba8126b

It is sal_Int32 that we want.

Change-Id: Idbe34ff9c0f39ad73ed7df9185512921294b3b4e

Change-Id: I96d5dc1267af714e78e431581592e75f0bff73f4