The editeng RTF parser was round-tripping signed integers through a
sal_uInt16 via implicit casts when populating SvxLRSpaceItem. This
worked because such an implicit cast may convert signed numbers into
their unsigned two's complement representation, and vice-versa.
Unfortunately, a recent change to SvxLRSpaceItem replaced the final
implicit uint-to-sint cast with an implicit uint-to-double one, which
does not have the same properties.
Change-Id: I80b1a36c47323309b33a8ddaee652c238a7530f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191052
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change adds loext:margin-left and loext:margin-right, which
implement margins that support font-relative units.
See tdf#36709 for additional details.
Change-Id: I31b0dd2b6f98cb5b02fd4dca3608db6fdee4054c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177473
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
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>
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
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>
Sorted out some methods at ItemPool which process
Defaults to make more clear what is going on and
what which method is doing.
Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
SvParser::aToken was OUString despite being a buffer where the parsed
result is collected.
Change-Id: Id24c842738ea0f6f1836f77d855069963ac5ae55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130763
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Hairline (0.05pt)
* Very thin (0.5pt)
* Thin (0.75pt)
* Medium (1.5pt)
* Thick (2.25pt)
* Extra thick (4.5pt)
This unifies the default border line widths throughout the program.
Users can still set any line width they want by chosing "Custom" in the "Border" tabpage.
Also, existing documents won't be changed. The new defaults are just for newly added borders.
Change-Id: I7af85dc189a688a749812824508c33c7814b50f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122683
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
I forgot that MergeRange is not modifying its object, but returns
a modified copy. Added SAL_WARN_UNUSED_RESULT to it (but it seems
to not have effect on Windows).
Change-Id: I919146fc25a0992d543890464ccac75737647ee5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119230
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
seeing as there are no warnings about
SvxRTFItemStackType::SetStartPos
try that pattern
Change-Id: Icad28503047323b01d8e048061c6b037bcdcb83c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116817
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Noel Grandin