Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I37b4b5ec56f846b5c46faeaa5aebb88340ac3c6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161385
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Imports \binfsxn and \binsxn from RTF and
w:paperSrc from docx files and applies paper tray to the page style
if the printer supports the imported tray value.
Works only on Windows.
Change-Id: Ie1170c58f7114f0dbf6bdd2721d4e077886cbe16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162236
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
I thought I had removed all fallback stuff from the unit tests,
but I was wrong. So do some general clean-up and simplification.
I also needed to fix the maximum value for relativeHeight.
Sadly, even my my unit test was wrong - since MS Word 2010 clearly
showed the yellow star on the top for tdf159158_zOrder_max.docx. FIXED.
I can't put my finger on why sometimes 0F00 0000 is a maximum...
More testing suggests that generally the max is 01dff ffff.
Again, this is based on testing
since documentation makes no reference at all to a maximum.
I also wonder if the last 10 bits aren't magical somehow...
The previous max didn't sound right because
there are so many unit tests with relativeHeights above 0F00 0000
(and the values jump by 0400).
RTF almost never uses GraphicImport, and no unit tests
access relativeHeight, only behindDoc. It is used for
IMPORT_AS_DETECTED_INLINE and passing arbitrary
property-names and values to a shape (via \sp \sv).
Thus, this change is DOCX only (effectively).
Change-Id: I18c0e129a078abe5987b998b15697f4ae1a50a96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162232
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Commit 73bd937420b9a99e1e35950e3f9dcbcfd874876d (n#780853 fix DOCX
import of w:sdtContent in table cell, 2012-09-25) had introduced a
restriction, where a framePr was ignored, when inside an sdt. It
was required to allow table import, which broke otherwise.
Since then, the situation has obviously changed; the test case for
the change, added in commit 7ea71eb8a28c4b41949299ff7d4b391486c90eea
(n#780853 testcase, 2012-09-25) passes after removal of the check.
This check disallows importing sdt in frame. This makes the bugdoc
of tdf#159259 to import the sdt in frame. The Lorem Ipsum paragraph
is still enclosed into the sdt - to be fixed in a follow-up.
Change-Id: I60fbb2dd6f753682217d86e4f8d315f1883c6e83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162258
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... trailing \par.
Commit a6ae84cc296d4d28e9a48a57406e955138c87a80 (tdf#70318: Prevent
extra empty paragraph in clipboard RTF content, 2015-11-10) made sure
to not emit trailing \par for RTF clipboard content. The problem was,
that in the absense of the \par, the settings of the last paragraph
were not applied (this happens in DomainMapper_Impl::finishParagraph).
This change makes sure to call dispatchSymbol(RTFKeyword::PAR)
(which eventually calls the mentioned method and applies pending para
properties). Since this also adds a new paragraph (which needs to be
avoided), a new flag is introduced, set by Stream::markLastParagraph.
Its purpose is to make sure that all properties are applied to para,
as opposed to bRemove argument to DomainMapper::finishParagraph, which
prevents setting some properties (e.g., related to numbering - see
DomainMapper::lcl_utext).
Change-Id: Ia5e368e540c30f95058c81a280a62205aa85398b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162154
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I352ca1bfee42b3dfe49401a4c75fbbb2140d28da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160204
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Apparently 0 and 1 are the highest zOrders, 2 is the lowest, then 3...
At least, this seems to be true for relativeHeight.
Of course the documentation doesn't say anything about this,
but documents conclusively prove a maximum zOrder of 251,658,240.
[When MS Word 2019 round-trips a file with a relativeHeight of 0/1,
it replaces them with the highest relativeHeight in the document,
but values of 2+ are preserved.]
Notice that there are two things that feed into zOrder,
the other being z-index where negatives have special meaning
in this context, but no special meaning for 0 or 1.
Interestingly, relativeHeight is unsigned, but z-index is signed.
This ends up not being a problem with a maximum of 0F00 0000.
GOOD! LO normally exports starting from 2, but writes 0 if no zOrder.
// It seems 0 and 1 have special meaning:
// just start counting from 2 to avoid issues with that.
Proof case that 0 is higher than both 300 and 225,763,766
make CppunitTest_sw_ooxmlexport8 CPPUNIT_TEST_NAME=testN747461
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0equalA
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0equalB
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0max
Change-Id: I3540252ca5b0be3b2d847f1a3885adb850f39c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162038
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Revert the previous solution and replace it with this simpler one.
This version of the patch is riskier, but from what I can see
last one always wins for GraphicImport.
I assume that Miklos just limited it to a certain situation
as a sanity check to try to avoid causing regressions
outside of the scope he was working on.
The fact that all DOCX and RTF unit tests pass is a good sign.
The only way I would expect this to cause problems is
if z-index somehow can come into play with a GraphicImport
(since both z-index and relativeHeight feed into zOrder).
However, an assert didn't turn up any instances where
applyZOrder was called without a relativeHeight being set.
assert(m_rDomainMapper.IsRTFImport() || bOldStyle || UsedRelativeHeight);
Change-Id: I28e8acd5997eed0e82d5853c85b672c62b21afe5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162036
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
[When MS Word 2019 round-trips a file with a duplicate relativeHeight
it replaces them with unique relativeHeights in the export.]
My THEORY is that bOldStyle should always be true for GraphicImport,
so a follow-up commit will basically revert all of this,
but at least if my theory is wrong, I'll still have fixed this problem.
Notice that there are two things that feed into zOrder,
the other being z-Index. I assume the very explicit code that says
that (except for bOldStyle) first one wins must be the standard for z-Index.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf159158_zOrder_duplicate
Change-Id: I842d016a7922427ce1290a7134d4e19fed52880f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161989
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and
cid#1546319 COPY_INSTEAD_OF_MOVE
cid#1546286 COPY_INSTEAD_OF_MOVE
cid#1546283 COPY_INSTEAD_OF_MOVE
cid#1546191 COPY_INSTEAD_OF_MOVE
cid#1545953 COPY_INSTEAD_OF_MOVE
cid#1545874 COPY_INSTEAD_OF_MOVE
cid#1545857 COPY_INSTEAD_OF_MOVE
cid#1545781 COPY_INSTEAD_OF_MOVE
cid#1545765 COPY_INSTEAD_OF_MOVE
cid#1545546 COPY_INSTEAD_OF_MOVE
cid#1545338 COPY_INSTEAD_OF_MOVE
cid#1545190 COPY_INSTEAD_OF_MOVE
cid#1545272 COPY_INSTEAD_OF_MOVE
cid#1545242 COPY_INSTEAD_OF_MOVE
cid#1545229 COPY_INSTEAD_OF_MOVE
Change-Id: I88813d9dbd87ce10375db8198028f8b70e23f0fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162027
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This is an IMAGE followup to vmiklos' shape/textbox fix in
LO 7.2 commit 2f21e4f357ec60450df84ddd858c3cf0a4711b02
Images follow a different code path, but needed the same treatment.
Change-Id: I974944c7fbb4e0fa6aa52ac239c6a16ec7f927e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161986
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Commit f09420fa189be5165b0311083ba127073500a121 (tdf#158855: Make sure
to not add extra paragraph after a table in a section, 2023-12-25) had
implemented copying all attributes of a paragraph using copyAllProps.
But the function didn't check the states of properties, so copied also
default values of properties, making them direct properties of the
paragraph. Due to tdf#158972, that caused an assertion when saving,
and the main problem was a set of direct properties in the paragraph.
Fix that by checking the properties states. Also make sure to work with
paragraphs, rather than with ranges, which treats any properties set on
paragraph level as default-state on the run level.
Change-Id: I7cd9c7fbb9313d666c46be201913f0223a6b4f5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161539
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I1da86b0be73713b506044c969930912b58b4d514
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161435
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and try something a bit more generic
Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ic09353c1c99265c789edb745044b0afe7dffbee6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161404
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ie63bad4bd2ab19ed1557ffc8648500c1183692e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160203
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Certain numerical comments in GraphicImport contained
debugging information that is no longer relevant to the
current code. These have been removed.
Change-Id: I931cd8dae6d1e449211d78eedd5422994b8c4423
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161232
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Simplify the condition for last paragraph removal in lcl_utext, and clean up
the complications piled after commit 2e8aad6d45c53d554ccaf26de998ede708cfc289
(fdo#39056 fdo#75431 Section Properties if section starts with table,
2014-04-24). This makes sure that the trailing extra paragraph gets properly
removed, even when there was a dummy paragraph added for a table in section.
Because of the removed check, import used to avoid the removal of the extra
paragraph immediately following a table (when the table needed to be the last
element in the section); hence, in DomainMapper_Impl::appendTextSectionAfter,
a last section's table was followed by two paragraphs (one that is expected
to stay after the created section, and one before that, that was not removed
after the table). xCursor had ininitally both paragraphs in the selection
after the forward goto* calls; and then, gotoLeft excluded only the last
paragraph from the selection. After the change, in such a case, there is only
one paragraph in the end: the one that should stay after the created section.
But calling gotoLeft then would have to put the end of selection to a text
node inside the table; since the selection that starts before the table can't
end inside the table, the call resulted in the whole table excluded from the
selection. This requires to add a paragraph here, to allow the previous
behavior of cursor; and then the last paragraph in section is destroyed. The
code makes sure that the trailing paragraph kept after the creation of the
section has all the properties applied to the old last paragraph.
testFdo53985 used to check for total 9 paragraphs in the document; while
3 of those were introduced exactly by the bug fixed here; they are absent
in Word. The test is fixed; its logic is unchanged, and it still correctly
tests that a round-trip doesn't increase number of paragraphs.
Change-Id: Ibf6349ba7906dac185c759eb3b58c1849ee5064a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161275
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and
cid#1545999 COPY_INSTEAD_OF_MOVE
cid#1545995 COPY_INSTEAD_OF_MOVE
cid#1545994 COPY_INSTEAD_OF_MOVE
cid#1545989 COPY_INSTEAD_OF_MOVE
cid#1545982 COPY_INSTEAD_OF_MOVE
cid#1545977 COPY_INSTEAD_OF_MOVE
cid#1545970 COPY_INSTEAD_OF_MOVE
cid#1545856 COPY_INSTEAD_OF_MOVE
cid#1545845 COPY_INSTEAD_OF_MOVE
cid#1545838 COPY_INSTEAD_OF_MOVE
cid#1545776 COPY_INSTEAD_OF_MOVE
cid#1545774 COPY_INSTEAD_OF_MOVE
cid#1545744 COPY_INSTEAD_OF_MOVE
cid#1545719 COPY_INSTEAD_OF_MOVE
cid#1545716 COPY_INSTEAD_OF_MOVE
cid#1545687 COPY_INSTEAD_OF_MOVE
cid#1545648 COPY_INSTEAD_OF_MOVE
cid#1545643 COPY_INSTEAD_OF_MOVE
cid#1545641 COPY_INSTEAD_OF_MOVE
cid#1545604 COPY_INSTEAD_OF_MOVE
cid#1545531 COPY_INSTEAD_OF_MOVE
cid#1545530 COPY_INSTEAD_OF_MOVE
cid#1545524 COPY_INSTEAD_OF_MOVE
cid#1545516 COPY_INSTEAD_OF_MOVE
cid#1545501 COPY_INSTEAD_OF_MOVE
cid#1545486 COPY_INSTEAD_OF_MOVE
Change-Id: Idcf3e27bb9e81b6a77d5ef75c9376eb1d6aff8c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161245
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546492 COPY_INSTEAD_OF_MOVE
cid#1546468 COPY_INSTEAD_OF_MOVE
cid#1546431 COPY_INSTEAD_OF_MOVE
cid#1546382 COPY_INSTEAD_OF_MOVE
cid#1546350 COPY_INSTEAD_OF_MOVE
cid#1546336 COPY_INSTEAD_OF_MOVE
cid#1546314 COPY_INSTEAD_OF_MOVE
cid#1546152 COPY_INSTEAD_OF_MOVE
cid#1546094 COPY_INSTEAD_OF_MOVE
cid#1546077 COPY_INSTEAD_OF_MOVE
cid#1546047 COPY_INSTEAD_OF_MOVE
cid#1545213 COPY_INSTEAD_OF_MOVE
Change-Id: Ia51df9f9cbde755db4d2685e34f22676ed5eceff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161141
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
While importing the properties NumberingRules and NumberingStyleName
interfere with each other. Avoid overwriting NumberingRules with an
invalid NumberingStyleName.
Regression from 588ff9a228f4894142264c68392ed1e9800a4d7d
Change-Id: I706ea514da43faae0fdb9a2c0d4f5b1928ef55f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160967
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
DOCX has some odd properties (bold, italic, shadowed, hidden ...),
which switch on/off if they are applied multiple times, e.g. with
paragraph and character styles. To fix that, a hard attribute has to
switch off the attribute in that occasion on import and on export a
hard attribute switches it on in Word.
Includes partial fix for tdf#154370.
Change-Id: Ie4c317cf9b7d02efd89b9d6a9996143585d7e937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160343
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
and
cid#1545957 COPY_INSTEAD_OF_MOVE
cid#1545944 COPY_INSTEAD_OF_MOVE
cid#1545939 COPY_INSTEAD_OF_MOVE
cid#1545931 COPY_INSTEAD_OF_MOVE
cid#1545926 COPY_INSTEAD_OF_MOVE
cid#1545909 COPY_INSTEAD_OF_MOVE
cid#1545899 COPY_INSTEAD_OF_MOVE
cid#1545896 COPY_INSTEAD_OF_MOVE
cid#1545894 COPY_INSTEAD_OF_MOVE
cid#1545858 COPY_INSTEAD_OF_MOVE
cid#1545823 COPY_INSTEAD_OF_MOVE
cid#1545820 COPY_INSTEAD_OF_MOVE
cid#1545819 COPY_INSTEAD_OF_MOVE
cid#1545772 COPY_INSTEAD_OF_MOVE
cid#1545749 COPY_INSTEAD_OF_MOVE
cid#1545743 COPY_INSTEAD_OF_MOVE
cid#1545739 COPY_INSTEAD_OF_MOVE
cid#1545635 COPY_INSTEAD_OF_MOVE
cid#1545603 COPY_INSTEAD_OF_MOVE
cid#1545602 COPY_INSTEAD_OF_MOVE
cid#1545592 COPY_INSTEAD_OF_MOVE
cid#1545544 COPY_INSTEAD_OF_MOVE
cid#1545532 COPY_INSTEAD_OF_MOVE
cid#1545520 COPY_INSTEAD_OF_MOVE
cid#1545512 COPY_INSTEAD_OF_MOVE
cid#1545490 COPY_INSTEAD_OF_MOVE
cid#1545483 COPY_INSTEAD_OF_MOVE
cid#1545467 COPY_INSTEAD_OF_MOVE
cid#1545461 COPY_INSTEAD_OF_MOVE
cid#1545458 COPY_INSTEAD_OF_MOVE
cid#1545428 COPY_INSTEAD_OF_MOVE
cid#1545394 COPY_INSTEAD_OF_MOVE
cid#1545385 COPY_INSTEAD_OF_MOVE
cid#1545383 COPY_INSTEAD_OF_MOVE
cid#1545366 COPY_INSTEAD_OF_MOVE
cid#1545357 COPY_INSTEAD_OF_MOVE
Change-Id: I76224326977b4067b94ca3176cad1ca6de17930a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160847
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This introduces a hidden property of SwXParagraph, named
OOXMLImport_AnchoredShapes.
Testing on my system, starting the main process first, then launching
another one like
time soffice path/to/bugdoc.docx
... so that it only measures time spent in import, gave the following
figures:
LibreOffice 7.5.0.3 (TDF build):
real 1m49.016s
user 0m0.000s
sys 0m0.000s
LibreOffice 7.6.0.3 (TDF build):
real 8m37.386s
user 0m0.000s
sys 0m0.000s
Current master (my no-debug build):
real 10m6.776s
user 0m0.000s
sys 0m0.000s
Current master with this patch (my no-debug build):
real 5m41.524s
user 0m0.000s
sys 0m0.015s
Indeed, it is not as fast as it used to be; and the fix doesn't really
remove the quadratic complexity, just uses faster iteration. If there
is a way to directly list objects anchored to a given paragraph, rather
than iterating over all objects checking their anchors, that would get
much faster, but that would be a rather large change.
Change-Id: Ie50515815e85fdce498d065185199c9b31d95794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160813
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and
cid#1545218 COPY_INSTEAD_OF_MOVE
cid#1545232 COPY_INSTEAD_OF_MOVE
cid#1545243 COPY_INSTEAD_OF_MOVE
cid#1545246 COPY_INSTEAD_OF_MOVE
cid#1545251 COPY_INSTEAD_OF_MOVE
cid#1545260 COPY_INSTEAD_OF_MOVE
cid#1545261 COPY_INSTEAD_OF_MOVE
cid#1545276 COPY_INSTEAD_OF_MOVE
cid#1545295 COPY_INSTEAD_OF_MOVE
cid#1545297 COPY_INSTEAD_OF_MOVE
cid#1545301 COPY_INSTEAD_OF_MOVE
cid#1545302 COPY_INSTEAD_OF_MOVE
Change-Id: I97ba935a4a2b8715b55ebbf6e853a66260b2eb90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160686
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1545723 COPY_INSTEAD_OF_MOVE
cid#1545708 COPY_INSTEAD_OF_MOVE
cid#1545705 COPY_INSTEAD_OF_MOVE
cid#1545684 COPY_INSTEAD_OF_MOVE
cid#1545674 COPY_INSTEAD_OF_MOVE
cid#1545673 COPY_INSTEAD_OF_MOVE
cid#1545667 COPY_INSTEAD_OF_MOVE
cid#1545661 COPY_INSTEAD_OF_MOVE
cid#1545660 COPY_INSTEAD_OF_MOVE
cid#1545657 COPY_INSTEAD_OF_MOVE
cid#1545653 COPY_INSTEAD_OF_MOVE
cid#1545636 COPY_INSTEAD_OF_MOVE
cid#1545624 COPY_INSTEAD_OF_MOVE
cid#1546124 COPY_INSTEAD_OF_MOVE
Change-Id: I7d50594e046a022147d9ddf077b8b2d8027f9bca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160721
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
... for shape w/ pagebreak"
This reverts 7.6 commit a9bc19c2d4a35606668aa2dcc53355651b71ee78.
The commit in general is probably fine. However, it fails in case
of an empty paragraph (with only anchors).
Unfortunately, there is no way of knowing ahead of time,
so either everything needs to be processed after a delay,
or else the paragraph needs to be split and then re-joined
in case it is not an empty paragraph.
Both options are extremely non-trivial - I don't know how
to do either of them.
In this case it is also the last paragraph in the document,
again something not known during import and which has
special-casing in MSO.
make CppunitTest_sw_ooxmlexport18 \
CPPUNIT_TEST_NAME=testTdf153613_textboxAfterPgBreak3
Change-Id: I4471e216b6523032b85178d85795434694cc1e22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160720
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
and
cid#1545679 COPY_INSTEAD_OF_MOVE
cid#1545691 COPY_INSTEAD_OF_MOVE
cid#1545697 COPY_INSTEAD_OF_MOVE
cid#1545711 COPY_INSTEAD_OF_MOVE
cid#1545730 COPY_INSTEAD_OF_MOVE
Change-Id: Ic0777a8ba532b00b021ffed81243505fbb7250f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160568
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1545791 COPY_INSTEAD_OF_MOVE
cid#1545800 COPY_INSTEAD_OF_MOVE
cid#1545806 COPY_INSTEAD_OF_MOVE
cid#1545817 COPY_INSTEAD_OF_MOVE
cid#1545832 COPY_INSTEAD_OF_MOVE
cid#1545834 COPY_INSTEAD_OF_MOVE
cid#1545841 COPY_INSTEAD_OF_MOVE
cid#1545848 COPY_INSTEAD_OF_MOVE
cid#1545852 COPY_INSTEAD_OF_MOVE
cid#1545854 COPY_INSTEAD_OF_MOVE
cid#1545864 COPY_INSTEAD_OF_MOVE
cid#1545875 COPY_INSTEAD_OF_MOVE
cid#1545882 COPY_INSTEAD_OF_MOVE
cid#1545900 COPY_INSTEAD_OF_MOVE
cid#1545901 COPY_INSTEAD_OF_MOVE
cid#1545908 COPY_INSTEAD_OF_MOVE
cid#1545921 COPY_INSTEAD_OF_MOVE
cid#1546054 COPY_INSTEAD_OF_MOVE
cid#1546145 COPY_INSTEAD_OF_MOVE
cid#1546146 COPY_INSTEAD_OF_MOVE
Change-Id: I8b23d0457cb293aa0e33593131224c1cdd1d8eb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160545
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1545179 COPY_INSTEAD_OF_MOVE
cid#1545187 COPY_INSTEAD_OF_MOVE
cid#1545188 COPY_INSTEAD_OF_MOVE
cid#1545189 COPY_INSTEAD_OF_MOVE
cid#1545196 COPY_INSTEAD_OF_MOVE
cid#1545197 COPY_INSTEAD_OF_MOVE
cid#1545204 COPY_INSTEAD_OF_MOVE
cid#1545223 COPY_INSTEAD_OF_MOVE
cid#1545236 COPY_INSTEAD_OF_MOVE
cid#1545239 COPY_INSTEAD_OF_MOVE
cid#1545253 COPY_INSTEAD_OF_MOVE
cid#1545274 COPY_INSTEAD_OF_MOVE
cid#1545286 COPY_INSTEAD_OF_MOVE
cid#1545309 COPY_INSTEAD_OF_MOVE
cid#1545311 COPY_INSTEAD_OF_MOVE
cid#1545345 COPY_INSTEAD_OF_MOVE
cid#1545358 COPY_INSTEAD_OF_MOVE
cid#1545361 COPY_INSTEAD_OF_MOVE
cid#1545365 COPY_INSTEAD_OF_MOVE
cid#1545367 COPY_INSTEAD_OF_MOVE
cid#1545372 COPY_INSTEAD_OF_MOVE
cid#1545373 COPY_INSTEAD_OF_MOVE
cid#1545377 COPY_INSTEAD_OF_MOVE
cid#1545392 COPY_INSTEAD_OF_MOVE
cid#1545399 COPY_INSTEAD_OF_MOVE
cid#1545404 COPY_INSTEAD_OF_MOVE
cid#1545408 COPY_INSTEAD_OF_MOVE
cid#1545430 COPY_INSTEAD_OF_MOVE
cid#1545439 COPY_INSTEAD_OF_MOVE
cid#1545449 COPY_INSTEAD_OF_MOVE
Change-Id: I3afe836a0bbc8bd70937035e60eb020435e413d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160539
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546278 COPY_INSTEAD_OF_MOVE
cid#1546276 COPY_INSTEAD_OF_MOVE
cid#1546247 COPY_INSTEAD_OF_MOVE
cid#1546244 COPY_INSTEAD_OF_MOVE
cid#1546243 COPY_INSTEAD_OF_MOVE
cid#1546220 COPY_INSTEAD_OF_MOVE
cid#1546209 COPY_INSTEAD_OF_MOVE
cid#1546207 COPY_INSTEAD_OF_MOVE
cid#1546206 COPY_INSTEAD_OF_MOVE
cid#1546205 COPY_INSTEAD_OF_MOVE
cid#1546197 COPY_INSTEAD_OF_MOVE
cid#1546180 COPY_INSTEAD_OF_MOVE
cid#1546172 COPY_INSTEAD_OF_MOVE
cid#1546165 COPY_INSTEAD_OF_MOVE
cid#1546164 COPY_INSTEAD_OF_MOVE
cid#1546158 COPY_INSTEAD_OF_MOVE
cid#1546151 COPY_INSTEAD_OF_MOVE
cid#1546135 COPY_INSTEAD_OF_MOVE
cid#1546132 COPY_INSTEAD_OF_MOVE
cid#1546129 COPY_INSTEAD_OF_MOVE
cid#1546128 COPY_INSTEAD_OF_MOVE
cid#1546122 COPY_INSTEAD_OF_MOVE
cid#1546117 COPY_INSTEAD_OF_MOVE
cid#1546113 COPY_INSTEAD_OF_MOVE
cid#1546106 COPY_INSTEAD_OF_MOVE
cid#1546099 COPY_INSTEAD_OF_MOVE
cid#1546091 COPY_INSTEAD_OF_MOVE
cid#1546085 COPY_INSTEAD_OF_MOVE
cid#1546069 COPY_INSTEAD_OF_MOVE
cid#1546063 COPY_INSTEAD_OF_MOVE
cid#1546062 COPY_INSTEAD_OF_MOVE
cid#1546058 COPY_INSTEAD_OF_MOVE
cid#1546056 COPY_INSTEAD_OF_MOVE
cid#1546051 COPY_INSTEAD_OF_MOVE
cid#1546040 COPY_INSTEAD_OF_MOVE
cid#1546030 COPY_INSTEAD_OF_MOVE
cid#1546028 COPY_INSTEAD_OF_MOVE
cid#1546015 COPY_INSTEAD_OF_MOVE
cid#1546001 COPY_INSTEAD_OF_MOVE
Change-Id: Ib954c92a300fc323b29f27880fdf8bc46ed98862
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160520
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546474 COPY_INSTEAD_OF_MOVE
cid#1546473 COPY_INSTEAD_OF_MOVE
cid#1546469 COPY_INSTEAD_OF_MOVE
cid#1546467 COPY_INSTEAD_OF_MOVE
cid#1546458 COPY_INSTEAD_OF_MOVE
cid#1546448 COPY_INSTEAD_OF_MOVE
cid#1546446 COPY_INSTEAD_OF_MOVE
cid#1546441 COPY_INSTEAD_OF_MOVE
cid#1546424 COPY_INSTEAD_OF_MOVE
cid#1546377 COPY_INSTEAD_OF_MOVE
cid#1546374 COPY_INSTEAD_OF_MOVE
cid#1546352 COPY_INSTEAD_OF_MOVE
cid#1546334 COPY_INSTEAD_OF_MOVE
cid#1546328 COPY_INSTEAD_OF_MOVE
cid#1546310 COPY_INSTEAD_OF_MOVE
cid#1546303 COPY_INSTEAD_OF_MOVE
Change-Id: I8a43fdd574857ba1d3ec416f23c8269a9a08e12f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160515
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1545748 COPY_INSTEAD_OF_MOVE
cid#1545741 COPY_INSTEAD_OF_MOVE
cid#1545698 COPY_INSTEAD_OF_MOVE
cid#1545594 COPY_INSTEAD_OF_MOVE
cid#1545588 COPY_INSTEAD_OF_MOVE
cid#1545558 COPY_INSTEAD_OF_MOVE
cid#1545545 COPY_INSTEAD_OF_MOVE
Change-Id: I5dfec77a68959b9384fc71a2fc0908c5d1b42869
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160448
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546459 COPY_INSTEAD_OF_MOVE
cid#1546452 COPY_INSTEAD_OF_MOVE
cid#1546403 COPY_INSTEAD_OF_MOVE
cid#1546396 COPY_INSTEAD_OF_MOVE
cid#1546394 COPY_INSTEAD_OF_MOVE
cid#1546338 COPY_INSTEAD_OF_MOVE
cid#1546324 COPY_INSTEAD_OF_MOVE
Change-Id: If61457cfaf1d7ce4a069bcecdc0cc657aeb43c68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160445
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546486 COPY_INSTEAD_OF_MOVE
cid#1546485 COPY_INSTEAD_OF_MOVE
cid#1546484 COPY_INSTEAD_OF_MOVE
cid#1546482 COPY_INSTEAD_OF_MOVE
Change-Id: I53cc622f16afc0f57ffd72e3e0a6f18e390fbb83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160443
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Crashreport signature:
Fatal signal received: SIGSEGV code: 1 for address: 0x0
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper_Impl::PushSdt()
writerfilter/source/dmapper/DomainMapper_Impl.cxx:987
program/libwriterfilterlo.so
writerfilter::dmapper::DomainMapper::lcl_attribute(unsigned int, writerfilter::Value&)
include/tools/ref.hxx:56
program/libwriterfilterlo.so
writerfilter::ooxml::OOXMLProperty::resolve(writerfilter::Properties&)
include/tools/ref.hxx:56
program/libwriterfilterlo.so
writerfilter::ooxml::OOXMLPropertySet::resolve(writerfilter::Properties&)
include/tools/ref.hxx:157
Change-Id: I76416ca707a4ac40495e5c22f62fcd017bcb5e48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160336
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 728f6ec104b1a91c8c8ea0790bc7f56471c67737)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160351
Tested-by: Jenkins
|
|
Instead of adding characters properties one at a time,
lets take care of everything all at once.
The results seem to be good so far.
There is even some similarity between
how MS Word has these properties on the
"in-between" pseudo end character, where
placing the cursor after the field gets these properties.
I don't see it happening in MS Word
at the pseudo start character, but it does in LO now...
Hopefully that doesn't end up doing bad things.
In the unit test, replacing the content ends up
in red, italic. However, I see the same thing in MSO
when testing with my second FORMTEXT example,
so I think everything is "working as expected".
I tried to see if I could limit doing this
for only certain types of fields or conditions.
However, pContext->GetResult() doesn't have a \fldrslt
yet at the time this is happening. Also, TextField.is()
happens less than I expected. I'm sure I could limit it
to just certain pContext->GetFieldId(),
but so far no problems are noticed for all field types.
make CppunitTest_sw_rtfexport6 \
CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat
make CppunitTest_sw_rtfexport6 \
CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat2
Change-Id: I3223437fd0d694f5e5733a9f7323f10f03d7802f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160232
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Any character property should be passed on,
but do that in a follow-up commit, so that
at least the bold case will remain intact
if the broader fix gets reverted for any reason.
make CppunitTest_sw_rtfexport6 \
CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat
Change-Id: Id77980b704db2ff118e89c29eb9d4db82e117cdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160221
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1998241849f0f9fa99d1b111f218cdab7e6074fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160208
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Previously the ooxml import added a new page style when the first
header or footer was detected. Since then we gained support to add
first page header/footer in an existing page style so we don't need
to import it like that anymore.
This changes the import code so that the old complication to add
"First Page" page style is removed and it always just uses the
"Standard" page style for all 3 cases: first, left and right headers
and footers.
This also adjusts the existing tests to align with this change.
Change-Id: Ibf69597e6990499ac520ea9e323a5f73f429800b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157860
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8218a4371f0b002d8ef4d544bf9227db6684915f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160012
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I1d734e1d30b91b84d42067b9cc621581ad744a40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The commit generated crashes in the crashtest documents
7711 bugtrackers/docx/fdo78333-1.docx and
695 forums/docx/forum-mso-en-4096.docx.
This was due to "m_xFieldStartRange", the start of the text
portion of the block SDT, being recorded too early. This led to
including characters that shouldn't be there in the generated
content control.
This patch moves the calls to setFieldStartRange to just before
the first appendTextPortion call.
Change-Id: I7230346fee9a37ebac70beb9bcafd9d7b612eb00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159816
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This removes all but 4 reinterpret_cast in the module!
TableManager::utext() even assumed that the bytes are little-endian.
Change-Id: I12031336cabedfd6c0fb614ee0e3400810f98e2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159486
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Convert all remaining callers to utext().
Change-Id: Ie1fdf22e9e474289df2c72eadc236ec6b270df4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159485
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
For testContSectionPageBreak, Word inserts an additional empty paragraph
at the end of the document that was missing in Writer.
Ensure markLastSectionGroup() is always called at the end of the
document so that the \par that is dispatched in m_bNeedPar case will be
inserted and not automatically removed immediately.
Also add a test for the same document without \sbknone, which has 4
pages instead of 2.
Change-Id: Ib3e4fbdb66df55941e4a487d4b249cd98fe42008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159472
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
... between commit fce18155052821756466ea043c638f4ed72f41d6 and
commit 15b886f460919ea3dce425a621dc017c2992a96b - move the code from
lcl_text() to lcl_utext().
Change-Id: Iaa515d2ebd9861e24b442b0d7b41f83662ed58df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159501
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
1. Some experimenting with the bugdoc (saving it to DOCX in Word
changes the layout in Word to exactly what Writer imports from RTF!)
leads to DOCX w:splitPgBreakAndParaMark setting.
2. the RTF implementation of \spltpgpar was missing; apparently if the
flag is present the "new" behavior is in effect, which is the
opposite of how it's specified in RTF Spec 1.9.1.
3. the DomainMapper code that uses this attribute is not in the text()
function to which RTFDocumentImpl sends paragraph breaks, but in the
utext() function, so send the break there instead, rather than
creating even more copypasta.
4. now some filters-text crashes with nullptr pContext in
DomainMapper::lcl_utext(), avoid that.
5. dispatchSymbol(m_nResetBreakOnSectBreak) doesn't do anything because
these are handled by dispatchFlag().
6. Test name: testFdo81892::Load_Verify_Reload_Verify
equality assertion failed
- Expected: Performance
- Actual :
Fails because additional paragraph break inserted after \page; in
dispatchSymbol() for \sect, remove the parBreak() as already hinted at
in commit 3c610336a58f644525d5e4d2566c35eee6f7a618
7. rtfimport.cxx:868:Assertion
Test name: testContSectionPageBreak::TestBody
equality assertion failed
- Expected:
- Actual : THIRD
It has no paragraph between SECOND and THIRD, whereas Word
definitely shows a paragraph there. In dispatchSymbol() for \sect,
sectBreak() is not called (which may create a paragraph break); in
m_bIgnoreNextContSectBreak case this needs to be done manually for
cont-section-pagebreak.rtf to get the empty paragraph between SECOND
and THIRD.
8. testFdo52052 fails; in dispatchSymbol() for \sect, if the document
ends with \sect (e.g. fdo52052.rtf) a paragraph break must be
inserted after this (because DomainMapper unconditionally removes
the last paragraph break), but not via m_bNeedCr as that creates
unwanted page break in testNestedTable (m_bNeedCr =>
dispatchSymbol(\par) => m_bNeedSect => sectBreak()); handle it in
RTFDocumentImpl::popState() for the end of the document by
dispatching \par.
9. rtfimport.cxx:1519:Assertion
testTdf108947 now has 1 empty paragraph in the header instead of 2;
Word also shows only 1 so it's an improvement.
10. Test name: testFdo49893_2::Load_Verify_Reload_Verify
equality assertion failed
- Expected: 1
- Actual : 0
- xpath should match exactly 1 node
This was reduced to only 2 pages, while Word shows 5; in
dispatchSymbol() for \page, for the consecutive \page send an empty
string to DomainMapper's utext() which causes a paragraph break to
be created if \spltpgpar isn't set (this was not at all obvious!).
11. testTdf133437 fails with some numbers of flys changing, but it had
those values before commit 3c610336a58f644525d5e4d2566c35eee6f7a618
which says "the exact number isn't that interesting".
12. testTdf153613_anchoredAfterPgBreak4 fails, but it now looks as in
Word, so this is a bugfix.
13. Jenkins build on WNT (only) crashes in testForcepoint93 in sw
layout code - disable test for now, debug asap.
Change-Id: Ia1063693d96adff900ece943020a5bf69bdeb7a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159471
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Currently LibreOffice uses the VML fallback, when a docx document has a
wpc:wpc element. This patch implements to use the choice part with the
wpc:wpc element. That is often called 'drawing canvas'.
The patch uses a similar approach as for SmartArt. The drawing canvas is
imported as group shape and for the background an additional rectangular
shape is inserted as first in the children vector.
Not using VML has the advantage, that the custom shape import is used
for preset shapes. VML import produces problems because some properties
are not available in VML or the current VML import has deficits. The
test suite shows examples, what is better without using the VML
fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828.
A drawing canvas must be used in Word for connector shapes. A connector
in Word on the drawing canvas is not written as cxnSp element, but as
ordinary wsp element with additional wps:cNvCnPr child element. The patch
generates a connector in such case.
Unsolved problems:
The path of a curved connector in OOXML is basically incompatible to
the path which LibreOffice generates. This patch uses the default
path for a curved connector. Same is done in import in Impress. Using
the VML fallback had generated a custom shape with the current path
and handles, but the connections to the target shapes were lost.
Export to docx is missing. The drawing canvas is not recreated,
instead a group with the additional background shape is exported. That
is no regression, using VML has produced a group too on export.
I don't know whether XML_graphicFrame can occur in
WordprocessingCanvasContext. At least charts and math equations are
not possible on the drawing canvas in Word.
Import of WordArt shapes does not work. That is not regression. It
works neither in the VML import.
Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
style attributes need to be repeated at the paragraph
if not repeated then defaults have to be applied
Change-Id: I4ee567e8006c240c046b7e7bb75eae92e5563776
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158839
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|