Change-Id: Icb932ee51dbf32d8baf4382aa00e89a680f5a41d

Change-Id: Icafdd4780eebd6356bf2070ff99dbba9d6956c16

Word supports formatting the paragraph parker itself, and we import that
as a formatting at a position after the last character (e.g. "foo" will
have that formatting at char pos 3, which is ignored by the layout).

In addition to this hack, commit
1c22545e (Fix issue #i119405: Numbering
text style changed after importing the *.doc, 2012-08-24) added a
SwTxtNode::TryCharSetExpandToNum() hack to Writer core, where in case
such a paragraph marker attribute is set, and the SwTxtNode has a
numbering, then also modify the associated character style as well.

As that commit already noticed, there are attributes which should not be
propagated to that character style. Extend this blacklist to ignore
RES_CHRATR_BACKGROUND as well, as Word does.

Change-Id: Idcb40d37d8688c76fbd61f28428f6e3bc995f799

Change-Id: Ib797c84e64a114df0e80067a97b714d4f97ff20a

on deleting a full table

Change-Id: I03af8bcbae41e78229163a945a74387f53787ca5

Change-Id: Ie3044bebc7921b0fa98f9a9a01f99ef0f2d05eb8

Change-Id: Iac147aef89e7f8be2f3d16e434c76d57a950d591

Change-Id: I23c80a462ef473defe5536f9090167ae734553b7

Change-Id: I5d41b22ba5b27c278d04a70987812a281dd7dba9

Change-Id: If59c5c4901aeec404099c810a021eea8b8b3d3ab

Change-Id: I008d4190191ebff1c6c97af120b1db2707597ffe

Change-Id: Ic5e50643d41c08900377a34676c2ff17977643c0

Change-Id: I76c9ea0740223b601440ca7c7122b814e777fca3

Change-Id: Ic7d11a7ad3c643354e0bb2aaf20bda2c3e41dba6

Change-Id: I13145c4dcdf95d7979dc1887ba08a243f8b5a224

Change-Id: Ia000655f3fe49a4c9c1015b37f44c0ba44d7666e

Change-Id: I8b38d37de6cba2a29c9d785adf17d65835c8a05d

Change-Id: I6bf80d034490583afa9e51cf720703cdf60a924a

Change-Id: Iff8f992e5260150b9ba108698b506f5a9ec7dea2

Change-Id: I88b7659fdfdcba43e69ef7489573b28952c8328c

Change-Id: Idb3414291161dc50ac5b291699d7ae8672576532

Change-Id: I2f818c865345c9396b3292d9bf0f8520556223e1

Change-Id: Id0be70056645a5fa5df49aa5186e3187c719e048

The brush color contains both the color itself and transparency as well.
In case of DocxAttributeOutput::FormatBackground(), the sColor should
contain the color part, and oAlpha the transparency part.

In case of drawingML export of Writer TextFrames, an automatic color
(0xFFFFFFF) shouldn't be recognized as "auto", as that's invalid:
instead an explicit 0xFFFFFF with zero transparency should be written.

Fix the problem by calling msfilter::util::ConvertColor() for the RGB
color only.

Change-Id: I2132375a4dbcac1667aed49c74e581183178b0cc

i.e. convert "::sal_Bool" to "sal_Bool"

Change-Id: Ie5943aee4fee617bf2670655558927ed25b7e067

Conflicts:
	include/sal/log-areas.dox

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

and dialogs that are loaded from the .ui format

Change-Id: I37aea52a3973d8d8f6a2ce8dabf80bb1e64db43f

the widget in glade for changing ellipsize gets focus and when you mouse wheel
up and down often it gets accidentally changed, sigh.

Change-Id: I6dc0dc6d9985ea0ff9a34817291e642a9706bf0f

The XContentEnumerationAccess is at the service manager, not the component
context.  Regression introduced in LO 4.0 with
4381f3dd "fdo#46808, Use BreakIterator ::create
method."

Change-Id: Idb7d38b9c14beea9a9ad347e6cbc8190d7248b2d

Change-Id: Ie6b1670445fd15e2ba791b13e4b6cd6803b2b9df

Change-Id: If8560d47c5b4e64367c441237c1e38f964cf6825

Change-Id: I28719b16fb47a618420195640f4f75a79ca889ea

Change-Id: Ia68283947d954d648fa25356f2b95ba0ab7010aa
Reviewed-on: https://gerrit.libreoffice.org/8811Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: I8bcc31900a95f2b7600645decafdfe528343d6d7

In a DBG_UTIL build fill the maContextBuffer and maUserBuffer of a
QuartzSalBitmap with an easily recognized pattern. Helps catch
situations where by coincidence they appear pre-filled with zeros most
of the time and almost everything usually looks fine.

Or is the QuartzSalBitmap implementation wrong, and SalBitmaps
*should* be created filled with zeros?

Change-Id: Ib5207779f2a47b9b7e539d8646b4128fea0ec150

And use constructor feature for UNO implementations.

Change-Id: I42b6a6f417049cc8e2d44b74c7adc552680b1f2d

Change-Id: I47a758fbcfcefc2bdd1cdbb89ef219a7ebb2af47

Change-Id: I0e8524a0933114196a80317b9a427d8cd3f3e459

It probably does not make much sense in general but will be used to
optionally disable some implementations in a library.

Change-Id: Ib491b8b642907b5bb20d458cbf766c9c9a5a5111

	Issue :
	Numbered list without suffix does not get preserved after
	Roudtrip.

	Description :
	- For level zero LO was writing w:lvlText with epmty value.
	- This was because in DocxAttributeOutput::NumberingLevel()
	  check was based on empty NumberingString.
	- But for "deciaml" also rNumberingString appears to be empty
	  for level-0

	Implementation :
	- Added check to write empty value for w:lvlText only if
	  NumberingType is "bullet" with level-0.
	- This will not write empty w:lvlText with level-0 and
	  NumberingType as "decimal".

Reviewed on:
	https://gerrit.libreoffice.org/8768

Change-Id: Ic6ece45e0122da05013beac93a6e11fac926514d