together with SfxPopupWindowType enum.

Change-Id: Ia0b2388b34c96bb044f1bfcc7e89b33ac37d5f95
Reviewed-on: https://gerrit.libreoffice.org/16766Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

(thanks Julien for spotting!)

Change-Id: Ifd9f908d1fe3cde8e926dae72270d6c7dfcfa234

While an S is already used in this file, it does not conflict
with this command from Math’s Tools menu.

Change-Id: Id69ade4b076e53b680395871b5bef34afe1c6ecc

... lets reduce it to somewhat bearable levels.

Change-Id: I2d17b313dfd151b3572ea1250613b73ebc20dbcf

Change-Id: If3ca55d4dc42975785a4978e473ddf78e7713912

- first, actually use the selection in MergeNew()
- secoond, bring back GetSelection() for that
- third, throw away lots of the old (dead) code that mostly just
  stumbled over itself
  - e.g. ExcludeRecord() wouldnt work on the last element due to a
    off-by-one error

Change-Id: I07d07e086b748b393f2ada7cb22fdb2ce285ad65

Change-Id: I3560bc689b2ffd44662678b62e18ce047efb22cc

Change-Id: Iaa59e208ed383ed9805f30ec177dd27a38c95773

Change-Id: Id7c9b359697613547040c9694c03a427f89f35c3

Change-Id: Ib3265d3e3d997251b4c5503e17271b70c8378226

and

coverity#1309264 Improper use of negative value

Change-Id: I496e92211b9ca0a7a27a7f00d17cff428cb3b42b

Change-Id: I0d4f924ded1285b83adb0d9672a63d243c4df7e4

Change-Id: Idea3a9f3465387680b814dc53ed4c0b13265f9f6

Change-Id: I296e3b928577b521d6c21bbfe812a451e56822dc

Change-Id: Ia2738454eebd768403ea19f7f231d43dabbb38e3

Change-Id: Ic13df34772a448f654924ca6076cb5bc92ea3883

Change-Id: I879b55c919edff1e146edd8a83bce6e5e9e699b5

Regression from:
f7424ed7

Change-Id: I7665d579696f21846abaed21ca8c4f14acdc964c

Change-Id: Id544bdf639151ff3d9a164c52977acc6022cede9

Change-Id: Ib01e794b70d611f68ab4a7c048860b28b2dca99f
Reviewed-on: https://gerrit.libreoffice.org/16676Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ic80b123bff60a0d6d5a01ba1620673c8d6360023
Reviewed-on: https://gerrit.libreoffice.org/16754Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ida42c6c0642973ada04d387dafc3ea62703cb50c

Change-Id: Icf362281c54509211b08c8bf5e29a0e31d9eb835

Change-Id: I75b4ad61785bf0ba1cb07735d938c0977356b8cc
Reviewed-on: https://gerrit.libreoffice.org/16705Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

Change-Id: Iddcc22f62ea134ea797292daa02e47042d52d0d1
Reviewed-on: https://gerrit.libreoffice.org/16710Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

Change-Id: Ic6415423f46aaee7ba90239a617c318cf92ae222
Reviewed-on: https://gerrit.libreoffice.org/16711Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

Change-Id: Id9296115f30858e7fd470a199e59343a96d7deec
Reviewed-on: https://gerrit.libreoffice.org/16712Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

regression from

Change-Id: Ie12713778112d1c6ddc9ed817af3998a3dcd9ba8
crashtest: don't crash on layout of ooo70429-[1|2]

Change-Id: I8b0a6c3323a4ffbe6a1ba09e5cff9ddd92ed49f1

This reverts commit 4a0cb642.
MacOSx only (more exactly CoreText only)
The handling of DXArray was buggy and need to be re-worked
so this revert to the previous case where DXArray are esssentially
ignored at the char level and only kept at the fragment size level
and used to redistribute space in a fragment

This create some issue too but on more esoteric case than
the one noticed in tdf#88941

Change-Id: Icb33d0600267c3136f3a6b15de8ecd739898ce04
Reviewed-on: https://gerrit.libreoffice.org/16747Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>

... the maMarkStack, which causes the order of calls to
startFastElement()/endFastElement() to differ from the order of the tags
that are written into the output.

This is an attempt to improve the assertions, but if an assertion fails
it's generally not obvious where the problem actually is since the
unpredictable order may cause the problem to be detected and reported
much later than its root cause.

Let's see if this finds any new problems in export testing.

Change-Id: I97699cc8ef9b18ea9f4f221d5210134feecf0336

This reverts the changes in FastSaxParserImpl from commit
16e8ffbd and instead fixes the problem
of inserting string properties with empty value locally in
OOXMLDocPropHandler.

This change was not wrong in any obvious way, but it turns out there is
one doc rhbz583386-4.docx that, when imported with this change and
exported to DOCX again, results in a non-well-formed document because of
some weird SDT stuff.

That problem is rather baffling, but unfortunately the
DocxAttributeOutput usage of FastSaxSerializer::mark() makes the DOCX
export rather un-debuggable, so avoid that problem by reverting the import
change for now.

Change-Id: I0d874cbfe82d4f15d58b50116dda152341bdf7b0

Change-Id: I458f8e8665373d3e5ab9ed20e39783f4d34ca128

Release the accelerator, and cleanup global references.

Change-Id: Id9931527f1b6d89067bc1e520e521ccfa6e28197
Reviewed-on: https://gerrit.libreoffice.org/16740Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

- crashed due to out-of-range index with empty vector
- kill pruposeless manual index fiddling for good
- add trivial test

Change-Id: Ic224c70f432d2b26718e05aa5a2742461cfb7bec

- the previous code tried to avoid breakage from changing an
  implementation detail
- this turns out to be harder than expected in a Python2/3 portable way
- also it would mean the intentional drive-by documentation of the
  expected implementation name will at least not bit rot now

Change-Id: I5972d0e79ef64abe30573182c5e23268e4830ade

The bool simplification from 3ac5138c
accidentally changed the logic of the return statement

Change-Id: Id6075356184e340dc970d2e59d1fb1d1a173d0a7
Reviewed-on: https://gerrit.libreoffice.org/16724Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Id545f3447472a8e6ee137a6630ee14b45a45d673

Change-Id: I43397f2b0caa31c334f87acf11fc96df2e051ad8

Exporting linked textboxes to docx format is in terrible condition.
Spacing, textboxes instead of frames, duplicate links and orphaned
shapes lying around, not to mention being being unlinked in MSWord...
This fix resolves this situation slightly: what LO saves can be
re-imported and re-saved without breaking the links - an incremental
improvement.

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