This is used in parsing of meta Contexts across different
modules. This also involved moving to XFastParser for
parsing xml filters in sw, sd, starmath.

Change-Id: Ic663aaac6cb20ee8ce5b97cae87c93220f5a2929
Reviewed-on: https://gerrit.libreoffice.org/42989Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>

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

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

Namespace prefix was missing here.

Change-Id: Id746d47713b22e2efd5d679c2325b32a0bee8a09
Reviewed-on: https://gerrit.libreoffice.org/51270Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: Ib5a1da6666ff3a136c05374f10b7ca138c14492d

...in efcb9a70 "use sw::WriterMultiListener
instead of SwDepend in SwPageDesc", causing

> /sw/source/core/layout/pagedesc.cxx:198:74: runtime error: upcast of misaligned address 0xbebebebebebebebe for type 'SwTextFormatColl', which requires 8 byte alignment
> 0xbebebebebebebebe: note: pointer points here
> <memory cannot be printed>
>     #0 0x2b06bea9116b in SwPageDesc::GetRegisterFormatColl() const /sw/source/core/layout/pagedesc.cxx:198:74

during e.g. CppunitTest_sw_odfimport of ASan+UBSan builds.

Change-Id: If50a920ca5dafdce6c1a3e2fbf540488685e641a

Project: help  781da1e8175459f27cca84bed2ca209b3e030067

tdf#99611 improve function AND() documentation

Added details on handling non logical arguments in
Calc logical functions.

Change-Id: I416fbe9443777a7a7bdfa9d3f61bdf072aff476b
Reviewed-on: https://gerrit.libreoffice.org/51176Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Olivier Hallot <olivier.hallot@libreoffice.org>

Project: dictionaries  3bc3ffdb0b622cc07b5d959225a9f2223afdf145

Hungarian grammar checking rules v1.6.3

Change-Id: I2c898690f12edc0ad4c83dc6395813e21a724f64
Reviewed-on: https://gerrit.libreoffice.org/51227Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Easier to see what's going on inside the LOK dialog.

Change-Id: I59974200af3d2356b7c27eb3dd4032a59c00dbed
Reviewed-on: https://gerrit.libreoffice.org/51263Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>

Previous fix 25cd8436 like any
other before it have some regressions, so reverted.

The root of most problems: fix for tdf#104141
d148340b, where mask drawing
was implemented in bitmap drawing code.

So instead of guessing for type of bitmap, mask is drawn with
DrawBitmapEx resolving all known problems (tdf#114726, tdf#115297,
tdf#113918 and tdf#104141).

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

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

Project: help  770c0c1746b5c0b94dc07d5f1d6c2c04802c8540

tdf#116296 remove produt version from help path

Part two.
Part 1 is in sfx2 module

Remove product version from offline help path but keep
in online help.

Product version is kept for online because a help server can have more
than one helponline version.

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

Part one.
Part 2 is in helpcontent2 module

Remove product version from offline help path but keep
in online help.

Test for existence of old offline help is done now
checking the presence of the file help/<lang>/err.html

Test for new (html) offline help is done now checking
the existence of the folder help/<lang>/text

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

- give priority to IPA P Gothic and Noto Sans CJK JP
- for Windows, try Yu Gothic UI first, then Meiryo UI
- look for Hiragino Kaku Gothic ProN/Pro on macOS

Thanks to Jun Nogata and AWASHIRO Ikuya for their suggestions.
This addresses only part of the issue; another incoming change
will take care of the rest.

Change-Id: I1491ba63e1447d3b9086dfcfdf3981bee6282661
Reviewed-on: https://gerrit.libreoffice.org/50515Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>

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

Instead of a hard-coded check for (effectively) one project name
"LibreOffice" (which is build-time configurable), check for the string
"LibreOffice_project", which has been produced hard-coded ever since
LO 3.3.0.

This now recognises additional downstreams "LibreOffice_Vanilla"
and "Collabora_Office", and also historic "BrOffice".

An important point here is that the build-time configurable version
numbers of any downstream that retains the hard-coded
"LibreOffice_project" *MUST* be the same as the upstream's at least
in their major and minor versions (micro and further digits are
currently not used), and that such downstreams don't backport
changes with ODF export compatibility impact further than upstream.

Add a unit test too, with a representative sample of 4372 distinct
generators in bugzilla attachments.

This revealed that StarOffice 6 and AOO 4.0.1 were falling through
the cracks and not recognised, so fix that too.

Change-Id: I8105222d3428e7b20cc4a6b8e76732c697812594
Reviewed-on: https://gerrit.libreoffice.org/51171Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

To avoid semi-manual refcount handling.

Change-Id: I4a0bcd00ef2811a76f85313d2f821daa1731898c
Reviewed-on: https://gerrit.libreoffice.org/51242Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

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

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

According to:

<mst_> noelgrandin: apparently this code exists so you can export a text

     frame as an image and then the urls in the text become
    image-map links

which means that according to my analysis below, nobody has noticed the
removal in 17 years :-)

SwNoteURL::InsertURLNote was the last place that constructed an
SwNoteURL and it was removed in
    commit bb7ade14
    Author: Noel Grandin <noel.grandin@collabora.co.uk>
    Date:   Wed Mar 7 13:42:58 2018 +0200
    loplugin:unusedmethods

and SwNoteURL::InsertURLNote was dead because
   void SwTextPaintInfo::NotifyURL_( const SwLinePortion &rPor ) const
was removed in
    commit 73139fe6
    Author: Noel Grandin <noel.grandin@collabora.co.uk>
    Date:   Fri Jan 19 13:10:22 2018 +0200
    loplugin:unusedmethods

and SwTextPaintInfo::NotifyURL_ was dead because
   void SwTextPaintInfo::NotifyURL( const SwLinePortion &rPor ) const
was removed in
    commit be8c4145
    Author: Noel Grandin <noel.grandin@collabora.co.uk>
    Date:   Fri Jan 19 09:13:03 2018 +0200
    loplugin:unusedmethods also check for functions returning bool

and NotifyURL was dead because calls to it were removed in
    commit 1b666235
    Author: Noel Grandin <noel.grandin@collabora.co.uk>
    Date:   Wed Jan 3 09:08:52 2018 +0200
    loplugin:singlevalfields improve copy constructor check
those calls were removed because the m_bURL field of SwFont was always
false.

tracing back, we find that m_bURL was called bURL before
    commit b4e2a13f
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Mon Oct 26 08:55:17 2015 +0100
    sw: prefix members of SwFont

and we find that a method
     void SwFont::SetURL(const bool)
that modified bURL was removed in
    commit 407731c9
    Author: Noel Grandin <noel@peralex.com>
    Date:   Tue Jul 21 10:44:17 2015 +0200
    loplugin:unusedmethods sw

and we find that calls to SetURL were removed in
    commit da7671e4
    Author: Andreas Martens <ama@openoffice.org>
    Date:   Thu Mar 15 14:59:12 2001 +0000
    Opt.(FME): The new attribute handler makes a lot of code superfluous

which appears to be the root of the problem

Change-Id: Id2362ce216c06bc8dcf71698695d708eb494af4e
Reviewed-on: https://gerrit.libreoffice.org/51225Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

we have this STL thingy now, pretty cool

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

mainly by using for-range loops
+ some algo simplifications

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

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

This patch is sponsored by ULAKBIM/Pardus project.
Signed-off-by: Mert Tümer <merttumer7@gmail.com>

Change-Id: I91c902bfd1acc5cc70ad30f16e0719e7a325702b
Reviewed-on: https://gerrit.libreoffice.org/47636Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I2779ef9a9f68dcf08c3072ffe83b9f2450b7257e
Signed-off-by: Mert Tümer <merttumer7@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/50757Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

...in Writer Sidebar Navigator deck helper toolbox

Change-Id: Ieeabcb30f421aa0ce2a5f841e45fff5f57358215
Reviewed-on: https://gerrit.libreoffice.org/50295Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

multiple attributes of the same name on the same element,
because AttributeList was wrongly re-used

Change-Id: I29b2317ce3d836d7349fa0474709726bed2c5ad4
Reviewed-on: https://gerrit.libreoffice.org/51087Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

(regression from 41af2a9e)

Change-Id: I47377447dd1e04a44033dea27ce7307a65821737

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

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

If nOverPos<i and i was last element, the next pOver=&rRange was
invalid, though not deleted because std::vector::erase() does not
reallocate.

Change-Id: I22d9302e2d45403dd47ac1947d2cf003b3a4f291

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

cause the vcl ones are equivalent to this so less change

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

Change-Id: I94208553c7678d9d108ec3f76decc3c38d69802e

which my plugin had previously been ignoring. Since that time, the
plugin has gotten a little smarter, and makes less mistakes.

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

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

I’ve always suspected this check in VCL is wrong since Writer calculates
Kashida positions for Arabic only. If we *really* want to Kashida
justify Syriac, then Writer has to be first taught how to calculate
Kashida positions for it.

Change-Id: I20c03a3a54bce14c9bebb55426bd22537fe50d6a
Reviewed-on: https://gerrit.libreoffice.org/51223Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

m_nCount must be accessed with m_aMutex locked.

Change-Id: I7e05cac2b549b975804d6061721c1da4d0b9f64e
Reviewed-on: https://gerrit.libreoffice.org/50236Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Also use the return value of the link's Call() [as the SvTreeListBox::ExpandingHdl()
is doing], the appropriate callbacks seem to return the expected 'false' in
the cases I've reviewed...

Change-Id: I0cdd63e8ec4c794839070b914150e0b32f743359
Reviewed-on: https://gerrit.libreoffice.org/51211Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

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