Modify the chart data label rendering in case of Column/Bar chart
only if the datapoint value is 0. This patch fix in case of NEAR_ORIGIN
and CENTER DataLabelPlacement.

Change-Id: Ia9857b5ac0cc5feaf2e1fd08e98c9f8534e5af04
Reviewed-on: https://gerrit.libreoffice.org/65082
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>

Change-Id: Iaa962fe5a590ef16e710fdd49d02d564f10f0f9f
Reviewed-on: https://gerrit.libreoffice.org/65188
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

Calculation of the visible area is not working correctly in
online case which leads to positioning of the shape outisde
of the view.
Instead of that calculation use the selected cell's position
to insert the shape at, similar how image insertion works.

Change-Id: I5c887261556c491962ed19f416ce480a63c24a9a
Reviewed-on: https://gerrit.libreoffice.org/65177
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

Separate generic code from Impress / Draw specific code
and implement shape selection handling in case of Writer.
This is an internal filter, so it can be called only from
the code.

Change-Id: I807e04a0949530d6029037bb964c10c80197ff33
Reviewed-on: https://gerrit.libreoffice.org/65174
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

* Update helpcontent2 from branch 'master'
  - Adjust bookmarks for python
    
    place bookmarks at the right page
    
    Change-Id: Ia5ce242ab9d21be2ca1b7b4f078af0b824d00c3a
    Reviewed-on: https://gerrit.libreoffice.org/65187
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

Bulleted paragraphs had a large left indent because we assumed the
bullet levels are inherited from the normal master page styles.

But that's not true, as
<https://support.office.com/en-us/article/add-bullets-to-a-shape-in-a-smartart-graphic-47edc03d-a2f8-4b54-acfd-ca103c515ab4>
points out:

"It is not possible to change the bullet style for text in a SmartArt
graphic."

This explains why the margin and bullet char info is missing from the
file format, and hints that just hardcoding these to the importer is
correct.

The result is less linebreaks in the shape text and the lost bullets are
also fixed.

Change-Id: I60bbee75f3e834551ebb1963a2f42101f3bd91d4
Reviewed-on: https://gerrit.libreoffice.org/65168Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

...by reverting part of 6f50961e "remove more
rtl::OUString and OString prefixes"

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

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

* Update helpcontent2 from branch 'master'
  - Fix missing entry in makefile
    
    + bookmarks
    
    Change-Id: I836964a1ec29485ee05617cce486dadd5b009591
    Reviewed-on: https://gerrit.libreoffice.org/65161
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

The testcase from tdf#102364 is actually a rather pathological case,
the document having a full 1M cells column with the same formula, and doing
undo in this case essentially pastes the column over itself (I think
a column is first deleted, which moves this column, and then ScUndoInsertCells
will trigger ScMoveUndo::UndoRef(), which will paste the column in that place
again. And since this is done cell by cell, removing old cell first splits
the large formula group and then adding a new cell with the same formula
rejoins the formula group, and setting these formula group changes for all
the cells over and over actually takes a long time.
Avoid that by delaying the formula grouping operation and do it just once
at the end. I'm not sure if this is that good way of handling this, given
the testcase is very specific, but I can imagine something similar happening
in other possible cases (manual copy&paste of a large column over itself
or moving it slightly up or down).

Change-Id: Ie4241197103a039c232150333250f78175b1c2c7
Reviewed-on: https://gerrit.libreoffice.org/64782
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Reviewed-by: Eike Rathke <erack@redhat.com>

The document has a large (1M cells) column, and when replacing old cells
with new cells during undo as described in the bugreport the repeated
calls to EndListener() from ScColumn::DetachFormulaCell() get quite costly.
Optimize this by doing a single EndListeningFormulaCells() call.

Change-Id: If51dacdfbe876134de956dbc6bbd73e97d9686ff
Reviewed-on: https://gerrit.libreoffice.org/64781
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Reviewed-by: Eike Rathke <erack@redhat.com>

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

The anchor can move to other pages if the frame is moved.
To avoid removing the contents of the frame, exclude this case.

This resolves a regression introduced by
8d62b79f

Change-Id: Ie7acd3c58ef9055cbe449ec15d337f03a02e0edd
Reviewed-on: https://gerrit.libreoffice.org/62987
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

PathRemoveFileSpec is used exclusively in GetCaseCorrectPathName(Ex).
The GetCaseCorrectPathName function is only called for absolute or
relative paths, not some arbitrary that chunks. So initial double
backslashes are only possible for UNC paths.

This change fixes handling of UNC paths by the functions. Previously,
the UNC path was recursively shortened until it only consisted of a
single "\"; then, if bCheckExistence was requested, testing this path
failed, which resulted in the whole recursion to return empty result;
else when returning from the recursion, original path components were
appended, but initial double backslashes were never restored. This led
to transformation "\\SERVER\Path\file.ext" to "\SERVER\Path\file.ext".

The GetCaseCorrectPathName itself is only used in two places:
osl_getSystemPathFromFileURL_() and osl_getFileStatus().

osl_getSystemPathFromFileURL_ only calls GetCaseCorrectPathName for
paths longer than 248 characters; bCheckExistence is false. In that
case, the resulting wrong path (missing one initial backslash) was then
processed in /* it should be an UNC path, use the according prefix */
branch, where two initial characters of it were stripped, one of which
being the first character of SERVER name. So, all the following
manipulations with resulting path were incorrect. This code path was
the reason for the bug.

osl_getFileStatus calls GetCaseCorrectPathName always; it requires
to check existence. This led to 0 returned from GetCaseCorrectPathName,
then osl_getFileStatus continued with copying the original string, thus
ignoring the error.

Change-Id: If7409afa2c0dd6dd001c79e719acbfd271a6ab72
Reviewed-on: https://gerrit.libreoffice.org/65158
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

race in SwDoc::CreateNumberFormatter on thread unsafe mpNumberFormatter.

thread 1:
SwDoc::CreateNumberFormatter
SwDoc::GetNumberFormatter
...
sw::DocumentTimerManager::DoIdleJobs
Timer::Invoke

thread 2:
SwDoc::CreateNumberFormatter
SwDoc::GetNumberFormatter
SwXTextDocument::GetNumberFormatter();
SwXTextDocument::queryInterface
...
SvXMLExport::setSourceDocument
SvXMLNumFmtExport::SvXMLNumFmtExport

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

In LO 4.3, Feb 2014 commit a31fbb53
totally changed the logic of the FormatBreak function, affecting
doc and rtf even though the focus was only on docx. This was quickly
patched for some specific cases, but the careless changes weren't fully
reversed.
Doing that now, because reading the code it just seems all wrong.

As I understand it, there seems to typically be two passes - a valid
pass for bBreakBefore and then a separate PageAfter pass. When DOC changed
to prefer a breakBefore sprm, it removed the bBefore flag, did nothing
on the bBreakBefore pass, and on the after pass, nC wasn't defined,
so it did nothing extra.
Dropping the bBefore flag probably broke the docx case.

Docx commit a31fbb53 just blew that all
away, and swapped when SectionBreak was called.

Another 2014 patch restored the DOC PageBefore behaviour (nC not defined,
so nothing happens), but didn't restore the PageAfter behaviour
so SectionBreak was still swapped.

So what logically seems to be needed is to restore the bBefore flag
(prior to DOC's preference for breakBefore sprm), restore writing
PageBreak_After in after pass, and ignore the FollowPageDesc
(because it didn't seem to be included purposefully).

PageAfter only seems to be UI possible in a table's text flow. So it is
VERY uncommon (no instance at all in existing unit tests.) And, not
surprisingly, it doesn't export a page break after the table in
doc or docx format anyway. At least now it won't put the break BEFORE
the table in docx.

This will restore these previous behaviours:
-doc/rtf: PageAfter no longer written in bBreakBefore stage
-docx:  -PageAfter no longer written in bBreakBefore stage
	-PageBefore not affected by FollowPageDesc.

PageBefore is generally unaffected by this change, and now the
test for page/column break matches again, as would be expected.

Change-Id: I265541a04be49e6b60bfbd84c33ab5783b454058
Reviewed-on: https://gerrit.libreoffice.org/64983Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

This reverts commit c9493b34.

According to
https://bugs.documentfoundation.org/show_bug.cgi?id=96248#c15
the asert was gone even before the patch...

Anyway, better to have an assert than a crash

Change-Id: I84389bf2e8e604f6967923c0eedaae3aec3455e6
Reviewed-on: https://gerrit.libreoffice.org/65115
Tested-by: Jenkins
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

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

Template format now supported not only for import, but for
export too.

Change-Id: I9fb9da14c4d6466b6979fa37fb2c0359ce5
Reviewed-on: https://gerrit.libreoffice.org/64947
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Result set field information should be stored correctly. It is queried
from database on demand and stored locally.

Change-Id: Ia62c62e6db32b45640b9fcd5f48c6249aecc41a2
Reviewed-on: https://gerrit.libreoffice.org/64861
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>

Change-Id: I0e975bb73211b1d4ddb2e721659f64b361d11322
Reviewed-on: https://gerrit.libreoffice.org/65121
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Cleaned directories are:
accessibility, drawinglayer, itemsetwrapper, main, sidebar

Change-Id: I612eae9dec636d57a3a3a00102d74b964da5b54c
Reviewed-on: https://gerrit.libreoffice.org/64307
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I09775c92f7c5b5e0f554a2822d243a230a06f626
Reviewed-on: https://gerrit.libreoffice.org/65136
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Martin Hosken thinks all patches are redundant now, so drop them.

Change-Id: I062168416a1289b7f4dd42d8ae58b7df56a37712
Reviewed-on: https://gerrit.libreoffice.org/65074
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: Id00bcd45faa3d9e82d3ed23843f5c4320bfa8f79
Reviewed-on: https://gerrit.libreoffice.org/65135
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I2d6c6d975a3047c879a87a1cee0305772c6b5d49
Reviewed-on: https://gerrit.libreoffice.org/65134
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

* Update helpcontent2 from branch 'master'
  - Correct "Print black" as "Print text in black"
    
    Change-Id: Ia6832472ac9b3c636e5880293794500601b5c010
    Reviewed-on: https://gerrit.libreoffice.org/65131
    Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
    

Since 'QObject' and the 'Q_OBJECT' macro are used,
the corresponding header needs to be included.

Without the include and forward-declaration given here,
the compiler doesn't know about 'QObject' and 'QAction'
which are used further below, unless another header that
takes care of this is included before 'QtMenu.hxx'.

The error could be provoked e.g. by moving the
'#include <Qt5Menu.hxx>' in front of all other includes
in 'vcl/qt5/Qt5Frame.cxx'.

Change-Id: I76c15eb445cbe26774d6e4177e12c93658daf0ad
Reviewed-on: https://gerrit.libreoffice.org/65130
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

... to squeeze some memory and later use this as a mass object
during consolidation.

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

Change-Id: I9ddb8f70b53600c02addeaf44a8cd1978e1ba5d0
Reviewed-on: https://gerrit.libreoffice.org/65128
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Take system includes ('-isystem') into account
when generating the '*.pro' files for Qt Creator
using the 'qtcreator-ide-integration' make target.

Without this, Qt Creator is unable to find the
corresponding included files.

This also makes Qt Creator's ClangCodeModel
able to properly process files and display
actual problems, rather than always showing
a multitude of errors due to missing includes
while parsing the source/header files.

Change-Id: Ie513341e1074ceab9304ae9df73fac9a79329db8
Reviewed-on: https://gerrit.libreoffice.org/65129
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

ScMarkData is passed since long.

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

So we can start to bundle everything in one place.

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

(Exactly the same thing as the old name NSAnyEventMask. The naming
convention just has changed to use a common prefix: NSEventMask*
instead of NS*EventMask.)

Change-Id: I18a1ae0a2b399ac38567a0171b0d211dcc9faec1

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

commit fec8c14e changed the default value
of InputRequired as read from the file; that is the value InputRequired
has when it is set to neither false nor true in the file

This is to mitigate the fact that InputRequired was not property
enforced and now suddenly is, but its default value was "true"! So
lots of past forms have InputRequired==true everywhere, users did not
pay attention to it because it was not enforced, and now it is
enforced, which suddenly is a huge PITA for users because they have to
update most controls in all forms. Since older versions of LibreOffice
omitted the input-required attribute in the file (the XML stream) when
it had its then-default value (namely "true"), we changed that to now
mean "false". As a side-effect, newer LibreOffice omits the attribute
in the XML stream when InputRequired has its new default value, namely
"false".

So the situation is that any file saved with an older LibreOffice will
have all its form controls with InputRequired==false when opened with
a newer LibreOffice, and any file saved with a newer LibreOffice will
have all its form controls with InputRequired==true when opened with
an older LibreOffice.

This commit makes LibreOffice always write the XML attribute. So that
any file saved with a newer LibreOffice will have the same
InputRequired values when opened in an older LibreOffice.

This enhances forward compatibility, because InputRequired was
enforced in older versions when the underlying database field was
marked NOT NULL. So the current situation leads to unwanted
enforcement in older LibreOffice versions, with a file that is saved
from newer LibreOffice with a control having InputRequired==false and
bound to a database field marked NOT NULL. This commit fixes that, by
ensuring that any form control with InputRequired==false in newer
LibreOffice will also have InputRequired==false in older LibreOffice.

Change-Id: I92ef48ad99c4e2ead43e95376282cc861c181ab3
Reviewed-on: https://gerrit.libreoffice.org/64642
Tested-by: Jenkins
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Reviewed-by: Eike Rathke <erack@redhat.com>

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

* Update helpcontent2 from branch 'master'
  - Help files: http -> https
    
    + some more conservative changes
    
    Change-Id: I328505b05838c3f3ce40759096ca77d30c874c57
    Reviewed-on: https://gerrit.libreoffice.org/63196
    Tested-by: Jenkins
Reviewed-by: Sophie Gautier <gautier.sophie@gmail.com>
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

* Update helpcontent2 from branch 'master'
  - Help files: http -> https
    
    + some more conservative changes
    
    Change-Id: I6f7e22164c975421f01e9ba974d82f14a34c0d5d
    Reviewed-on: https://gerrit.libreoffice.org/63219
    Tested-by: Jenkins
Reviewed-by: Sophie Gautier <gautier.sophie@gmail.com>
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>