HierarchyDataSource::createInstanceWithArguments does
not need locking since it does not access local state.
Change-Id: Ia29f9a5ca20095d51e4eb168cdc0a080d178f9bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134087
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
file by asking password re-typing unstoppably. Instead
of this, skip recovery file saving, if the document
contains password hashes which haven't been supported
by the "calc8" filter of the recovery file (which
triggered the "Re-type password" dialog).
Solved problems:
– Asking for passwords during a non-interactive
background process.
– A single Cancel didn't close the "Re-type password" dialog
window, only pressing three times at least (according to the
value of RETRY_STORE_ON_MIGHT_FULL_DISC_USEFULL), but
waiting for the password for a while could result a
frozen "Re-type password" dialog, where only retyping or
removing the password(s) were the escape routes.
– Re-typing the password required the password (but modifying
the original document doesn't require this).
– Removing the password resulted in loss of the protection
after saving the original XLSX document.
Add a UI test to keep the "Re-type password" dialog during Save As.
Note: because of the regression reported in tdf#145757, it needs
to wait 10 min for saving the recovery file, yet, despite the
changed time in Tools->Options->Load/Save->General.
Change-Id: Icc6ee4d67048cdf15ab75ef8e2ee8f1709cdd4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134409
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
61f4250ee9 "Make CLEAN fully compliant woth ODFF
v1.3" has changed lcl_ScInterpreter_IsPrintable
(sc/source/core/tool/interpr1.cxx) to use ICU's u_isdefined to check for Unicode
code points of category Cn (i.e., noncharacter or reserved). This is at least
questionable, as assignment of code points to that category varies with Unicode
versions. And while
<https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part4-formula/OpenDocument-v1.3-os-part4-formula.html#__RefHeading__1017856_715980110>
"Open Document Format for Office Applications (OpenDocument) Version 1.3.
Part 4: Recalculated Formula (OpenFormula) Format: 1.4 Normative References"
references "The Unicode Standard, Version 5.2.0" (so one might expect CLEAN to
use the category classification from that old Unicode version), versions of ICU
keep being updated with current Unicode versions' category classifications. For
example, the currently bundled external/icu's icu4c-70_1-src.tgz uses Unicode 14
(according to <https://icu.unicode.org/download/70#h.x1orhyniml8k>) for its
implementation of u_isdefined. And for --with-system-icu, all that configure.ac
apparently requires is that "icu-i18n >= 4.6" (i.e., it will potentially allow
the behavior of u_isdefined to vary over a wide range of Unicode versions).
And case in point, 61f4250ee9 also added a test to
sc/qa/unit/data/functions/text/fods/clean.fods (row 47) that verifies that
U+FDCF ARABIC LIGATURE SALAAMUHU ALAYNAA does not get cleaned away by CLEAN.
But U+FDCF is only an assigned code point (thus no longer of category Cn) since
Unicode 14 (cf.
<https://www.unicode.org/charts/PDF/Unicode-14.0/U140-FB50.pdf>), so while
builds against external/icu (covering Unicode 14) succeed, --with-system-icu
builds like a flatpak build against org.freedesktop.Sdk//21.08, still at ICU 69
and Unicode 13, fail CppunitTest_sc_text_functions_test with
> Testing load file:///run/build/libreoffice//sc/qa/unit/data/functions/text/fods/clean.fods:
> /run/build/libreoffice/sc/qa/unit/functions_test.cxx:43:TextFunctionsTest::testTextFormulasFODS
> double equality assertion failed
> - Expected: 1
> - Actual : 0
> - Delta : 1e-14
(<https://flathub.org/builds/#/builders/11/builds/7103>).
Irrespective of whether using ICU's varying u_isdefined in the implementation of
CLEAN is correct, at least make that "doesn't get CLEAN'ed away" test more
resilient to what version of ICU is being used, by using F+UF00 TIBETIAN
SYLLABLE OM, which got added all the way back in Unicode 2, rather than U+FDCF
ARABIC LIGATURE SALAAMUHU ALAYNAA, which only got added in Unicode 14.
(And to add insult to injury, in sc/qa/unit/data/functions/text/fods/clean.fods
61f4250ee9 encoded U+FDCF in text not as the three
UTF-8 bytes 0xEF 0xB7 0x8F, but rather re-encoded as the six bytes 0xC3 0xAF
0xC2 0xB7 0xC2 0x8F, i.e., the three characters U+00EF LATIN SMALL LETTER I WITH
DIARESIS, U+00B7 MIDDLE DOT, U+008F. But I assume that was just a mistake, not
something that I should faithfully copy in the file's new version.)
Change-Id: Icc8d879b1397d8292914cbd31708d0c561f3b06e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134474
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... to not break on e.g. 4.0
Change-Id: I5b93f6138a5ca85891d2d60beca098b6bcfc15d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134435
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Char width is 0 when multiple characters made up of one glyph.
Don't insert extra space in that case.
Change-Id: Ieb37aa8a4fffc534d84acf994a231e801e89f782
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134244
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
As described in bugs tdf#65067, tdf#103816, tdf#149052 and a few other duplicates, Formula objects in Writer receive 2 unnecessary spacings:
1) From the "Formula" frame style, which has a Left/Right internal spacing of 0.2cm
2) From the Math formula editor itself, that adds an additional 1pt of internal spacing (left/right)
In MS Word the default behavior is setting all of these spaces to zero, which makes the formula flow better alongside text in paragraphs.
Therefore, this patch set both of these spaces to Zero so that Formula objects in Writer behave similarly as Formulas in MS Word.
Change-Id: Iedcef7124afed6b799f85bcefe37016c8fd972e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134185
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
.uno:InsertObject opens a dialog to insert an OLE object.
.uno:InsertObjCtrl appears to provide a control for a dropdown menu.
It appears in one toolbar, but it is unclear if it is actually used.
Meanwhile, it appears in the Customize menu, but when added to a
toolbar, it does not have any obvious functionality.
The purpose of this patch is to change the labelling on these two
commands, and add a tooltip to .uno:InsertObject so that it will be
easier in the Customize dialog to understand what .uno:InsertObject
does, and to get an impression of a possible function of
.uno:InsertObjCtrl.
Change-Id: I7cb01763c4a84511e7b7c45d8d00dc6873a3748f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134434
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Fixes build breakage on macOS at least. Noel said it was OK to revert.
This reverts commit cc4325f84a.
Change-Id: Ib78d29fc21d4d030b4032955b18271de1761f396
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134458
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
and not the text_change which is called before the value is parsed
from the new text
Change-Id: Ib6bd5647139f1b79f299beb42b704b465ddf535c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134412
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is meant to be a content control (providing rich text), which is
also a picture placeholder field.
Add a new Picture property to track this type, this way the click
handler will be able to present a file picker when showing the
placeholder.
Change-Id: Ibbd3720fc94d0f17654ec813821d218166c76424
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134457
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
`OString::getStr` already returns `const char *`,
so there's no need to cast to that.
Change-Id: Ief787f9823ffea075882658cf0adec29a8030199
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134455
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
How it interacts with SwCursorShell::MoveTable() is far from trivial.
Change-Id: I04c9123c0b39192df43fe32984d66852102ebd1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134410
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
so we check if we have a shape before we try to do any work
Change-Id: I9496e6fd38d7d7f312226791b942190c56e9d34e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134398
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The repeated inserts each trigger SvTreeList::GetVisibleCount(),
which has a poor performance because of repeated uses of the
SvListView::Impl::m_DataTable map.
Change-Id: Ibb261a8501a1d5c168b37675e34498386f161595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134415
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Faster and the ordering is not needed.
Change-Id: I9d9f8ef084f441d24d35dc92ecf060f576d7db2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134414
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This way, the document used for chart copy has the proper sheets, and
the data ranges are created correctly.
This reverts commit 8d98dd8b38
Author Mike Kaganski <mike.kaganski@collabora.com>
Date Thu Jun 03 13:15:11 2021 +0200
tdf#142635: skip UITest for now
Change-Id: I0a3aa6028f49ded278f8665556007b1f722e21b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134251
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Required for eventual sharing of the document between the shell
and other pieces having different lifetime, as required to fix
tdf#142635.
Change-Id: I9e69bd2e3b57d7712526f51161e7e725d4af8068
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134383
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Apparently even calling OutputDevice::GetFontMetric() rather than
GetFont() makes a difference with e.g. tdf#65046-1, when only
vcl::Font is used it triggers the assert in checkGlyphsEqual()
because of the fonts actually being different.
Change-Id: I2a2aba6bf6d4bf78b7449ccdb16be0746663ee87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134401
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Test:
- create a file in memory
- open a stream
- write a byte to the stream
- read the byte from the stream
Change-Id: I257880bdd9020d2410f183e612a356eb785621ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127674
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
Modify is really similar to insert, just we pre-fill the list item
properties dialog with old data.
Also allow moving items up / down, and eliminate a not needed frame in
the inner dialog, which would assert when using the gen backend.
With this, the content control dialog is quite complete for dropdowns.
Change-Id: I26e77dd881f0a0eea44d2a6137f76fd29ab32fc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134405
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Make the keyboard accelerators in the Statistics tab of the
File - Properties dialog select the text of the fields that they label.
Change-Id: I61a93e227ed1e457355dc971dc4864ab4419a770
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134358
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
it can never be a dir
Change-Id: Ib1c234cb20387cd075a19e13e6656738be88716b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134397
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
With this commit EmfPlusDrawClosedCurve and EmfPlusFillClosedCurve
support was added. There is still missing Filling Mode (it
is always set to Even Odd Alternate:
https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule )
and Tension support for spline bends.
The graphics is displayed as Tension=0.
A value of Tension=0 specifies that the spline is a sequence of straight lines.
As the value increases, the curve becomes more rounded.
For more information, see [SPLINE77] and [PETZOLD].
Change-Id: Ibccfd584e3d55cd0ca8a29da9f450916d56705d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134333
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
For some reason B2DPolygon used a CoordinateData2D class that
derived from basegfx::B2DPoint with no added functionallity that
is used in practice (just an explicit method transform instead of
using an operator*=). This class has been removed and replaced
with B2DPoint instead.
Also removed was the typdef CoordinateData2DVector and calls to
the std::vector's iterator (begin, end) have been simplified with
"auto".
Change-Id: I0d187ded05a8e22de36a8e17523e87871aab912c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134378
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
so it is shown in the Navigator
Change-Id: Ia4e9c847a1a8cfbaa3465f1472d4b899f4bde3fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134334
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
When the range to compact spans only 1 row (CompactUp)
or 1 column (CompactLeft), a GetValue() method returns
a scalar and not an array as expected in usual cases.
This caused an abort of the script when invoking the
UBound() value of the returned array with a Basic run-time error
Object variable not set
A test on being scalar or array of the result of
the GetValue() method avoids the error.
To be done in both CompactXXX() methods.
Impact only on Basic code. Python not involved.
No changes due in documentation.
Change-Id: I74cf2b274944b442f843e1f4b7ac3a05dd6eaae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134352
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
