Change-Id: I1d07802f2671c460dbe145c4d5178aff272ca091

Change-Id: I806058555f58a3f03153372e581fae6d8cb0670b

Change-Id: Ifcce7f0d75cb595add30a4403e5c42348043137b

Change-Id: I1efe68a3b63ddd4b1583a29dd8d71d217bfdd9a8

Change-Id: Id9ac29ec88a98e626a1ecfb364e474b2a11a8004

Change-Id: Id9d014d01d4c2da2d2c421893ba49a4b2fddacc0

Change-Id: Iedee81b4c0474a1bbda0b2366c246f6b6b433a10

Change-Id: I6abb408c91c9d6ea2d60c328be221c7608a7906c

Change-Id: I51b3e9bccbe54686fbe869ce5ba669d000530572

Change-Id: Iacf4373221b93a97e030b09501cc91589f2fdff7

Change-Id: I118771b78d83441202c15d3b08b9055ba5e63623

Change-Id: I8a829ee5d36281098f2788a704b203e6b777d371

Change-Id: If4c218c471b34e2f0c8f083131bc24f1ac9d48e3

Change-Id: I11aa7ecfa52054085aaca70b165a831b5ec8577b

Project: dictionaries  d478664ac0a8e8997d8d17a76a39d2704f7a254d

It would be possible to modify the condition in
SwChapterField::ChangeExpansion() to check for rTxtNd.GetNumRule() as
well and make the bugdoc work again, but do we really want to use
"chapter reference" to refer to plain numbering?  Perhaps it would be
better to add a "numbering reference" field type; without investigating
what Word actually does here and what the actual problem is that was
supposedly fixed here (which is not possible given there's no reproducer
document) it's best for now to just revert it.

(regression from commit 63198037)

Change-Id: I7eb9ea46e42729c53c350ff450d49a1eb84ee8eb

Change-Id: I9bfbde0f5abad6d6f297fc18e24f6b20be914ce4

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

Sure, not a lot of code, but best to not even compile it, to catch
eventual usage attempts.

Change-Id: I7462ea9a5fbe6080fcec2f424d1a1b80ad0afe21

They won't be used for now, but just to enforce portability of the
libgltf code a bit.

Change-Id: Ie5d2b9125eb0f4a2e432dcb8b55d5f494a5ed34d

Change-Id: I7060ae18a98e0793a936834b398f1e232d336672

Change-Id: I0dacaa9fb08062aba758613bd25ebcf7039f36e0

Change-Id: I5a918a6ae4159dd561e46116f612037e194a4847

Change-Id: I66d7c8444c1a89c21ea2ce5e42fb3cd97fd39b7c

The code here counted the numerical XOR of the two pointer values, but
most probably the logical XOR was intended (in case only we or only they
have a node index, then we are not equal).

Change-Id: I261b8c4b498eb860fa0e0fa72ba5a5e0758064e6

...so declare them as such.  This avoids the recurring mistake of storing such
IDs as sal_uInt32, truncating in 64 bit environments, causing RemoveUserEvent to
potentially not remove the event, it thus firing "too late" and probably causing
a crash.

While at it, consolidate the trivially unnecessary overloads of both
Application::PostUserEvent and Window::PostUserEvent.  And in each of them, it
looks like deleting the mpLink member was missing from the failure branch.

Change-Id: Iab13afbb06e12ac15dec6a6b5b85a7e402a3c654

It won't be used for now, anyway, as libgltf is used only in avmedia and we
don't build any avmedia for Android. But just to make sure the code stays
portable.

Change-Id: I7a4e5ee3d22f28a407d400a65a1704c23dcb1107

Change-Id: Ia02481046640248bc8a62ab0f93bf4e0bb49cca8

Change-Id: I6a2e0992077b185107f8d7190478d95f8d898e9e
Reviewed-on: https://gerrit.libreoffice.org/9266Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Maybe this can be completely replaced by SfxEnumItem

Change-Id: I049dcd3e5a03f859f8b1dddad801db4ca772ef6a

	Issue :
	LO was exporting DOCX containing MultiColumns with additional
	Section break Continuos.

	Implementation :
	1] Added check for Column_count in MSWordExportBase::WriteText()
	   If Column_count > 1 and Text node is empty then do not
	   export Section Break.
	2] Written Export unit test case.

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

Change-Id: Ibf3e6bd2d4827aa77a659b1600939cc56d65a63b

Change-Id: Ie49a9e20f72c8e2f81b2d169f5fd19964811c193

This causes crash with dbgutil build, and I'm sure would cause issues with the
release build as well.

We now use broadcasting to handle reference update during undo of block move,
so this old way of handling undo for block move is redundant and obviously
causes issues.

Change-Id: I9dcbb9d9e3808da3f8510eab16ad21b626f881d9

Change-Id: If2ec3ba8fb6b5affa7e20b4586a60852e2b818df

Change-Id: Ic7ac1a1bc3ac3901c844ee6e1c59a1518043f761

I have renamed ImplInitAppFontData to InitAppFontData and moved it from
Window to Application. This is because this is something that sets
*application* global variables, it just so happens it gets it from a
Window parameter. But it should be set when the application starts, so I
have moved it to Main().

This was previously reverted, but I have since located what was causing
unit tests to fail and the font dropdowns to stop loading in writer:
see commit c6d7ba5f33c3 where Application::SetSettings() was setting
pImplSVData->maGDIData.mnAppFontX to zero.

Change-Id: I5da7073b0d8541f1a71a09b0a8337d012fc4134b

pImplSVData->maGDIData.mnAppFontX is *not* a flag to determine if
application font dimensions should be reset. The way it currently works
is:

1. Application::SetSettings() is called to reset Window settings,
etc.

2. Settings are updated on all windows - but at the same time
pImplSVData->maGDIData.mnAppFontX is set to zero as a way of indicating
to the global function ImplCalMapResolution that we need to get the font
from the first window, or if this isn't available then create a new dummy
WorkWindow and use this to get the font data, and set the application
font to this.

This is very odd. What we really should be doing is calling on
ImplInitAppFontData directly from within SetSettings() instead of making
ImplCalcMapResolution detect that mnAppFontX is zero and there is a
valid first frame window.

Ultimately, this was found when I commited f76026a4 to move
ImplInitAppFontData from Window to Application. Somehow I entirely missed
that the font and style dropdowns in writer died, and I also somehow
a whole bunch of tests failed but I again didn't notice this either. With
this fix, I should be able to recommit the previous change.

Change-Id: Ib526954962fdc397fb3ddd3c21ae947d939db9e5

Change-Id: Ifffcf30f68aa4486e22211d9dfc5ad6d77346a85

Change-Id: Ibc7262921173036297c670fda3c68c6d77b9853e

Change-Id: I70d71bb21ff43aeb49339ff1f1d9e73c923e0201