At least the ones detected by astyle, as requested at
<https://gerrit.libreoffice.org/10351>.

Change-Id: If87d847f260b4e7ed71115bd8cc1af55cd349b02

Change-Id: Ic014db043a08fc2b82c56e6a1f944c9403c441d0

This avoids the flashing window even on Linux, while making such tests
headless would make them fail.

Change-Id: I7cf8d410e257574f0177ca8b7e6465a5efd62280

Project: translations  1b5734b51f56352171d54cf8ac0a05015b23983f

And avoid some strcat's when at it.

Change-Id: I0c70ee2a1abf0c9e2914f756b06bedc3a16df19b

Instead, we need to make sure it works with libmerged too :-)

This reverts commit 4e9d8ca4.

The problem was the following: due to borders, the LR space items were
not equal, but we still want to merge the page styles, as they only
differ due to the page border.

Change-Id: I55069368edba27ab9c70421e5e71ca24c73350e9

Change-Id: I01d7a56d9d90d015eb6c897e4d3fca359961b01b

OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients
have just a start and end colour, plus an optional uniformly coloured border
(on the "start" side). In addition, LibreOffice has the "axial" gradient mode,
which means the gradient is reflected in the middle.

It is thus obviously impossible in general to losslessly map OOXML gradients
to LibreOffice ones. But let's try a bit harder than earlier to get visually
more similar result, in at least some simple sample cases.

We look for the widest gradient segment and use that for the start and end
colours of the LibreOffice gradient.

Also, map an OOXML gradient to an axial LibreOffice gradient only if it is
symmetrical. Also, use the border property when suitable. In general, look for
the widest OOXML gradient segment (once a segment corresponding to the
LibreOffice gradient border, if any, has been accounted for) and use that as
the LibreOffice gradient.

Possibly some perceptionally better heuristic should be used... Like, if we
have a three-segment gradient, with a wide gradient segment between two
visually very similar colours (for example, two shades of red), and a narrower
segment ending with a visually very different colour (for example, yellow), it
probably would be best to represent that in LibreOffice as a gradient from the
first red shade to yellow, instead of as a gradient between the two shades of
red. Or even, if a first or last gradient segment is between very similar
colours, equalize those start and end colours, thus using a border colour in
LibreOffice instead. The possibilities for bikeshedding are endless.

I am sure there are instances where the old code (by accident?) produced
visually more pleasing results... But hopefully this works more pleasingly and
consistently in a larger number of cases.

Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab

When we update boost, we should use boost::intrusive_ref_counter
in non-threadsafe mode instead here.

Change-Id: Id63610bf14d7fcb7f681e009a5ac6e4f8e077a81

Change-Id: I350bca3544680ab8227d3bb1c093cba981cba5fc

Drop a couple of unnecessary forward declarations for classes defined in files
included earlier from the same file.

Change-Id: I9a0a24f88990447d7eafe0438f3713e58f649cf9

Change-Id: I947bc5867a6b61a923d47cad48d04ab5fc2769c9

The old code only run detection if an UCBContent property was passed.
That means that any time the function got only InputStream, it claimed
that it was a Keynote presentation.

Change-Id: I377828229e7e95384257bde247612d7768307581

Context is correctly created and the OpenGL calls no longer crash but it seems that I still have a buffer problem so nothing is shown on the screen.

Change-Id: Ia9cc585cd92c6049197dbfa47a41e30e130739ed

Camera moves by click and drag, with checking the last mouse
position we can make sure click was done inside the window
before drag.
Resizing can trigger drag event, but not click event.

Change-Id: I9e8b70fcb4a0abf26e76e03cafd026f940eceb10

When viewport changed it is necessary to resize the whole scene.
Calling releasFbo removes size dependent objects and triggers
creating the new ones with the new size.

Change-Id: Ibd8be1e92be92da31add4a30aa799f0995b1cc88

Project: help  a8c8f80b933a42a284e681c1d1973166445a4451

so give them the known final size to work with via a non-layout aware tabpage

Change-Id: Iaae3abfacd78ebc8bcc3ece54ed0603a4b28b9e9

Change-Id: Ie8a93a51096471d9d40644741fe3359ee016efe1

Conflicts:
	cui/source/inc/treeopt.hxx
	cui/source/options/treeopt.cxx

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

... in order not to be imprecise. Also, restore Title Case: enough trouble
(for l10n teams especially) is this case thing, let's be consistent.
See https://bugs.freedesktop.org/80373#c12

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

(cherry picked from commit 3b13e15a)

Conflicts:
	svgio/inc/svgio/svgreader/svgstylenode.hxx
	svgio/source/svgreader/svggnode.cxx
	svgio/source/svgreader/svgstyleattributes.cxx
	svgio/source/svgreader/svgstylenode.cxx
	svgio/source/svgreader/svgsvgnode.cxx

Change-Id: I5cfe6871ab235305f206d83d643884b493901dfe

Change-Id: I764f6472903e6aebef55af1e96c4941e8429d18f

and

coverity708511 Uninitialized scalar field

Change-Id: I05b5d836f3a207e70f8fff84524866a54a15daa2

This was already documented in the code, but first it got copy&pasted
several times, then now it's "hidden" in a header, so not so easy to
find.

Change-Id: I6c6814a14bb6208d9f31ee66f0c0f9b843ee7157

There were two problems here:

1) Citation field was around a run, but was exported as around the
paragraph.

2) The SDT properties were discarded, as they were inserted into a
character context that was thrown away. To fix this, add a (character
properties) context to the field state, so when it's inserted, it can
have the requested properties.

Change-Id: Ic36deff616060f049147874633c6c7264ae8ecf2

Instead of checking the third paragraph, remove everything else from the
bugdoc, so checking the only paragraph is enough.

Change-Id: I74e8db16cb1f27370ac88d9dff136aaeceb63cdb

For shapeType PictureFrame, a default CustomShape was created and then
RTFDocumentImpl::resolvePict() crashes because it actually operates on a
previous shape, because in this special case RTFSdrImport::m_xShape
is never actually set to the new shape, so contains the previous one.

Also the new shape needs to be added to the draw-page, at least
otherwise the assertion of the supported service fails because
some SvxShape::mpObj weak-reference is dead?

This essentially reverts commit 3cab1adf
(except for the added testcase, which was slightly different because
it did not have a "pib" property).

(regression from ba9b63d8)

Change-Id: I6539c4286850dff2d8564006487cc765f1d117be

Change-Id: I93ce16b4dd059ca0ed79975cfb6373dd629f29a9

Change-Id: Icecc2cce52d7f27c030270639e6b85877e3aa620

Change-Id: Ic0fbe955dfdb8f044d7bf0f45215a632a111eae2

Change-Id: I06ed104e4f26191b1ca1eb9c34aa54e3b0422500

on the correct page frame

- trigger formatting of selected object when moving view to the selected object
or when graphical horizontal line has been inserted.

(cherry picked from commit 82fafc47)

Conflicts:
	sw/source/core/frmedt/feshview.cxx
	sw/source/core/layout/fly.cxx
	sw/source/ui/shells/textsh.cxx

Change-Id: I4b4b523ff445f2ce20d9b81ad1187db7b44bd145

Change-Id: Ifd9c0dd2ceec08f50f3a8c4356fb288e65040dc5
Reviewed-on: https://gerrit.libreoffice.org/10345Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

For use of sw_JoinText and sw_GetJoinFlags.

Change-Id: I6bda9a41fcb42663517b505098f74ec596ac6551

Change-Id: I2ff32753c9fb6b8b48f9fc3228d91436951d09a1

Change-Id: I71f678e60586706ba427485055c26059bb68caa6

Change-Id: I3ca4cf51f6d3999a0f701f108a7c5c21329eb1c7

the current implementation of CoreText simply dropped the proper
implementation of DrawTextArray, by ignoring DXArray
this very visibly borked the show-non-displayable character
feature of writer.. the bullet representing the 'spaces'
was quite misplaced.
This solve specifically this problem.
More work is needed to bring proper support of DXArray back to CoreText


Conflicts:
	vcl/inc/sallayout.hxx
	vcl/source/outdev/text.cxx

Change-Id: Idb2cc90d5ffaa8b83f79241cee2d512112d1c3be