Change-Id: I63e8925e54c48cc35e09d9cd993520d6c85622eb

Change-Id: Ia6e9594654f89cadaedc19e7c3bddc1083cf9347

Change-Id: Ia0bee4a370e130a7e6fddd7cc984c31aa9a39a5d

Change-Id: I97c0f9154828c1d3ce801482242d951de8eab7e7

Change-Id: Ia4779dba9b8068d172d47ce2aff32219634a9616

Change-Id: I7b68754b1ac2fd3bd1ca8944deeded646a2e74d6

Change-Id: I64a73fb73b16ce265cd78d76c0325db051e55e26

Change-Id: I0d4f9b14f2a41a3acb08ba1b6c13fdf1174021e7

Change-Id: I93d42ad234c4be20a4af0a2d68246699c6653105
Reviewed-on: https://gerrit.libreoffice.org/12270Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

... with unknown encoding, mapping non-ASCII chars to something that
doesn't cause trouble (in FilterDetect::detect()).

Change-Id: Ibf2a2e2fd7c0c00e55042d2ccad173fab7a1b0bd

...because rtl_ImplGetFastUTF8UnicodeLen has already checked that.

Change-Id: I17f2b80f374073934a8f0b1a97099d4dec89ce4e

Keep the fast path fast, fall back to the text encoder in case there's a
fly in the ointment.

Change-Id: I94507856a7f3170f770adb741aa1e282d0d2400c

This reverts commit 05050cdb,
not all places that use e.g. OStringToOUString to convert potential UTF-8
are guaranteed to fulfil the prerequisites necessary to use fromUtf8 (and
some places like e.g. in codemaker are happy with the best-effort effect
of OStringToOUString's OSTRING_TO_OUSTRING_CVTFLAGS).

i.e. selecting footers/headers/slidenumber/datetime previes placeholders in
master page view and pressing delete will toggle those master elements off.

Change-Id: I91f745703e43cbb4fdd037da4eab7c8f6bf9fbf5

Change-Id: If6929dfae5e284b1201da5505b9c4e5abceedc6d

Change-Id: If4edb16b2e94396249f3e2ba99381fcd8341d790

Change-Id: I862e491068ac88659bfd1cc99e7403dba2929275

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