Change-Id: Ifbabb338739ae452bee6cac73e4b2046356a4d17

Change-Id: Ic93c6306cc90a8c7ed77c0aa7d5a898ee911b75f

The constructor of SvxNumRule initializes aFmts[i] with a format but
always sets aFmtsSet[i] to false, so SvxNumRule::Store()
and SvxNumRule::SvxNumRule(SvStream &rStream) need to be able
to round-trip that combination to prevent spurious numberings.

It is unlikely that this class is serialized in the table auto-format
files but i haven't checked; this change does not change the size of the
serialization so shouldn't cause trouble anyway.

(regression from a95cce27)

Change-Id: I589ea108ac069624aaa7b26cdc3bfe8182b15851

Change-Id: I04c87c5299559932733c88a317808241fd1755d4

Change-Id: If5c203844d245f370ac6fdb52c779561fb5f165f

Change-Id: I1a1e38dd36b2144a3e6b96886a56a11a023c47fe

Even if the symbol font bit isn't set, the oox import route lacks the ability
to state that the bullet font is a font of symbol encoding. If the font is not
available on the system we go into fallback logic to state that famous symbol
fonts are in symbol encoding. But there is a symbol font on mac so its not
unknown and that doesn't happen. And the mac symbol font is not actually in
symbol encoding (seeing as it's all rearranged into the correct unicode
positions) so the recode logic is skipped in this special case to map the
microsoft/adobe private use area chars to the modern code points where they
were moved in the apple font.

I guess one alternative possible solution is to lookup all the fonts used in a
openxml doc using the fonttable stream where the charset info is available. But
seeing as it should only affect one particular font lets just move the encoder
test outside the issymbol block.

Change-Id: Ic5bd3ec15c8d8d99e2cab0fb67cc4bc33081c756

It fits better this way.

Change-Id: I139de7858e999a6dd26633a548c47634dfad8a65

Change-Id: I35ac8e9480a7540e049dc251a1470a27f0c2eafd

Change-Id: Ib5177530b7af15a5574245f53acfecd0ccce4b50

Change-Id: I3eef26d4ad07a93e044bf8dddddf2d922849435d

Change-Id: Icf4746d70488bec20b4c47fc65fa989cfe90992b

e.g. when growing m_aRow from size 3 to size 10
(that is, columnIndex==9),
the old code was initialising only position 9
while it we need to initialise all new positions,
that is positions 3 to 9.

Change-Id: I6a51b816104e33fdd7773b68e254e9bea50110ef

fillColumn is the only caller of impl_getBookmark, so all necessary
setup (in particular ensureCacheForColumn) is already done, and
does not need to be done in impl_getBookmark again.

Change-Id: Ic78b7dabd7c536abd9ed956baa178d685a63f713

Change-Id: I121e0bd6004a736c7a64fb24ebc58ad784543bd1

Change-Id: I1851e4eb821d1230df7268378c786d55a8652f9d

Change-Id: Iddfe959568f73f71827d9c1c651087ec93cbc941

Change-Id: I459a9aefa65cb1e3e65e128bf9e2e323768acade

Change-Id: I70d5ab9bacdeabe6c4edf6f70a9ba283b46c180f

Change-Id: I99bac2cfde956d2b91dce33fc12ce9044a9c219a

Change-Id: Id5e2aab669ba047e9ecb392187aae7c4aa384dda

Change-Id: Ic27e886643128edeb5b2d5c81e86681f4dd8d33b

Change-Id: I88f47ee442ade499c7f4018ce8b1ffe54b362067

Change-Id: I8a6c9f335574196a50827db7eb44b82f9ea4df16

Change-Id: I2a36296e1210e349a7b53d999a2438aa45f3e2c2

Change-Id: I88be91690f11bc11d70bd54310d0130723245286

Change-Id: Ife3694e9432141e638d8f6050f4e5335c254cdbf

Change-Id: I0e67eec9efa32c1d3d3f8d3ad3845368822bb0ee

Change-Id: I74b4085394955906e075d77bc761dbdc92d06182

Change-Id: I817b2cf9a015709d90b3f1c22290bce0cbc31eab

Change-Id: I73024a91740dbfde6df78c5388ae4861a6e44294

Change-Id: Ib5a880698dd6faea9a5b592221f2b302889bfc24

And a new test case to catch it.

Change-Id: Ie51ddf185f70c656e7d838fc7016b5726efbdf3f

Currently the hsqldb and jdbc sdbc drivers are broken due to this.

Change-Id: Ib49cb2aac707a354f6de9e4c658f9baf288142fd
Reviewed-on: https://gerrit.libreoffice.org/5666Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: Id28fb53a98ff164cd14f8f9dcb4ebee7a71bfd1e

(cherry picked from commit 2178fea0)

Change-Id: Ib83d10bcd2d0950fbb8afe8894caa9c0b60e6a5d

Change-Id: Ief0109289c6dc70b51193fa5f4432efe2b48c3fb

(cherry picked from commit 07302c14)

Change-Id: Iba5303085bf4d6fcc79c0d04197429c436666e15

required due to 45a8eaf9

Change-Id: Ibffc9b4a5eaa8ad538ce53f0389519721fdbcf20

The bugdoc has a table with a single cell, and also a nested table in
that cell. Both tables have auto width. The problem was that the width
of the outer table was too large.

There is a trick in DomainMapperTableManager::startLevel() to get the
cell widths at the correct level: do the same in
DomainMapperTableManager::endLevel(), and that'll fix the table width
problem. (Because with that, the outer table will correctly have access
to its cell width.)

Change-Id: Ib750f0475364fd7e47c445cb54f2df34f3af085d