As we already rely on the GlyphItem's font instance, consequently
this removes the SalGraphics GlyphItem based functions. Also
unifies the glyph bound rect cache handling.

An interesting aspect is the rotated glyph bounding box handling
moved from CairoTextRender to FreetypeFont. It doesn't look like
an implementation detail for Cairo, so it may have been a bug.

Change-Id: I81bbb5d8ee98fb77a1eee05568c456f9e4553023
Reviewed-on: https://gerrit.libreoffice.org/62503
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

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

Change-Id: Ib0808750854c1d59f8d208dbbe4e95045ceb56d0

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

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

Since we can't know the real SalLayoutGlyphsImpl type, we
always have to clone and delete it on assignemt and in the
copy constructor.

Change-Id: I3e3aa1e0271c5ecbb1474a70fae5e63bd7124677
Reviewed-on: https://gerrit.libreoffice.org/62583
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: I3b89cb6c24c263a1a8ea4e249ab24256a7d6f3f7

REGEX( Text ; Expression [ ; [ Replacement ] [ ; Flags ] ] )

REGEX(Text;Expression) extracts the first match of Expression in
Text. If there is no match, #N/A is returned.

REGEX(Text;Expression;Replacement) replaces the first match of
Expression in Text, not extracted. If there is no match, Text is
returned unmodified.

REGEX(Text;Expression;Replacement;"g") replaces all matches of
Expression in Text, not extracted. If there is no match, Text is
returned unmodified.

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

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

How to reproduce the problem:

1) Create an ODT file which has an OLE object, where the native data i
an OLE2 container, containing a Package stream, containing a DOCX file.

2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].

3) Load the ODT file in hidden mode, e.g. connect to a

 ./soffice "--accept=socket,host=localhost,port=9999;urp;StarOffice.ServiceManager"

process from remote Java, load the file with Hidden=true in the
Arguments parameter of loadComponentFromURL().

4) Save it in a format that reads the replacement graphic of OLE
objects, like HTML or DOC.

Expected result: the replacement graphic is there.

Actual result: the <img> tag has no src attribute (HTML case).

The root cause is that in case the document is loaded in hidden mode
then the IDataObject::GetData() call in OleComponent::getTransferData()
fails, so the OLE objects enters a state where it no longer has its old
replacement graphic, but it doesn't have a new one, either.

Fix the problem by making this update more transactional in
svt::EmbeddedObjectRef::GetReplacement(), so the "document conversion"
scenario (load in one format in hidden frame, save in other format)
works.

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

We don't really care for the palette or even lower bitness of the
original icons, when scaling them. So just convert them to 24bit
to get the best scaling quality.

And also actually fail the OpenGL scaling for 8bit color icons,
instead of handling them as a grayscale image, which results in
"funny" luminance based color icons.

Change-Id: I62ff9e7cd45dbffba81b0db5a0252737b6189059
Reviewed-on: https://gerrit.libreoffice.org/62505
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Needs to be part of Qt5AccessibleWidget

Change-Id: I3543cb3b5834c9967066733f0dbd73e974175892
Reviewed-on: https://gerrit.libreoffice.org/62515
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Change-Id: I184bad8a6915048d425f8baa56d2e5675d4b97d1
Reviewed-on: https://gerrit.libreoffice.org/62512Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

regression from
    commit b4fc9965
    loplugin:useuniqueptr in SdrHdlList

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

Now that we store the LogicalFontInstance instead of the fallback
level, it's not enough to keep a pointer in the glyphs in
SalLayoutGlyphsImpl. We also need a reference to the font, to
keep the font instance alive.

Change-Id: Idc99cf9259af6be672a97ab2c67dbffd9cf29c70
Reviewed-on: https://gerrit.libreoffice.org/62520
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Nobody outside of VCL should deal with GlyphItems.

Change-Id: Id84b0f320bc49f790658f23efe129b92262c2aea
Reviewed-on: https://gerrit.libreoffice.org/62446
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

The FreetypeFont might already have released the font instance of
the glyph, but the glyphs font instance must still be valid, so
use this instead to cache glyph bound rect.

For whatever reason the Windows compiler doesn't accept inline
functions in the GlyphItem struct and wants to export them in
the DLL, even when declared VCL_DLLPRIVATE, so this just uses
static inlines as a workaround.

Change-Id: I4539d91a846a54a05f9648638494e1e99f704b0a
Reviewed-on: https://gerrit.libreoffice.org/62425
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

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

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

The first fixes were wrong and only brought some regression

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

Change-Id: I21a100209d9177b80cfb9f4a629fb320626df1b7
Reviewed-on: https://gerrit.libreoffice.org/62511
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

after
    commit 50c63e5c
    pass OutlinerParaObject around by std::unique_ptr

spotted by Mike Kaganski

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

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Also a typo fix :)

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

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

Allows dropping 3 upstreamed patches.

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

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

Use range-based loop or replace with STL functions.

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

Commit 'Special methods NewStandardLayer and SetStandardLayer
not needed' has removed the last user of mbUserDefinedLayer.

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

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

This reverts commit eb34a6a9.

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

As the floating objects anchored to footers aren't wrapped around properly
(they behave as if they are wrapped through unconditionally), which makes
imported tables to overlap the page body text making the document unusable,
let's just disable the conversion for the time being (until the actual bug
fixed properly).

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

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

This not only avoids all the overhead of i18npool's TextSearch and
Transliteration efforts (which are useful in the Find&Replace
dialog bu we don't use here) that could possibly even get in the
way how they are implemented, but also gives us direct control
over all possible flags; plus ICU's replace features are more
convenient to use and have better error checking to report back
and there is the advantage that ICU's regex description can be
taken verbatim.

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

and update NameGroup arrangement

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

I wonder why we have that iOS ifdef in SvpSalInstance::Wakeup()?
Elsewhere in this file we do compile code that uses those same fields
for iOS, too.

Change-Id: Ib801ea81fafcf2296181874018c1df2ceef144a1

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

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

If importing the certificate and private key is done separately,
they don't associate with each other, so with this you can add
the private key to the certificate that it belongs to. If the
private key is set in this way, then getPrivateKey() call doesn't
look into the database but just returns the private key stored
in the member variable.

Additionally use CERT_DecodeCertFromPackage to import the DER
certificate from the imput as CERT_DecodeDERCertificate doesn't
import a complete certificate and doesn't add it into the
certificate database.

Change-Id: I29876030f167cc5fa6b887f9bfeb0b84622c751e
Reviewed-on: https://gerrit.libreoffice.org/62271
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

The method ImpGetBitmapEx in svdhdl.cxx needs special single
marker files to generate display dependent markers on the fly.
List them in bitmaps.hlst so that they are packed and delivered.

Change-Id: I26d86fa31d82ab623016c9ed0bfb6eb9a3e91a14
Reviewed-on: https://gerrit.libreoffice.org/62488
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

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