The EditEngine decomposes it's content mainly to
Prmitives (there is still a direct paint mode used
in rare remaining cases which we not yet got rid
of). For TABs the special case for 'extended' TABs
(see format/paragraph/Tabs, FillCharacter) was
handed through all layers using method DrawingTab,
put into a DrawPortionInfo and held at the text
primitive (TextSimplePortionPrimitive2D). While
for direct paint the expansion was already done in
ImpEditEngine::Paint anyways (and always painted,
independent from bStripOnly what was unneccessary
and I corrected that, too) it had to be done for
text paint in VclProcessor2D for each repaint.
This is not needed, so now the extended text
created in EditEngine decompose gets used.
This makes a lot of stuff simpler, including
EditEngine/Outliner and some involved classes.
If it somehow should show that it might be
necessary to do that for each paint it should
be done in the obvious way then - using an own
primitive that creates the expansin in the
decomposition (and buffers it).
Change-Id: Ieb02219142af8f6bee01dcd658e08b185a4212cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171380
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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 8ab44b114c
(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
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>
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>
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>
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>
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 85fd526fc6
"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>
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
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
This reverts commit ae56dc05b2
"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>
which did I not see when I did
commit cb3c65fb70
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
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>
