Change-Id: I738401babffd38c241ef16e23d1b246444fd8d55

we still need to invalidate the layout of our parents, but we can
keep the cached optimal size

Change-Id: I8e77366bd61ff45d34f9d411c7f501a3a9ccbd4e

Change-Id: I539741e71785232987b26c7b414a416dda5e4bb6

Change-Id: Id499cb873938621762f0e213fa17505fefb33574

Change-Id: I328cf5e83e6532dfa5090f5c5e3a1568c48c11d2

Change-Id: I74e4689062d452f8e0fba115cd984aa876711c45

Change-Id: Id05fd31d3a62bec8d658b9ecbae484ac081b8960

Change-Id: I9b344efa1b46a6e7c6b69d3044ef88b4cba826cb

Change-Id: I524a14cd124e69e288de5ae8464eb611989dffde

Change-Id: I30b4036b6cf00dec753115bbc59990daec27ef20

ShapeContextHandler::getDrawingShapeContext mxDrawingShapeContext is set once and never reset.
So in a file which has numPicBullets and vml shapes in document.xml there is a problem.
First the fragment path is set as word/numbering.xml.
But when msRelationFragmentPath changes to word/document.xml,
mxDrawingShapeContext is not reset and hence the relationships are not resolved.

Conflicts:
	sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
	https://gerrit.libreoffice.org/10180

Change-Id: I4a1401103797972731257145430f2048b94a04bc

Change-Id: I9303249880ea0eb2f354fd3ae20c9eb3607a836b

The inheritance relationship of styles in Draw was lost when writing files.

Change-Id: I81588a031bf4c649338fad9b7342fbbe11df9aef
Reviewed-on: https://gerrit.libreoffice.org/10309Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

This fix contains two parts:
  * initialize NSS in the CMIS UCP right before sending an HTTP request
    in case internal curl is used. This makes internal curl find the NSS
    CACERT database from the user mozilla profile.

  * add nsspem to allow curl to use CACERTs from libnssckbi. Without
    libnsspem curl is unable to read the certificates from the NSS
    database. The nss-pem code has been extracted from the fedora-hosted
    repository: https://git.fedorahosted.org/cgit/nss-pem.git

Change-Id: Ie8dedf020480cca01bf9761382886566a1150778

We don't need this switch case due the fact we already check it
before the switch itself. I did introduce this in commit
5bd241b9 but it is redundant.

Change-Id: I24e8c946ef8b8f094daa248c701772e54790c9d1
Reviewed-on: https://gerrit.libreoffice.org/10317Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>

This element is not specified in any released svg specification.
It might be mentioned in svg1.2 but since this is not yet released/
or will even not be released ever -> ignore it.

Change-Id: Iaf5a392893070fda9e7a420bc951c8565bcfb37f
Reviewed-on: https://gerrit.libreoffice.org/10312Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: Id0b883b7d7b902c1f8e41bcf39220ef74b3488bf

Change-Id: I72d336b8aacf80f9ab6472c0948766ee56fda34f

Change-Id: I83cfa2f11e76e03b919216e8dd04d1121ea6afd8

This "end of list" flag determines whether the row insertion was an
automatic insertion at the bottom.  Calc doesn't use this at the moment
but Excel uses it to differentiate a normal row insertion from an
automatic one.

Change-Id: I6b28669d816c54d1dc1e4c106918ba688415788d

refupdat.hxx is under the ui directory.  Not everyone has access to it.

Change-Id: I3f60761e1105946ed5bd6bddb339ee9a9e7705ad

Change-Id: Ieb54e895f334361978cfc22956ab65687fb74adf

Change-Id: I127879c4f1b6d3605ff800c3f3aa3929a098fead

Change-Id: I5cb90f10112afda77e68035d89cb7026d6e32eec

Change-Id: I9fe3078e2c4ea4a63efcc3e26a090c8e3cbc7ccc

... as used by wrap polygon import, see fdo#41068 fdo#76803.

Change-Id: I4467560c2c3bbdab3fc9f8cd7a0c0b415429186c

(regression from a71a562a)

Change-Id: Ie3a44a80c720f59831bc2b1da91792fb8aa24d62

Change-Id: I89e458dbd01a45761948b64cb457424383ca5f51

regression of 3b7472b2

Change-Id: I95a30acbf4b2684dda9684f5b51b887356a940e1
Reviewed-on: https://gerrit.libreoffice.org/10302Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>

Extend d98c817c and fix default.

Change-Id: I79ad35bd5ad6fbd6e7d260864d4bf40fafb6b604

Project: help  00c49810c4e883958eb698f2f5b0d413077f14b1

Change-Id: I6cbf610123b88b29a81a33320ac2c6ce5e224486

I converted RID_DLG_LISTCOMBOWIZARD, RID_DLG_GROUPBOXWIZARD and
RID_DLG_GRIDWIZARD to .ui

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

To build a universal binary in Mac OS X 10.6+ with an Intel processor, it is better to set --with-universal-archs=intel, remember that Rosetta is not installed by default in Mac OS X v10.6 and it is neither included nor supported in Mac OS X v10.7 or later.

If we don't use --with-universal-archs then the configure.ac sets the architectures:

...
UNIVERSAL_ARCHS="32-bit"
if test "`uname -s`" = "Darwin"
then
        if test -n "${UNIVERSALSDK}"
        then
                if test -z "`/usr/bin/file "${UNIVERSALSDK}/usr/lib/libSystem.dylib" | grep ppc`"
                then
                        UNIVERSAL_ARCHS="intel"
                fi
        fi
fi
...

In Snow Leopard (Mac OS 10.6):

/usr/bin/file /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 4 architectures
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc7400):	Mach-O dynamically linked shared library stub ppc
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc64):	Mach-O 64-bit dynamically linked shared library stub ppc64
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture i386):	Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library stub x86_64

/usr/bin/file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 3 architectures
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library stub x86_64
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture i386):	Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture ppc7400):	Mach-O dynamically linked shared library stub ppc

If x86_64 (for OS X 10.8+) or PPC (for OS X 10.5) is only desired then a universal binary is not useful and we don't have to use --enable-universalsdk=${UNIVERSALSDK}.

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

Change-Id: If655b5ef94657b2771d4e05dd6a2c494aa0e587d

in table cells are part of table formulas

(cherry picked from commit b384441c)

Conflicts:
	sw/source/core/fields/cellfml.cxx

Change-Id: I4780ce0c1ac9ac911b654f61aa12938d7b225139

Change-Id: I6f6d2e7516d99a02ad813ba5e03c5cdcac2f4964

If you copy the class members on the stack and tweak those (and not
class members), then there is no need to manually restore the copy at
the end of the method.

Change-Id: I42b50cd6b99b6b277dd9809b40385ef6512ef141

The root cause was that code in
SectionPropertyMap::PrepareHeaderFooterProperties() saved member
variables on the stack, modified them, then restored them at the end of
the method, but forgot to restore m_nBottomMargin there.

The result of this was that First Page's FooterBodyDistance got set to
zero, which is not the same as Default Style's FooterBodyDistance (150),
so on export sw::util::IsPlausableSingleWordSection() returned false,
which turned the page break into a section break.

Change-Id: I1afa2603de1313ae1e2aaefd4b7c771fce27e21e

I imagine it would be best that the Graphics were delivered pre-swapped in by
higher levels in case there are second level caches or more complex caching
systemed wrapped around it, so warn about it in debug mode but give it a
last-ditch shot anyway. i.e. while the .docx problem should be fixed there
is a report of a very similar .xlsx problem

Change-Id: Ie40ee10fe5cba8ff9c321f47b83e33ee2c1425fd