Age | Commit message (Collapse) | Author |
|
Regression from commit a2a08463e0299d514e6e555ae61c68bb0e4348d0,
where I mistakenly assumed that the value is just to accommodate
enough entries. I don't know where it's documented, but this
fixes the bug.
Change-Id: Ifecf5d294222e3a40cb23f7c147694dbdf35e405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145869
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The base UnoControl uses WeakAggImplHelper9, so (for better or worse) derives
from XAggregation, but SbaXGridControl failed to properly implement the
XAggregation protocol.
Change-Id: I26c825b9b64b4e886e69f95bc3d4d5d42120bd8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145865
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The base FastPropertySet uses WeakAggImplHelper3, so (for better or worse)
derives from XAggregation, but SbaXGridControl failed to properly implement the
XAggregation protocol.
Change-Id: I31378f13256b1fa20775890b206f455d782ea864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145868
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...rather than on the deprecated WeakAggImplHelper3.
It was found that those two classes were implementing queryInterface in a way
that is incompatible with the XAggregation protocol inherited via
WeakAggImplHelper3. It looks like no code actually made use of the XAggregation
offered by these classes, so the easiest fix for those queryInterface
implementations appears to switch from WeakAggImplHelper3 to WeakImplHelper
(thereby dropping XAggregation, and thus rendering the existing queryInterface
implementations OK).
Change-Id: I8f841ca959838d9a87943091b76f3ce1cf8c9303
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145866
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...rather than on the deprecated WeakAggImplHelper1.
It was found that that class was implementing queryInterface in a way that is
incompatible with the XAggregation protocol inherited via WeakAggImplHelper1.
It looks like no code actually made use of the XAggregation offered by this
class, so the easiest fix for this queryInterface implementation appears to
switch from WeakAggImplHelper1 to WeakImplHelper (thereby dropping XAggregation,
and thus rendering the existing queryInterface implementation OK).
Change-Id: I2352f5a57f2e23e6c7d512ef4d850844149269c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145867
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
When Fill style is none we can not use fill attribute element. So It is
better to hide.
Change-Id: I88d5e49448040b3afa18fbf66377d254716e7415
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145817
Tested-by: Jenkins
Tested-by: Pedro Silva <pedro.silva@collabora.com>
Reviewed-by: Pedro Silva <pedro.silva@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
regression from
commit 3a02b5f8aae803b7b5a232c724135594483627a4
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Tue Aug 16 18:44:31 2022 +0200
convert more nNode to SwPosition::GetNode
Change-Id: I636590ec5eb28f0db3640464a49f0ab5582ff853
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145864
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
otherwise it looks like only one row is getting moved
Change-Id: Ie0b63a9c3cea377c3753785d9c6f7958cbc7ac1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145818
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id8c2679b2b9984f1fa7a133c40e8536cded12c64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145829
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6bbe75ae26d5411d2d032311e8877632b1e4d850
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145862
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I31dcd7a498e2742c49d98e5626f10aa7dcafa8f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145861
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85f4ffab71b8321cc592e3b70fec63111bbd78ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145860
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4513cc38b31062327a773afd91dd3b4ee98c1bcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf544314d0c47209b254c3bb40d35c03e6556f5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145858
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I87e635f371278132be9da4e6a60ba90180d25522
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145857
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Split text lines in a paragraph, right before polygons are created
for rendering, so eol will brake line in fontwork just like eop.
Change-Id: Ie9e6764f9f91c2e19afd43dc9a212bd18c41c99d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145425
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Importing an inline content control from DOCX used to be just plain text
in Writer, so the PDF export of that was also just plain text.
Now that content controls are actually supported, we used to not emit
them as plain text in the PDF export, since
82d90529dc2b3cb8359dec78852cbd910a66d275 (sw content controls, rich
text: add initial PDF export, 2022-09-12). Part of this was to write the
string value of the content control as the /V (value) key of the form,
when it's not in placeholder mode. This made sure that once the form is
filled in, no overlap between the plain text and the filled in text
happens.
Try to support both use-cases at the same time by also mapping the value
of the content control to /V, even if it's in placeholder mode. This
keeps avoiding the unwanted overlap, but this way the placeholder text
is no longer lost on PDF export.
An alternative would have been to map the placeholder text to
description when the alias/title is empty, but that would show up only
as a mouse tooltip, so won't change the behavior when the PDF is
printed.
Change-Id: I9408b5abe36af28cd00845a74a3dfff13973b83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145828
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
there is no benefit to having this constructed in such a convoluted
manner
Change-Id: Ib02b4bfe689326784bd8233003d10960700811d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145778
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Early return on useless parameter,
and conditional processing on missing ID.
Change-Id: Iecf2d7522bd0c1e958f826214368966399be311c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145831
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Sets an image for image content entries that are of linked type
Function 'InsertContent' added to replace duplicated code that
inserts content.
Change-Id: I25dec3f5765fa3dffe505743cd9c5fe044349ab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145530
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
This patch is a mixed blessing.
It will be a regression if an IF FIELD was bogus,
and the user only wanted to see the modified, unrefreshed text.
That is because in MS Word, most fields do not update automatically,
but require the user to press F9 to refresh the contents.
The contents are also editable, so the result might not match
either the true or false result-string.
However, in LO the IF FIELD is always refreshed, and thus will
never display any bogus hand-modifications.
The import of these IF fields started in DOC in LO 6.1,
but it was never correct and immediately duplicated content.
Additionally, DOC format didn't export at all, so anything
to do with IF FIELDS was lost - meaning that after a round-trip
the result was the same as what MS Word last saw with the field gone.
So in the eyes of the user, the fixing of import and export
might be causing a regression of changed text.
So be it.
I can only assume that in most cases the use of an IF FIELD
is intentional and that it would be desirsable to have it working.
Change-Id: If90f6f4cddcefebf379352aac6519595c1bf2b23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145821
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Instead of assuming that the "insert reference" entry is always the second item of the menu tree, search for the correct child in the tree list. This commit addresses the failing build from https://gerrit.libreoffice.org/c/core/+/140985.
Change-Id: I6f0d7021ab6f632784cab85656823c69f90baf60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145816
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Some examples inside odk/examples/java/Spreadsheet are ported to
Python:
ChartTypeChange.java -> ChartTypeChange.py
EuroAdaption.java -> EuroAdaption.py
SCalc.java -> SCalc.py
Code format is checked with 'pycodestyle':
pycodestyle --ignore=E501,E722 odk/examples/python/Spreadsheet/*.py
Signed-off-by: Chenxiong Qi <qcxhome@gmail.com>
Change-Id: If0631b5970faab6499cfea3eef559e003fad24d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143810
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I12565dcdd1437c461762688ed3bf0e1adad828ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145827
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I56dfc6dfec21b8c57b6f402c53b0229a2a2e7778
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145824
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The fieldmark may overlap a section; at the start was considered here,
but at the end was not and so the assertion wrongly fired.
Change-Id: I118bc36c2d9c4ca7028a583278d0f193537c4cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145826
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
...rather than on the deprecated WeakAggComponentImplHelper4.
It was found that e.g. GridControlAccessibleElement, deriving from
AccessibleGridControlBase, was implementing queryInterface in a way that is
incompatible with the XAggregation protocol inherited via
WeakAggComponentImplHelper4. It looks like no code actually made use of the
XAggregation offered by this class hierarchy, so the easiest fix for that
queryInterface implementation appears to switch from
WeakAggComponentImplHelper4 to WeakComponentImplHelper (thereby dropping
XAggregation, and thus rendering the existing queryInterface implementation OK).
Change-Id: Ia7f033d0a93e78a48573cb489dc5542603c35b8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145793
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I18c229f31738707e4a379c9379425141ba4dc690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145787
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib2ffd8a58eb696dfa845a08f6d05fd9898ff7db8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145785
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id9d80bac06377018eaf768bdbd68e98b1de0666b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145782
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If22cf501522115ebd87dee8580831750ea8bbbd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145781
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib39e51900826b13824906c33775a8aa375955fcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145780
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
because if we allocate two things in the same location, we can subtlely
lose the second one.
Change-Id: I4dda5c738802da8544d280c020e059da63b5d71c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145779
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The base SvxDrawPage uses WeakAggImplHelper7, so (for better or worse) derives
from XAggregation, but SwFmDrawPage failed to properly implement the
XAggregation protocol.
Change-Id: Idf2c2d27cd5fb443e574cfd770091600a23c6e8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145771
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It was causing layouting issues in LOK.
Change-Id: Ic7520f46efa764d2d6b50b021b44e0a5dd07d837
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136343
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Rashesh Padia <rashesh.padia@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145791
Tested-by: Jenkins
|
|
...rather than on the deprecated OComponentHelper.
The two classes SfxDialogLibrary and SfxScriptLibrary, both deriving from
SfxLibrary, had been found to implement their respective queryInterface in a way
that is incompatible with the XAggregation protocol inherited via
OComponentHelper. It looks like no code actually made use of the XAggregation
offered by these Sfx*Library classes, so the easiest fix for those
queryInterface implementations appears to switch from OComponentHelper to
WeakComponentImplHelper (thereby dropping XAggregation, and thus rendering the
existing queryInterface implementations OK).
Ideally, SfxLibrary would derive from WeakComponentImplHelper<XInitialization,
XStorageBasedLibraryContainer, XLibraryContainerPassword, ...> covering all the
UNO interface classes from which it currently derives manually. But changing
that manual implementation across SfxLibrary and its SfxDialogLibrary and
SfxScriptLibrary derived classes looks tricky, so merely introduce an "empty"
WeakComponentImplHelper<> for now and keep all the manual stuff, and leave
proper clean up for later.
Change-Id: I12dc5bad2c017b8d76ce28ac189e95cf2e3810e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145792
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iba92ac9d7093b7fd8d6d61be2496333ad1d8b59d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145815
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
<center> is not valid XHTML, have to use CSS styling instead.
HTML export uses <center> by default around tables where the alignment
is center.
Fix the problem by avoiding <center> in the XHTML case and set the left
and right margin to auto, which means:
If the values of margin-left and margin-right are both auto, the
calculated space is evenly distributed.
according to
<https://developer.mozilla.org/en-US/docs/Web/CSS/margin-left>.
The import will be adjusted to recognize the new markup in a follow-up
change.
Change-Id: I51e3507e9cde713f961b783378d66db59194a6ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145814
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The problem is that first CURLOPT_POST was set and later CURLOPT_UPLOAD,
which overrides the HTTP method to PUT. Move this out to the 4
functions that need it.
Change-Id: Ibd555dcc00a03baa1bb300a9ab9905f383179c67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145786
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
...rather than on the deprecated WeakAggImplHellper5
Change-Id: Id9e61341cba10c4a497500d41479629ff3af30ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145790
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...rather than on the deprecated OComponentHelper
Change-Id: Icb83d3cc0a0588a703a9041c00730b2a8d8bb90b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145789
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Also add a test for checking the right behaviour when
changing the content of a cell
Change-Id: I33dda97a467355273d49ddbcab56886a9b1950d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145776
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
The problem was that Word treats empty w:num/w:lvlOverride elements
for higher levels as defining corresponding w:startOverride equal
to 0. This only shows when the first list element has a lower level
and resets numbering; in this case, implicit higher levels get zero
value, and the following higher level items start from 1.
This writes the correct w:startOverride values (from the respective
rule) to the gap-filling levels.
Change-Id: I18db1c6011bf09826ba586aaec16e7939ecb0c6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145770
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I24ce412fd3b62843ee3fabc7a3fca36ae91c0222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145784
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iac543121a809eeabae630d4a426e72d5f9d47057
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145783
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5c4f70d98dd8ea03c137cd368a2c097cd866609d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144222
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Rashesh Padia <rashesh.padia@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145067
Tested-by: Jenkins
|
|
Dialog in File>Export As PDF>Security>Set Password
Close subdialog when parent dialog is closed
Signed-off-by: NickWingate <nick.wingate@collabora.com>
Change-Id: I9db8459309f2806ed47f9f932e0bde246400b2dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144854
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145759
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
The implementation of SxvFmDrawPage::getTypes was presumably forgotten when
e97beb270fd1a5121cdb69ffafd12ea04100e290 "NTEGRATION: CWS xmlperf02" changed
SvxFmDrawPage from supporting XFormsSupplier to supporting XFormsSupplier2
(which derives from XFormsSupplier).
And SwFmDrawPage uses ImplInheritanceHelper to derivefrom SvxFmDrawPage, so
there should be no need to implement SwFmDrawPage::getTypes manually (and
wrongly, at that, in that it included the types of SvxFmDrawPage twice, once
directly via SvxFmDrawPage::getTypes(), and once indirectly via
SwFmDrawPage_Base::getTypes()).
Change-Id: I8c467f5a20e1f44396378abe9199851e646f6947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145772
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
XForms replace doesn't work because:
CDocument::IsChildTypeAllowed() tests that the document node does not
already have an element child, because only one is allowed - but when
called from CNode::replaceChild(), the existing child will be removed,
so that needs to be allowed to proceed (check that removed child is
also element).
(regression from commit c5db3b93ee1058bd20ebcde2e757b52b9a67b74a)
Change-Id: I167de3462f4d1934dbf8404ad395349897cfd981
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145757
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This allows to send correct cursor position (at the very end
of the cell) when typing numbers in LOK mode.
This fixes regression from:
commit 9257486636dfe95b73e5690462ba6e8408a12166
lok: sc: render expanded EditEngine when editing in-place
Change-Id: I1f6c7ce3de7a2ba7ccbd4f9f9becd49e352cf05e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145260
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145769
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|