Age | Commit message (Collapse) | Author |
|
Change-Id: I8fdf9833dede6f4c9ba4bbb76b9ab9b6b419f155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
adding together constants like this is not safe
Change-Id: I6c92b591e623fed9adcf76c08fcd1fb136f8d423
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8fab74e92a932fd284a63357e7a20f208af2d20d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100728
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
rather just let the debugger or crashpad handle it
Change-Id: I44e0dd06f2c84a7bf0099093a53032d759c18dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
no logic change intended
Change-Id: I755de2e37bec3843500920476fc23f013103f976
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100685
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
we're not in DOS anymore, Dorothy
Change-Id: I79926e0d694163940ba7ebf20419724dd0a486f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100721
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I83d78b6a145b68af16375baee688c372700f6b9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100719
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
It is better to let the exception be uncaught and then catch that in
the debugger, or let our crashpad handler capture a full
stack-trace and report it.
Change-Id: If5a4259c22c9f47d788e01725c802eeeb46162e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94596
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
as formula fields instead of exporting only cell
text content.
Only unmodified formula fields were exported from
commit d42776e01b87f12fddbcf78101bca1e10a6e4f97
(tdf#118682 DOCX: export formula fields).
Now newly added Writer formula cells or modified
table formula fields imported from DOCX (which are
converted to formula cells after formula editing)
are exported.
Change-Id: Iecec75b2a36b94c2d3aa998603ac10ea2f2b8d4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100667
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Since .doc and rtf don't postpone flys, they shouldn't also be
postponing the text.
Partially revert my LO 5.3 commits b39feae4f12b07a0fdb2c8c2a48d5aae613cd7c9/
3ade281c1da91b7646a56227cffba8eb8818ea30
which only avoided postponing within tables for the .doc format,
since this patch eliminates it completely for .doc and .rtf
I think the original Synerzip LO 4.4 patch
commit 80fd9fb7209cfd5c0622ee99d59e42e6db32f021
was only intended for DOCX formats.
I am concerned about doing this since the implications are unclear,
but I take comfort in seeing that many synerzip commits just
need to be reverted, and that a number of .doc bugs are
solved by doing this. The fact that few bug reports have
been made since 4.4 also suggests this isn't a hugely
active area. No intention to backport, and still lots of testing
time available for LO 7.1.
Change-Id: I9284d3cc516c480e8bb0848c17797988ffcdcd2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100175
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
And test com.sun.star.comp.Draw.XMLOasisMetaExporter instead in
JunitTest_xmloff_unoapi.
Change-Id: I1cd485378097b094e6773a7c37798b9aadf3070f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100687
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I67c51424db1302aaffc78389466f680952045326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100625
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I55bfe3cc00da74fdfd594175643684c3e28fe09b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100664
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
add new autocorrect words for Korean
Change-Id: I740a9476ad676591d4647d133027739ce9030781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100682
Tested-by: Jenkins
Reviewed-by: DaeHyun Sung <sungdh86+git@gmail.com>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I6ab8cc8907943c3bb7fd717624ea4ac7c9d4fd5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100711
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibc2896acc75375d89df02563383dfbec6efff558
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100710
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
This removes the only place that hadn't used transparent impBufferDevice
yet - in VclProcessor2D::RenderMaskPrimitive2DPixel. Not clearing the vdev
made it draw on whatever garbage was left there from previous paints when
the buffer was taken from maFreeBuffers in VDevBuffer::alloc, so since this
was also the only place left that didn't clear the buffer explicitly, this
makes the clear unconditional in impBufferDevice ctor.
Also this makes sure to clear proper rectangle in VDevBuffer::alloc, and to
clear mpAlphaVDev in OutputDevice::Erase.
Change-Id: I7c1c0cc510a92628f19020b3faf0c0cd81f5a599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100674
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I346fcf31078cc52b90a9ce39fd93a331e65957cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100689
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
Change-Id: I02f05d87920a09f2cbb8a66caa2f76b7aad62a49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100539
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iea6b931b1f2328886354f70ad81a3e07367db717
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100669
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: If3336b8a39e41d958de2e998e3d9467888f2df6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100659
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Co-authored-by: Attila Szűcs (NISZ)
Change-Id: If6ce28aab938eaf22fe578f8880e139b7b4eb22c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100418
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
MSWordExportBase::NeedTextNodeSplit() simply uses the soft-page-break
positions to potentially insert section breaks - but now that Writer can
display field instructions, it's quite silly to insert section breaks
inside them.
Change-Id: Ie57e6281a0287aac36984e5467920852db19a8ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100661
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
This hit assert(bSavePos && bSaveOtherPos);
Tweak SwUndoSaveContent::DelContentIndex() for fieldmarks to only accept
an equal end position if the start position was in range as well.
(regression from 24fd14b387dca458a1b6e9415e936d26562ddb1e)
Change-Id: If6c9b049193bb7f1bc39ec66d1c965512f9d6ec1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100660
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
commit dce1d0766c5013e35762ab85f263df312901f5f4
Author: Caolán McNamara on Mon Oct 14 13:24:31 2002 +0000
#i2916# integrate markm character anchoring export impl
1.) if (nPos >= nStartPos && nPos <= nMinPos)
2.) nMinPos = nPos;
3.) ++nPos;
4.) if (nPos >= nStartPos && nPos <= nMinPos)
5.) nMinPos = nPos;
So lines 3/4/5 should be dead code.
With lines 1 and 2, MinPos has changed to be nPos,
so if we increment nPos, by definition it will now be
larger than itself (aka MinPos).
There is ONLY one time when this could have been used,
and that is if nPos == nStartPos - 1.
However, in that case the fly WILL ALREADY BE HANDLED,
because it is in the current run's position.
So if the fly is already going to be handled,
what good will treating the next character
separately do?
So the comment sounds really important, but in practice
it seems as if it is not happening.
Plus round-tripping already breaks everything anyway,
so very unlikely to raise any substantial regressions.
Change-Id: Ifa867ac3614aef82a3dde358ee3e5bd54d5a1142
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100386
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
* gcc3_linux_aarch64 needs a hack to detect the reserve member in LLVM >= 10
libcxxabi __cxa_exception, in addition to the existing hack for LLVM 5.
On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/
code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need
neither of the two hacks there.
(And a7d1fed24557b203acb5016a98af26f4ef24d27a "Hack to dynamically adapt to
__cxa_exceptiom in LLVM 5.0 libcxxabi" had introduced a "fillUnoException" vs.
"mapException" typo in the comment when it copied it from
bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx.)
* Similarly, gcc3_linux_x86_64 needs both hacks when it is built against
libcxxabi (and the need for the LLVM 5 hack had gone unnoticed there for now).
* It is not clear to me now why gcc3_macosx_x86-64 needs the LLVM 5 hack (which
I even initially developed for that platform,
7a9dd3d482deeeb3ed1d50074e56adbd3f928296 "Hack to dynamically adapt to
__cxa_exceptiom in LLVM 5.0 libcxxabi") but not the LLVM >= 10 hack (although
it does need the corresponding hack in fillUnoException when running against
recent upstream LLVM trunk libcxxabi, f4b6f6a8ae60bdec53512728d00853b73fa18500
"Hack to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi".
Change-Id: I8e7a5c871fbeeaf82bbd16fa03e73f10f229da93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib552cd678cde4048ceca4cc85c0d0347fbcf54b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100580
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
- Backing code for private:image/3242 was removed in commit
367fedcc4456a74cb2fc29a28279bef314bd47ff ("loplugin:unusedenumconstants")
for unclear reasons. Fortunately it's used for a .uno:NewDoc menu item,
so an appropriate icon can be retrieved using that command.
- private:image/3216 was removed in commit
2559cab126f81375197051fb5b07ba6abb9efc77 ("FDO#42454 - EasyHack: remove
code associated with unused icons"). No idea how it worked, or whether
it was already broken at this point.
Change-Id: If5c43626a1334c27604409bcf7eb5920930430db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100450
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
Change-Id: Ie3fe919a7b8296440cd2a670f218147da98f7822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100653
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Tested-by: Jenkins
|
|
and simplify the destruction - we only ever called ReleaseInterface
on destruction, so no need to bother with that, and risk touching
pointers that might be nullptr
Specifically, the problem is this code
pImpl->pSlotPool.reset();
which triggered the path
~SfxSlotPool -> ~SfxInterface -> SfxGetpApp()->GetAppSlotPool_Impl()
which crashes because the pSlotPool pointer is null at that point
Change-Id: I8577760d09be598926623d6eb5500969e07dd6f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100624
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3122a4058f5447cbf0369b60b368c76e5fe40089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100647
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I57a47358d5e4f1e41fc1c89884b7603d8afdc3bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100646
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8b4e1d6654c3a75a3174d56ac01f7d0c7aea5a8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100645
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If4e9b192557b6c9f56bd04ccf9f6a5a8273d7515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100340
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: I2d93d3d76f2fe5e24e6864725184519c0595076b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100638
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...in LLVM 10 libcxxabi, same as f4b6f6a8ae60bdec53512728d00853b73fa18500 "Hack
to dynamically adapt to __cxa_exceptiom in LLVM 11 libcxxabi" for
gcc3_macosx_x86-64 and 986bd28388df745dd969e7be7c3bda36b2b2cb0e "ofz#24641
libc++abi __cxa_exception has grown another member" for gcc3_linux_x86-64.
(Note that 91c8a3f3e7d3c178952d7e78e24cd0d6ba2b165a "The
__cxa_exception::reserve member has been backported to LLVM 10 libcxxabi" found
out that this is already relevant for LLVM 10, contrary to the mentioned
commits' subject lines.)
On macOS arm64 (which shares the bridges/source/cpp_uno/gcc3_linux_aarch64/
code) we know that we always target a >= LLVM 10 libcxxabi, so we do not need
the hack there.
Change-Id: I49e3d5b06b0b427ee3edeb10281025e4b9f2615f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100644
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I71b1dcdaac623d3d5927035fabc031a64204995a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100635
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
Change-Id: I16184cc81bda1b9608bbf52d2732e2fd3f5a8cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100636
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
* Update helpcontent2 from branch 'master'
to 30948b9f503a6270edd2ead2dd13fe9085ab5076
- There is no space in “OpenCL”
Change-Id: I11e897ee51ec3f8962a203ba7192fcf10f36c668
|
|
Did you know you can install xcu files directly via extension manager?
Now it should be easier to discover...
Change-Id: I9a96708fd13f762b20916540e6fa9b87bb582677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100176
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
no need for the impl class to hold a reference to itself
Change-Id: I4ee3fc46df93d9ba087590af33d78834a454161f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100619
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6745f281924573140b02c5f7e5b7174cd9661134
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100631
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iced9299be454f5260582b0b639aad8e5d362d730
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I90fda5d15168027bb92d9c6265b0065e3fa0472d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100621
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8377fc5e8d79456aaa5d827f62e3d9c74ca8e52a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100623
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0aee92369627b18f8c6eabb756e0f409863e2a58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add some API to O*StringLiteral, to make it easier
to use in some places that were using O*String
Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If55b75c4af523e2cd1440d0546e7ae38d578af93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100634
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
Change-Id: Ifcffc928040fc5e3f82f005d977bf3f6df8bd786
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100633
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|