| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Change-Id: I7aa8ed716998a185996482dc561219b398a1c919
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169080
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I103c53783b286be0c8472b1850e3cf3e3d6a925f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169057
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I437ab776ccf50dda6c34d458c6a7eaaea09e4d7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169056
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ic2387c75209496ea9301e4c5a129c56e15cfe955
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169055
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I9ca9c6cfe1b92de8ef6fa93ccc0a4c84a11e8686
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ic0d740d336f291f80d82989283dafc0704e97958
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169053
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
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>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ied2b0ed968987f44446abf1066b7e9af106e909d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169039
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I3979577a82539c6b9d36bef0faa2a34689be2a17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169038
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since
commit 2d8056d884ee3ab7b4454c378618dceb6f5a7ae8
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Apr 4 10:55:36 2024 +0200
loplugin:unusedmethods
Change-Id: I2ccdbf45ac688e39df23fd69b8ec21efebad044c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169003
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: I153b36b8cc5e91f46bff42dba2f36fce733a8df9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I75995fb7640977276feeea2e2963725974adbe42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169001
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: Ie653fc6880e096ca4fad4dc1cf77bb3f16915dbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169000
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I55f419e08323d0fe7cc16bc525fc93920980f4c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168999
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ie755b1cbc175d98756f6e6ecc173f32c65c7ff7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168955
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: I061481f7218bc0365c6783662c24642da5f63370
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168954
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: Ifc82d3dd2624868f812533b9df9a34af51a06888
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168953
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Iec53dad76756241b0f0ec31e76def89e336ee6ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168952
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: I07642b427461d76f4fb0a48158598d62f1d2d24e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168951
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: I65f827cd4cf5fdb2a9f0db5f0a26bfce38629222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168950
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: I5aa2d12ff0c85893e2facd491d3c5ed00db77de0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168929
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ia58dd654872f96cb0eaf964df6a9cc7d3b5628f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168928
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: Ia887c46c70971f51a77a74fd03132b7eebb6c192
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Iec4edf42c3047823b4dce6af789a94a849dd5039
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168926
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: Iba2a42344aa5f8d00e4201d9a4ed72ca4c2b2193
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168925
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: Ic7084dd7ab935f0a24f7284745b8d6e8c179545b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168924
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we have the implementation in one class, instead of bouncing
back and forth between two.
Change-Id: Ia91df69b95159f5487d914a67848fb3f18a69dc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This changes applies to draw text, only
JUnit test is included
Basic HTML table import is included.
Change-Id: I00387f3932c0aa54099c9bc7390ad86b4398b417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162871
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
no difference at all, just annoying to be different to its sibling
checks
Change-Id: I1713958f2d2d425d47c626f72a3aa0f3c687526e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168772
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
so turn that off here in editeng where we know the script type
Change-Id: I8e385d35910e378655deb21bce89c4335724a36d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168733
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
With all the changes done for Items we can now do deeper
basic changes to the ItemSet itself with manageable risk.
I already did https://gerrit.libreoffice.org/c/core/+/166455
aka 'ITEM: Add measurements for SfxItemSet usages' to
get some statistical information about the fill/usage grade
of the ItemSet's fixed PtrArray to SfxPoolItems, check
that out to get an own picture.
Those results show that an average usage is between some
extremes ranging from 0% to 50%, but when using more checks
and using multiple files/interactions/edits in all
applications we end up with around typical 12%-19% of that
array used, the rest is nullptr's.
Thus I thought about one of the initial ideas of this
series of changes (ITEM), to use a std::unordered_map
(A) instead of that fixed array of SfxPoolItem Ptr's (B).
Tthat again was for a complete type-based rewrite, which
I once did a POC, but the code cannot be adapted to that,
just too much work.
Those are very different in architecture, (B) is done
since a long time (since ever), but as pointed out above,
(A) is now possible. There are many aspects to it, let's
grep some:
Speed (iterate): (A) and (B) are both linear. (A) has
less entries, but may touch different mem areas
(buckets). (B) is linear, but many empty spaces which
are usually uselessly iterated.
Speed (access Item by WhichID): (A) is hashed by
WhichID, so mostly linear for unordered_set/hash.
(B) is in a linear array, but has to calculate the
offset for each WhichID access.
So I guess speed will mostly equal out.
Memory: (A) will be dynamically allocated (buckets),
but stl is highly optimized and may even re-use areas,
has to provide some extra info but will need less
places for Items since it's dynamic and can start empty.
(B) will be allocated once (except AllItemSet) and may
even be 'derived' to the ItemSet (SfxItemSetFixed), but
has to allocate all space at once.
I can go in lots of more detail here, but due to the
results of the statistics I just made a test now,
including measuring some results (will include in
gerrit, not here). I used two pro versions for that.
That way I have some data now.
Result is:
- It is now possible to do this, it runs stable :-)
- Speed: As expected, mostly no change
- Memory: Depending on usage, 0% to 25% less,
usually around 8-10%
Side effects:
- SfxAllItemSet could be done without WhichRanges,
thus without expensive 'merges'
- SfxItemSetFixed is not needed. While the idea is
good, it needs a lot of extra stuff
- Access to Items is linear if set
- WhichRanges: Still needed, but for vaildity
checking/filtering of ItemSet content
- WhichRanges: Worth to think about if these are
needed at all, probably just exist for historical
reasons since allocation/number of added Items
was never ever dynamic -> just not allocatable
Putting the current version on gerrit, may still
trigger some UTs (checked SW/SC/SD...)
I did not like that functionality at ItemSet that
hands out a vector of the set items for cases where
to avoid iterating and deleting items at the same
time at an ItemSet, so changed to using a local
vector of remembered WhichIDs and deleting after
the iterator is done. I also saw some strange
usages of SfxItemIter in sw which i will have to
check.
Since there are still problems with UTs which I can
not reproduce locally I have now added asserts to
the case that an ItemSet gets changed with still
having active SfxItemIter(s). That is always an
error, but with the architecture of that fixed
array of ItemPtrs did not have devastating effects
(purely by coincidence).
With that asserts, UTs run well in SC and SD, but
in SW I get 11 (eleven!) asserts from the UTs, all
of them from 'ITEM: SfxItemSet ClearItem' BTW.
I guess these have to be fixed before thinking
about this change...
Good news is that all 11 cases were the same in SW,
in SwHistorySetAttrSet::SwHistorySetAttrSet which
does some strange things using two SfxItemIter in
parallel. Thus SW UTs are also clear and I see no
more errors caused by ItemSets being changed while
SfxItemIters are alive.
Bad news is that I still have errors to hunt...
NOTE: Have now cleaned all UTs, this showed that
there are some unexpected side-effects of the Items
being processed in another order when SfxItemIter
is used, also found one case where a
WhichRangesContainer is constructed for a
SfxItemSet using the set items from another ItemSet
and SfxItemIter to do so. There *might* be more
cases not covered by UTs.
NOTE: While speed stays the same and mem is reduced
up to 25% (see measurements in 1st comment) another
*important* aspect is that this frees the way for
using ItemSets *without* WhichRanges - these are
necessary mainly to create that fixed array of
pointers to the Items in a *manageable* size. With
a dynamic structure like unordered_set there is
in principle *no need* anymore to use WhichRanges
to pre-define the Items a Set could hold. There
is one exception: We have cases where one ItemSet
is set at another one with defined WhichRanges to
*filter* the contained Items - these would have to
be identified. This is a rare case and we would have
to check cases where an ItemSet gets set at another
ItemSet. This would be as if all ItemSets would be
AllItemSets in principle - much easier for everyone.
NOTE: Waited for 24.8 split just to not take
unnecessary risks.
Change-Id: I75b0ac1d8a4495a3ee93c1117bdf618702785990
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166972
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
This change fixes issues causing Writer to clip paragraphs at the ascent
of the top line, and descent of the last line, of a paragraph. This
issue caused certain diacritics to render incompletely, or not at all.
Change-Id: I99a3a25335f8b1d798fc8a55ff42d5c78749fca4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168557
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
|
|
Shave 5% off load time by using ItemInstanceManager subclasses for some
the more heavily used pool items
Change-Id: Id389ebb397e2fccfcbae28c8043fe05011b8f1cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168307
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Previously, Writer performed shaping for each span of text separately.
In certain situations, this caused incorrect glyph use, or incorrect
glyph positioning. This change updates Writer so it will also consider
neighboring text while performing shaping.
This change resolves the outstanding duplicates filed against tdf#61444.
As a side effect, this change also fixes tdf#134226.
In addition to the shaping fix, this change implements rendering for
individually-styled glyphs, which is required to fix tdf#71956. However,
this change does not implement diacritic selection, which is also
required for that issue.
Change-Id: Iab4774ffaab5ad6113778c54d02cb260a70c1010
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167699
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
|
|
As soon as SetPrefix or SetSuffix are called,
any partially formed sListFormat is invalid (unless nothing changed).
ListFormat creates sPrefix/sSuffix as a convenience/compat item,
and changing it directly is NOT reflected in the sListFormat itself.
Trying to keep them in sync would be very complicated.
Any process that uses these functions OUGHT TO be doing it as
building blocks to eventually call SetListFormat(prefix, suffix, lvl),
at which point a proper sListFormat will be created.
Change-Id: I05f681c812ea5207cb8127b30dafbd543ffea219
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167832
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
|
|
bug 156105's listWithPercents.odt is an example of a
properly defined ListFormat which contains a percent symbol
in the prefix and suffix, which looked fine in the document itself,
but was cut off short in the UI.
sw/qa/extras/ooxmlexport/data/tdf116883.docx is also an example,
which can be seen if you reduce the first entry to level 1
instead of level 2.
Level 1 is improperly defined as "1%>". This is invalid formatting,
so the entire thing should be considered a suffix.
MS Word also considers it to be a suffix.
This code segment still isn't completely comprehensive
because it won't properly parse "%1xyz%1%." and "%1xyz%10%."
but I'm losing patience.
There is still a potential problem with the
nInclUpperLevels calculation in case
a '%' is used as an in-between separator,
but that seems extremely theoretical and irrelevant to me.
IIUC, the main impact is that it shows some extra dots
in the bullets and numbering UI preview.
Change-Id: Ic1b8fbda62917ad4c7b88bf4fff136d72242f977
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167782
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Tested-by: Jenkins
|
|
According to the orthography, disable superscript for the Catalan
ordinal indicators (only used for -a): 20a, 20è, 20ns, 20es.
Change-Id: I2a3cd17b51a29300e9cfcacdcf0cb123d225248a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167652
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Add missing dot, support plural and alternative forms with 'r':
– add missing dot: 1a -> 1.ª, 1o -> 1.º
– support plural forms: 43as -> 43.ªˢ, 43os -> 43ºˢ
- support alternative forms:
1ra -> 1.ª, 1ro -> 1.º, 43ras -> 43.ªˢ, 43ros -> 43.ºˢ
Change-Id: Ibaeae958ca209edffb13f611ee8a71c80bf15a26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167649
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
