This took me ages to implement. I'm still not 100% sure, it works
correct. One main problem was the loop where the ATK listener will
rebuild the list of children based on the current child count.

Then there is the "broken" SPI bridge behaviour. I could actually
test this with the gtk3 backend just fine, if I started LO *after*
the accerciser. Otherwise the displayed tree will be really broken
and the add and remove child events won't be correctly processed,
because some Windows in the hierarchy will return a negative
parent index. And generally the accerciser has various problems,
with most result in Python backtraces an inconsistent app state,
but even SIGSEGV happened a few time. Already have some patches
for the easy reproducible ones.

No idea what will happen on any other setup then Linux with ATK.

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

This way the example buttons will have a name for better
accessibility, instead of being blank.

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

as its preferred size, causing it to not clip its child, but grow instead to
match

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

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

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

See https://bugs.documentfoundation.org/show_bug.cgi?id=56738#c3

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

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

in superscript/subscript text positions instead of
changing the greater values (eg. imported from DOCX)
to 100% by accident, simply using the character
formatting window.

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

by editeng support of large superscript raising.

Maximal raising of superscript text is 1584 pt in MSO,
while LibreOffice didn't import the values greater
than 100% of the current font height. Using the maximal
percent value of the default 11 pt font, the limit
is 14400% now, fixing most of the import problems.
Greater raisings will be limited to 14400% during the
DOCX import.

Note: the standard doesn't limit the bigger percent
values, see "20.374 style:text-position" and
"18.3.23 percent" in OpenDocument 1.2.

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

...as seen during CppunitTest_sw_layoutwriter:

> testUserFieldTypeLanguage::TestBody finished in: 1271ms
[...]
> workdir/UnpackedTarball/zlib/trees.c:873:42: runtime error: null pointer passed as argument 2, which is declared to never be null
> /usr/include/string.h:43:28: note: nonnull attribute specified here
>  #0 in _tr_stored_block at workdir/UnpackedTarball/zlib/trees.c:873:5
>  #1 in deflate at workdir/UnpackedTarball/zlib/deflate.c:1025:17
>  #2 in ZipUtils::ThreadedDeflater::Task::doWork() at package/source/zipapi/ThreadedDeflater.cxx:163:15
[...]

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

Change-Id: Icc72fca62e189559956abc0ebbca9ce196a02073

Sadly we can't accept public.utf8-plain-text, i.e.
text/plain;charset=utf-8, as the code does not know of such a
SotClipboardFormatId. The only text/plain is UTF-16.

And it probably is a good idea to accept HTML anyway. We have to
continue to (I think) not offer text/html because of the assertion
failure issue, see comment in DataFlavorMapper::openOfficeToSystemFlavor().

Change-Id: If5d77b97649424e347c50af10475c2be997c8632

Change-Id: I821a699ee4f44881aadac89f265974a10095b544

Same problem as in 96ae2a33

Regression from 497e40ad

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

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

Revert of:
2903c5f5

Reverting this commit does not lead to the original bug
to come back, so we can revert it without a problem.

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

Replace OSL_VERIFY with if-statement and SAL_WARN.

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

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

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

Some parameters were passed by value for no reason, it's always a good
idea to declare a variable at the point where we can also initialize it,
etc.

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

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

so that they are laid out in correct order

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

Takes load time from 4m to 3m

Use equal_range to give us a start and an end, so we avoid the operator<
cost while scanning

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

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

In any case is included a few lines after, so I guess it
can be removed the check (if it's not ready also for future
other includes).

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

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

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

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

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

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

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

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

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

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

copy and paste from the normal document info page I imagine

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

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

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

Now it works to copy and paste images (PNG ones at least) between the
iOS Collabora Office app and other apps.

We don't seem to need the PNGDataProvider after all, as we use it only
for data that is already in PNG format. Possibly I am missing
somethin, though.

Change-Id: Ia6bcc8aefbe1a6687f13e28454b96658fc66c856

It seems a bit pointless to offer formats that no other app will use.

Change-Id: I54474a4ba40d91c184592cede4224cbfbb78d518

Still awfully slow for "realistic" images as taken by modern digital
cameras, though. It would be much better to not encode the PNG to put
on the clipboard from the internal bitmap representation, but use the
ooriginal PNG or JPEG data.

Change-Id: Ib72a573bd31d4ae7380dacccb4287e19afabb0d4

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