Age | Commit message (Collapse) | Author | Files | Lines |
|
copy from 9ac4e1b0b5b3c2eab2405f6403ea9cf84252b41a, as git fails to
cherry-pick/merge itself.
Change-Id: Ie6b85546f327b92d7ea36b88eed6e5b7b068fa23
(cherry picked from commit 4ffd96036440545a24312f170cd1c5ce79154640)
|
|
The code is now more robust and will accept illegal arguments.
Change-Id: I43ae82b953cea845fb170aa7b6e8d42470ad4e5e
Reviewed-on: https://gerrit.libreoffice.org/14580
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 4bdbea5447f36beb9cc33df173a89a49a9918290)
Signed-off-by: Michael Stahl <mstahl@redhat.com>
|
|
The problem was that the bugdoc had a table, and inside the table there
was a long paragraph that flows to the next page, but only the paragraph
mark of it does so. We first split the frame to have space for the
paragraph mark, but later decided that all the content would fit the
first frame, and this way the last hard line break and the paragraph
mark was painted on each other.
This is normally not a problem without tables, because
SwTxtFrm::FormatAdjust() just calls SplitFrm(), sets its nNew flag to
non-zero make sure that later SwTxtFrm::_AdjustFollow() doesn't try to
join it, and we're ready. However, when the paragraph is inside a table,
then the paragraph was formatted multiple times, and next time when we
already had a follow nNew was not set, so even if there was a correct
split first, the new frame was joined later.
Fix the problem by explicitly setting nNew for the "in a table and
paragraph ends with a hard line break" case, that way we don't blindly
join the frame, only in case there is enough space for the follow in the
master.
(cherry picked from commit 7e33cce05b2df3f1761bcc66606c4d3b2b2671e9)
Conflicts:
sw/qa/extras/uiwriter/uiwriter.cxx
Change-Id: Iede654740dcb0d8aa768d742ee330208291a383a
Reviewed-on: https://gerrit.libreoffice.org/14476
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
(cherry picked from commit 38f2b8b3b16aab19a2564ec699d253d3dccecc3c)
Change-Id: Iedf8eacd37b8ed8e307a10e8ade32f53c7417c4a
Reviewed-on: https://gerrit.libreoffice.org/14571
Reviewed-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
Tested-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
|
|
.. building the color table
(cherry picked from commit 87a5cf7db1f070cbc4a674a1c12c805a2c950856)
Change-Id: I8a74640e0d51d76b910394be5210c18d89818edd
Reviewed-on: https://gerrit.libreoffice.org/14392
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
In theory this is to be in sync with the ODF import. In practice the old
UNO property seems not to have a proper fallback to populate the doc
model with the fillattributes, so without this even if the import result
is visible, it would be lost on ODF export.
Additionally, this detected a bug in SwUnoCursorHelper::makeRedline(),
where paragraph format redline tried to use the map of a text portion
instead of a paragraph.
(cherry picked from commit 24077b2d52ab3d0fd0db5afb25d8b94b62386e3e)
Change-Id: I026e38e1990ed2a460624a8d967a16ae3fb6c512
Reviewed-on: https://gerrit.libreoffice.org/14353
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I12c74380b65e463be352825c7f1459393883283b
|
|
Change-Id: I273af8b570adfcb7bfb784495bc31d2f4f1ee00b
Reviewed-on: https://gerrit.libreoffice.org/14333
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 675e1fe198298702ced8eab02a7df5164d66a8f0)
Signed-off-by: Andras Timar <andras.timar@collabora.com>
|
|
Regression from 7d9bb549d498d6beed2c4050c402d09643febdfa (Related:
i#124638 Second step of DrawingLayer FillAttributes..., 2014-06-02), the
problem was that exporters still expect an SvxBrushItem for the para
background color, while doc model was changed to have an XFillStyleItem
/ XFillColorItem pair instead.
(cherry picked from commit 60cdeb2d441a6bf5c55f511f574b2b9dd598fbb8)
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Change-Id: Ib94fda103ec35a6f087307aafdd890183d9d935f
Reviewed-on: https://gerrit.libreoffice.org/14328
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The problem is that SwUndoDelete will move the fully selected nodes to
the UndoNodes but it leaves bookmarks with their SwIndex pointing to the
deleted nodes. The SwNodeIndex are corrected by SwNodes::_MoveNodes()
so they point to a different node than the SwIndex.
This only happens if only one position of the bookmark is inside the
deletion range; if both are, the bookmark will be deleted by
SwUndoSaveCntnt::DelCntntIndex().
Also joining the 2 start/end nodes of the selection will accidentally
correct the bookmarks but only if it happens to delete the end node.
(and apparently there is also a DeleteRange method that doesn't join)
Change-Id: I91ec362bb833328f8d681fd9458cb915c4efb267
(cherry picked from commit 370febbf19a5f362394d1c9e69b12dcb218f6501)
Reviewed-on: https://gerrit.libreoffice.org/14240
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
... only in case the whole table is already selected
Change-Id: If7626954460e16945af6b21402a84e90c71ae138
(cherry picked from commit fa39e7970496537258eaad1f5351db2d675225b6)
Reviewed-on: https://gerrit.libreoffice.org/14157
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
LibreOffice recognizes MS Office TOC, but LO files saved as
.doc format had no text showing. Now bookmarks using the LO
naming convention are also imported as TOC bookmarks.
testcase included
Change-Id: I9b2855e9d00f4d103c3be22b1b1185c557865d87
Reviewed-on: https://gerrit.libreoffice.org/14099
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I67f472d72efe123b533d4d94be0084986c0e8349
(cherry picked from commit 6acd5c45c764d81aea1539e66adbfadb51df0aa3)
Reviewed-on: https://gerrit.libreoffice.org/14079
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
(cherry picked from commit e4de5b40eb7220da2d337eb98d7905a98dc12c72)
(cherry picked from commit 80eb001e6a861c68f2915d4eebded5e36e1875f6)
Change-Id: I543ec24f8825bcc7c35acc106402f4fc6b4b5d79
Reviewed-on: https://gerrit.libreoffice.org/13858
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
We can't do anything sensible with these CustomXML elements but now we
have to handle them because.
(regression from 9dbf817fe5c5253fba0831aefa17575ae0ba3af1)
Change-Id: If4247890ff9961a77434587802670d28608a7922
(cherry picked from commit f22964e0e622af1168e241f933e5cf98e093ec2b)
Reviewed-on: https://gerrit.libreoffice.org/13913
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit 01fc08c0b5c57fef8ad3755672f4266d85e849a5
(fdo#85554 SwXShape: fix getting ZOrder property when doc contains
TextBoxes, 2014-11-20), the problem was that we returned wrong ZOrder of
shapes inside group shapes.
In SwXShape::getPropertyValue(), pObj points to the Writer-interfacing
outermost group shape in case of shapes contained by group shapes, while
GetSvxShape() gives access to the real shape. Given that TextBoxes are
only possible at the highest level (and not inside group shapes), just
check if the two pointers are the same: when not, then no need to
convert anything.
With this, child shapes get back their original ZOrder -- before in case
the group shape had ZOrder=0, all its child shapes had ZOrder=0 as well.
(cherry picked from commit 97952280f0adbe195e6a2e0bab8a21a7e352a721)
Conflicts:
sw/qa/extras/odfexport/odfexport.cxx
Change-Id: I9c4097154130cd04f6ab2f2082abafc1d4333872
Reviewed-on: https://gerrit.libreoffice.org/13562
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This makes CppunitTest_sw_ww8export pass on Windows again.
Change-Id: I16fed4eabbe7b9ccdcc0c71361b85b0e13f2245a
(cherry picked from commit 4d3b725000e537ce6199f0abd1c80580c9bf95c8)
|
|
And add a minimal reproducer that shows how the old way was broken.
(cherry picked from commit 0ec0ec267986644084baaa5bda5ba917dc5744df)
Conflicts:
sw/source/filter/ww8/ww8par.cxx
Change-Id: Ic2dadf9905d603b0fd0573651b235ecd5dd70e71
|
|
Change-Id: Ib2a477319f843c9da4f9fa4cb9e491bef8b3f03b
|
|
Change-Id: Icda252e1f092707728d3a24df50fba7080e759bb
(cherry picked from commit 1dd1dfc152c7cbeb374fe4f38b08c6af9cef2c06)
|
|
Change-Id: Ia957541a5997961aa86b2eb8537ebd29d3092691
(cherry picked from commit f14e6e06b9e3c82c267649d63512a3538e5ee2f5)
|
|
SwPageDesc no longer contains RES_BACKGROUND but XATTR_FOO.
Change-Id: Ie722b0279f9d9831338f6613a4722010afd1543e
(cherry picked from commit 298e144f8235bb4fe48e204764ec0ba936f3b0c0)
|
|
Regression from 01a32b7d074511bed24044dc94e1159aea62722b (fdo#85179 RTF
filter: import image border, 2014-10-23), there were a number of
problems here:
- CppunitTest_sw_htmlexport: revert back to the old behavior, where in
case there is no border, we don't set the color of it.
- The testcase of the above commit omitted fLine=1 shape property, which
is present in the original bugdoc, and only with that should we put a
border around the shape.
- Let fLine=1 explicitly change the line style from NONE.
- dmapper: if line style is NONE, then don't bother setting the border
color and width.
Change-Id: Iffee41066d42822b699c478821645b9742df3f58
(cherry picked from commit 4568d1d298bf4fc98dcd86384743a04587a2fe6f)
|
|
(cherry picked from commit 9338bea6e8dfab8d360fe8ab19dd5d75071bfc2a)
Conflicts:
sw/qa/extras/uiwriter/uiwriter.cxx
sw/source/core/undo/unbkmk.cxx
Change-Id: I79d8d3c30b6b0b2cc253963fdd50019aec033e12
|
|
Change-Id: I0f3d35a0e64c9ce5646fa63eda317bee42de5540
(cherry picked from commit 4517c94000153eab6c034ea548698953dd93f794)
|
|
Change-Id: Ibc6553c8f529eb7bcd3d97ebd2219c5047c5f9c0
|
|
Change-Id: Ib41921e9ceed30a05e16ace298d9c5dc87cc5458
(cherry picked from commit 3f28f67084f12fd806e05020ed8bac8d5a05c025)
|
|
There were two problems here. First, commit
bbe3627eece0c3486e7ea11f2f13377aaa3a8fed (rtftok: stop sending
sprm:CRgFtc{0,1,2} tokens, 2014-03-05) broke the use-case when the font
encoding is 0, but it's present. Before that commit, we parsed the font
encoding instantly; after that commit we parse it once we have a font
name. If we do that, then we have to have an idea if we have a font
encoding. Given that 0 is a valid encoding, use -1 for the "have no
encoding" case instead.
Second, commit 7839633fb356285652ed96f4bf3f85bcd5b561a4 (fdo#85889
handle pc, pca and mac rtf keywords in writerfilter, 2014-11-24) abused
m_nCurrentEncoding, which is meant to be used within the font table
only. The problem with this is that this way only the first font will
get the encoding, while the spec says it should be used in every context
where there is no other explicit encoding. Fix this by setting the
default encoding for those 3 control words instead -- and consider the
default encoding in getEncoding().
Change-Id: Ia1d71f8ce70f2a53a3770b4840e21362d082e71f
(cherry picked from commit fa15d039e3a553da8500c17190d27169a9477cf2)
|
|
the rtf doc has three bookmark starts but only two matching
bookmark ends.
The tokenizer has three starts 0, 1, 2, but 0 is missing an end. Without the
end of 0, the mapper never inserts an entry for it, so later inserts the start
of rtftok index 1 as mapper index 0, and passing the end for a bare "1" cannot
be found by index. If we pass the name then it finds it by name as mapper index
0 and all is well.
Change-Id: I344db84e4f1c7d55fca59cdfe692080c7d0b8033
(cherry picked from commit 2b54caceab9d975bffa7e24bf732cb877b16632f)
Reviewed-on: https://gerrit.libreoffice.org/13133
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ic54f2233a37562bdc516e440af0b4b7973f56342
(cherry picked from commit 7839633fb356285652ed96f4bf3f85bcd5b561a4)
|
|
Change-Id: Iabff543c8191fc86dceb9274ea1552f60d73dabd
(cherry picked from commit bb77fd64f9219f1b8f990f5041d81cfddd021213)
|
|
Change-Id: I242853d491c2ef83f192486fa6fe5a3407700047
(cherry picked from commit 74249cb6f4f52b7c10ebaa92f943920f6f94aaf4)
|
|
Change-Id: I307af9b8619db00afaef378df60352c06eb1e4c9
(cherry picked from commit 04b3a3c801bc452f659048a816829300d6b2a16f)
|
|
Change-Id: I5a46eb90749965193d2965740d85a1a2eb1ce641
(cherry picked from commit 7171f7920ee2e8d31f51d27eab86305ecf14626e)
|
|
Change-Id: I17ea9518e862b8c97c4c3f4564caedf9d045b7b3
(cherry picked from commit 82e5f287cc278781cdedee0d92fb4ce17cbc42bc)
|
|
SAX interface is not required to provide the whole node content in one
characters() call (e.g. if there's an entity that needs decoding). However
it's easier to consumers to assume this (e.g. writerfilter's
DomainMapper::lcl_utext() handles datecontrol that way), and expat apparently
never used this. However this can happen with libxml2, so ensure such consumers
still work.
Change-Id: Ib564f372fbea8451f84553a6d49a07d091a950e9
|
|
Change-Id: Id95518c7ea38a974593a1880b4ef581ff49bcb90
|
|
Change-Id: I9b6b83f0f6d627bb14a880a19769ee70564cf52b
|
|
Change-Id: I041b497bab9415b2b33d6b4b91f3c58ea9dbc05f
|
|
And also in SwTxtFormatter::NewNumberPortion(), use
SwTxtNode::IsIgnoredCharFmtForNumbering(), via
checkApplyParagraphMarkFormatToNumbering(). Otherwise the color of the
paragraph mark is inherited by the numbering portion, which is not what
IDocumentSettingAccess::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING
(mirroring Word's behavior) is supposed to do.
Change-Id: I5d8df9b404916cc4a4405bf796d971ede59e6111
|
|
Looks like the old code would create a link starting at the beginning in
this case, so let's do the same.
(regression from 94b296d5416dd71d721ad16216b50bce79e3dc04)
Change-Id: Idcd17ae51c478aa5c2a000c7b33a8244f06bd166
|
|
When importing RTF files, the outline is treated
as normal numbering list. Open the tools>chapter, outline
doesn't correspond to heading styles correctly.
This patch is to handle RTF keyword \s in a \listlevel.
The patch use style name as its id so that is consistent
with the one already used by StyleSheetEntry.
Change-Id: I5ab6602b5ce64ca65ec08e0adb34d60ae7293650
Reviewed-on: https://gerrit.libreoffice.org/12960
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I0b941bd7a733408655db192b8608ed3987b9c1fc
|
|
Change-Id: I9fb6e1e33f6b67342c8b407eafc9882ee44f4b46
|
|
Change-Id: Icf3e1013d5eba5702badf19aa6c1f5e6708ed154
|
|
Change-Id: I9ab33513ffb927b02c27fbd6c115b41702751d18
|
|
Commit d72237741ed1d8f976032ff2ee5d2a8702d3380e (abi#9930
DocxAttributeOutput::AddToAttrList: avoid duplicated attributes,
2014-11-02) added a quick fix to avoid writing duplicated attributes,
but the validation problem of duplicated elements remained.
Make sure that when writing paragraph marker properties, then we write
either the hints at the end of the paragraph or the character attributes
range of the paragraph properties, but not both.
The only exception is the character style that's always set as
a hint, as explained in commit 4bb872b1924453f22e90bdd14e2898a3e66d5551
(DOCX export: fix handling of paragraph mark on empty paragraphs,
2014-10-17).
Change-Id: I494e5bb9871aa535532fef32bd344d8093e9f762
|
|
found by PMD
Change-Id: I87780366119c141cd2dafe6ca1bf2d9798b10aec
|
|
Conflicts:
sw/qa/extras/ooxmlimport/ooxmlimport.cxx
Reviewed on:
https://gerrit.libreoffice.org/12519
Change-Id: Ifd8a562bcee4f57cc99ed3215e6d8d6dd95216b0
|
|
Change-Id: I3fc87b89c85bf800bfafccf1c379bc379ebba058
|