Age | Commit message (Collapse) | Author | Files | Lines |
|
Writer just has a list of text nodes, but ODF and HTML can have multiple
paragraphs inside <li>, in case the non-first text nodes have their
RES_PARATR_LIST_ISCOUNTED set to false.
Improve b6f7a4908d1c3fc610440a1cbbbc1673a53da8b6 (sw XHTML export:
properly write <li>...</li> around paragraphs, 2018-04-11) to make the
decision around when to write </li> based on not only the current but
also the next text node. This way we omit </li> for non-first paragraphs
inside <li>, but keep writing it in other cases.
Change-Id: I994855961aeea92050268dba5f19f125c7ad2b7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94622
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Do not reduce the inside area of the chart depending
on the size of the legend. Use the default legend size.
Regression from commit: 739ed2c29f49ea5e83bcd1352b2644c2e2d09f7b
(tdf#115630 tdf#88922 Chart: fix custom legend position and size)
Change-Id: Ic191229d7ceab1f2689ab07424353108f8cb2b95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94059
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Tünde Tóth <tundeth@gmail.com>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Position export depended on OLE object names, instead of the
type of anchoring.
Follow-up of commit 2150fdc7d0f63288ac56c33cb898589512057642
(tdf#131539 DOCX export: fix position of OLE objects).
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: Ib98a19cb012047f37a5830c81541ef00c55589dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94190
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Id2458c16f259a58e2376f42104a9a6c9056cab11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94536
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94589
Tested-by: Jenkins
|
|
Change-Id: I09806869f2fdbae61f4c5d5c9db6859202bb63b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94609
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This was added in commit 56b2cf0c10d9caa01ebae1d80465e342d046a85c
(sw-collapse-empty-table-par-like-html.diff:, 2010-09-14), it's on by
default and off for old ODF documents.
Change-Id: I372c3447b0f8d63a4608543bb466817d694cbff4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94599
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(nested lists) and other items of lists, when auto
margin is defined by paragraph style, and list items
have got w:numPr.
Follow-up of commit 162d74ae7a53eb1cde738f0a7558f297b8162f7a
(tdf#132807 DOCX import: fix top auto margin in lists).
Change-Id: I4cf470173fa367ac07e15dc901b0e202178c9fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94588
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
to avoid of rounding error of EMU -> 1/100 mm -> EMU
conversions, which messed up recognition of preset
line widths in MSO.
Co-authored-by: Szabolcs Tóth
Change-Id: Ide0e393e667848683f00f9ba7a73ff8a45a908b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94043
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I7f0f17bc96d73cead6c8fd4269ea7cee1d85bca8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94552
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
1.) Remove unnecessary test for !bDontSplit,
since by definition, bTableRowKeep requires !bDontSplit
const bool bDontSplit
const bool bTableRowKeep = !bDontSplit && ...
const bool bAllowSplitOfRow = bTableRowKeep && ...
2.) Put the trivial !bPrevInd test first and so
potentially avoid the non-trivial lookup of
AreAllRowsKeepWithNext(pFirstNonHeadlineRow)
3.) bAllowSplitOfRow by definition contains the two
requirements of !bDontSplit and !pIndPrev,
so pull out and test earlier - potentially avoiding further tests.
This also emphasizes its similarity to bEmulateTableKeep.
Change-Id: I41cb72aa03371eacfdb68d63dc3df21f85e755bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93635
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: If179d0a13f3c9f7a49e3efe9027a64368ed600a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94544
Tested-by: Jenkins
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic03d43de5b83addcc25e857ae198ffcdd769f775
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94551
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Well, don't null them out at all, for the benefit of merged
cells, where the right border might be lost.
There doesn't seem to be any point in clearing a border because
LO sets a "merge adjacent line styles" in the borders
which does exactly what the comment indicated it was trying to
do. This option has been around since at least LO 3.5.
Change-Id: I22954e5fc31dc1c072f1ff5ccaaa05cd0f69fda4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93064
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Ie2ade3ce50049dec3e91a8bf29400c302d564aeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94540
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: I5697ff10c1118c9f6b4ea1760a9dce7e94d56f96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94542
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Use-case: HTML-copy 2 lines from a browser from a mattermost chat, paste
it into Writer. The content is not visible at all, because there are 5
invisible full-page textframes covering the actual content.
The browser has no problem with showing the content as these divs are
all invisible. Writer does not support hiding textframes, so just ignore
them on import for now.
Change-Id: I36a807d46f5f8348239e4693ec85da49a2205854
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94500
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
... for strict ODF versions, only write loext:table in extended.
Since commit 62391c28fae5099dd1f67c322867933fcb05bc9f LO can read the
loext:table elements, LO 4.4 should be sufficiently long ago.
Actually with ODF 1.2, the export asserts because loext namespace was
exported but isn't declared.
Change-Id: I92318f78b3282989de1d9c2764c2ed7663cb50b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94438
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
I added these files more or less recently and they have long lines. Use
clang-format to break at a sane column limit.
Change-Id: Id4ef832e4843fc81f4a497385e49ccb835a7197f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94503
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ibeb7ce063cf009b54337a44061ae186172011c99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94496
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Fill explicitely set to Start
Change-Id: Ib17e74e41afe3bad04ae0b665f88df044544c0a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94481
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Associate a style of family "drawing-page" with a style:master-page.
This fixes the small part of the draw:fill attribute problem that is
covered by OFFICE-3937 in ODF 1.3.
This is the import part.
Change-Id: I4c86fa24c36407b64ce33f0890e5da8c26c5292a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93670
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
This adjusts my LO 5.2 code for tdf#91083 that tried to emulate the
table's keep-with-next property which doesn't have a matching
counterpart in MS formats.
I always confused myself trying to understand what my year-long coding
attempt was trying to do. This seems much understandable, and efficient.
The big clue was that it affected non-MS formats - which was unintended.
Change-Id: I7886e52430cb34799e25f7fcf73500e28bbe2a55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93443
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
mbHasBlinkPortions is always false by the time this function is called.
Change-Id: I73b9128ce26ad8fad0227d0c93a62c28d46541c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94467
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
* FuInsertChart as a memeber in ScTabViewShell
stores instance is needed to react on the dialog's result
* CreationWizardUnoDlg converted to XAsynchronousExecutableDialog
added dialog close handler which notifies listeners
In the Online dialog become dead after closing, additional
PostUserEvent was needed to kill the dialog after real close
(without it user needed to select any cell to close dialog)
* Reuse in Writer
Change-Id: Ib09b5d83af9e1aa67218e093aa161419e8ddb922
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90380
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Although the original document completely defines the numbering
in (inherited) paragraph styles, the unit test was checking
whether the paragaph itself had the exported numbering.
That tests the current implementation where style information
is copied to the paragrah, but in a correct world that information
would stay in the styles.
This unit test uses the EXTREME example where a "chapter numbering"
is inherited by a sub-style - something LO completely does not
support, so this needs serious emulation. Thus I am keeping
the implementation-specific check, but clearly documenting
that fact.
Change-Id: I5b95646498c4d936eceb9be1841c654a5bd81275
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94401
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
... to configuration and UI.
The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and
stored as value "3" in configuration.
Adapt a few places related to DocumentDigitalSignatures etc. to new
default.
Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
When direct character formatting defined in w:pPr/w:rPr
overwrites some character style properties (character
style defined by w:pPr/w:rPr/w:rStyle), empty paragraphs
lost such direct formatting, resulting for example,
different page layout by different height of empty
paragraphs. Also text of that originally empty paragraphs
got different formatting during typing.
Co-authored-by: Justin Luth <justin_luth@sil.org>
Change-Id: Ic7b3a73d4d7364993cc58073c9e1a09a2711d1b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94308
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
0 line width is the thinnest possible line width,
but without its explicit export (a:ln w="0"), shape
outline was imported with 0.75 pt line width by MSO.
Co-authored-by: Balázs Regényi
Change-Id: I40f7aefe6358bebe9a3853fe3e7d6faa170bc34c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93968
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I98319183a7bd9abb9ed6b1dd9f85cf00ee701fc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94405
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: I95391ef6ed5154efc2c7705dde22afa59da24a70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's not enough to check the paint area. because it's
in logic units, which does not change by zooming.
Change-Id: I9ee51c03e7edc2c70d91d6ef6dbaaae8c2c7beff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94400
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Margin (left, right, inner, outer) alignments of VML shapes
weren't handled.
Co-authored-by: Attila Bakos (NISZ)
Change-Id: I5f8ece64707a2d699b71d6151887db05ac39c4f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93723
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
In a build via ssh, the test hangs while trying to connect to Evolution
Data Server that presumably isn't running:
1 in g_cond_wait () at /lib64/libglib-2.0.so.0
2 in e_flag_wait () at /lib64/libedataserver-1.2.so.24
3 in e_client_wait_for_connected_sync () at /lib64/libedataserver-1.2.so.24
4 in e_book_client_connect_sync () at /lib64/libebook-1.2.so.20
5 in e_book_client_connect_direct_sync () at /lib64/libebook-1.2.so.20
6 in connectivity::evoab::(anonymous namespace)::OEvoabVersion38Helper::createClient(ESource*) (this=0x912d150, pSource=0x90c0660) at connectivity/source/drivers/evoab2/NResultSet.cxx:480
...
35 in SwMailMergeConfigItem::GetResultSet() const (this=0x8f10b30) at sw/source/uibase/dbui/mmconfigitem.cxx:875
...
63 in SwMailMergeWizard::SwMailMergeWizard(SwView&, std::shared_ptr<SwMailMergeConfigItem> const&) (this=0x8f0f340, rView=..., rItem=std::shared_ptr<SwMailMergeConfigItem> (use count 3, weak count 0) = {...}) at sw/source/ui/dbui/mailmergewizard.cxx:60
Change-Id: I1b43b05509f4e293ce1f00044a05f045bf975ce4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94364
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
So it can be removed and client code can be adjusted accordingly.
Change-Id: Ib3ca86cf147387fdbd646eb46077eff89d4c56f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94397
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
We need to distunguish when we have list format string, but it
is empty (no level text will be diplayed) or it does not exist
at all, so we need to fallback to old prefix-suffix syntax.
Change-Id: Ifd4ccd5a676db86c39d2ef48e91d191d92b9b2a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94322
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I2601cc41ff8b7c678ac6d5d0ccce05d17f6be18b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94107
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Failing to treat CRs without corresponding LFs resulted in 0 inserted
in the place of the CR, but the text up to this position not inserted,
and pLastStt not updated. Thus all following text was dropped when the
insertion was finally performed (when CRLF or EOF was reached), because
of the 0 marking end of inserted text. But that was inconsistent with
how other Windows applications treated stand-alone CRs, and also with
our own handling of them when they happened in the end of the internal
read buffer.
Change-Id: Idf4876b0cccd4aa3f14f6efede54d27670f55c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94277
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If0e362cf5b403be63439ec694f3a0e440dfd9bc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94327
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by bin/check-missing-export-asserts.py
Change-Id: I270b5dce748039427aaf5507006a8c145ef1419b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94331
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Most of these are calls to
DocumentDigitalSignatures::createWithVersion(), where it doesn't make a
difference if "1.2" or "1.3" is passed in but maybe it will be different
with "1.4".
There is another ctor createDefault() which looks appropriate for
non-ODF contexts and can also be used when no actual signing or
verifying is done.
In cases where there's an actual document its Storage has the version.
Change-Id: Id636bbf965d9f96c7ed5f50774c509032525b2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93091
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I494349b99a122f67ed1f2881faf1a37e4358c55b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94214
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If the wrap polygon is influenced by crop at import time, we need to do
the opposite at export time.
Do this for RTF and DOCX, where there is matching import code in
writerfilter/, leave DOC alone for now.
Test this by changing testFdo76803 into an export test, then seeing how
the first point's Y position fails and fixing up the exporter, so we
get back the old good value.
Change-Id: Ieef18aad3c76f7945c7348201b07bcb27a4cd48d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94246
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Icab23e9d5dbd70c15373b3fd228e8563b777af71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94068
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia1e67cd70c0327a95db96ed4a78fac631017e660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94113
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: Iab360691cd23f663b7f6bf00227e8749d4c9e48e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94114
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Shapes are handled in all modules; images only in draw/impress (TODO).
Change-Id: Ib96eb4c36fdb69dd605f9b5a507f67a279797286
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94162
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Found with bin/ui-checkdomain.sh
Change-Id: I2a3ec2593b9ce0a19efced9020b95dff796e4702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94153
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
|
|
Word first applies the crop, then applies the wrap polygon on the
remaining visible part of the image.
Writer applies the crop on the original bitmap, and even has explicit
code to make sure the uncropped bitmap is used for the wrap polygon, see
how SwFlyFrame::GetContour() calls SwNoTextFrame::GetGrfArea(), which
will extend the resulting size based on cropping.
Fix the problem by moving and scaling the wrap polygon, so it ends up
where it would in Word.
Also adapt testFdo76803, which had a similar crop+wrap polygon case, but
the different there is quite small.
Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94149
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Iff2d6d8120118c35aa6d3d44016a0a7c2e193ec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94116
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: Id813d95a90fdbb360dfc8670c0b55b635f633965
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|