Age | Commit message (Collapse) | Author |
|
On stress test with shapes and typing a segfault ocurred due to
using a freed vcl::Cursor.
On SdrObjEditView::SdrEndTextEdit, delete pOLV can delete the cursor
remembered in pTECursorBuffer. But if it is set to the window before
the deletion, it will be safely removed from the window.
And on SdrObjEditView::ModelHasChanged a re-anchoring sets a cursor
on the window that sholdn't be there and other SdrObjEditView can
see, remeber, and use it even after this one died and freed the
cursor.
Change-Id: I3cfef3b68b77e6e6b49c3b68297a6a20e1f9394a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171184
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 3b5738ab1a646d089fa7cc59ffaeda7d011c1e07)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171288
Tested-by: Jenkins
|
|
This allows optimizations when 'this' is empty, avoiding allocations, and
making it possible to not special-case it in other places, as was done in
ContentNode::Insert in commit 8ab44b114c6706ab2e3d8a19884daeb544d3c2e1
(tdf#161846 avoid allocation in ContentNode::Insert, 2024-07-30).
A couple of disambiguation templated overloads was introduced.
Change-Id: I2b5e94c2175379b2696c34e600393d32731f0ab6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171271
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
if we already call GetItemState, we can use that call to fetch the item
Change-Id: I736dec9bb56ad3bd66bb53e1cef2cf1e3092821d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171269
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the methods are already returning by value
Change-Id: Ie9eaf2ba3ae0ca4ad79b05229dd6856537580044
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171249
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
we can fairly easily allocate the exact buffer size we need and avoid
needing to extend the buffer
Change-Id: I7f0b2533dab03452db60ddaa5b8a5f3471c195ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171225
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is fairly common
Change-Id: I3b1ec65d880cb71b8894f292061e23376af177bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171224
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
with large property maps, even a binary search starts
showing up, but we can do a O(1) search here by using a map
Change-Id: Ie7916076073e6dd393f0a1fb5a0db1b973999408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171173
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
and
cid#1555227 COPY_INSTEAD_OF_MOVE
cid#1555329 COPY_INSTEAD_OF_MOVE
cid#1555384 COPY_INSTEAD_OF_MOVE
cid#1555387 COPY_INSTEAD_OF_MOVE
cid#1555399 COPY_INSTEAD_OF_MOVE
cid#1555400 COPY_INSTEAD_OF_MOVE
cid#1555406 COPY_INSTEAD_OF_MOVE
Change-Id: I85dc45e2686c6b3e8b97a23872cb26416edc27c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171178
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1556135 COPY_INSTEAD_OF_MOVE
cid#1556146 COPY_INSTEAD_OF_MOVE
cid#1556164 COPY_INSTEAD_OF_MOVE
cid#1556171 COPY_INSTEAD_OF_MOVE
cid#1556177 COPY_INSTEAD_OF_MOVE
cid#1556181 COPY_INSTEAD_OF_MOVE
cid#1556182 COPY_INSTEAD_OF_MOVE
cid#1556183 COPY_INSTEAD_OF_MOVE
cid#1556192 COPY_INSTEAD_OF_MOVE
cid#1556201 COPY_INSTEAD_OF_MOVE
cid#1556208 COPY_INSTEAD_OF_MOVE
cid#1556215 COPY_INSTEAD_OF_MOVE
cid#1556224 COPY_INSTEAD_OF_MOVE
cid#1556227 COPY_INSTEAD_OF_MOVE
cid#1556228 COPY_INSTEAD_OF_MOVE
cid#1556238 COPY_INSTEAD_OF_MOVE
cid#1556246 COPY_INSTEAD_OF_MOVE
cid#1556247 COPY_INSTEAD_OF_MOVE
cid#1556288 COPY_INSTEAD_OF_MOVE
cid#1556293 COPY_INSTEAD_OF_MOVE
cid#1556305 COPY_INSTEAD_OF_MOVE
cid#1556310 COPY_INSTEAD_OF_MOVE
cid#1556317 COPY_INSTEAD_OF_MOVE
cid#1556321 COPY_INSTEAD_OF_MOVE
cid#1556322 COPY_INSTEAD_OF_MOVE
cid#1556331 COPY_INSTEAD_OF_MOVE
cid#1556339 COPY_INSTEAD_OF_MOVE
cid#1556342 COPY_INSTEAD_OF_MOVE
cid#1556351 COPY_INSTEAD_OF_MOVE
cid#1556358 COPY_INSTEAD_OF_MOVE
cid#1556370 COPY_INSTEAD_OF_MOVE
cid#1556379 COPY_INSTEAD_OF_MOVE
cid#1556390 COPY_INSTEAD_OF_MOVE
cid#1556423 COPY_INSTEAD_OF_MOVE
cid#1556532 COPY_INSTEAD_OF_MOVE
cid#1556561 COPY_INSTEAD_OF_MOVE
cid#1556662 COPY_INSTEAD_OF_MOVE
cid#1556704 COPY_INSTEAD_OF_MOVE
cid#1556730 COPY_INSTEAD_OF_MOVE
cid#1556988 COPY_INSTEAD_OF_MOVE
cid#1557071 COPY_INSTEAD_OF_MOVE
cid#1557081 COPY_INSTEAD_OF_MOVE
cid#1557177 COPY_INSTEAD_OF_MOVE
Change-Id: I2c723f0fe9a4eefa62a68f47049ed690d06eb0ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170932
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I6cf0557b1e44dff08fa1efa4aefa14dec276458e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167134
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
|
|
avoid doing GetItemState if we don't have a wrong list (the common case)
Change-Id: I3a1a22da657835ae37e8025d8ce21ad14d4e2c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I954c9e3f8502a5243c664ed0bf066fb4c4cb4ccc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169991
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
for large complex documents with lots of shapes.
When that happens, we spend a lot of time scanning the std::unordered_set inside DefaultItemInstanceManager.
Since most of our items are already capable of being hashed, and thus avoiding the scanning cost, make it so we can use the HashableItemInstanceManager most of the time.
Change-Id: I43f4c04e956d316c976bea67d1941529d2d91182
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170813
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
followup to commit 57c228803e55ed343c6693de7d0857ad7d3cd9e3
Change-Id: Iebfb23bb65e2bf898bf27f367cc9641f47a14cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167998
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
|
|
so we can get rid of TestAutoCorrDoc, only used for
test purposes
Change-Id: I0931fa76550358d071ebdec364fd6b55485bb3b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170680
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Id7a81db385dd3ca30daa37ba74a82d06c417a51c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170678
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Previously, Writer counted characters for all CJK languages, rather than
words. This is the correct behavior for Chinese and Japanese, which make
extensive use of ideographs. However, it is not correct for Korean.
This change adjusts the Writer word count algorithm to count Korean
words, rather than Korean characters.
Change-Id: I6e77136867baca1a7b51248886ee5fd7073ad364
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170621
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
|
|
and
cid#1555160 Use of auto that causes a copy
Change-Id: I2e2056ddbfb2d11d288a5b2df273e8bc049387fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170455
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
This patch allows tools::PolyPolygon to be iterated using c++11's
fancy range-based for-loops. It also upgrades a bunch of old-style
for-loops iterating over polypolygons to the new style to make code
more readable.
Note that not all for-loops iterating over polypolygons have been
upgraded, as I didn't find a way to automatically find those. I just
did a few I found manually.
Change-Id: Ifa8d0d44e6f0aa28fdcfd87d70058b12f48c1349
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168730
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
to avoid it accidentally coming to life during shutdown.
Change-Id: I016a3396639c30350432b60c375c9777e551eb84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170425
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
for the ItemInstanceManager the identification was done
using typeid/hash_code, but that has problems - it is
only defined to be identical for two instances of the
same type, but other types can have the same code.
Thanks to Noel to find that out, that is not reliable
to be used.
In the meantime we have SfxItemType to identify Item
instances, so I changed the code to use that.
The master had five additionally added Items that
use the (2a) method of this mechanism (see comments
in svl/source/items/globalpool.cxx for that). The
gloal is to use as less as possible of this Items in
that mechanism, so I checked.
For four of these hashing was used, so the mem/runtime
aspect is okay -> access is fast enough to prefer
mem over runtime. Adding hashed Items (or any other
fast mechanism) is always okay.
One did not have that (SvxBoxItem) and used just the
fallback ItemInstanceManager, so I removed it. We
now have 18 Items for which that mechanism is
initialized immediately.
Noel also already moved the countdown for starting
to use the mechanism in case of default handling
(case (1), NUMBER_OF_UNSHARED_INSTANCES) to the
unorderd_set. someting I had already planned to do,
too - thanks!
Change-Id: Icf6f427e5ea64672f385357aaad75bb5b7fcbf98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170314
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
and
cid#1607910 COPY_INSTEAD_OF_MOVE
cid#1607818 COPY_INSTEAD_OF_MOVE
cid#1557402 COPY_INSTEAD_OF_MOVE
cid#1556530 COPY_INSTEAD_OF_MOVE
cid#1557396 COPY_INSTEAD_OF_MOVE
cid#1556522 COPY_INSTEAD_OF_MOVE
cid#1555628 COPY_INSTEAD_OF_MOVE
cid#1554705 COPY_INSTEAD_OF_MOVE
Change-Id: Iae3fbf4a04bf3714f416995640b9d70fe204cf73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170321
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This reverts commit 85fd526fc681a994415bb422090d1d23aa7d54f6.
Change-Id: I5019f72f88497f50a77666d57f2d16c2749bd1c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170218
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I40a4dc9bc13bfb769b2f9f15b0ab1ff9490639da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170076
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
found by doing some git grepping, we should now have values
for all items in the hierarchy
Change-Id: I397ca7e8f53f53737201385c4c8029b436895c1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170016
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
after commit 85fd526fc681a994415bb422090d1d23aa7d54f6
"fix and simplify the ItemInstanceManager mechanism"
The problem is that some *Item classes in sw/ and sc/
share WhichIds, and a whole bunch of SfxBoolItem
subclasses share the same SfxItemType enum value.
So we ended up mixing and matching objects
of different concrete subclasses in a given
*ItemManager collection.
Add some asserts to the global pool code to catch
issues like this earlier on.
Add unique value of the SfxItemType enum for all
the SfxBoolItem subclasses
Change-Id: I3c8d4e02be1cd412b0292e973a6498df5f8e7102
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170003
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic96d53c113cd6ae5b805df5a8e80d4da7adfec59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169966
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ic5c78a0de4e7edafc0ba97bf69d43c377f7b5503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169633
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic03c78f6dde68f5557d474147336fa62be6f3aaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The mechanism is currently broken because it uses hash values as keys,
in two different places. But hash values are not required to be unique,
and as soon as there are enough items of a given type, a collision is
inevitable.
So just simplify this whole mechanism. There is no reason we need
type-specific item managers. Stuff everything into a single global pool,
that uses hashing correctly.
Notes
(*) Performance, as far as I can tell, is the same or slightly better.
(*) I removed the NUMBER_OF_UNSHARED_INSTANCES thing, in favour
of just having a simpler mechanism
Change-Id: I9068baf9bf6fae2500ae5748c6d1aabe6c3a18a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169709
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I7d798b233eae9906f9caff9da411b27d3e26ebb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169858
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Id790c9f8433e7dd780aeaec1a1dd614c6ab3daa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169791
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Icd6bf3bc72ac9728b4a7f3c602cb919bfdef18e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169790
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
otherwise we get the weird behaviour where two SvxTabStop instances
which are constructed the same, return false from operator==
because one instance has had getDecimal() called on it, and the
other not.
Change-Id: I1f708c1b1e03efcd9fc554eaf2777c4c3e8a80b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169774
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I073ac7358c1bcb82992ec7746f4b3986d6d35633
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169755
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit ae56dc05b27f05ffcee99845d661a237e70a7a51
"tdf#96787: AutoCorrect: after deleting a replacement entry, it's still used".
Change-Id: Ifb4cf1b359b852c7610337d4bd389a8ca5dce610
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169713
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I7aa939681720bc0dc81c8f114a3608a8cdfb4f60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169722
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
which did I not see when I did
commit cb3c65fb706cb1c7c9224222fd16875e924a9759
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Jun 27 19:24:28 2024 +0200
assert when SfxObjectItems are modified while in a pool
Change-Id: I16e2ee72eda4b3ca69f83eb70ad4f4b0a14748a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169696
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which has always been a problem, but becomes a more obvious problem when
I implement some upcoming optimisations
Change-Id: I8b0368b0b8e9a726c71d241841afeed3876281d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169657
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
If the paragraph marker is formatted as Uppercase,
then Uppercase is applied to that line's numbering as well.
However, if the marker is formatted as SmallCaps,
it MUST NOT be applied for MSO formats.
Apparently MSO only supports Uppercase and SmallCaps,
not Lowercase or Titlease.
I don't like these adhoc exceptions, so I didn't
attempt to apply them to ODF formats.
Let's keep it simple for ODF - any char format that applies
to the entire paragraph should apply to numbering as well
(except for the existing underline/overline exceptions).
- if you don't like that char attributes apply at all, blame MSO.
- if you don't like that DOCX is missing your goofy formatting,
blame MSO for being inconsistent.
ooxmlexport12's tdf143384_tableInFoot_negativeMargins.docx
is almost interesting because it applies superscript
and small caps. However, the list is already uppercase,
so it can't be used for the test.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf43767_caseMapNumbering
Change-Id: I273baebc996adfd001e1c591dbb9aef9272a42f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169476
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
|
|
create a template class to reduce repetition
Change-Id: I8c9c71fdfdac20a3b34432affac07aa1d46e8373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169613
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I324a1814fc1b3321eed5b29922790600e7092c17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169344
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
CheckIdleFormatter() already does that
Change-Id: Ie6b9e3285303899e3f67cccb0fc5f5625c8db684
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169343
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I851578ff553b01fb7d48cf5aa8f7a2d795496751
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169340
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
SvxAutoCorrDoc::ChgAutoCorrWord() implementations: correct multiple patterns
* include/editeng/svxacorr.hxx, editeng/source/misc/svxacorr.cxx:
- Add classes SvxAutocorrWordList::{Iterator,WordSearchStatus}.
- Make SvxAutocorrWordList::SearchWordsInList() return WordSearchStatus
so the search can be continued with the added
SvxAutocorrWordList::SearchWordsNext() method.
- Make SvxAutoCorrect::SearchWordsInList(), and its lcl_SearchWordsInList()
companion, return WordSearchStatus propagated from
SvxAutocorrWordList::SearchWordsInList().
- SvxAutocorrWordList::WordMatches():
The existing mechanism of preventing collision of patterns like in
tdf#83037 (→ and ← and ↔ autocorrect collisions) was by storing
the matched string of wildcard pattern back to the list without
overwriting existing one. If the matched string was found in the list,
it would just be treated as no matching.
While this worked well for collision prevention, it caused failure
on the new exhaustive wildcard pattern visiting method when autocorrecting
the second text chunk with the same content. In such situation,
all intermediate stages of corrections of the first text chunk would be
recorded into the list. And, in the second chunk, the first stage would
just be applied from the recorded pattern, but all the next stages
would be refused due to the "collision" with the recorded patterns.
Moreover, the new method would cause the list to grow more quickly
as the autocorrections are done.
To solve the problem, just "peek" for the collision instead of
actually storing it. And SvxAutocorrWordList::ContainsPattern()
is added for this purpose.
* editeng/qa/unit/core-test.cxx:
- Modify TestAutoCorrDoc::ChgAutoCorrWord() to iterate through all patterns,
instead of finishing at the first one.
* editeng/source/editeng/edtspell.cxx:
- Ditto for EdtAutoCorrDoc::ChgAutoCorrWord().
* sw/source/core/edit/acorrect.cxx:
- Ditto for SwAutoCorrDoc::ChgAutoCorrWord().
- SwAutoCorrDoc::ChgAutoCorrWord(): Remove old dead code for autocorrection
on text with redlines.
* sw/qa/extras/uiwriter/uiwriter6.cxx,
+sw/qa/extras/uiwriter/data/tdf158454.odt:
- Add unit test "testTdf158454".
Change-Id: I8fb4a628a977b79b0ed2f239fd3749f15823b5df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160160
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
|
|
Change-Id: I4bc67811e228b4806db9f9b9bf9fb0de0eb36de2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169263
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia216da9bd7764f2d21aaee761a02eafda88d892e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169257
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Copy a single world from the Impress bugdoc to Writer, number of
paragraph styles increase from 126 to 221, while only +0 or +1 are
expected.
It seems the problem is that the editeng doc of the shape refers to all
styles of the masterpage and we write the style table before the
content, so we export all styles to be on the safe side.
Fix the problem by iterating the paragraphs of the selection in the
"copy" (not "export") case, assuming that typically the selection
doesn't refer to all available styles in the document, and the number of
paragraphs in a shape is not a large amount.
An alternative would be to limit the style import on the RTF reading
side, but not producing those not needed styles in the first place looks
superior.
Change-Id: I43e4c542e530ff6422357a28399718e89fdbabe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169251
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I0b82778c57b0da2dc4f1e685349d5f423a3d4090
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169241
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3bcbaa4005e65ecdb8d1344a792a465b83aec9fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169237
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|