Age | Commit message (Collapse) | Author |
|
Change-Id: Ifaff6a048b9d174a9aa3fc9dabf62c1f8c509eb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114572
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: Ic52623ac8ca6e0758578b7ae57332f0e9c184b5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114573
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I0a8279429c9e0d884a5e8fbb8f22617832385a53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114574
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Tool button using the image was removed by
5da3ae08596c2465532e662537f5292454a84a3e
and with no other tool button using it, it accounts for blue
'decoration' at the top of 3D effects dialog
Change-Id: Id5705832614315316433e38e0c8635e1b4a3d906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114569
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Those were mostly suggested by Android Studio, like:
* mark members static or final
* drop unused variables and members
* avoid unnecessary cast
* simplify condition: '(!cond)' instead of 'cond == false'
* drop unused imports
Change-Id: I252fe836e4a3184e13af59a30202c6daccac1794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114546
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
... and make its static 'LOGTAG' member final.
Change-Id: I6d16bc76590341a60db9e123d20d81dcd7adba71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114545
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
It appears to be unused since
commit f3eccc655387b47fb0986558b8835588eee2898d
Date: Tue Feb 3 18:19:32 2015 +0000
tdf#87432: normal icons for folders in android doc browser
Change-Id: I6984ff75392f7f28ba1b2659846d164d25b66f2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114544
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
instead of digging into parent a11y via getAccessibleParent which
isn't there when hosted in a gtk widget
Change-Id: I417737ae568c823b550bc259c3b3047124a411ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114552
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
if the number of items exceeds 1000, just stop, the UI
becomes unresponsive.
This takes the load time from 24s to 17s on my machine, and also
makes clicking around much better (because it rebuilds the tree on
every single cursor click)
Change-Id: Ib32578306d1098fe9953d8c96b6926110c64d1c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114553
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id4e7778ffcbeadf53684e5b6814d139e82bcf7e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114555
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic7d819775f59b7303dea1a381a20ca3ea1ac8d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114550
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I810e84a9c246df73010c053944a1b602fe53c1d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114562
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Following up on f62cb40bdfaf41cf8e989640f9be79f652f30914 "Remove dubious #pragma
pack" and 9eba8aa38db3a0dc2f7dfaf24a003c16418aef18 "Remove dubious #pragma pack"
for O[U]StringLiteral, which argued that the pragma pack around rtl_[u]String
are useless cargo cult (paraphrasing): "All struct member types involved
(oslInterlockedCount aka sal_Int32, sal_Int32 itself, sal_Unicode, and char)
have size <= 4 resp. < 8, so the member alignment ("on a boundary that's either
a multiple of [the pragma pack value], or a multiple of the size of the member,
whichever is smaller", according to
<https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=msvc-160>) is not
affected. And neither are alignof(rtl_String) and alignof(rtl_uString)
affected, which would remain e.g. 4 on x86-64."
(Curiously, the pragma pack value had always been 8 for rtl_String but 4 for
rtl_uString, ever since at least 9399c662f36c385b0c705eb34e636a9aec450282
"initial import".)
The plan is as follows: In step 1, add temporary static_asserts that state the
current alignof/sizeof values; keep this for a while to see that all relevant
Windows builds actually agree on these status-quo values. In step 2, remove the
pragma pack cargo cult; keep the static_asserts for a while to see that the
removal has no impact on any of the relevant Windows builds. Finally, in
step 3, remove the temporary static_asserts again.
Change-Id: I8059ac300cc5b517db4a575f0eaba48678966537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114540
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
gen uses the absolute screen position so that's what's expected
Change-Id: I4f51c272a49a640e0a387bc123b2cc17ea430d6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114551
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I11ad5375e5fee35065bb855fb0db0b0c00d75fd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114554
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This recently crashed in jenkins, in UITest_sw_navigator:
Thread 1 (Thread 0x2b46be801700 (LWP 8577)):
0 rtl::Reference<vcl::Window>::get() const (this=0x9999999999999a21)
1 VclPtr<vcl::Window>::operator vcl::Window*() const (this=0x9999999999999a19)
2 vcl::Window::GetChildCount() const (this=0x2636360)
[...]
13 WindowUIObject::get_children() const (this=0x1899cd0)
14 UIObjectUnoObj::getChildren() (this=0x18986f0)
15 non-virtual thunk to UIObjectUnoObj::getChildren()
16 gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*)
Change-Id: I190738a436e4cd957362f5bb2cd8993c8424512a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114541
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
for native gtk widgets inside vcl docking windows. Put vcl focus in
container on F6 so cycling moves between expected panes.
Change-Id: I70bd54493a345ae5bdb801caf79d567bc1ae0438
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114543
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
* Update helpcontent2 from branch 'master'
to bb496ca3d2da2fd0846cd56cfde58a584e512c47
- Create FormControl service help page
Change-Id: I32ec1a4509e5d59b73696ac25a4a757d055dfb70
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/114186
Tested-by: Jenkins
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
|
|
Change-Id: I678db4ed598b3e1061857e942185b2307fbb9e88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114538
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Provide the "Save As..." menu entry in Android
Viewer also if read-only mode is used, either
because the experimental editing mode is disabled
or there is no write access to the document.
This way, a copy of the original document
can be saved elsewhere.
In case experimental mode is enabled, editing
is allowed after saving the document.
Call 'ToolbarController#setEditMode' in
'ToolbarController#switchToEditMode' right away instead
of posting it to the main handler in a Runnable along
with the other commands (that change the UI), so the new state
is already taken into account in
'LibreOfficeMainActivity#onResume' and the toolbar
isn't switched back to view mode there right away.
Change-Id: I321e42d0833463b31c7b39336d66b29bd51d9890
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114539
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
commit 3dba2e4a325fa0fdfbbedb0ffc1fcf678bfcbc94
Date: Thu Mar 25 12:23:43 2021 +0200
Include the pdfimport library constructor in the mobile apps if enabled
had unconditionally included the constructors, so e.g. a
'--disable-pdfimport' Android build would fail due to
missing symbols.
Change-Id: Icbf92dd226ef9a3104c37610ee56416c8205b7a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114533
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
|
|
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data is
an OLE2 container, containing a Package stream, containing a DOCX file
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Open this document via Java, using URP. Load the document with
Hidden=true and OnMainThread=true.
4) Save the document using XStorable.store().
Expected result: the native data is there.
Actual result: the native data is sometimes missing (0 bytes).
The root cause is that GetUserClassID() Win32 API call in
OleComponent::StoreOwnTmpIfNecessary() fails in some cases, and
re-trying a few times after a small sleep doesn't help.
Handle this error better by doing what
OleEmbeddedObject::SwitchOwnPersistence(XStorage, OUString) already
does: discard the old native data only if we have non-empty new native
data.
A result of the above was that an export to reqif-xhtml (sw HTML export
with FilterOptions set to xhtmlns=reqif-xhtml) wrote empty \objdata.
Change-Id: I59611601cf09597e9f7727db5bd6d7426fe17b75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114537
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I8c8200756a7120db9a9c946889a30f6c549fd617
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114536
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Filtered rows do not belong to a selection and are not pasted.
Change-Id: I03e1c03c42b508e24194b769a466611503ce44d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113991
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...that were introduced with bca539e889d40e06cb3275442622cb075b2484a2 "make
OString(OStringLiteral) constructor constexpr", apparently to mimic the
corresponding #pragma pack for rtl_String in include/rtl/string.h. But neither
of them appear to have any value: All struct member types involved
(oslInterlockedCount aka sal_Int32, sal_Int32 itself, and char) have size < 8,
so the member alignment ("on a boundary that's either a multiple of [the pragma
pack value], or a multiple of the size of the member, whichever is smaller",
according to
<https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=msvc-160>) is not
affected. And neither are alignof(rtl_String) and alignof(OStringLiteral<N>)
affected, which remain e.g. 4 on x86-64. (And prior to
bca539e889d40e06cb3275442622cb075b2484a2, OStringLiteral did not have any pragma
pack cargo cult, but which did not cause OStringLiteral::assertLayout to fail,
or raise any other documented issues.)
So remove the pragma pack cargo cult again at least from OStringLiteral. (And
leave potential removal from rtl_String for another commit.)
(This is similar to the corresponding f62cb40bdfaf41cf8e989640f9be79f652f30914
"Remove dubious #pragma pack" for OUStringLiteral.)
Change-Id: I7808837a667bca717aa2e3abfdf9cb16268789ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114535
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I did not write any tests, as the multi range copying to system clipboard
has another issue, see tdf#141847
Change-Id: I3af58d68370038274a07d753809fb4ceca9016f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114534
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
revert...
commit f97dbac73fe149e8fed0932890d0c1d6be4869a3
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed Jun 26 21:00:02 2019 +0100
infinite focus changing in toc biblio page
which blocked calling focus-changed callbacks when grab_focus is called
explicitly analogous to how we block value-changed callbacks setting
values through code but don't block them when the value is changed by
user interaction.
In retrospect that was a poor choice, so revert that and subsequent
workarounds in favour of just not calling gtk_grab_focus if the widget
already has focus.
checked:
a) tdf#138427 focus set to wrong input box
b) tdf#138078 only call GetFocus if we gained focus from an unfocused state
c) tdf#137993 ensure the toplevel vcl::Window is activated
d) tdf#136941 call focus in handler explicitly
Change-Id: I411480e2d627aa9995fb41b0aa17e9fb6d34d73f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114524
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
doh! forgot the most important part in
commit bca539e889d40e06cb3275442622cb075b2484a2
make OString(OStringLiteral) constructor constexpr
Change-Id: I0c13b3b8f33f643fa72c11d8596bab70e863a879
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral)
constructor constexpr"
Change-Id: I5be28505f0222bbd4d10c7aa5233bd7346136de7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114528
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie5968b80583f8c560b145463a60e2e86992fdb96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114513
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
so its in the expected state when the child contents are created
Change-Id: Id5baaca8479334c8fa2ec60ce8b598b7a61a3d7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114481
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
'make check' now passes for me without pdfium, all relevant tests are
annotated to skip asserts when there is no pdfium anyway.
Change-Id: Ie22a2b3b42d16e72f9d34ada85dee264d79d5155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114523
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I626ae2fc3e8be7cb7770adfff2f99f0a7e130e93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114516
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...that were introduced with 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make
OUString(OUStringLiteral) constructor constexpr", apparently to mimic the
corresponding #pragma pack for rtl_uString in include/rtl/ustring.h. But
neither of them appear to have any value: All struct member types involved
(oslInterlockedCount aka sal_Int32, sal_Int32 itself, and sal_Unicode) have size
<= 4, so the member alignment ("on a boundary that's either a multiple of [the
pragma pack value], or a multiple of the size of the member, whichever is
smaller", according to
<https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=msvc-160>) is not
affected. And neither are alignof(rtl_uString) and alignof(OUStringLiteral<N>)
affected, which remain e.g. 4 on x86-64. (And prior to
21584b304b21bfe6b99b6f29018c6b754ea28fc0, OUStringLiteral did not have any
pragma pack cargo cult, but which did not cause OUStringLiteral::assertLayout to
fail, or raise any other documented issues.)
So remove the pragma pack cargo cult again at least from OUStringLiteral. (And
leave potential removal from rtl_uString for another commit.)
Change-Id: I1a3626f0db1a0413ff792bd00ebaf76e4249b13f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114484
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: If5b2f2433b4be7b654b08815cbfb08faaac309db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112130
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
WW8ListManager::nMaxLevel is a valid value meaning "Body Text".
If a valid setting is provided during initialization,
you can't tell if the property set contained the setting
(or at least not so easily).
The other related items (LFOPosition and mnWW8OutlineLevel)
both use out-of-range initializers, so it just makes
sense to do the same here.
This will be especially important to see whether
inheritance should come into play.
This should effectively be a Non-Functional-Change.
Change-Id: I05a2013e72c84653a16d61652fd8f23d3f441521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114399
Tested-by: Jenkins
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Regression from commit cb09533c4a007e7cfde69046bcaeb47117d30a86
("tdf#141269 Incorrect transparency after roundtrip").
Change-Id: Ic20db743e6f364fe14305ccb9f4b74d95a7040aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114527
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Username is not mandatory for http://, and files require only path.
Change-Id: Iab4e81692b288d17dd8a35954e34a1bbe7c943ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114526
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Both the webdav=neon and webdav=serf cases were actually using
the same ucpdav1.component file. And f3f0d05f72d8dbd9717910b4d6b4
changed component handling for neon, but not for serf.
So separate component handling for neon and for serf, and also
do the f3f0d05 change also for the serf case.
Change-Id: Id5907cf1c8fbb93817e81295f71ad87191fe5c16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114525
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Windows crashes when an IFileDialog object is used on a non-main
thread when cancelling a long search operation, when COM is
initialized as single-threaded apartment for that thread.
Trying to use a non-main thread with COM initialized to
multi-threaded apartment hangs the dialog UI. The only solution
that works is to run all File Dialogs on the main thread. This
has a performance penalty on the application while a File Dialog
is open or if multiple dialogs are searching and then cancelled,
but it's better than crashing. Other applications like Firefox
use only the main thread for File Dialogs, but have additional
processes to avoid the performance penalty.
Change-Id: Icf8a8179dbea19bd3d749a1c2fe8e67dbfc726c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114482
Reviewed-by: Matt K <mattkse@gmail.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
3a4bfe3e45be2d5b591ab5cae3694c9492ca9e1b made cairocanvas #include
also a pixman header, but the internal cairo case wasn't setting
up the pixman include path.
Change-Id: Ib0daab3a5ec1a6ebf1b29eb37b039d2f41f770c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114491
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I36d82423b5f75010552696a66cec7e53ee265ce4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114395
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we are re-creating it every time, so caching makes no sense
Change-Id: I8a175c7ebd83c369c644d5936004167906539ad7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114517
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic3351a833bf2244c95f7280176b7d56f85011901
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114514
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
When they fail, the output is human readable
Since a080727522e04b8e1fc1641c892af9227d2e8dad
< sd: improve output when asserting colors >
Change-Id: I5dc943fc6076879b5bf56575c0e0c3ceb10b85d7
Change-Id: Ia25ef5e066673a55a1c5b3ec38772d2a1ea8e420
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114489
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I01dc96ccb6dd65d19a96dad0451291aa1106cec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114515
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id06dc8750b735ecdba26ac607394c6e7dee16db2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114470
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Dante DM <dante19031999@gmail.com>
Tested-by: Jenkins
|
|
(regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb
"tdf#134298 sw: layout: remove left-over page frame without content")
When updating the 3rd ToX, the change to remove empty page frames
causes one page frame to be deleted.
On the subsequent layout, things generally move backward, but there are
some fly-related hiccups; the first problem is visible on page 7.
Commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf
"sw: layout: if fly's anchor moves forward, move fly off SwPageFrame"
helps quite a bit, but not completely; now the first problem happens on
page 54, when SwTextFrame 1261 and its fly 3132 are formatted.
Frame 1261 moves forward to page 55, and then
SwObjectFormatterTextFrame::CheckMovedFwdCondition() returns true and so
SwMovedFwdFramesByObjPos::Insert() is called to prevent frame 1261 from
moving back to page 54.
But the reason why it moved forward is that there are 3 flys on page 54
that are anchored on frames in the next-chain of 1261, namely 1275,
1283 and 1284; if these flys weren't on the page then 1261 would fit.
While the move forward cannot be easily prevented in the situation, it's
possible to avoid the entry into the SwMovedFwdFramesByObjPos map,
by detecting that there are flys on the page that would should forward
*before* the current one does.
With this fix and the above mentioned commit to get the flys off the
page, frame 1261 will eventually move back to page 54 again.
Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114478
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
i.e. a copy of
commit 21584b304b21bfe6b99b6f29018c6b754ea28fc0
make OUString(OUStringLiteral) constructor constexpr
Change-Id: If5b0c2b896f8a730d01a076d3eb9161ad628979b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114480
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Bug 101217 - Setting the column width and height should not round
the values causing compounding errors
This patch fixes the problem caused by rounding errors by
increasing the number of decimal places for row height,
optimal row height, column width, and optimal column width to 4.
Change-Id: Iefb5ef09af3bd81d429cf17386c8b1a54e111957
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113824
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|