Now the function both complies with ODFF1.2 and behaves the same
as Excel does.
Change-Id: Ic49af48cacedbac54688266a916c5fa6e28bb5c4
Reviewed-on: https://gerrit.libreoffice.org/34037
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
As code is shared for various t-distribution functions, the applied
constraints did not all apply for T.DIST.RT.
Change-Id: Ia68330e6fad7990e964fa5fd86fc062c156d1a4e
Reviewed-on: https://gerrit.libreoffice.org/34149
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Project: help 0dbfd3f53a4cb4074ea5745fa5c7331d87c2742e
update help ids for writer sort/edit comments menu .ui conversion
Change-Id: I960d72cd9e7903c9682e84770d8587fd69b4883b
Project: help 358d6c4eb7e82309fb1bc1f362d5f43297cbc2ba
update help ids for calc sort/edit comments menu .ui conversion
Change-Id: Ib95596c2063b3edb7ace4d4f9cc1c25c829a00c1
Probability p must be 0 < p < 1 for inverse cumulative left-tailed
t-distribution function.
Change-Id: I4f79eac8c9362e31de46b3ff4ebe7283ec475fac
Reviewed-on: https://gerrit.libreoffice.org/34375
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
It's the opposite of OOXML's <w:doNotUseHTMLParagraphAutoSpacing/>, so
the default is different.
Also adapt the fdo82006 bugdoc where the original bugdoc contained this
flag, but the testcase did not.
Change-Id: I2fd757a8f95be9b1bee63570c9f587c17d3b22bc
Reviewed-on: https://gerrit.libreoffice.org/34507
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This is to follow up on the commit 9bbc168c29 by:
- Changing "Comma" to "DecimalMark"
- Changing "VorComma" (literally "before comma") to "BeforeDecimalMark"
Change-Id: I3eff7024df56c701ac721a1e74645c8be764bff4
Reviewed-on: https://gerrit.libreoffice.org/34429
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...as clang-cl doesn't support the /clr switch.
* In configure.ac, capture the MSCV version (that would be used if CC hadn't
been overridden to use clang-cl) into MSVC_CXX.
* The logic which flags to pass into gb_CObject__command_pattern is coded into
the platform-agnostic LinkTarget.mk, so it's too late to try and filter all
relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is
a normal one built with the normal $CXX or a special /clr one built with
$MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures
this information early.
* When building with clang-cl, the generated config_host/config_*.h files
contain values suitable for clang-cl, but not for MSVC. But the .cxx files
compiled with MSVC happen to include config_global.h, and would fail. Hack
around that problem for now by introducing a hard-coded, minimal
solenv/clang-cl/config_global.h that is found first when buliding such a
CxxClrObject. Needs cleaning-up properly.
Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33
Reviewed-on: https://gerrit.libreoffice.org/34509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
wrt initial default color if none gets set.
This doesn't fix the various bizarre things in font and replace by formats, just
restore to its historical initial behaviour
Change-Id: I82cc3f05d2f205947a140483537baae882e91530
...introduced with b862cbdd34 "Support MSVC 15.0",
but $(filter ...,) always expands to the empty string, and this is probably what
was intended.
Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862
Reviewed-on: https://gerrit.libreoffice.org/34482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
INetMIMEEncodedWordOutputSink had been intended to encode (non-ASCII) content of
a "free-form text" header field as per RFC 2047. It used a heuristic trying to
detect already encoded words (=?...?...?...?=) in the input, to pass them
through unmodified. (Arguably, it could just as well have encoded them,
assuming they were meant to be genuine input.) However, that heuristic had a
bug ever since 8ab086b6cc "initial import", going
from STATE_FIRST_EQUALS to STATE_FIRST_EQUALS instead of STATE_FIRST_QUESTION,
rendering the heuristical detection logic effectively unused.
Instead of fixing the bug, 6e12729f71 "remove
unused enumerator from EncodedWordState" and
b8d8fb3f0c "convert EncodedWordState to scoped
enum" crippled the code further by removing any reputedly unused cases.
But the only remaining use of INetMIMEEncodedWordOutputSink is in
INetMIMEMessage::SetHeaderField_Impl, encoding MIME-Version, Content-Transfer-
Encoding, Content-Type, and Content-Disposition header fields. And none of
those headers have any "free-form text" content that should be encoded as per
RFC 2047. The first two have fixed ASCII-only content ("1.0" and "7bit",
"8bit", etc., respectively), while the latter two have structured content that
may contain parameters of arbitrary content, which must be encoded according to
RFC 2231 (but currently isn't).
And the only place where such arbitrary-content parameters are generated is in
the two calls to SetContentTransferEncoding in
forms/source/component/DatabaseForm.cxx. (The calls to SetContentType there and
in tools/source/inet/ itself are all known to have unproblematic ASCII-only
content.) So mark those two places with TODOs about the missing encoding (which
had been missing since forever) and, in INetMIMEMessage::SetHeaderField_Impl,
liberally convert the content to 8-bit via OUString::toUtf8 for now.
Change-Id: I4b2a219b396953b219ca66441a5227157a35951f
This reverts commit b7640cbb4b.
Not much idea yet but moving it to sw/ for some reason makes callback
pertaining to last 'InsertAnnotation' uno command not firing and on
ubsan tinderbox even the first 'InsertAnnotation' command is a noOp
failing the tests there. Lets keep it in desktop/ for now where it was
earlier.
Conflicts:
desktop/qa/desktop_lib/test_desktop_lib.cxx
Change-Id: I67f5bdeffa218ae2a7afe0896f7cdde5324a5f09
This fixes a hang caused by repeated Shift+F4. Although it seems
a regression from 2af1f5691e,
the original code of SmEditWindow::SelPrevMark() had been doomed
due to conditional loop depending on obscure signed/unsigned
conversion.
Change-Id: I61f630eec44b285dc1f1c27097acde4b48ed2991
Reviewed-on: https://gerrit.libreoffice.org/34503
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
