This change extends layout for font-relative paragraph first-line
indentation into Edit Engine.
Change-Id: I5906f493b91fbcb87ded165709fb132b33ce1906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176487
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change adds an ODF font-relative first-line indent paragraph style
attribute as a LibreOffice extension. The corresponding ODF standard
change is tracked by OFFICE-4165.
This change only implements what is minimally necessary to serialize,
deserialize, and check for ODF files containing this attribute. Further
changes are necessary.
* Added cssLength to schema, which is equivalent to length but also
allows ic and em as units.
* Added loext:text-indent to schema as a paragraph style attribute. This
attribute is equivalent to fo:text-indent, but accepts cssLength
instead of length.
* Added XML_TYPE_UNIT_MEASURE to the ODF parser, which currently accepts
only the font-relative measures and forces fallback in other cases.
* Added loext:text-indent to the ODF parser. This attribute accepts
font-relative metrics, and will behave as an import-only alias for
fo:text-indent in other cases.
* Updated SvxFirstLineIndentItem to handle unit-denominated measures.
* Added proof-of-concept indentation handler to Writer. This
implementation is incomplete and temporary, and will be revised in
future changes.
Change-Id: I7eb5c7382093cb18a9b0afbf93dacb34ba1d35ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175941
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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
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
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>
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>
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
because they are unused and incorrect. They are incorrect because
hashCode and operator== are not mutually consistent, as I found
out when I tried to use them.
They were introduced in
commit c39e4f6b8a
Author: Oliver Specht <oliver.specht@cib.de>
Date: Wed May 22 12:26:46 2024 +0200
Add SfxItemType to SfxPoolItem
but were not used in that commit.
Change-Id: I1c3c67e904823117401a0f72a49c80f4bb6398a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169773
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and add some asserts to catch if we modify these things when they inside
a pool, which now that they are in hash-based container, will cause
trouble.
Change-Id: I2779f25cbcf056fbf71e417731d9b1f09ae33dd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169629
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
ESelection::All() select all text
ESelection::NotFound() sets seletion to not found state
ESelection::NoSelection() sets selection to no / invalid selection
Introduce max paragraph and position constants in ESelection,
use for EE_PARA_APPEND, EE_PARA_ALL, EE_PARA_MAX_COUNT,
EE_TEXTPOS_ALL, EE_TEXTPOS_MAX_COUNT.
Also simplify some ESelection constructs.
Change-Id: Ib110c5a730a1deabe4f988baa5a600249b3a31e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169356
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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>
The SfxPoolItem has a new member SfxItemType m_eItemType to
compare types based on enums instead of typeinfo() which
consumes a lot of time e.g. while AutoFormat is running
Change-Id: I033ce67bc9a28ee4790f162380314de85fb4154e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166452
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Vasily's commit aa5c6d1275
new ODF numbered list parameter loext:num-list-format
Internal LO format for list format is changed:
instead of placeholders like %1, %2, etc
we right now use %1%, %2%... Reason: for ODT documents,
having more than 9 levels there is ambiguity in "%10":
it is "%1" followed by "0" suffix, or "%10"?
It was introduced in 6.4.5 for DOCX support with
Vasily's commit 7459b9ecb5
tdf#116883: sw: support for lists level format string
Change-Id: I5962ed04c555356c6a3fc05ab7e036975d7eee40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167833
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Support XSL attribute "column" and CSS 4 attribute "spread",
stored in loext:hyphenation-keep-type, to give better control
over hyphenation-keep. E.g. spread: both parts of a hyphenated
word shall lie within a single spread, i.e. when the next page
is not visible at the same time (e.g. the next page is not a
right page of a book).
– css::style::ParaHyphenationKeep is a boolean property now,
importing hyphenation-keep = "page" as true.
– type of ParaHyphenationKeep, including the new non-ODF types
is stored in the new ParagraphProperties::ParaHyphenationKeepType.
– default value of ParaHyphenationKeepType is COLUMN for
interoperability.
– Add checkboxes to Text Flow -> Hyphenation Across in
paragraph dialog:
* Column (previously: Hyphenate across column and page)
* Page
* Spread
– enabling/disabling them follows XSL/CSS 4/loext, i.e.
possible combinations:
* No Hyphenation across
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "column")
* Hyphenation across [x] Column
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "page")
* Hyphenation across [x] Column [x] Page
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "spread")
* Hyphenation across [x] Column [x] Page [x] Spread
(hyphenation-keep = "auto")
– Add ODF import/export
– Update DOCX import
– Add ODF unit tests
Note: recent implementation depends on widow settings: disabling widow
handling allows hyphenation across columns and pages not only in table
cells.
Note: RTF import-only, but not used bPageEnd has been renamed to bKeep.
Depending on the RTF test results, likely it will need to disable
the layout change, e.g. GetKeepType()=ParagraphHyphenationKeepType::AUTO,
if PageEnd uses obsolete hyphenation rule, i.e. shifting only the
hyphenated word to the next page, not the full line.
More information:
– COLUMN (standard XSL value, defined in
https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep)
– SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last,
equivalent of hyphenation-keep, defined in
https://www.w3.org/TR/css-text-4/#hyphenate-line-limits).
Follow-up to commit 9574a62add
"tdf#132599 cui offapi sw xmloff: implement hyphenate-keep" and
commit c8ee0e8f58
"tdf160518 DOCX: import hyphenation-keep to fix layout".
Change-Id: I3ac6d9e86d0ed1646f105de8607c0e8ebc534eaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165954
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Mohamed Ali