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
The full bugdoc loops; text frame 3160 (on which a floating table is
anchored) is split, immediately joined, and split again...
SwTextFrame::IsEmptyWithSplitFly() has a wrong condition that compares
document coordinates with relative position inside the frame; try to use
the confusing SwRectFnSet to compare instead, which prevents this frame
from splitting because it actually fits into its upper.
Another problem in that function is that it checks RES_PAGEDESC but not
RES_BREAK; try to fix that too.
(regression from commit 16b5b21d36)
Change-Id: I94251b7443e51303b28d14f0597b0bf782142480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168668
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...where "Referer" is now passed in as an additional property, so that the
relevant objects can decide whether to obtain graphics while loading a document
Change-Id: Ie3dabc574861713212b906a0d7793f438a7d50a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Objects that are marked as annotation shouldn't be rendered to the
PDF document. Those should be written to the PDF as annotations
(if output of annotations is enabled in the PDF export options).
Change-Id: I60650b5a64dc52da6d32d8ac92441e4b21900126
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168574
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Make annotation objects selection similar like it was with the
old annotationg tags.
Change-Id: I0623ddf56274dc996ed9dd16096256e03ad65270
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168523
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
The code to open AnnotatationWindow was removed in the previous
change as it needed to be changed to make it work with annotation
(sdr) object.
Change-Id: Ic75e4fca6b46359f29762bc4735a76204aeb90f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168514
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Previously the annotations are shown as annotation (smart) tags,
which just mark in the document the existence of an annotation at
a certain position. For PDF support the annotations can be more
complex, so they can show many forms of vector graphic, ink,
bitmaps, text boxes,... and for this a normal tag is not enough.
This change moves the annotations from simple tag to use the sdr
objects, so any SdrObject can be created as an annotation. The
previous tag annotations are using SdrObject (actually SdrRect)
subclass AnnotationObject and the code that previouslly worked
with the tag annotations has been adapted.
The (PDFium based) PDF import has been changed to use subclasses
of the SdrObjects for the PDF annotations.
Change-Id: I4746b85b5b679499e470987e61ed356397e56bf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168485
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
* Update translations from branch 'master'
to 0d53fb56250d16d87e001ef05b52d289dff5b1df
- update translations for master / 24.8.0 beta1
and force-fix errors using pocheck
Change-Id: I92f8e74d5cf8127e8f85e83c600472b6b84c97ed
If the Name - Name Value pairs contains already an ocPush result
no need to interpret, so the Calculation parameter can reuse it.
Change-Id: I55465d674eb31aea7c3123c889250c9fa127f1fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168661
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Open the bugdoc, the in-table paragraphs have some top and bottom
paragraph borders in Word, not in Writer -- because the cell and
paragraph UNO object both have a property named TopBorder as mentioned
in commit 39c54c0ef8 (tdf#161443 DOCX
import, table style: fix para border leaking into cell border,
2024-06-07).
The previous fix avoided the problem that the unwanted border affects,
the cell, but re-routing the property to affect the in-table paragraph
were not done.
Fix the problem by adding 3 new meta-properties with a "Para" prefix for
all 4 border locations (top/left/bottom/right), this way the paragraph
borders defined in a table style can affect the in-table paragraphs, but
not the table cells.
Apart from the border itself, this also affected the border spacing,
which means that the position of all text inside and below the table is
now also correct. Unfortunately this also means we need to move away
from the constexpr frozen container that is only suitable for a limited
number of items:
sw/source/writerfilter/dmapper/PropertyIds.cxx:394:6: error: ‘constexpr’ evaluation operation count exceeds limit of 33554432 (use ‘-fconstexpr-ops-limit=’ to increase the limit)
Returning to std::unordered_map is good enough for our needs.
Change-Id: I478f274800a1d0b200f10226438ab4cfd4957b74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168659
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Downloaded from https://www.python.org/ftp/python/3.9.19/Python-3.9.19.tar.xz
* python-3.8-msvc-sdk.patch.1 is no longer needed
* Comment out deprecated warnings for now:
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(42): error C2220: the following warning is treated as an error
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(42): warning C4996: 'PyUnicode_FromUnicode': deprecated in 3.3
C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/pyuno/source/module/pyuno_util.cxx(64): warning C4996: 'PyUnicode_AsUnicode': deprecated in 3.3
Change-Id: Iaa358ffaaea63cf6ec47914759d0469e70e1cc65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168551
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
.. and draw:rotation in <draw:hatch> element.
ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2
it is specified as double with unit "deg", "grad" or "rad", or without
unit. The unit-less value is specified to be in degrees. But OOo, AOO
and all LO versions had written the value unit-less in 1/10th of a
degree in some cases.
To fix it, LibreOffic will be enabled to read units. When then the
active versions are able to read units, starting with the then actual
version, LibreOffice will write angles with unit 'deg'.
This has already be done for gradients, see tdf#89475. This patch
starts the first step to make LibreOffice able to read units for
dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO
FillHatch.Angle). I have not found further cases of writing 1/10deg.
The patch still writes unit-less 1/10th of a degree for export to
ODF 1.3 and earlier. When it is time to write unit degree or when
LibreOffice supports the next ODF versions, some places need to be
adapted. They are marked.
The converter convertAngle is renamed to convert10thDegAngle() to
indicate, that it is special. The parts, which were specific to
gradients are moved to the gradients, so that it is now usable for
dr3d:angle and draw:rotation too.
I intend to write next a patch that enables LibreOffice to read angle
units for cases where LibreOffice already writes unit-less values in
degree. That is not so urgent, but to bring LibreOffice nearer to ODF,
reading angle units should be implemented nevertheless.
The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc
to have access to it from xmloff/source/draw.
Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
commit 5f9a955042
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 7 13:03:19 2024 +0200
tdf#158914 sc a11y: Send TEXT_CHANGED event when text changes
had made sending a `AccessibleEventId::VALUE_CHANGED` event
conditional on the cell having a *numerical* value.
Assigning the new string to `m_strCurCellValue`
should always happen independent of this, though,
as this is the string value, not the numerical
value.
Thanks to Patrick Luby for noting the difference
in [1].
[1] https://gerrit.libreoffice.org/c/core/+/167961/comment/1af95eb6_7db33e0b/
Change-Id: I1d1da2caeb7f2199251599313ec4412d7b6e47b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168635
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This reverts parts of the LO 24.2 patches commited for bug 57414.
There were lots more vocal people than I expected
that want the crash-recovery to restore their session state.
Since there is no working alternative to trigger a session save,
just revert the bits that made the RecoveryList clean
(as I and other users had requested)
and revert back to the original, historic behaviour.
This means that now the following files will again be recovered:
- saved documents (opened from file URL)
- read-only documents (opened from file URL)
- files that were opened, but never modified (opened from file URL)
- files from now-potentially-unavailable disks/servers/temp-dirs
- recovery will attempt to access those file URLs
At least one benefit remains:
- new, unmodified documents will not be in the RecoveryList
Maybe I'll look into a session save option for 25.2.
Change-Id: I2477f194bf94f14620d284728027846ec5b6119e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168650
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No need to loop through all of the textboxes
if the rName.isEmpty() since that is never accepted as a duplicate.
As soon as a valid duplicate is found,
we can quit search the rest.
Change-Id: I785c2cf4cc619fc45fc2b95f492fe1b5ff0f1a55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168582
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
formatted rounded values.
Filtered formatted values were not sorted with the rounded values
but with the original values and the duplicated values caused wrong
filter results.
Regression from commit: 2d1df9f3dc
(tdf#117276 sc: Show hidden filter elements as inactive elements)
Change-Id: I7540ba5fa98e6bbe0b014448bf2449432261d542
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168592
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Fix 1) missing or too narrow hit area (tdf#157833),
and 2) not recognized click inside hit area (tdf#155692).
It was impossible or very hard to resize text table
columns and rows using the mouse:
1) Double arrow, i.e. "resize row/col" mouse pointer shows
the hit area of text table row/column borders. This was
missing or was very narrow with normal zoom, because of an
obsolete constant for low resolution displays.
Change this constant used in IsSame() with scale-dependent
values to support the same hit area on different zoom levels
and with different screen resolutions.
2) Especially on bigger zoom, "resize row/col" mouse pointer,
i. e. the visible hit area didn't guarantee drag & drop any
more because of too small hit area in pixels in the svruler
code base: clicking on not exactly center of the hit area
resulted selection of cells or the cell content instead of
drag & drop the border, violating WYSIWYG. Enlarge the default
1 pixel to 5 pixels to cover the whole hit area. Note:
only for resizing table borders inside the document, not on
the horizontal and vertical rulers.
Change-Id: I398a0de782040b0ad18835658ed625117a6e0e06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168605
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
As discussed in the design meeting, this patch adds an internal white outline to the selection overlay to provide better contrast.
FTR: This is the same approach used by other office suites (Excel, OnlyOffice, etc).
Change-Id: I9b279ebfa9efbd2b5d9894b94ebda653c3dba6e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168538
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
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>
Don't execute On expression GoSub Statement; On expression GoTo
Statement if the expression lies out of range.
Change-Id: I5c1de25918b5e812d7ec82034f8d56351374d56a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165960
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Bayram Çiçek