* Add new uno command alias '.uno:RedactionPreviewExport' with the
desired label.
* Add a link to the icon of the '.uno:ExportDirectToPDF' command so that
the new alias is displayed correctly on the Redaction Toolbar
* Replace '.uno:ExportDirectToPDF' with '.uno:RedactionPreviewExport' on
the Redaction toolbar and the Redaction menu
Change-Id: I72d17cac7d570341d89d1e59776e1af25f8d8b87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120835
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
which went a little wrong in
commit dd91d3389c26645459d3b80649941d65efa4f63f
Date: Sat Jan 2 14:36:44 2021 +0100
Fix some warnings for Raspberry pi 4 (part3)
Change-Id: Ief7e1146b7480a1c16ec0810f991296710214332
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120830
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
possible regression from...
commit 6e3424ca1131fe371f63e456267de476b5eb0eae
Date: Sat Jan 2 11:03:12 2021 +0100
Fix some warnings for Raspberry pi 4 (part2)
which changed that
Change-Id: I9a19d7d6bc1e4115ffffbe32d8d62be5d275d500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120747
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This looks completely wrong and unnecessary to me.
HOWEVER, at the time it really fixed a LOT of documents
and bug reports, so definite congratulations to the
original programmers for a successful hack in
a minefield code-area.
But it definitely seems hacky and full of wizardry.
AFTER setting the PROP_OUTLINE_LEVEL to be the real thing,
then we change the placeholder values to something different?
Plus, OutlineLevel has NOTHING to do with a list level,
so it should be irrelevant here.
[There is a fail-safe that ensures that outline level
matches list level for Chapter Numbering, but that is
not a DOCX thing, but a LO thing.]
Other major changes earlier in 7.3 fixed a lot of
inheritance issues, and highly refactored
Chapter Numbering recognition, so it is highly
likely that this code is completely pointless.
-confirm tdf#95495 examples same in Word 2010, 2016, LO
• Windows PowerShell Language Specification Version 3.0 (confirmed)
• 95495 Windows PowerShell - APPENDICES (confirmed)
• 385.docx (comment 12) (confirmed)
• numbering.docx (confirmed)
• test1.docx (confirmed)
Change-Id: I0f1ac7c9367b094a6431fe61442d3b58ffee79d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120755
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
So the for {tag} entries "too geeky" argument of spell-checker
dictionary developers and language enthusiasts will be moot in
future and we can stop adding 100 more tags if it's not for locale
data.
Change-Id: Ic44fe5b2f794ddb258e56ec073f310ccaf6e470d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120799
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
To be used in generating display names for on-the-fly language
tags in the language listbox.
Change-Id: Ibb36fe312e550f77f1e2d3acc2dbff9e83c15f7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120797
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
since
commit cd09fc9451897e6efedbf9f5e1d5b9bd96e65cb5
Date: Mon Mar 22 19:06:15 2021 +0100
do not enable mbSupportsBitmap32 for headless (tdf#141171)
turned back off the mbSupportsBitmap32 support experiemented with in
commit 86ea64f216819696cd86d1926aff0a138ace2baf
Date: Fri Feb 15 13:14:32 2019 +0100
Support for native 32bit Bitmap in VCL and SVP (cairo) backend
Change-Id: I818c3f11d0334278a65a0e45b61141327669121d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120709
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
As subsequent_export-test.cxx code style is following the recommended
code style (except too long lines and minor formattings), the code
is used only for testing and it is rarely modified (mainly adding
new test cases), I decided to enable automatic code formatting.
It is one step closer to migrate to common code style.
Change-Id: Iaa6c243fab45c37cb01672633717577651916c3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120706
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
This reverts the code of commit 9343551f5588ffa4916e2c5d33cbd6fcf56ca99d
but keeps the test-case
No reason to have this after: 0bb3ccf9148106ce3e5d9e03c23ab5a9602e843c
'Revert "Simplify Rect2Poly"'
Change-Id: I37f363e51dc5daed3faf85f27203b2cfe09b82c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120746
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
JsonWriter provides better performance than boost::property_tree and
it is also cleaner, so we need to start using the latter in place of
the former as much as possible.
Change-Id: I8c1e910c0b3d511b89679e622e2cc5d4848a8b47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120656
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
This reverts changes that were made to prevent process exit when an
OLE client is connected. These commits had the side effect of preventing
the use case of creating a document via OLE, and then allowing
the user to view/edit and ultimately quit from the GUI.
Revert "More hacks for quit requests from an OLE Automation client"
This reverts commit 05e03911cd1f8a355b6410d3997cffc2c794a1e9.
Revert "Veto process exit while an OLE client is connected"
This reverts commit 89f883bd90a50587868a57397b6350ed9559a20f.
Change-Id: I29a1e42a830815bc8d1ff0056c22d86b8f98cc1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118596
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
In Writer,
there are 3 issues about comment section:
- comment section scrolls to top of its view
when clicking inside a comment view.
- clicking inside a comment view, scrolls the
view to old cursor location automatically
(if old cursor out of the visible area)
- comment section scrolls automatically to the
old *selected* text (if it's out of visible area)
when clicking inside the Writer canvas view
this commit is intended to solve these issues
Change-Id: If7d62373f5215adea85512b66b78736e04e02c3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118638
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
nCheckPos is always set to something, but for nCheckPos != 0 nType might
be left uninitialized, so test nCheckPos == 0 before nType
seen in ooo76602-1.slk and ooo10703-1.html with distro-configs/LibreOfficeOssFuzz.conf
==623515==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x59600b4 in SvNumberFormatter::PutandConvertEntry(rtl::OUString&, int&, SvNumFormatType&, unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag>, o3tl::strong_int<unsigned short, LanguageTypeTag>, bool, bool) svl/source/numbers/zforlist.cxx:658:72
#1 0x8c7f72 in ScImportExport::Sylk2Doc(SvStream&) sc/source/ui/docshell/impex.cxx:2130:48
#2 0x8bcb26 in ScImportExport::ImportStream(SvStream&, rtl::OUString const&, SotClipboardFormatId) sc/source/ui/docshell/impex.cxx:392:13
#3 0x650f4b in TestImportSLK sc/source/ui/docshell/docsh.cxx:3360:19
#4 0x6055a7 in LLVMFuzzerTestOneInput vcl/workben/slkfuzzer.cxx:87:11
#5 0x555b53 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/out/slkfuzzer+0x555b53)
#6 0x541622 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
#7 0x54722e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/out/slkfuzzer+0x54722e)
#8 0x56fa82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#9 0x7fbd8b65ebf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
#10 0x51cc49 in _start (/out/slkfuzzer+0x51cc49)
Uninitialized value was created by an allocation of 'nType' in the stack frame of function '_ZN14ScImportExport8Sylk2DocER8SvStream'
#0 0x8c27c0 in ScImportExport::Sylk2Doc(SvStream&) sc/source/ui/docshell/impex.cxx:1837
Change-Id: I0422ca34827319d1e35d453606a7afe6a9de3840
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120762
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
... and get rid of the whole GetBackendCapabilities, which was
just overkill. Maybe this should even be some bitmap + enum
+ set/get function, but I'm too lazy...
In the end add a bool for the OpenGL support of the VCL plugin
(or maybe sticking it into ImplSVData, which is already some
catchall for common VCL data).
Change-Id: I9f0ececac482d8e2a94ef6024628e9631b49e773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120760
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...after 074790ad6f4e02e7aed3f9c954f0b4005b40fa21 "remove some locking from
UriReference" (and its follow-up 0f44815ce7b2925189cd603853ce55d8363549dd
"loplugin:constmethods"): The m_path member is modified by
UrlReference::setName in
stoc/source/uriproc/UriSchemeParser_vndDOTsunDOTstarDOTscript.cxx. Also make
the non-mutated members (for which locking is thus indeed not needed) private
for now. (The original intention was that there can be further parsers for
other URI schemes, which might need to modify further UriReference members. If
such further parsers are ever implemented, the relevant members can be made
public again, and the locking be restored where necessary.)
Change-Id: I80b437fe14f43294a52e465a7e1f31ddf2ab0482
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120749
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The relevant constructor is defined as deleted since incorporating
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2166r1.html> "A
Proposal to Prohibit std::basic_string and std::basic_string_view construction
from nullptr" into the upcoming C++23, and has caused undefined behavior in
prior versions (see the referenced document for details). That caused
> workdir/UnpackedTarball/clucene/src/core/CLucene/index/SegmentInfos.cpp:361:13: error: conversion function from 'long' to 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char>>') invokes a deleted function
> return NULL;
> ^~~~
> ~/llvm/inst/lib/clang/14.0.0/include/stddef.h:84:18: note: expanded from macro 'NULL'
> # define NULL __null
> ^~~~~~
> ~/llvm/inst/bin/../include/c++/v1/string:849:5: note: 'basic_string' has been explicitly marked deleted here
> basic_string(nullptr_t) = delete;
> ^
at least when building --with-latest-c++ against recent libc++ 14 trunk (on
macOS).
(There might be a chance that the CLucene code naively relied on
SegmentInfo::getDelFileName actually returning a std::string for which c_str()
would return null at least at some of the call sites, which I did not inspect in
detail. However, this would unlikely have worked in the past anyway, as it is
undefined behavior and at least contemporary libstdc++ throws a std::logic_error
when constructing a std::string from null, and at least a full `make check` with
this fix applied built fine for me.)
Change-Id: I2b8cf96b089848d666ec37aa7ee0deacc4798d35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120745
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit aaabfc644afd57577980998c83f94a271f633c02.
Reason for revert: Large csv files will not open in a reasonable amount of time.
Change-Id: I7d3d3bf0341bcb83f86be88e8911879de13918ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120720
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
