Age | Commit message (Collapse) | Author |
|
The problem is that at the end of WW8 import, a delete redline is
inserted that ends up calling DeleteAndJoin from inside
AppendRedline(). A fly is anchored AT_CHAR at (node 46, offset 0)
and the deletion goes from (node 46, offset 0) to
(node 48, offset 13) hence the special case check in
IsDestroyFrameAnchoredAtChar() for the IsInReading() prevents it
from being deleted, and then its anchor is still registered at the
node 46 when it gets deleted.
So try to restrict the WriterfilterHack to writerfilter, so it won't
affect WW8 import.
Unfortunately this is far less obvious than expected, because import can
happen for creating a new file, in which case it's all done via UNO in
writerfilter, or when inserting into an existing file, in which case
SwReader::Read() is used.
The SwDocShell's pMedium can't be used becuse in insert file case it
will be the loaded file, not the inserted file.
There isn't any obvious alternative to adding a silly UNO property for
the writerfilter to use.
Change-Id: Ia7fdc9bb1925202f6692ebee6e4b6b1fe50e5345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90384
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit c4dab726caaa73be9f9c731312080143b0a0b89d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90951
|
|
The OLE objects (in this case charts) had bad wrap option setting
and this lead to misplaced objects. Now this parameter is set
according to the file.
Change-Id: I506be91b6801f0ffc3942e514f81119d895fdcb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88091
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit affe9c8384475fc85027703332bc0f1b36eaa0a6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89908
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
RTFDocumentImpl::dispatchDestination detects the custom footnote
and even sets NS_ooxml::LN_CT_FtnEdnRef_customMarkFollows in the
character attributes of the context, but that is at least not
handled in the DomainMapper later on, so we can't check for
m_pImpl->IsInCustomFootnote() here.
Change-Id: I26c02ea16d0e75ed5bfde0cda9e0c6a2d30261a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89240
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 38306ea92560c82b0d70bdc195267549a8bab830)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89143
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
... and add a comment, so nobody tries to move these again.
Change-Id: I79e6f7a1538d0839fd525870439facef3218ec65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89239
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 70a9c644c63248719f1f4248e288df7ee06635cc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89142
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
caused by incomplete handling of tables with 1-column
rows with merged cells.
Have to check the rows below current to see if they contain
also one cell, therefore form a column, or more than one cell,
in which case do not remove vertical borders.
Regression from commit: 8a2eb40abbd52d960dd21308157186be0ca9dd3d
(tdf#129442 DOCX import: fix right border of 1-column tables).
Change-Id: If9ca7ccd42255e78c61b6271e19262ab5cc8e439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89081
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 111db716c23f9f8450eda58c13dd2423770fd15e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89134
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
in DOCX export of MSO 2003, 2007 and 2010, where ilvl and outlinelvl
settings are missing, based on the settings of the parent styles.
Change-Id: I01d239db505d46a89d7f3b9118ef0b55697bc7fc
CO-Author: Balázs Nádasdy (NISZ)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87328
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89216
Tested-by: Jenkins
|
|
Regression from commit 36ac7749523e0c6f40a77beac278bd9e7a667a9b (DOCX
import: make sure rotation does not affect shape position, 2014-09-24),
the motivation for tweaking the rotation when setting the position of a
shape was for images. By accident, this also happened for group shapes.
But the bugdoc shows it's not a good idea to read the rotation of group
shapes: the group shape is just a container, it does not have rotation
in itself.
(The test120551 intention was probably just to verify that the position
is not entirely off, so the small required change to the expected value
should be OK.)
(cherry picked from commit 9fedce7a261f28dc286943f7bdd2adb010ed9b31)
Conflicts:
writerfilter/CppunitTest_writerfilter_dmapper.mk
Change-Id: I8e12c28e65c5f64168c3f802546fddf472fcc6eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87589
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
There's a compatibilityMode in word/settings.xml in DOCX files:
https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/90138c4d-eb18-4edc-aa6c-dfb799cb1d0d
If a document doesn't contain compatibilityMode, then the default
is 12, but the code for table indent import/export assumed that the
default is 15, so loading an ODF document and exporting as DOCX results
in wrong table indent when loaded in Word.
(regression from 9a31d1c83e08600507689dc18f6f0973bc7e4389)
Change-Id: I3ce32286473640e5b7e12b487aef5f123bfb8d12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88408
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit d978f5d40102a098f1faf1e98aa39ad122284299)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88392
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Regression from e49d2b31fb2020d065b4ad940d1031d07b10f32b (fdo#78939
[DOCX] Hang while opening due to incorrect modification of Style,
2014-06-06), the problem was that the 2nd sub-list of the bugdoc was not
restarted in Writer, while it was in Word.
The PR2 paragraph style inherits from the PR1 one and only that sets the
numId; tweaking the bugdoc to state the numId directly in PR2 would work
around the problem.
Fix the issue by improving DomainMapper_Impl::finishParagraph(), so that
it uses lcl_getListId() rather than calling
pStyleSheetProperties->GetListId() directly; since the previous knows
how to walk up the parent chain if needed.
(cherry picked from commit 63d3ac37865460ff51348a6e792bbacf2f7c4653)
Conflicts:
writerfilter/qa/cppunittests/dmapper/DomainMapper_Impl.cxx
Change-Id: I1c460919b0389d5b053b4ca1c9210279d6cd183c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88426
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
The bug document somehow manages to generated a footnote, which
never terminates the format loop in SwTextFrame::Format_.
It contains an unstyled footnote, which I wasn't able to reproduce
to create in Word. So I manually edited the XML of the included
unit test document, which I used to develop the original patch,
and which reproduces the broken parsing behaviour.
This patch correctly stops the parsing of the custom footnote
reference, if the text run containing the footnote reference is
finished, which also fixes loading the bug document.
The unit test checks various footnote variants, which represent
different problems I found when developing the custom footnote
parsing in commit a991ad93dcd6807d0eacd11a50c2ae43a2cfb882
("tdf#121441 improve DOCX footnote import") and now also includes
an unstyled one.
It also contains a (still?) broken footnote test, with a complex
differing footnote.
Change-Id: I748955285d76b6f3122d1da5d8823068f3d7633f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87981
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 7d886eec953efa593708db9560d0e69ac12c99cf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87993
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit 213d6390a2cc59d174173f4359c161625a9c4bdc (tdf#108272
DOCX table-only header: fix SAX parser error, 2020-02-03), except its
testcase and replaces it with a better fix that does not import all
floating-table-in-header as non-floating tables.
See the new testcase, which is 1 pages in Word, it was 3 pages in
Writer, and with the better fix it's now 1 pages in Writer as well.
Change-Id: Ica3500120f12222d7cf766d55c17d78164865026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88037
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88098
|
|
Floating tables in table-only headers are imported
as non-floating ones after a SAX parser error. Now
we import them as non-floating ones from the beginning
to avoid of the parser error.
Change-Id: I0a816a7af642f402a25ed53d9766b1e8b82db789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87874
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 213d6390a2cc59d174173f4359c161625a9c4bdc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88097
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
There seems to be fields with content values, which don't use it
as the presentation value. So this reverts the content handling
code back to the original one and just checks the content value
from Input fields in addition to the SetExpression fields.
Change-Id: I2abd227883035c559b1fc3f7aacf10769b0e79a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87093
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 3a248dfe57318af57fc5df89652cb64dfa923e46)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87740
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Since tdf#121441 we parse custom footnotes to get at least the
DOCX footnote text, even if we can't represent the formating. This
might push additional contexts to the parser stack. Therefore it's
now not sufficient to check the current context for a footnote,
but one has to check the global parser for a footnote context.
The actual bug is the unsupported footnote page break, which was
not correctly ignored and added a paragraph context to the stack,
resulting in the async substream input and output stack size.
Change-Id: I143254e7df37a619cb4efb542b58d3eff3afffa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87114
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit b87af9775167002d36a3bc16cb308ea7895d7ea0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87742
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Obviously the real error is somewhere else, which results in tdf#126435,
and produces unexpected state with missing text append context on stack.
This is just a hack to avoid crash.
Change-Id: I420ac3b74f5efb9688dc764ac2ad0dcc974ba0e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87595
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit eca00082c78fddf79f247057227404738be8806c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87634
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Bottom border of a vertically merged column of a table was missing
if the inside borders were turned off and the merge included the
last cell of the column. This happened because the first cell
(topmost) in a set of vertically merged cells determines the borders
of the new merged cell, and the turned off inside borders were at
the bottom in this case.
Change-Id: I3d3defad18a1315117a554a36ad599eb46daffe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85988
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 0f4dd820ee433932d9d9237b676292d31c4ba913)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86430
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
(VML) and layoutInCell (DrawingML) attributes to fix
regressions caused by commit 10f29d8bf05d44ca8bc11d34d1294ec17f8ac0f1
(tdf#87569 tdf#109411 DOCX import: fix shape anchor in tables).
Position of shapes anchored to tables is calculated from
the cell margin only if the previous attributes allow that.
Change-Id: Ifcfcb7f4959aea522dd45dff00cefd1bb9f4edda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86922
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Signed-off-by: xisco <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86980
Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu>
|
|
The bugdoc contains nested fields for some of the page numbers:
{\field\flddirty{\*\fldinst {\caps0\lang1024 GOTOBUTTON _Toc434317064 }{\field{\*\fldinst {\caps0\lang1024 PAGEREF _Toc434317064 }}{\fldrslt {\caps0\lang1024 4}}}}}
The problem is that the outer field does not have a \fldrslt, only the
inner PAGEREF field has one.
This used to be imported incorrectly because the nested field's result
ended up in the outer field's result; now it's imported correctly but
then there's no field result to show, because Writer can't expand
fieldmarks.
As we can't do anything with a GOTOBUTTON field, just ignore it
explicitly to prevent creating a generic fieldmark; the PAGEREF is
already ignored inside of a ToX since commit
9679e9c23216decb5f9f25f85b04cb3f25211111.
("regression" from e511a0ca5dde6d731bb126bbfe21768867890102..d9030ad6298e2f49ee63489d6158ea6ad23c0111)
Change-Id: I8135c8d14995378181ce959d22d9be5ea0cae260
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86796
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit f761059b8c8ffe4e7b6e28924898ba71ee6b9ea8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86832
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The problem was that the end of the outer nested generic field did not
call PopFieldmark(), so the end of the field was at the end of the
document.
(regression from f610f9b611fe9f206b872ed06f7e859d688385fc)
Change-Id: If5928b14dd35f7dd509370c2b8eef4c31bd149dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86785
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit cf226535f9903a048b1c105b180ae3a50a776e68)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86797
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Embedded graphic objects had got 0 values for vertical and horizontal
positioning before, resulting overlapping, hidden charts,
but now they are positioned according to the values in the document.
Change-Id: Ia5403ac65ff7192d61072e8a9d8a7f80c7178b9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86521
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit d9c535ead688e9f156dbcf43948df08a69e218be)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86536
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
ToC, bibliography, and index sections import code changed to closely
follow what Word does, make sure that pre-rendered entries don't get
imported as standalone paragraphs outside of the index sections, and
paragraph count is accurate (no missing or added paragraphs as much
as possible).
In Word, an index may start and end in the middle of a paragraph:
<w:p>
<w:r>
<w:t>Some text before index</w:t>
</w:r>
<w:r>
<w:fldChar w:fldCharType="begin"/>
</w:r>
<w:r>
<w:instrText> TOC ...</w:instrText>
</w:r>
<w:r>
<w:fldChar w:fldCharType="separate"/>
</w:r>
<w:r>
<w:t>First pre-rendered index entry</w:t>
</w:r>
</w:p>
...
<w:p>
<w:r>
<w:t>Last pre-rendered index entry</w:t>
</w:r>
<w:r>
<w:fldChar w:fldCharType="end"/>
</w:r>
<w:r>
<w:t>Some text after index</w:t>
</w:r>
</w:p>
However, normally it looks like either no runs precedig index, or no
runs of pre-rendered contents will be present. When no Std elements
are used, the typical situation is that there's a normal paragraph
(possibly with some user text), which ends with index start marker,
without any pre-rendered contents in the same paragraph; and all pre-
rendered contents goes in following paragraphs. Such index normally
ends with index end marker in the *first* run of a paragraph, which
then might have normal text runs.
When Stds are used, then no leading/trailing out-of-index runs in
paragraphs with marks are usually present; and in this case, when
paragraphs with index marks don't contain pre-rendered entries, they
still are treated as part of the index.
In Writer, indexes are node sections (and so cannot be inline with
other paragraph contents). When there was some paragraph content
already before the start-of-index mark, the paragraph is assumed
to end before the index; in this case, when current <w:p> element
ends, importer decides if a separate starting paragraph is needed
or not, depending on if there was some runs after the mark. When
there was no text runs before the starting mark, then the paragraph
is treated as leading paragraph of the index. This allows to not
miss empty paragraphs before index; and not have two paragraphs
where there was one in Word. Only in cases when user had manually
typed text both in and outside of the index in the same paragraph
in Word, we would have the paragraph split into two in Writer.
For end marks, the behaviour depends on whether it's inside Std.
When inside, the ending paragraph starting with index end mark is
considered part of the index. For out-of-Std case, it's considered
normal paragraph (and measures are taken to make sure it's not
dropped even if empty, because sometimes such paragraphs don't
have other content, and have section settings, which is usually
treated by Writer as "drop this paragraph" sign).
A special problem is multi-column index. It's wrapped into a
continuous section by Word; and in Writer, we also wrap it into
a section. It would be possibly useful to detect somehow if this
section is part of index definition, and in this case, drop the
section and put its properties into the Writer's index section.
That would avoid an explicit section in the imported document.
This is TODO, for someone who figures how to detect reliably if
the section belongs to index definition. See comment in
DomainMapper_Impl::appendTextSectionAfter. By the way, current
export code is wrong, producing an index that is single-column
in Word; this change doesn't touch that.
Several existing tests needed to be fixed, which used to test
wrong results.
Reviewed-on: https://gerrit.libreoffice.org/85089
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 5cdb14345842c07eb1a466897753da910e9488f8)
Change-Id: I9597c8ab13f31ded9abcc24054d3478d3e3a3b40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85289
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
... except for processing enough to observe the separator exists.
For each footnote reference, the entire footnote.xml file is
parsed every time. The text in the "separator" footnote was
being added to every footnote. The normal case where this is just
a single paragraph was already handled, but this patch generalizes
everything to handle cases of actual text or multiple paragraphs.
Not every footnote has a type, so we can't depend on that to turn
ignoringText ON/OFF. Every footnote has an ID, but theoretically
the ID could be processed before or after the type, and it has
no idea which type it is. Finally, the skipped text has no idea
how many times/paragaphs it needs to skip. So a three-way
control was needed to handle on/used/off. As a safeguard, finishing
the footnote.xml parse (PopFootOrEndnote) ensures that
ignoring won't be left on in the unlikely case that
the separator is the last footnote.
Change-Id: Ia30ca8d3a36417a4691e3b2e1c978720be017030
Reviewed-on: https://gerrit.libreoffice.org/82172
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit acb9d901009d026cb48e6a8b94e6200f05110504)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85734
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Bottom border was missing in a 1-row table with disabled
inside borders. This happened because LO applied the empty
horizontal borders to the bottom border of the table.
Change-Id: I40140bf63297189edad13088f98fc5f869969c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85303
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 6b1bd2699b0bdad6dc42db741dea0717cf7c1d36)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86397
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
It was introduced in commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4
"avoid sending duplicated paragraph flags", and supposedly was meant
to avoid having duplicating sprms in the collected properties, when
new properties were pushed back at that time. Using specific sprm id
was likely a mistake (nParam should have been used instead).
Now the new sprm is added using RTFSprms::set with eOverwrite having
default value of RTFOverwrite::YES, which takes care to avoid dupes,
so the call to erase is redundant.
This reverts commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4.
Change-Id: Ied19f6feb41bd17ef317812d4d295ca0542a5843
Reviewed-on: https://gerrit.libreoffice.org/85602
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 989043b0644354b92fd17e4194897c2eb0935031)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85742
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Right border was missing in a 1-column table with disabled
inside borders. This happened because LO applied the empty
vertical borders to the right border of the table.
Change-Id: Ib190689bf5059bfd7dbf07b07808cd761015f37e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85301
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 8a2eb40abbd52d960dd21308157186be0ca9dd3d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86261
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
and in last row of tables, i.e. regressions caused
by the following commit.
This reverts commit b2c6d2d961a6113d0f111fab45ae12a40d389a23
(fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After),
except some unit testing.
Change-Id: Icb2d65b7a0766cf8dd00511cde500af3f94d2a94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86125
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86211
Tested-by: Jenkins
|
|
Reading the spec, "nil" is the opposite of "clear": i.e. if the
(background) color is red and the fill (color) is green, then "clear"
means green. And you would expect "nil" means red, but it's just nothing
in Word.
Fix the problem by doing the same: don't set any paragraph property for
the "nil" case and keep doing it for the common "clear" case.
(cherry picked from commit fbe7612d654be9dfe1ea6f2e67900eb4eec4202a)
Change-Id: I30af8a7fb55fb9bab2d12e120069a479fc7ab0a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86098
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
The interesting part of the bugdoc was:
- table style wants visible borders
- table direct formatting clears left and right borders
- 1st row of the table has 1 cell (2 cells in fact, but they are
merged)
Fix the "inside" vertical border handling, so that the first cell gets
these vertical borders as a right border only in case there are multiple
cells.
(cherry picked from commit fd92740a86ab8e71e77d947d1d7dabc51a8d0794)
Change-Id: Id847109ecfa95d1745abe62ddf36c4936b730855
Reviewed-on: https://gerrit.libreoffice.org/85574
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The "CONTROL Forms.CheckBox.1" field has a shape as its result.
Previously this was imported as an unknown generic field by writerfilter
and exported as a CONTROL field followed by a SHAPE field; the CONTROL
field was discarded by Writer on a subsequent import.
Now this is exported as nested fields to WW8, i.e., SHAPE inside the
result of CONTROL, which is an improvement.
Unfortunately the WW8 import discards the result of the CONTROL field,
because its field code is written as ww::eUNKNOWN = 1, not
ww::eCONTROL = 87.
To fix that, set the ODF_ID_PARAM parameter in writerfilter for these
fields, which is checked in MSWordExportBase::OutputTextNode().
This reveals that the field code was set wrongly on the fieldmark too,
it should be set as a ODF_CODE_PARAM parameter and not as the type.
Furthermore the WW8 import needs to allow nested fields in the eCONTROL
field.
Change-Id: If79a186ea30c3b4a933ba1d8325111215250b833
Reviewed-on: https://gerrit.libreoffice.org/85418
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 27b6c82b79f4af2ab16d53de3b2065df0acebdb8)
Reviewed-on: https://gerrit.libreoffice.org/85527
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Import "relative from page" horizontal setting of
VML and DrawingML shapes as "relative from column"
in tables, just as MSO handles it.
Change-Id: If71f2e52bbba324a98651e701feaeb99acfefc48
Reviewed-on: https://gerrit.libreoffice.org/85141
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/85572
|
|
... on the last node of the previous section.
This works for this particular document, but it's quite dubious that it
will work in the general case; feel free to revert this if it causes
problems.
Change-Id: Ia03d41a1127df505c4e9da7131323b70d88a285f
Reviewed-on: https://gerrit.libreoffice.org/85294
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 3f680aef65a158cfbc98c8afd1c3628d7f4f7b83)
Reviewed-on: https://gerrit.libreoffice.org/85304
|
|
always replace break with follow-page-style, not first-page-style.
It looks like Word ignores <w:titlePg> on continuous section breaks,
unless it's the first section, which was already handled by code above.
Change-Id: If7c0fe96a1789f64f1943ece453db3dbc284ca48
Reviewed-on: https://gerrit.libreoffice.org/85293
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit d7e9daf2d21d3bcafaa6aae4aed6c9df5e0999c4)
Reviewed-on: https://gerrit.libreoffice.org/85300
|
|
There are several problems here:
* CloseSectionGroup() is not only called for actual sections in the
document but also at the end of every special text like comment,
footnote, etc; only actual sections can set page styles. Writer
comments use editengine so cannot even contain sections.
* With continous section breaks, headers and footers are inherited from
the previous section unless defined by the current section;
SwXText::copyText() did not copy the content of the header on page 4
to page 5 correctly because it used an SwXTextCursor to create the
selection, which cannot select the table at the start of the header.
* For continuous section breaks, WW8 import filter has a heuristic to
find the first page break in the section and set the PageDescName
property on that node to apply the page style with the headers of the
new section; do something similar in writerfilter
SectionPropertyMap::CloseSectionGroup()
Change-Id: I3ebe3d299f83197cbf8f10de46c34de98677626c
Reviewed-on: https://gerrit.libreoffice.org/85213
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 08f13ab85b5c65b5dc8adfa15918fb3e426fcc3c)
Reviewed-on: https://gerrit.libreoffice.org/85268
|
|
Had to check an additional criteria before removing
inside borders.
Change-Id: I0828d973bd331e65ebabc1fe2e2f25f1bcaf58b0
Reviewed-on: https://gerrit.libreoffice.org/84676
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit dff3ae42d94fdf97c856c4a4d1e66234604927f4)
Reviewed-on: https://gerrit.libreoffice.org/85199
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144 (tdf#115719 DOCX import:
increase paragraph spacing for anchored objects, 2018-02-14) added an
import-time tweak for a problem that has been confirmed to be a Word
layout bug in the meantime (and the tweak makes Writer behave the same
way if the document has been created by an affected Word version for
layout compatiblity).
Later, commit 4883da6fd25e4645a3b30cb58212a2f666dae75a (Related:
tdf#124600 DOCX import: ignore left wrap on left-aligned shapes,
2018-02-14) fixed left spacing of anchored objects aligned to the left,
to be in sync with what the DOC import does.
This broke the previous fix in case the shapes are left-aligned.
Fix the problem by tracking what is the in-file-format and logical left
margin, so the final doc model has the value necessary for correct
horizontal positioning and the importer has the value that's necessary
for correct vertical positioning.
(cherry picked from commit 814cb2433da6bd608e935fa5531d2a2b92867985)
Change-Id: I8f16cbe7bad40e243111c902bdc1ab0e8141d6b9
Reviewed-on: https://gerrit.libreoffice.org/85207
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
without serious regressions, ie. losing the import of complex
forms with multiple or nested tables.
Complete the fix for tdf#116194 (DOCX import: fix missing
tables with w:gridBefore) with handling gridAfter on
DomainMapper level.
This consists of also rejections (except their unit tests) of
commit cf33af732ed0d3d553bb74636e3b14c55d44c153
(handle w:gridBefore by faking cells (fdo#38414)) and
commit 1d1748d143ab4270a2ca1b5117852b1b1bb4c526 (Related:
tdf#44986 DOCX import: handle w:gridAfter by faking cells)
Change-Id: I31fa1de03bcdf42424fa5507fb5a3e06aa47107d
Reviewed-on: https://gerrit.libreoffice.org/84517
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit b2c6d2d961a6113d0f111fab45ae12a40d389a23)
Reviewed-on: https://gerrit.libreoffice.org/84724
|
|
Regression from the commit cf33af732ed0d3d553bb74636e3b14c55d44c153
"handle w:gridBefore by faking cells (fdo#38414)"
This patch replaces the previous fix with a better solution,
fixing tdf#38414 on the proposed DomainMapper level. (Note:
to reject the old fix completely, its follow-up commit w:gridAfter
will be handled in a similar way.)
Now the related regressions, tdf#111679, tdf#120512 and the complex
forms of tdf#116194, tdf120256 and tdf#122608 are fixed, too.
Change-Id: Id25f5fb4d9021c87ee8c82782b2038e6fb255673
Reviewed-on: https://gerrit.libreoffice.org/84263
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit da1f71edfc72928b07a569b98e2766a8a7de9d2a)
Reviewed-on: https://gerrit.libreoffice.org/84711
Tested-by: Jenkins
|
|
* Add checkbox to pagraph dialog
* Store property in paragraph model
* Move docx import/export from grabbag to paragraph model
* Add ODF import/export
* Add ODF unit test
* Add layout test
Change-Id: Id4e7c5a0ad145c042f862995d227c31ae2aa0abd
Reviewed-on: https://gerrit.libreoffice.org/83979
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 72bd0df107ee47c4d54fa88b4960d32ea03e9f69)
Reviewed-on: https://gerrit.libreoffice.org/84620
|
|
... at least in the view.
This "fixes" the import side of the exported OOXML document with
multiple overridden numrule character format. This prevents the
change of the shared numrule, which results in all bullets being
formatted like the last overridden numrule.
What is missing is a consistent way to edit the override, as the
override is currently just stored in an internal attribute, the
"ListAutoFormat" property.
Fixing editing for good will be a larger work, as "ListAutoFormat"
must be reflected in the GUI and must have a higher priority then
the numrule format. Currently positioning the curser in front of
the number or bullet entry lets one change the numrule format,
which is applied to all bullets of the same rule.
This special DOCX override mode is enabled by the import filter
setting DocumentSettingId::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING
to true. This should also change the edit mode, so that a change
of the entry doesn't modify the rule, but the override and this
must also be reflected in the GUI character settings.
Change-Id: I057f7a354bc3c413b114eec772e06c7063029699
Reviewed-on: https://gerrit.libreoffice.org/81878
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 6ed12ab2d0742f86ce25defec3c776562dbfad9a)
Reviewed-on: https://gerrit.libreoffice.org/84624
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
The Word 6.0 (Japanese) compatibility option
\dntblnsbdb switches off the balancing of SBCS/DBCS
characters, including the longer space sequences.
Note: using \dntblnsbdb, it will be possible to
set normal (short) space sequences in RTF export, too,
to avoid broken document layout during RTF round-trip.
Fix regression from commit 24b04db5a63b57a74e58a7616091437ad68548ac
(tdf#123703 RTF import: fix length of space character sequence).
Change-Id: I5ade9e0a2db0bde204d1debe831058045fd8f586
Reviewed-on: https://gerrit.libreoffice.org/84397
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit cd7241e3d2892c2a115265f842f464d017d7c7e1)
Reviewed-on: https://gerrit.libreoffice.org/84414
Tested-by: Jenkins
|
|
UI uses SdrEditView::MirrorMarkedObjVertical() to flip a line shape
vertically, handle it similarly at import time as well.
Also note that this flips in-place, while the naive '*= -1' for the
height would have an incorrect vertical position.
(cherry picked from commit f9f421b7beaf117968c0dbfd84a2dad3dc85136a)
Change-Id: I42b7feb5f799b99337ddec734dcf98dd1d553755
Reviewed-on: https://gerrit.libreoffice.org/84209
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
which is a favorite input document for crashes and assert apparently,
this is the third time it has triggered a different problem
this one is new since...
commit 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Sat Nov 16 16:34:25 2019 +0300
Also consider saved exceptions when terminating parse
Change-Id: I394b650613e8a835fe8a9f216a48864bdbc5065b
Reviewed-on: https://gerrit.libreoffice.org/83925
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
when they have (sometimes incorrect) fixed cell widths.
Change-Id: I98bf37bfce72b84eed14e354520e4741ae2ddada
Reviewed-on: https://gerrit.libreoffice.org/83787
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 001e11c8f4a52a2eb308562bdee8516efb77b96b)
Reviewed-on: https://gerrit.libreoffice.org/83851
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
downgrade to warning instead of assert as per
https://lists.freedesktop.org/archives/libreoffice/2019-November/083836.html
Change-Id: If561930ca9733899cf0f4e3a6d8bb6609c94fc1d
Reviewed-on: https://gerrit.libreoffice.org/83486
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8a7efffb2866e46e978d09ca9fb5c9dec231e132
Reviewed-on: https://gerrit.libreoffice.org/83384
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
(cherry picked from commit 3185ce226447fb04c530af76f799fed86672f99c)
Reviewed-on: https://gerrit.libreoffice.org/83397
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
in table cells, ie. using paragraph styles with bottom
margin setting or direct paragraph formatting of bottom
margin. Both of them overwrite the table style based
bottom margin.
Change-Id: I527b16c24fe47df8412291089ff86fadd3f9430b
Reviewed-on: https://gerrit.libreoffice.org/82800
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 6100909c84550036932d031f4d2f652e158a1a0a)
Reviewed-on: https://gerrit.libreoffice.org/83154
Tested-by: Jenkins
|
|
Extra cell borders appeared on the bottom, top, left or right
of the 1-cell tables when only the "inside borders" option was selected.
The extra borders were the ones that would normally have appeared as
inside borders if there were more than one cells in the table.
Change-Id: I05d5f2a5a0168989f220d20a95b6dacf5152f9f7
Reviewed-on: https://gerrit.libreoffice.org/82675
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 8a59f18b6eb22c43ec10cdc29ba5a13d5feba4f0)
Reviewed-on: https://gerrit.libreoffice.org/83303
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Without that, simple text shapes inside groups were written in
<pic:wsp> elements, with many child elements also having pic::
prefix.
Change-Id: I114cf3499e03aa5ca042211d7b134aaf5b0e7fbf
Reviewed-on: https://gerrit.libreoffice.org/82980
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Also consider saved exceptions when terminating parse
As with previous commit 18ae77a065cb8ae6940d4067f6ab7e99a3f74047, this
will start showing parse errors on invalid files which previously just
opened without warnings, silently losing the invalid stream part. Any
bug bisected to this commit is not a regression from this commit! The
real problem was already before, and was just disclosed by this (which
is the actual goal).
Also simplify unit test data for tdf#128820, which will now be enough
after the change.
A unit test (testN779627) revealed unexpected throws when parsing; this
was fixed.
Change-Id: I5a21b9001874ec6e3b8273c10043ef930bf1cc82
Reviewed-on: https://gerrit.libreoffice.org/82981
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
tdf#128820: improve unit test to not depend on opening bad file failing
... also test exported XML directly
Change-Id: I50237593dd111e7c7974452769c8d49c22012713
Reviewed-on: https://gerrit.libreoffice.org/83005
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Fix UBSan build after 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2
The said commit simplified a testdoc to testTdf128820, using a smallest
possible SVG in it. This seems to produce the smallest possible PNG of
size 8, which is passed into GraphicDescriptor::ImpDetectPNG. There its
size is read into nTemp32 past the end of the file without checks,
which keeps last value of the variable (which was the magic number
0x0d0a1a0a), which is then saved into the descriptor. Then that value
is used in ImpGraphic::ImplGetSizePixel, and later multiplying it in
lclConvertScreenPixelToHmm causes UB.
Fix by checking all the reads in GraphicDescriptor::ImpDetectPNG.
Change-Id: Ib4740fac2b87fbef57d5150151129b9852f3ecb8
Reviewed-on: https://gerrit.libreoffice.org/83119
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/83296
|
|
Revert of commit 17e904ed66c3caf87e658b9d3a18d7b13f4a0b52
("bnc#816593 DOCX filter: import paragraph spacing from table style),
keeping only the working unit test.
Change-Id: I735744aadb071ef2f0d939cb637d83cfc5716fe4
Reviewed-on: https://gerrit.libreoffice.org/82776
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 00eeb7b3f765a51f51f7911a116982fbfb83efb7)
Reviewed-on: https://gerrit.libreoffice.org/83098
|
|
When direct formatting of a table paragraph set only top margin,
but not the bottom margin, also there was no paragraph style setting
for the bottom margin, the paragraph was imported using docDefault
bottom spacing instead of the table style bottom spacing.
Change-Id: Ib7f5f80dd2485a0fd4ab8e0645b7d730a7ec3c5c
Reviewed-on: https://gerrit.libreoffice.org/82771
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit d8f3f8ecd9e6304f3a98ab03fae6bc545893f782)
Reviewed-on: https://gerrit.libreoffice.org/82789
|