This is the fifth and final patch in the series.
When you start a new document, Writer compat setting
"Consider wrapping style when positioning objects" is off.
Now, when saving and reloading it with LoadUserSettings disabled,
it is still the program default of "off", instead of "on".
Change-Id: I3e3b4cb6c48dad35b258a898990d7fadfd3048db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108549
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
It was probably not intentional to write the resolved state only in case
the annotation has a name.
Change-Id: Ia3a6b2320e2288528c43c832211ebfcde492881e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109354
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
If there was nothing else at the end of the paragraph,
Ctrl+Del was acting like Ctrl+Backspace - it turned
around and started deleting the earlier words.
Instead, we need to keep deleting to the right,
starting with the next paragraph.
That's what Ctrl-Backspace does in reverse anyway.
It looks like this was just a copy-paste mistake
already seen at original import and the few times
that people tried to fix up this area, they didn't
notice that apparently? But then again, the code
changes don't look that impressive either...
[if x == 1, set x=1?]
make UITest_writer_tests UITEST_TEST_NAME=\
tdf137459_editeng_ctrl-DEL.tdf137459.test_tdf137459
Change-Id: I0c2268f9f1a2102997b2e84b0b7a6d0e2da43b15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108265
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This should fix https://github.com/CollaboraOnline/online/issues/849
This is based on the corresponding fix for macOS. Much of our
clipboard code for iOS is based on that for macOS.
We need the pasteboard to have the OBJECTDESCRIPTOR type as a MIME
type that includes the typename attribute, because the code in sc
checks for that when it decides whether it is a proper
OBJECTDESCRIPTOR.
Simplify the data in the flavorMap array. No need to duplicate the
same MIME type string as both the pasteboard type and MIME type, for
those cases where the MIME type is used diretly as pasteboard type. We
also know that for those types, the MIME type might have additional
parameters, so be more lenient in checking.
With this change, and my recent change to sot, this now works:
Start the Collabora Office app. Open a spreadsheet. Select a cell
range. (It can include formulas.) Copy. Close the spreadsheet
document.
(Killing the app process is not necessary, as no in-process
clipboard is kept on iOS, but to make sure you are really accessing
the system pasteboard and not some in-process cache, feel free to kill
the process. After that, start Collabora Office again.)
Open a spreadsheet. Paste. You get the very same cells that you pasted
as such (with relative cell addresses in formulas properly adjusted,
as expected).
Previously, it would paste an image of the copied cell range, which is
fairly pointless.
There is still lots of opportunity for cleanup in the clipboard code
for macOS and iOS.
Change-Id: I4a385d52bbaafcd2ab8cb18e8f613c5efa592d11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109368
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
* Update helpcontent2 from branch 'master'
to 655482c647bd7a8a4c517d6ef3bd71c7d6f9db68
- tdf#126492 add mention of new information sent in Crash Report
https://gerrit.libreoffice.org/c/core/+/109358 adds "system RAM"
to the Crash report. This patch adds this information to the help page.
Change-Id: Id9eb944824f86a1e4916cb2691c84fe2fe6e295f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/109348
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to fc682e9a8b7d6d6438668fb61304460f35002b3d
- tdf#119657 add related topics links to help about rulers and margins
( shared/02/13020000.xhp ) (Setting Indents, Margins, and Columns)
+ add <variable> to <h1>
+ add appl-switch and <relatedtopics> section
+ add link in related topics to "Using Rulers"
For now, this is the only link, and only applies for Writer
and Draw, so <relatedtopics> and link are only shown for those
two applications
* update to <tip>,<note>,<keycode>
( swriter/guide/ruler.xhp ) (Using Rulers)
* change order of instructions about changing indents
+ add example to illustrate how to make an indent
+ add link to "Setting Indents, Margins, and Columns" in 'related topics'
Change-Id: Ie8735e3b81667601602f3bdc134433c7d3a874a6
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/109341
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Tested-by: Jenkins
A fieldmark was deleted. UpdateFramesForRemoveDeleteRedline() deleted
the MergedPara but its start node was before the start node of the
fieldmark, and then MakeFrames() didn't find a frame on the preceding
node and did nothing.
Similar problem likely possible with redline.
Change-Id: I532f9a67c0268f3287736a61da4cc9fefec7b8e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109307
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
SwUndoDelete calls DelContentIndex(), which calls
SwUndoFlyBase::DelFly().
This calls DelFrames() first and then SwUndoSaveSection::SaveSection(),
so by the time UpdateFramesForRemoveDeleteRedline() runs for the
fieldmark in fly it's expected that there are no more frames.
Also, don't try to recreate fly frames in this situation; it will crash
when resetting the RES_ANCHOR.
Change-Id: I11f6fb011d84e96f77b93ffbd1b5904594cbc591
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109306
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
In this bugdoc it happens that the field with instruction
"\aINDEX \\c \"2\"\\h \"A\" \\e \"\t\"\003\063 "
result end is on a node following the start of a section,
so sw::mark::FindFieldSep() asserts.
In this case it looks like the section was wrongly set by the import,
but experimenting with Word reveals that it will respect sectPr on a
paragraph inside a field, so i guess we need to cope with that.
Also adapt InsertCnt_() to skip the section end node.
Change-Id: I5517d463de43b04bf773528a28de12123e534069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109305
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The == case was omitted, iirc because of changing the first compare at
the last minute.
(regression from aacaa2aa91)
Change-Id: I03602917def8248150139d788c880d93cab18bf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109304
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Also for single-reference links, use the temporary indexes
calculated in commit f85d860ccb
(tdf#87973 XLSX export: fix lost file names in modified links),
Note: only a new test case has been added to the modified unit
test document.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I4337a4e68008956ea42b626d210f07b1cbfe59ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109088
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Follow-up of commit a4eec60c38
(tdf#123613 XLSX export: fix position of rotated shapes) and
commit 368c56144a (refactor
for xlsx shape export).
Change-Id: If5a79685efa1a80ea82eac19aed12bb426d10987
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108533
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
It can happen that the default SwNumRule of a SwList isn't used by
anything directly, but there are other SwNumRule associated with that
SwList and then the DOCX export needs to export it as an abstract
numbering definition.
(regression from 632ee9aae6)
Change-Id: I6b1851980464aaa95bf731a60b7d11ab91cec7b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109303
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
a:custGeom was exported without the a:arcTo element
and its attributes.
Note: see customshapegeometry.cxx for import of a:arcTo
attributes.
Change-Id: I611ea9fb6a81d45cfd52a16abbb37071ea0ce7d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108874
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
a) as per https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html
use-stock=gtk-ok is deprecated and plain "OK", "Cancel" are indicated
instead.
b) to avoid adding thousands of extra labels to translate we'll convert
use-stock buttons to use the translatable strings, but give them all the
same "stock" translation context. Our translation rules don't like
duplicates in the output .po's so strip "stock" contents from the
translation collection rules in uiex and add a single set per .po in
l10ntools/source/localize.cxx
c) a script to rewrite the .uis to the new rules
the previously use-stock labels won't appear translated until there has
been a round trip of extraction, translations and import of translations
Change-Id: Ibe4d0d27f2abbf5aa3df9c63af1561cd01d9fddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108812
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
GetRedlineAuthorInfo() should produce a JSON array and not an object
with empty strings as keys, which is incorrect JSON. The code in
Collabora Online expects an array, see Document::getViewColors() in
kit/Kit.cpp.
Producing the wrong kind of data leads to Poco throwing an exception:
Assertion violation: !_key.empty() [in file "src/ParseHandler.cpp", line 64]
Also SwXTextDocument::getPostIts() should produce a JSON array.
Change-Id: I1ab0653ca1eaa3c466d31b1f068ba5937a04e43e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109316
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It is wrong to iterate over UTF-16 code units one by one. We have
OUString::iterateCodePoints() to iterate over Unicode code points.
The two UTF-16 code units of a surrogate pair (for a non-BMP code
point) should not be encoded separately to UTF-8 bytes. It is the code
point that should be encoded (to four bytes).
Change-Id: Ica4341308deb6618c9c2da8dcee8a11ef4e8238d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This fixes a demonstrable problem, and affects only macOS.
This is also on the path towards fixing
https://github.com/CollaboraOnline/online/issues/849 , even if the
code touched here is for macOS only. The iOS pasteboard handling code
is based on the macOS one.
We need the pasteboard to have the OBJECTDESCRIPTOR type as a MIME
type that includes the typename attribute, because the code in sc
checks for that when it decides whether it is a proper
OBJECTDESCRIPTOR.
Simplify the data in the flavorMap array. No need to duplicate the
same MIME type string as both the pasteboard type and MIME type, for
those cases where the MIME type is used diretly as pasteboard type. We
also know that for those types, the MIME type might have additional
parameters, so be more lenient in checking.
With this change, and my recent change to sot, this now works:
Start LibreOffice. Open a spreadsheet. Select a cell range. (It can
include formulas.) Edit > Copy. Quit LibreOffice.
Start LibreOffice again. Open a spreadsheet. Edit > Paste. You get the
very same cells that you pasted as such (with relative cell addresses
in formulas properly adjusted, as expected).
Previously, it would paste an image of the copied cell range, which is
fairly pointless.
There is still lots of opportunity for cleanup in the clipboard code
for macOS and iOS. It is presumably rather pointless to put images on
the pasteboard in Windows bitmap format, for instance. Just PNG should
be enough. No idea why the code provides the TIFF pasteboard type for
images. Ditto for Windows metafiles (WMF and EMF). It is also unclear
how useful the EMBED_SOURCE or LINK_SOURCE types are on macOS, for
instance.
Change-Id: I573648480b03972b506203b4f470d513bcb81212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109297
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Revert the addition of the latter.
Change-Id: I93636a901cde401b0b7d923e052887f57dd58212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Which is, I think, the last direct pdfium usage outside vcl.
Change-Id: I2e435e5a3669c6163bf2c20bc6d1d8bd4c88cecd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109314
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Coverity complaints that
"nVal = nNum[0] in bigint.cxx:84 is an assignment of overlapping memory"
But this is essentially a tagged union, so it's actually fine.
Workaround the warning by using a temporary (which the compiler
will optimise away anyhow)
Change-Id: I0fda945f831b1cdd7b33f7cb671a744150990bf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109294
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This was always comparing pointers, ever since commit
cb07ed8c74. They could only
happen to be not different if they are both nullptr. But
the uses of the function seem to expect value comparison
(see SdrObjEditView::ImpChainingEventHdl,
SdrObjEditView::SdrEndTextEdit).
Change-Id: I2265dc8f0f7e4441940f8e19ec0b016b5f78e812
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109284
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Page navigation in the move navigation handler scrolls the view without
moving the cursor or unselecting selections. This patch makes page
navigation that results in document wrapping, scroll the view without
changing the cursor position or selections. This is useful, for example,
when find all search is made and page viewing is wanted that does not
destroy cursor selections.
Change-Id: Ie062eeba9a29c2b8a42605ed842d60244cc74147
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108380
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
In sw/uiconfig/swriter/ui/mmsendmails.ui
we got:
id="cancel"
gtk-cancel
<action-widget response="-6">cancel</action-widget>
+
in sw/source/ui/dbui/mmoutputtypepage.cxx
IMPL_LINK_NOARG(SwSendMailDialog, CancelHdl_Impl, weld::Button&, void)
we got:
if (m_bDestructionEnabled)
m_xDialog->response(RET_CANCEL);
we want to cancel the process to send (of course what's already be sent can't be undone)
Change-Id: If221ecc20366f0634079ab515613757cc019c8ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109300
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In sw/uiconfig/swriter/ui/tocdialog.ui
we got:
id="cancel"
<action-widget response="-6">cancel</action-widget>
In sw/source/ui/index/cnttab.cxx
we got:
SfxTabDialogController(pParent, "modules/swriter/ui/tocdialog.ui", "TocDialog", &rSet)
which contains std::unique_ptr<weld::Button> m_xCancelBtn;
and finally if you change some options in the TOC dialog and click on "Close"
then open again the dialog, all the changed options are reverted.
=> UI impact, the button is renamed "Cancel" instead of "Close"
Change-Id: Ia99e7c8a10da51f258faf0833ea1931ce62364bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109301
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is the fourth patch in the series.
When you start a new document, Writer compat setting
"Hide paragraphs of database fields with an empty value" is on.
Now, when saving and reloading it with LoadUserSettings disabled,
it is still the program default of "on", instead of "off".
This one was a bit different because it didn't initialize
in the standard way.
// for some properties we don't want to use the application
// default if they're missing. So we watch for them in the loop
// below, and set them if not found
So I'm changing it to match the standard way,
and adding the now familiar clause to cover the case
when the LoadUserSettings is disabled.
Change-Id: I979b01340000056567a4baa9ace27f9f9d15e9b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108548
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
* Update translations from branch 'master'
to 4668a661bfdc743bb88bfc5b7fbc83383974d733
- update translations for master
and force-fix errors using pocheck
Change-Id: I5a86a2cfa383bbd34bd95ea0008959518a230793
When moving list items by Move Down (see Bullets
and Numbering toolbar) to a non-content node (e.g.
tables, images or end of the document), tracked
deletions of the inserted paragraphs reappeared
as non-deleted text.
Note: disable unit test on Windows because of
a not reproducable problem of the Jenkins build
(moreover, reverting the patch, and modifying the
unit test according to the revert has still resulted
the same problem on the Windows test machine).
Change-Id: I3fb49061a81f832e1070da0f78cf7c5b3bd7d2c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108888
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
* Update helpcontent2 from branch 'master'
to 0a848766232d6516f2af5a7605373b2ab8ca193e
- tdf#130170 update change in dialog box label
tdf#139017 changed a label in the "New Style from Selection"
dialog box. This patch updates the label.
Change-Id: I830cec29fdf1a358ae0a217ee53688059a193f67
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/109286
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Tested-by: Jenkins
For instance, if SotExchange::GetFormat() is passed a flavor with MIME
type
"application/x-openoffice-objectdescriptor-xml;windows_formatname=\"Star
Object Descriptor (XML)\";typename=\"LibreOffice 7.2 Spreadsheet\"" we
do want to recognize it as SotClipboardFormatId::OBJECTDESCRIPTOR,
even if the MIME type in the entry for it in the array in
ImplFormatArray_Impl only has the windows_formatname parameter.
This is part of fixing
https://github.com/CollaboraOnline/online/issues/849, but it will help
for corresponding problems with LibreOffice on macOS, too.
Note that on Linux, SotExchange::GetFormat() gets called with a flavor
with a MIME type that does *not* have all the extra parameters
(classname, typename, displayname, viewaspect, width, height, posx,
posy) (See the GitHub issue mentioned above.) This change does not
remove any checks for classname, typename, etc. There are/were no such
checks in SotExchange::GetFormat().
But, in the (much different) code path for macOS (and iOS), with my
work in process in vcl, SotExchange::GetFormat() gets called with a
flavor with a MIME type that *does* contain those extra parameters. I
don't see the point in introducing checks of the "sanity" of those
into SotExchange::GetFormat().
Change-Id: Ie65ed1ab922cdaa6557eb65d980b9e886d3c6971
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109254
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
