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

Allow multiple file imports, each one having a
non-conflicting range name, by being sheet specific. As
Eike states, "This does *not* mean that they couldn't
be referenced from other sheets. By prefixing the sheet
name it can be used from any other sheet, for example
Sheet2.HTML_1. (This wasn't possible in early versions
with sheet-local names but it has been possible for
a while already)."

In theory, it would previously have been possible to create
a generic sheet with calculations using a range name
that doesn't exist yet, and then importing *any* file
to be analyzed.

In practice that has never been possible
since all names were relative, and imports always
create a new sheet, so the relative name would point
elsewhere. Also, the non-existant name only resolves
after a round-trip of the file, not immediately
upon file import.

So, it is logical to set the imported range names
to be sheet-local instead of global.

Change-Id: I3103f0655b2373bb731c192bb5d2c0757938ee28
Reviewed-on: https://gerrit.libreoffice.org/55349Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Eike Rathke <erack@redhat.com>

MSO apparently requires absolute sheet references
in named ranges.

XLS and XLSX compose the range in entirely different ways.
XLS doesn't use the sSymbol result at all, while XLSX is
entirely dependent upon it.

XLS doesn't require the range to be 3D in order to be absolute,
but XLSX and ODS do require that, so it only makes sense to ensure
that 3D is always enabled when the range changes to absolute
in order to enhance inter-operability.

GLOBAL names will be handled in a followup commit.

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

Change-Id: I8d1d3273fcafe1ce750e66e55712eac607722717
Reviewed-on: https://gerrit.libreoffice.org/55643Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>

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

Found with bin/find-unneeded-includes
Removal proposals and fallout management are dealt with here.

Change-Id: I21217fbac071f06987b989e735982b2dfad6a54e
Reviewed-on: https://gerrit.libreoffice.org/55537Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>

Depends on the gtk-3-24 dev branch, for the public
gdk_window_move_to_rect symbol.

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

Change-Id: I42a55562747e6097c1193e285da67235f5364bea
Reviewed-on: https://gerrit.libreoffice.org/55610Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I3e2579601c94fe6261e4eb56bbcf3b3b7905be7f
Reviewed-on: https://gerrit.libreoffice.org/55550Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>

Change-Id: If1b985d8b29cf2d30449f04c2a788b6db2f5db67
Reviewed-on: https://gerrit.libreoffice.org/55507Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I7e055f296f524e39c37fc7c502b8486d0cbbe3fd
Reviewed-on: https://gerrit.libreoffice.org/55560Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I147ed2c69a279703ad857a9532737201b7cde015
Reviewed-on: https://gerrit.libreoffice.org/55567Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

the text hightlighting feature was implemented backed on to the vcl
TextFillColor feature. TextFillColor fills the background of the bounds
of the text with that color

Likely either the same problem or similar as tdf#93789

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

Project: help  3b958f38a3af98fab6dd879eb0decc4d3cc02510

Further cleanups and improvements

in /shared/01/022*.xhp files

Change-Id: I6e25791dc6bd1b68fac06ebb35c5cc8477fe8fd0
Reviewed-on: https://gerrit.libreoffice.org/54940Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

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

its original use is during a drag/drop operation so its expected to
be in use just for a temporary scope, so End after Start

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

otherwise build fails on 32bit platforms as multiple matching
overloaded func are found. Thanks _rene_ and mst_ for helping
me to figure this out

Change-Id: Ief4571ad735ad4efea9ddc70daea45885e5954c7
Reviewed-on: https://gerrit.libreoffice.org/55474Reviewed-by: Rene Engelhard <rene@debian.org>
Tested-by: Rene Engelhard <rene@debian.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>

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

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

Change-Id: I26a0da1ec9cda9030371977596053a45303756a0
Reviewed-on: https://gerrit.libreoffice.org/55609Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Also ensure that transliteration-spellout and
(transliteration-format,transliteration-style) are mutually
exclusive and transliteration-spellout is only written if ODF
version is >1.2, namespace 'loext' for 1.2 with extensions and
namespace 'number' in anticipation of ODF 1.3 (may need to be
adapted).

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

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

because it is an actual division-by-zero error and Excel does.

Call for suggestion: I would like to add a test case to
sc/qa/unit/data/functions/statistical/fods/ztest.fods, but
do not know the right manner of adding it cleanly without
messing up other parts such as styles.

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

The bug document has a formula cell (at O7) that depends on cells with
non-default number formats, but this cell's number format was force
set by the user to the default. So the mbNeedsNumberFormat for this
ScFormulaCell object is now false. But when a copy to clip
and paste as GDI metafile is made, this subtle information about
the "user forced default number format" is lost.
ScColumn::SetFormulaCell() is used while making the copies of the
original formula cell to clipdoc and then to another document, where
it sets the field mbNeedsNumberFormat of the formulacell to true if the
number-format of the target cell is default. Note that the
number-formats along with all attributes of the target cells are
copied from the source before copying the actual cell contents.
As a result, after copy pasting, the formulacell at O7 of the new
document will have mbNeedsNumberFormat = true. This causes the
attribute modification (in ScAttrArray of corresponding column)
while Interpret()'ing the cell. Unfortunately this Interpret() happens
while in a call to ScRefCellValue::hasNumeric() while in the middle of
rendering the cell of the new document (in ScOutputData::LayoutStrings()),
and naturally this messes up the ScPatternAttr references the view has been
caching, hence the crash.

The steps involved in the fix are :-
1. Carry around the state of mbNeedsNumberFormat in
   the copy-constructor of ScFormulaCell, in case the src formula-cell
   is not yet Interpret()'ed. Note that after Interpret() is done, the
   mbNeedsNumberFormat is set back to false and inherited numfmt is
   applied to attributes data structure.

2. In ScColumn::SetFormulaCell(), allow an optional param
   bInheritNumFormatIfNeeded (default = true). In that method,
   the mbNeedNumberFormat is set to true only if this flag is true
   and the cell format is default. So when the copy/paste operation
   is going on, we pass the mbNeedNumberFormat of the source
   formula-cell for the new parameter to SetFormulaCell().

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

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

It does not change only the date part nor the time part
separately, thus holding single DateTime is sufficient.

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

I got to know that, earlier the code I've submitted about line algorithm
creates error. I've fixed that in this patch. Moreover, child width and
height doesn't depend of nIncX and nIncY, so I've removed that code, it
relates only to the position of the child.

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

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

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

look for methods returning only 1 and/or 0, which (most of the time)
should be returning bool.

Off by default, because some of this is a matter of taste

Change-Id: Ib17782e629888255196e89d4a178618a9612a0de
Reviewed-on: https://gerrit.libreoffice.org/54379Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I2ff0f1fff7302cbf884e35879c72df0dc09eede4
Reviewed-on: https://gerrit.libreoffice.org/55597Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

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

Change-Id: I14483c82490e17e9832215bc90a7f5870215bb93

Change-Id: I8895c79a65750330600ebf0be19d184736fe2c1c
Reviewed-on: https://gerrit.libreoffice.org/55543Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: Jenkins <ci@libreoffice.org>

regression from

    commit 79800559
    convert MT_ constants to scoped enum

The original code used bit-wise operations and some clever constant
values, which I did not convert correctly

Change-Id: I2fcd9e2584638d4a690773ef3f178415153b8b19
Reviewed-on: https://gerrit.libreoffice.org/55596Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I0e60ec7a3edae42b25ff0917828d0a893ed39a38
Reviewed-on: https://gerrit.libreoffice.org/55245Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

since we are now holding these via reference counting, no need to clone
them

Change-Id: I7b0bd86f4a5bca428f7dcd989f838a9aa0c7e179
Reviewed-on: https://gerrit.libreoffice.org/55427Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ied01f97a09d34c43f786c030fbdd256bcf849f04
Reviewed-on: https://gerrit.libreoffice.org/55535Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ic1e98a7efdd75a6c940c5ce81bfb414711c4ab37
Reviewed-on: https://gerrit.libreoffice.org/55534Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Icf2a8f2b334b1a0b9a7028fb1718710dd67c7a81
Reviewed-on: https://gerrit.libreoffice.org/55533Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>