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>
...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>
<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>
The implementation of SxvFmDrawPage::getTypes was presumably forgotten when
e97beb270f "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 c5db3b93ee)
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 9257486636
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>
The base UnoControl uses WeakAggImplHelper9, so (for better or worse) derives
from XAggregation, but UnoGridControl, UnoRoadmapControl, and UnoTreeControl all
failed to properly implement the XAggregation protocol.
Change-Id: Ia1676782e616216f645dc86ba978c2f5887dc508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145767
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The base SvxDrawPage uses WeakAggImplHelper7, so (for better or worse) derives
from XAggregation, but SdGenericDrawPage and its derived classes (SdDrawPage,
SdMasterPage) failed to properly implement the XAggregation protocol.
When fixing this, it became apparent that SdGenericDrawPage::queryInterface had
erroneously delegated to SvxDrawPage::queryInterface rather than to the
intermediary SvxFmDrawPage::queryInterface, so that querying for e.g.
XFormsSupplier had only worked by accident: SdGenericDrawPage::queryInterface
didn't support it, so delegated to SvxDrawPage::queryInterface, which didn't
support it, so delegated to WeakAggImplHelper7::queryInterface, which didn't
support it, so delegated to OWeakAggObject::queryInterface, which (as there was
no delegator set) delegated to the most derived SvxFmDrawPage::queryAggregation,
which supports it.
Change-Id: Ia7154d62e493238738e6d15dea2f01a437a70bff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145763
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is similar to commit 43d80906c8 (sw:
.uno:TextFormField: handle Endnote as a value for the Wrapper parameter,
2023-01-17), but that was for fieldmarks & endnotes, this is for
refmarks & endnotes.
Change-Id: I46512dd973508f51f7093521c40ad4100dd39ae6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145762
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Fixed the EdgeLine1Delta calculation in case of bentConnector2.
(when L shape imported as a special Z shape)
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I08c92e63adc744322061e4e433bfdc512745eda1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145548
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
The bugdoc DOCX had a shape anchored in a table cell, and the cell had
large enough height so the shape could fit into the cell, while the
expected cell height was independent (smaller) from the shape.
The problem is around the follow-text-flow feature, which is called
"keep inside cell boundaries" in Word. This setting would normally
increase the size of the cell, so the shape remains inside the cell. An
exception from this increase request is the wrap-through wrap mode,
which leaves the cell size unchanged.
Fix the problem by considering two previous use-cases:
1d9221ebc8 (tdf#145688 sw: fix misplaced
images in table cells, 2022-11-29) and
489eef894e (tdf#124601 sw FollowTextFlow:
fix vert pos of objects outside the current cell, 2019-10-01):
- tdf#145688 is a legacy ODF document: do require the the "in
background" wrapping, otherwise make the cells big
- tdf#124601 & tdf#153045 are Word documents: here don't require the "in
background" wrapping and go with small cells when the wrap type is
through
This requires adjusting the tdf#145688 testcase that minimized the
original bugdoc incorrectly.
Change-Id: Ieaf3d9c1c4477e5e57e5e1e825775648840ab32b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145756
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The DOC import keeps duplicating the content part,
so I haven't added a separate unit test to this patch,
but manual testing shows this works for DOC and RTF.
The unit test for DOCX already handles the correctness
of the code, so no real need for another test anyway.
Change-Id: Iceb41a647b8408150ae8558b10b581d3a6c49e45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145755
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Old SvTreeList did split a string on embedded \t Tab characters,
the new weld::TreeView does not but needs column text set
explicitly.
Regression from
commit 56dd851cfc
CommitDate: Sat Apr 27 12:41:14 2019 +0200
weld cluster of change tracking dialogs
that did the necessary changes for
ScAcceptChgDlg::AppendFilteredAction() but not for
ScAcceptChgDlg::AppendChangeAction() and
ScAcceptChgDlg::InsertChangeActionContent().
Odd that no one reported this in all the time..
Additionally, the "Changed contents" label being used instead of
"Row inserted"/"Column inserted"/"Row deleted"/"Column deleted" as
soon as cell content change is present depending on such action,
was a copypasta fallout from
commit e7c76b30bd
CommitDate: Mon Aug 29 17:21:12 2011 -0400
String to rtl::OUString.
Change-Id: I855c527da61723c104c743e3b3f159fb026917df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145749
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
so bizarro ppds with no resolutions don't trigger a warning unless it
gets queried about the resolution
Change-Id: I4828ddf80d011265aefb271d964f6362842b3014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145734
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
... \t style name separators.
OOXML says in 17.16.5.68 TOC:
\t field-argument
Uses paragraphs formatted with styles other than the built-in
heading styles. text in this switch's field-argument specifies those
styles as a set of comma-separated doublets, with each doublet
being a comma-separated set of style name and table of content
level.
The reality is documented in Word online help:
https://support.microsoft.com/en-us/office/field-codes-toc-table-of-contents-field-1f538bc4-60e6-4854-9f64-67754d78d05c?ui=en-US&rs=en-US&ad=US
Note: Syntax shown here uses a comma (,) between the Style and Level
parameters. A semicolon (;) is also valid, depending on which
character is specified as the list separator in your operating
system's regional and language settings. Because of language-specific
dependencies, we recommend not using the \t switch in templates or
documents that are intended for users across multiple language
configurations.
It's easy enough to recognize both ',' and ';' as separators on import,
and unlikely that anybody would use these characters inside a style
name; for export, both can't be written and a decision must be made.
So do the same thing on export as Word does, assuming most document
exchange is between users in the same locale; currently only for "de"
locales but more can be added.
Interestingly WW8 used to write ';' before 2009 when CWS hb32bugs01
changed it to ','.
Change-Id: I2dcfdd009f448f6fae37cbd28929d0bbe504acf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145744
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The bugdoc contains this style:
<w:style w:type="paragraph" w:styleId="IntensivesZitat">
<w:name w:val="Intense Quote"/>
<w:basedOn w:val="Standard"/>
<w:next w:val="Standard"/>
<w:link w:val="IntensivesZitatZchn"/>
...
which is referred to by:
TOC \o "1-3" \h \z \t "Intensives Zitat;3;Custom1;3;_MyStyle0;3"
Word in an "en" locale is unable to match the "Intensives Zitat" in the
TOC field with the style "Intense Quote", which is a built-in style
in Word (no equivalent in Writer).
At first glance nothing in styles.xml matches the localised built-in
style name in the TOC field.
But it looks like the w:styleId value is somehow generated from the
localised style name by omitting certain characters like SPACE and
non-ASCII letters.
Change-Id: I2050f7cf7f8d80bee1f667ee53b7f9981bbf7b49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145745
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
we can just use the concrete type, instead of casting
Change-Id: I947b45eb454328390e077654bbf677f6a0fe8a89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145740
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Added like this in commit be515af4d9.
Change-Id: I4a9190b18c80930c2c7ba31c9e657280527c3ea9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145743
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Jenkins fails on mac and windows with
sc/qa/unit/uicalc/uicalc.cxx:297: Assertion
Test name: testTdf151886::TestBody
equality assertion failed
- Expected: 1,1
- Actual : Err:509
Change-Id: Iaa51174ef246bc4ac9096b345e2a33370a5ab967
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145403
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In Hide Changes mode, Undo of insertion of CH_TXT_TRACKED_DUMMY_CHAR
(workaround of the deletion of empty table rows), resulted a crash
because of inconsistency of table and redline nodes. As a workaround,
skip that insertion from the Undo.
Regression from commit a74c51025f
"tdf#146962 sw: hide deleted row at deletion in Hide Changes".
Change-Id: I0666d7bcbbf08d84386cea64c1807f69f751479d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145737
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
w15:paraIdParent attribute indicates that the comment is a reply to the
value id
Change-Id: I9e6eca6a656594c956629c1434b8e5c3aa573c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145314
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
We urgently should get rid of XOR paint, modern
graphic systems allow no read access to the pixel
targets, but that's naturally a precondition for
XOR.
While we can do that for the office's
visualization, we can in principle *not* fully
avoid getting stuff that needs/defines XOR paint,
e.g. EMF/WMF imports, so we *have* to support
it (for now - sigh)...
This makes this renderer complete from the minimal
to-be-supported primitives, too.
Change-Id: Ie8fa98b777de764af0babe969296a671ca5cc7ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145739
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The Calc.SortRange() method sorts
the given range on any number of columns/rows.
The sorting order may vary by column/row.
The sorting algorithm allows for maximum 3 keys.
When the number of sort keys is > 3 then the range
is sorted several times, by groups of 3 keys,
starting from the last key.
In this context the algorithm used by Calc
to sort ranges is presumed STABLE,
i.e. it maintains the relative order of records
with equal keys.
Change-Id: If7f4920f7ab8f8ffb71edf648ed9accc8eb62dce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145681
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
UI stuff is a total black box,
so most of the config is just copy/pasted from a similar function,
with nothing to indicate what any of it means or does.
Miklos pointed me to this documentation,
so I've dumped it here so that there are a few breadcrumbs
pointing to the specs for what this stuff means.
Change-Id: Iccbc0ff5b400328af8ae683fdcf42203e4029d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145624
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Although this function is only used for ww8 import (and qa tests),
it is documented as being more generic. So I decided to just trim
at the source and not try to introduce any MS-isms into the parse function.
Something similar will be needed for DOCX,
but DOCX import for FIELD_IF is completely missing.
Change-Id: I822b400e3e53abd953f4c382947f0e80ae62b234
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145691
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
And make the dynamic_cast more specific, matching the now-removed
unconditional static_cast.
Change-Id: I322312eb8675b28af79b7cca552d6347f74c5faa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145593
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Just like for the the case where editing is disabled
(s. Change-Id I2f8c86f5db96a5135ff8a66a7a7078b664d05a5e,
"android: Only offer creating docs when editing enabled"),
just hide the UI to create new files when running on devices
that don't support `Intent.ACTION_CREATE_DOCUMENT`, rather
than showing the button, but then showing a message that
creating files is not supported once the button is clicked.
Change-Id: Ifedf40e22dc8906557d5364ecf9ec3a9db2315e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145736
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
