This reverts commit 5ff701226b.
Reason for revert: Tester reports no change in behavior after the commit.
Change-Id: Ic6d9f4834c7c6e3fae34d132298b335f433df280
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160470
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
Shapes and text boxes didn't show the optional hyphen
at line break.
Change-Id: I5cc842964fc91571e5c55995981de697da966b14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160453
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
* Update translations from branch 'master'
to a0c2cb43becec95fddd09ed6300525a735b4ba95
- update translations for master/24.2.0 Beta1
and force-fix errors using pocheck
Change-Id: Ib7130fc4085faf604d249a62ae42e92019f69cf0
Now that the minimum SDK version/API level has been bumped
to 21 in
Change-Id: I875e784dd4e62993f51059ae6a280d425cb49c0a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Dec 5 09:57:22 2023 +0100
android: Bump minSdkVersion to 21 (Android 5.0)
, this patch is no longer needed.
Change-Id: I391657caac76ed5b66f564a5888a35b5afb16ed0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160335
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
NDK 26 dropped support for API levels < 21 [1] [2].
Do the same for our Android build, to ease the
maintenance.
Adapt configure.ac accordingly and drop the
now obsolete code paths in Android Viewer
Java code.
This in also means that the same minSdkVersion will
be used for all architectures now, while API level 21
was already used for the 64-bit variants (for which
the minimum supported version was 21 anyway) and
API level 19 was used for x86 and 32-bit ARM when
building with NDK 24/25, API level 16 when building
with NDK 23.
According to [1] and [3], more than 99% of
Android devices have at least Android version 5,
i.e. support API level 21.
[1] https://github.com/android/ndk/issues/1751
[2] https://developer.android.com/ndk/downloads/revision_history
[3] https://apilevels.com/
Change-Id: I875e784dd4e62993f51059ae6a280d425cb49c0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160334
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In Writer, the "Lines" property in File - Properties - Statistics does not have enough width to handle numbers with 4 digits or more.
This patch fixes the issue by adjusting the label width when it is updated.
Change-Id: I1a56da106f7c80ffbbaa8bdfb93932a3974b1ee0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160367
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The code had apparently rotten a bit,
* a wchar_t vs. char16_t confusion in desktop/source/app/updater.cxx
* code broken by 926e4e469d "Rename online updater
functions and strcmp relpath" in
onlineupdate/source/update/updater/updater.cxx
* -DUNICODE missing in some places (so that plain Windows functions resolve to
the ...W variant), which had been set centrally in the past IIRC
* silencing some warnings like "C4267: 'initializing': conversion from 'size_t'
to 'int', possible loss of data" (where silencing is the right thing to do for
effectively extern code); no sure why those apparently didn't hit in the past,
maybe it is all warnings that compilers only started to emit in recent years,
or only for recent -std:c++... modes
* silencing some "Conversion from string literal loses const qualifier" errors
with -Zc:strictStrings-; these hit at least with recent VS 2022 Preview and
--with-latest-c++, where -Zc:strictStrings is apparently now on by default
Change-Id: I7fe46f5aa2b42fc9c03f24f7f0236512b4d3b936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
regression from
commit 6ed8c5a0f1
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Sun Jul 25 21:35:05 2021 +0200
use officecfg for security options
where I forgot to go back and complete a piece that was initially
a little tricky.
Change-Id: I2df8529ec7047bdcd9d7f655303fd72eeaa50cc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160429
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Missed a special case in previous commit, in case the input is
completely empty and PK11_DigestFinal() doesn't see a problem with it,
aResult could be empty too.
Change-Id: I8ea900774ae390857307ec5bab38876bead6bc86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160441
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...when building against LLVM 18 trunk libc++,
> In file included from Numbertext.cxx:6:
> ~/llvm/inst/bin/../include/c++/v1/locale:3772:1: error: 'wstring_convert<std::codecvt_utf8<wchar_t>>' is deprecated [-Werror,-Wdeprecated-declarations]
> 3772 | wstring_convert<_Codecvt, _Elem, _WideAlloc, _ByteAlloc>::
> | ^
> ~/llvm/inst/bin/../include/c++/v1/locale:3649:17: note: in instantiation of member function 'std::wstring_convert<std::codecvt_utf8<wchar_t>>::to_bytes' requested here
> 3649 | {return to_bytes(__wstr.data(), __wstr.data() + __wstr.size());}
> | ^
> Numbertext.cxx:164:22: note: in instantiation of member function 'std::wstring_convert<std::codecvt_utf8<wchar_t>>::to_bytes' requested here
> 164 | return converter.to_bytes( s );
> | ^
> ~/llvm/inst/bin/../include/c++/v1/locale:3591:28: note: 'wstring_convert<std::codecvt_utf8<wchar_t>>' has been explicitly marked deprecated here
> 3591 | class _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 wstring_convert
> | ^
> ~/llvm/inst/bin/../include/c++/v1/__config:942:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
> 942 | # define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
> | ^
> ~/llvm/inst/bin/../include/c++/v1/__config:915:49: note: expanded from macro '_LIBCPP_DEPRECATED'
> 915 | # define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
> | ^
(The warning is apparently only emitted late during compilation when
instantiating template code, so extending the existing `#pragma GCC diagnostic
push/pop` area did not work, and the `#pragma GCC diagnostic ignored` rather had
to be enabled all through to the end of the TU.)
Change-Id: Iffc1c468426407e3252724d18f358b9923f7f733
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160437
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
When scrolling on some Intel Macs either via dragging
the scrollbar thumb or via swiping the trackpad with two
fingers, final repaint of scrollbars doesn't appear to
get flushed to the screen. It appears that scrollbars
aren't updated and repainted until after a batch of
native scroll events have been dispatched. On slower
machines, this lag is long enough that any pending
forced flushes have already been done so when the timer
that repaints scrollbars finally fires, the repainted
scrollbars won't get flushed to the native window until
the next normal flush which may not occur until seconds
later.
Change-Id: Iadef6812cd2495a28347560caae81f604c908b51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160440
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
If this function returns null, storing a document will proceed without
reporting an error to the user, and lose all the data.
Change-Id: I0f9fd53702321e7997b28e12eb5bed3349bbcc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160435
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* Update translations from branch 'master'
to 193b35fe99d7112b6a2b9c8077bbca6471326db3
- update translations for master/24.2.0 beta1
and force-fix errors using pocheck
Change-Id: Ie89030ffdc21fe71f753b07ea11bbf838e91417c
before adding it to the list of trusted certificates.
This prevents certificates from being thoughtlessly
added to the list of trusted certificates.
Change-Id: Ifd0273df39f13432ebad72f1289ede0e6e7a8d5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160427
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
and
cid#1546284 Using invalid iterator
cid#1546275 Using invalid iterator
cid#1546049 Using invalid iterator
cid#1545929 Using invalid iterator
cid#1545870 Using invalid iterator
cid#1545668 Using invalid iterator
cid#1545420 Using invalid iterator
Change-Id: I3ad3000631b4be5917b9c5f49f21b8cc003a309c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159056
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
But make it default-off for the while.
Change-Id: I54e2fb8544ceb5ffe88053504294e2f3d5df50d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160436
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
ScXMLExport::ExportFormatRanges cannot advance because nMaxCols is 0
so busy loop and no progression
In ScRowFormatRanges::GetMaxRows, aRowFormatRanges is empty which is why
nMaxCols is 0
In ScFormatRangeStyles::GetFormatRanges aTables appears to be 30 empty
items.
But why it is empty can't be seen from the bt.
Force this to be an assert to ensure crashtesting can flush out this
case, rather than letting it get killed off as a timeout.
Set this case as an error and break so failure results in an error
message of failure to save instead of a hang.
Change-Id: I827e1e638cddd976a48340f86741c21075afe856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160363
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Style "Object with no fill no line" was not correctly treated during
automatic translation to UI language
Change-Id: I9364b25e326387110af81494d7fa5e4c05b5f972
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160262
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
from Impress/Draw
last mention of them was removed in 2006 by:
commit deef3fdfd9
removing a commented out caller
that was already commented out by "initial import" time
Change-Id: I50fefe42a92c752727dfbf3b9d7c645492d034da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160190
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...sharing the existing option tab page for the traditional
--enable-online-update feature
Change-Id: Ic7b04bf15bf841a46a96d62cf5a857deaa399428
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160430
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...by turning the latter into its own option --enable-online-update-mar. (The
intention is to potentially have the experimental --enable-online-update-mar
configured in alongside any traditional --enable-online-update, and have it
disabled by default at runtime---for which some configuration is needed and
which is forthcoming.)
Change-Id: Id53b4f52b310da472b305c8b23c1e2ba1931296d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
adds new expert option DisableActiveContent
Right now only disables active embedded content / OLE.
If OLE content is being imported via
UNOEmbeddedObjectCreator::createInstanceInitFromEntry with the
expert option DisableActiveContent set, the imported OLE object is
now forced to be ODummyEmbeddedObject.
ODummyEmbeddedObject doesn't implement any other state then
embed::EmbedStates::LOADED (i.e. doesn't implement RUNNING,
ACTIVE etc.) which makes it possible to prevent the imported OLE
object becoming active.
The functions that now throw lang::NoSuchElementException are
usually called on new creation of embedded content via UI. But
since the call sites expect the possibility of embedded content
failing to initialize, that is handled by showing a popup stating
some form of `unable to insert`.
A follow-up improvement of disabling insertion of OLE content via
dialogs could be implemented.
Change-Id: Ib558a2a129b491798f5036a7bb269116545be75d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160402
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
