Otherwise, not-yet-allocated columns have STD_COL_WIDTH (1280), while
normal columns have widths like 82 (pixel), making the oversized grid
look as if the columns not having vertical lines at all.

Also, we need to consider default attrubutes here, to properly render
cell properties like borders and background for unallocated columns.

Regression after commit 7282014e

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

Do the same for the gtk3_kde5 VCL plugin as commit
2c69c93f does for the
kde5 one.

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

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

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

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

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

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

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

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

Change-Id: Iaafc0f45282b0351c24b4ddc433ed1086177ff73
Reviewed-on: https://gerrit.libreoffice.org/71400
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

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

On my machine, this takes the loading from 21s to 8s.

We can delay doing line height calculation till after load, since we run
the calculation over all rows after load

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

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

This adds GenericTypeSerializer, which is now responsible of
serializing the Color into a stream (other types will follow), but
only for the older version of the binary format. The new version
we just write the sal_UInt32 mValue directly.

This is a start of decoupling the serialization of generic types
in tools and vcl module from the actual type, so we can in the
future replace those with basegfx variant.

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

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

It is expected that <text:text-input> will be converted to
{FORMTEXT} MS field, but practical implementation was
missing.

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

All strings reviewed

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

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

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

since 7034311d affine transformation
is passed down to drawPolyPolygon and drawPolyLine functions.

The transformation was correctly applied to cairo context, but not
the extents of damage so those had old, untransformed coordinates and
were therefore not redrawn

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

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

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

ofz#13491 SvxRTFItemStackType dtor recursively calls the dtor of its
m_pChildList. The recurse depth can grow sufficiently to trigger asan.

So breadth-first iterate through the nodes and make a flat vector of them which
can be iterated through in order of most distant from root first and release
their children linearly

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

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

These areas are zero when you start to draw a 3D object with the mouse.

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

which just makes the code harder to read

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

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

* Update helpcontent2 from branch 'master'
  - tdf#122548 copy bascode and pycode to clipboard
    
    This will allow easy testing of coding examples.
    
    Change-Id: I30fc53642b1579744591f2de0c84a615d1755352
    Reviewed-on: https://gerrit.libreoffice.org/71385
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

* Update helpcontent2 from branch 'master'
  - topic tag correction
    mispelled link
    
    Change-Id: I34ecbbfca31285efe9af3eaa9ab0d2c1ee7b7b64
    Reviewed-on: https://gerrit.libreoffice.org/71377
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

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

On macOS it is possible to copy from a PDF a subset of a document,
which will be transported as a new PDF document containing the
subset.
LibreOffice didn't support PDF as a valid clipboard format and
previously it also didn't support showing PDFs inside the document,
so in such cases it copy-pasted a low resolution bitmap. The result
wasn't good.

As we are now able to display PDF documents as Graphic in LO, we
can also support this use-case. This adds support for the PDF
documents as a clipboard format in general and to the macOS
backend. This commit only adds support for Writer.

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

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

The UI default is in the SwForm ctor, where the content type sets the
link start char style to STR_POOLCHR_TOXJUMP.

Have the same default in the UNO API in case the import filters don't
set it explicitly, since that breaks clickable hyperlinks on PDF export.

This also fixes the OSL_ENSURE() failure for missing character formats
in SwTextINetFormat::GetCharFormat().

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

As the Qt documentation for 'QFileDialog::supportedSchemes'
says, setting supported schemes to a non-empty list restricts
the available options:
"Setting this property allows to restrict the type of URLs
the user will be able to select. It is a way for the application
to declare the protocols it will support to fetch the file
content. An empty list means that no restriction is applied
(the default)."

The call to 'QFileDialog::setSupportedSchemes' was copied
over from the gtk3_kde5 VCL plugin in commit
6196b729, where it had been
added by commit f1b60bd6
"Support opening of (some) remote URLs through the KDE file
dialog".

Since only either all schemes (if nothing explicitly set)
or a whitelist of supported locations seems to
be possible (s.a. the Phabricator changes referenced
in the commit message of commit
f1b60bd6), add the
"" scheme that makes removable devices shown -- while
there doesn't seem to be an official documentation on
the available schemes, at least not in
KFileWidget's API documentation [1].

A quick test with all new available options after removing
the call to 'QFileDialog::setSupportedSchemes' altogether
indicated that opening and saving files there doesn't work
reliably in all cases, so rather excplicitly add the ""
scheme rather than claiming support for all schemes
(including e.g. "timeline", "search", "remote", "trash").

[1] https://api.kde.org/frameworks/kio/html/classKFileWidget.html

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

Reverts the "fix" for i#42807 from CWS swqcore08 since there's
now SwUndoUpdateIndex.

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

* SwTOXBaseSection::Update(): refactor this to *first* collect the info
  from the document (creating CrossRefHeadingBookmark as a side effect)
  and *then* do the node deletion/insertion of the ToX itself

* add new SwUndoUpdateIndex class for the update itself; it does 3 of
  the 4 required steps, the last one is done by a SwUndoDelSection that
  is already created when the original title section is deleted

* SwUndoInsSection::RedoImpl() for a ToX should not Update the ToX
  because that's the job of SwUndoUpdateIndex

* SwUndoSaveSection::RestoreSection()/MoveFromUndoNds() need to create
  frames for the moved nodes; not sure why other users of
  RestoreSection() don't do this currently so add a flag

* SwUndoSaveContent::MoveToUndoNds() should *always* delete frames;
  seriously, why would leaving frames alive ever be a good idea?

* SwUndoSaveSection::SaveSection() should not delete the surrounding
  section node of the ToX, so add a flag to prevent it

This fixes tdf#123313, the SwUndoInsBookmark are now appended at the
right time.

This should fix the crash in i#42807 properly.

In order to fix these bugs, implementing the feature requested in
tdf#38703 was necessary.

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

Revert "tdf#123313 sw: workaround Undo problem with ToX Update"

This reverts commit 60ea01af - it was
quite simply a bad idea, and only pushed due to lack of time...

Much better to refactor things so that any new CrossRefHeadingBookmark
are inserted (with SwUndoInsBoomark) *before* nodes are inserted into
the ToX.

However! This patch does not fix the problem yet; that needs some more
significant changes.

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

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

* Update helpcontent2 from branch 'master'
  - added hasUnoInterfaces()
    
    Change-Id: I41e521c34c4dbf161b0bd4316da75d6db7ec4314
    Reviewed-on: https://gerrit.libreoffice.org/71214
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

Change-Id: I1893d52df505bc43428c37a624ca05c569ba1bc0
Reviewed-on: https://gerrit.libreoffice.org/70958
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>