Age | Commit message (Collapse) | Author | Files | Lines |
|
the shrinking patch a4dee94afed9ade6ac50237c8d99a6e49d3bebc1
causes problems, if the textboxes are anchored in the
footer. Therefore, disable it in this case.
For details, see comments in bug tracker.
Change-Id: I117a99041ff67c19a9de17803ff7864c62afdb50
Reviewed-on: https://gerrit.libreoffice.org/34517
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ib008613fb06c82791c63d5b074a3e2ff1c3607a0
Reviewed-on: https://gerrit.libreoffice.org/35834
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5b10aada64408897a56a5932aa28486d7562d617
Reviewed-on: https://gerrit.libreoffice.org/35822
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3178fed3ef4ada61cd9ba0becce4732c8043050f
|
|
Change-Id: Ib0360ddaa21841b7e5921098d14029aec43cc371
|
|
* translate German source code comments
* remove bogus surce code comments
* remove ascii art
* removed old StarOffice/Sun internal bug tracker references
* remove left over from commit dcd5dee88e3c1185638b190553bef65c2ef6566f
Change-Id: I3c5cce621c43e4a03afb76f4cc5a12065914e5ad
Reviewed-on: https://gerrit.libreoffice.org/35404
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I379c3f8ca971e6180744fb7270dde9164ebcec1a
Reviewed-on: https://gerrit.libreoffice.org/35814
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Idbaca4fe90cb943124cded56d8b031a66e488c1b
Reviewed-on: https://gerrit.libreoffice.org/35776
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ibef75de246fb31884153437fe8c05e299fe5962f
Reviewed-on: https://gerrit.libreoffice.org/35782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
we (very irritatingly) create dashed lines by creating a sequence
of dash drawing layer objects, so if its hugely long we create a hugely
long sequence
Change-Id: I38a0c6052cf058d5e02ebef7dd6a90e27f6e5454
Reviewed-on: https://gerrit.libreoffice.org/35781
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
translated comments in sw/source/filter/ww8par3.cxx
Change-Id: I40b41cecb1c73b9678c51d7e4dc41745a96a243f
Reviewed-on: https://gerrit.libreoffice.org/35765
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
The problem here was that while in general paragraph style / direct
formatting deduplication is supposed to happen in the tokenizer,
paragraph tab positions is an exception, and dmapper expects to see the
duplicated tokens.
Fix the problem by introducing a blacklist that contains tokens not to
deduplicate.
Change-Id: I1cca53e99cfdb082df389ff295f3447cc8f9d3b8
Reviewed-on: https://gerrit.libreoffice.org/35790
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I7768f4dbe9892c4264cb16eed87497894aa7494e
Reviewed-on: https://gerrit.libreoffice.org/26582
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Introduction
------------
In MSWord, you can create a variable with `SET` field and then
reference it later in a formula. When you save your file as `docx`,
this `SET` field is registered in you file. In its current state,
LibreOffice can't parse the `SET` field in `docx` file.
Context of this fix
-------------------
This fix is entirely located in the `DomainMapper_Impl.cxx` file
because it's where the parsing is done.
How this fix works
------------------
First, we add `SET` support by adding it to the `aFields[]` variable.
Next, to handle the `SET` constant, we add a condition (swith case) in
`DomainMapper_Impl::CloseFieldCommand()` to call `handleFieldSet`.
Finally, `handleFieldSet` works like `handleFieldAsk` with small
differences.
Note
----
I have renamed `lcl_ExctractAskVariableAndHint` to
`lcl_ExctractVariableAndHint` because this function is used for both `ASK` and
`SET` fields.
Change-Id: I2bf948e26e8506ac151d1d0bc8556721bbe0392b
Reviewed-on: https://gerrit.libreoffice.org/34333
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I69e880e348372b3695b14efd4928f38f29bda37e
Reviewed-on: https://gerrit.libreoffice.org/35747
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Paragraph mark of inner table (0x0D) sometimes has
sprmPFInnerTtp, but no sprmPFInnerTableCell. This still counts
as cell end (at least, MS Word treats it that way).
Unit test included.
Change-Id: I5589cdd486c03ca4567d61882826cc7c245a40c9
Reviewed-on: https://gerrit.libreoffice.org/35763
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id28b9d552083212f730d03725646c5b511462a26
Reviewed-on: https://gerrit.libreoffice.org/35743
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ie52f63382a9fb36f9a472801be012b140bfb51f6
Reviewed-on: https://gerrit.libreoffice.org/35722
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic0a1d4d25eb1d13e9937f4fbd1250596e9e6e341
Reviewed-on: https://gerrit.libreoffice.org/35611
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: Idbd31b84f252abdab1787945c4964173ad5765ba
|
|
Change-Id: I14a820b7c0baba8d8b17d07715bf17c42c73c8fb
TODO: Remove support code from idl and sfx2 modules
Reviewed-on: https://gerrit.libreoffice.org/35718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I52604902247e7d8565476fafe98211fff32c5543
Reviewed-on: https://gerrit.libreoffice.org/35658
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...where the "controlling expression" of any sort of loop contains a sub-
expression of the form
var < val
where the type of var is smaller than that of val. Theoretically, this could
turn up lots of false positives, but practically it didn't run into any. Most
findings have been cleaned up over the last weeks. There's just a handful
remaining places that are hard to clean up, so I flagged them here with
(deliberately awkward) sal::static_int_cast for later clean-up.
Change-Id: I0f735d46dda15b9b336150095df65cf247e9d6d3
Reviewed-on: https://gerrit.libreoffice.org/35682
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia87318cb323d403cdff947da0b70e0d2aabaacd4
Reviewed-on: https://gerrit.libreoffice.org/35657
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...after 64b993e046f23baaacaff1572b7d2a816588b5ef "finish deprecation of
O(U)String::valueOf()" replaced OString::valueOf with OString::number in their
bodies. (Change done in preparation of teaching loplugin:redundantcast about
C-style casts in macro bodies.)
Change-Id: Ifbb4725c496eed18a926fbabeaf4691ac98d9c5e
Reviewed-on: https://gerrit.libreoffice.org/35678
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I317b5fcd6e5753b4f854930ed4f4ceea53a385c4
|
|
What's the point?
Change-Id: Ifdff4aae85282d213f82bd2d69f61f96f8b5e40c
|
|
Change-Id: I74d4b31ea619c94245759b7a061c40095a0879ad
|
|
Change-Id: Ie375b199e055a01b0888a6efe56ef3a2801412b2
|
|
Change-Id: I3bb8430be2460fa72938a4952670d3d92b12e123
|
|
Clearly the mutex must be locked by the caller already.
Change-Id: I2c8a76f5b04751610ed07819343994b75bea4f4f
|
|
Change-Id: Ifa0a036589fba816eaa3503b17223e80f5b99aa1
|
|
Change-Id: I43aef41cee96f69b0bbd540b832780c4002219e3
|
|
These are unnecessary with the fix for tdf#58624, because now
SwAccessibleContext dtor will check that the map is still
alive.
Anything that's still alive at that point should have been disposed
by the recursive Dispose call.
Change-Id: I39102a6b222b2121987d92077d4b9548281d9973
|
|
Change-Id: Ifc1f654e4f63fc7aa62e1b920d1550281a0fa71e
|
|
Change-Id: I6ba3131155fbbe5a01e47aca4008d39191254fe0
|
|
Change-Id: I33ad32f4fa6ca6206e98b38f9170634bce9970de
|
|
Change-Id: I9dbe7218d6ca0fa7ffc780094843be232af74e95
|
|
As seen in JunitTest_toolkit_unoapi_1:
Method doAccessibleAction() finished with state OK
LOG> doAccessibleAction(): COMPLETED.OK
debug:27272:12: -SwAccessibleParagraph mutexwait 0x3fd9f50
debug:27272:9: SwAccessibleContext::Dispose 0x3872620 11SwRootFrame
debug:27272:9: SwAccessibleContext::DisposeChildren 0x4047c80 0x386d600 11SwPageFrame
debug:27272:9: SwAccessibleContext::DisposeChildren xAcc 0
debug:27272:9: SwAccessibleContext::DisposeChildren 0x4047c80 0x386cef0 11SwBodyFrame
debug:27272:9: SwAccessibleContext::DisposeChildren xAcc 0
debug:27272:9: SwAccessibleContext::DisposeChildren 0x4047c80 0x3878fe0 11SwTextFrame
debug:27272:9: SwAccessibleContext::DisposeChildren xAcc 0
debug:27272:9: SwAccessibleMap::RemoveContext erase 0x3872620
debug:27272:9: ~SwAccessibleMap: frame entry 0x3878fe0
debug:27272:9: ~SwAccessibleMap: mpFrameMap 0x3eb64a0
debug:27272:9: ~SwAccessibleMap: mpShapeMap 0
soffice.bin: sw/source/core/access/accmap.cxx:1726: virtual SwAccessibleMap::~SwAccessibleMap(): Assertion `(!mpFrameMap || mpFrameMap->empty()) && "Frame map should be empty after disposing the root frame"'
The problem here is that thread 12 is blocked on SolarMutex in
~SwAccessibleParagraph(), while thread 9 is in ~SwAccessibleMap().
This means that in SwAccessibleContext::DisposeChildren(), the
WeakReference to the SwAccessibleParagraph cannot create a
uno::Reference because its reference count is 0, so
SwAccessibleContext::Dispose() is not called on it and it remains
in the SwAccessibleMap::mpFrameMap.
This triggers the assert and later on ~SwAccessibleContext() would
access the deleted SwAccessibleMap and crash.
To fix this, introduce a weak reference from SwAccessibleContext to
SwAccessibleMap; use a std::weak_ptr because that is not derived from
OWeakObject.
The weak_ptr is only used in the dtor ~SwAccessibleContext(); as
long as the ref-count of SwAccessibleContext is > 0 it is guaranteed
that the SwAccessibleContext::m_pMap is either null or valid
as the recursive Dispose() will work fine.
It is possible that additional temporary owning references could delay
the destruction of SwAccessibleMap, and the order of destruction
of Writer documents is very fragile, so rely on the SolarMutex lock
to prevent that; the only shared_ptr that owns SwAccessibleMap while
SolarMutex is not locked is the one in SwViewShellImp.
(An alternative fix would be to represent the 3 lifecycle stages of
SwAccessibleContext by adding a C++-pointer to the
SwAccessibleMap::mpFrameMap, so that DisposeChildren() can, if
the WeakReference is no longer valid due to ref-count 0, use the
pointer and clear SwAccessibleContext::m_pMap - this and the
corresponding call to SwAccessibleMap::RemoveContext() from
~SwAccessibleContext() under a mutex that is shared_ptr-owned by
SwAccessibleMap and all SwAccessibleContext.)
Change-Id: If2b44c79189e3b3d276491a5c57d5404bb2be71a
|
|
after commit 7916487cf4d9603cdbe4c7ffbe9bb3f28b51ce4e
"convert ViewShellId to o3tl::strong_int"
Change-Id: Ie7b8ac51a94c3b9e6d39e397aa3dd5cb42acc6d0
Reviewed-on: https://gerrit.libreoffice.org/35623
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib90aba380be7eeef3c7418ea85b553079794cf87
Signed-off-by: Gulsah Kose <gulsah.1004@gmail.com>
|
|
Change-Id: I45553d11d56aa8c4432aec126ca51f24bd3ead09
Reviewed-on: https://gerrit.libreoffice.org/35421
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The only place this function is called (SvxMSDffManager::ImportGraphic,
filter/source/msfilter/msdffimp.cxx) it is passed the sal_uInt32 return value
from a call to DffPropSet::GetPropertyValue, so that seems a better type.
(SvxMSDffManager::ImportOLE used long at least since
d2000efb31f864e912c6cf52760eea0e602b6893 "#i106421#: move msfilter to filter";
DffPropSet::GetPropertyValue used UINT32 back then, changed to sal_uInt32 with
e8c2c1daae9008d383288f94600b1d34d2059fb1 "removetooltypes01: #i112600# remove
tooltypes from filter". Unclear if those had ever had more compatible types in
the distant past.)
Change-Id: Ia486d169cd2cc0e73042e72fd4476cc2ae0e8cc5
|
|
Change-Id: I8bf3e30687e20151a9e1936e69362abfe9b3a99d
|
|
Change-Id: I21e54bf70108991b7ca7f96232e6d9411af23ff9
|
|
Change-Id: I9c61e1b558104fa55d887a6c32e1ef2b03f1d1a0
|
|
Unused since commit 2c8fe2e737b84ecd3dbac36a4fe6bd061bbd3bae
"update unusedmethods plugin to deal with constructors"
where I removed a unused SfxDockingWindow constructor.
And in that case, the helpid was only being used to assign
the window a UniqueId.
Change-Id: I148e424424fcf08449440b83a8600071b39d7a07
Reviewed-on: https://gerrit.libreoffice.org/35554
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1ac11a2481c0f4d8be1e1fd7c7637ac0ece3d65c
Reviewed-on: https://gerrit.libreoffice.org/35558
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
We should always be clear and precise, given that LibreOffice handles various
kinds of links.
Nobody at L10n wanted this change, but they were ignored.
This should fix tdf#103093, which was a consequence of the introduced ambiguity.
This reverts commit a1297fc2df243d765ffb14f18bbdde158459b9f4.
Change-Id: I29232c7a8384c3fa501c61aab26e061ebcb1a0d8
|
|
Change-Id: I18d600bf21573bbc47ffcd105afeb652fd74392b
|