Age | Commit message (Collapse) | Author | Files | Lines |
|
If the wrap polygon is influenced by crop at import time, we need to do
the opposite at export time.
Do this for RTF and DOCX, where there is matching import code in
writerfilter/, leave DOC alone for now.
Test this by changing testFdo76803 into an export test, then seeing how
the first point's Y position fails and fixing up the exporter, so we
get back the old good value.
Change-Id: Ieef18aad3c76f7945c7348201b07bcb27a4cd48d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94246
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Word first applies the crop, then applies the wrap polygon on the
remaining visible part of the image.
Writer applies the crop on the original bitmap, and even has explicit
code to make sure the uncropped bitmap is used for the wrap polygon, see
how SwFlyFrame::GetContour() calls SwNoTextFrame::GetGrfArea(), which
will extend the resulting size based on cropping.
Fix the problem by moving and scaling the wrap polygon, so it ends up
where it would in Word.
Also adapt testFdo76803, which had a similar crop+wrap polygon case, but
the different there is quite small.
Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94149
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is the same as page, but it is from-left on odd pages and
from-right on even pages, i.e. our "mirror on even pages" mode.
Change-Id: I018e0ac165a3d802f64cfc314d5c5f58da3cb580
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92965
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I808b7e3f6b580ee6f1876aa06038b5741d7ff6a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90001
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I47ff7eecabc87081eb953c5970a3cbd56c86d728
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88897
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
1) This is not needed: Word only supports inline "anchoring" in
textboxes.
2) If the textbox has a certain ZOrder, we don't want the inline shapes
to be behind the textbox.
3) This allows restoring the old assert in sw_ooxmlexport7 that was
changed in commit 99847d6b3005c5444ed5a46ca578c0e40149d77c (DOCX import:
fix ZOrder of inline vs anchored shapes, 2020-02-12).
Change-Id: I817e4fb70cb789e8eb116219050fc1aeaec76667
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88873
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Shapes which are anchored but are not in the background should be always
on top of as-char anchored shapes in OOXML terms. Writer supports a
custom ZOrder even for as-char shapes, so make sure that they are
always behind anchored shapes.
To avoid unnecessary work, make sure that when there are multiple inline
shapes, we don't pointlessly reorder them (the old vs new style of the
sorting controls exactly this, what happens when two shapes have the
same ZOrder, and all inline shapes have a 0 ZOrder).
Adapt a few tests that used ZOrder indexes to access shapes, but the
intention was to just refer to a shape: fix the index and migrate to
shape names where possible.
Change-Id: I670e4dc2acbd2a0c6d47fe964cb5e3f2300e6848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88540
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Effects have an extent, and unhandled effects (like this blurred shadow)
need to take space in the margin of the shape to make sure they use the
correct amount of space in the layout.
This was working in general, but not in case the importer decided to
import the shape as Draw shape + the shape was inline.
(And also disable a new CppunitTest_sw_uibase_shells test on Windows,
which is only stable on Linux, it seems.)
Change-Id: I9d0531d9393d8c2cd274e6f54bbbfe8024bf270f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88427
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
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.
Change-Id: I1c460919b0389d5b053b4ca1c9210279d6cd183c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88413
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
To avoid duplication.
Change-Id: I0ee7c26d5d55bd868ead04c77e7f4ef2582f90e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88138
Tested-by: Jenkins
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>
|
|
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.)
Change-Id: I8e12c28e65c5f64168c3f802546fddf472fcc6eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87551
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is one of the text effects properties, which is already
grab-bagged. That is done in a generic way, so the easiest is to just
read the value from the grab-bag, rather than from the dmapper tokens
directly.
Change-Id: Id74a3eb0abddf745a9e4e59625bf9345f7df9dfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86884
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from commit 7d3778e0ef9f54f3c8988f1b84d58e7002d6c625
(bnc#816593 DOCX import: ignore page breaks in tables, 2013-09-02), the
page break was ignored because the preceding footer ended with a table
(no empty paragraph at the end of the footer stream).
Fix the problem by saving/loading the table state around header/footers,
that way the page break is not ignored.
Adjust testTdf102466 to test the page number from Word.
Change-Id: Ia4c22452ee2c37f7f941dfd922db04c851644d0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86435
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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.
Change-Id: I30af8a7fb55fb9bab2d12e120069a479fc7ab0a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86096
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
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.
Change-Id: Id847109ecfa95d1745abe62ddf36c4936b730855
Reviewed-on: https://gerrit.libreoffice.org/85536
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
To be consistent with CppunitTest_vcl_filters_test. This also allows
writing actual manual test code for writerfilter/source/rtftok/ (next to
the tested code) later, where the natural choice for such a test suite
would be CppunitTest_writerfilter_rtftok.
Change-Id: Iff5be9b95b6c2be3ef441e7a766584b2d008a66a
Reviewed-on: https://gerrit.libreoffice.org/84460
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I16e0c1adf854c3a2fa8d945724270d2d87461b39
Reviewed-on: https://gerrit.libreoffice.org/67192
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I2040315707674dc99a37aedb96ac61dca274c13a
Reviewed-on: https://gerrit.libreoffice.org/47348
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
I (tried to) keep the RTF filter style consistent locally with astyle in
the past, but now that's redundant when we have an enforcing
clang-format mechanism in place. So drop the astyle config and switch to
clang-format in the RTF filter case.
To minimize backport pain, do this shortly before the libreoffice-6-0
branch-off.
Change-Id: I708dbeb0b5ad2afacc90029ee5abba9495f4601f
|
|
To test: make CppunitTest_writerfilter_rtftok
These crash triggering instances were hidden by the presense of \super
in topcontext-2.rtf - so I copied it, and only removed \super.
My fix for tdf#109382 triggered a unit test failure for one
missing m_xTextFactory. It seemed safe enough to test for all of them
that aren't in try/catch blocks, not just for the specific
instance I can prove with the test.
Change-Id: I1e317e05f9bcbbb14360941ce07af1bdf0edac6a
Reviewed-on: https://gerrit.libreoffice.org/41060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ic1e953b5bcae6124ee6ce7d141ddac11a94b2a8b
Reviewed-on: https://gerrit.libreoffice.org/37464
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Icb3c640e04416f9120d37558646a570daeddf0a4
Reviewed-on: https://gerrit.libreoffice.org/28825
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I033454670d1ee662bc80bc07578690155d97ce28
Reviewed-on: https://gerrit.libreoffice.org/28805
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
but we only use the RTFParserState to use its m_pDocumentImpl and
the m_pDocumentImpl is never changed for the RTFParserState lifetime,
so take the m_pDocumentImpl at ctor time instead and use that
directly later
Change-Id: I15152e3f6d9008553b4a384a5e5da21373904cc9
Reviewed-on: https://gerrit.libreoffice.org/28802
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8e881871b1ae4dea757263d04796779e62e168dc
Reviewed-on: https://gerrit.libreoffice.org/28693
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5d208bb2a85d7aa4eea9b1c950eeb6f35493f759
|
|
Change-Id: I2045ce82a1d536ab566e6a1218bea9c6a6696024
|
|
Change-Id: Ibb4cadb58aa17eacfc9741f7f13c780be347cd8b
|
|
Change-Id: I51736459f9f098d9d793bff3b9a1a403962e099d
|
|
and a m_xTextFactory check too
Change-Id: I9352410c42048b4dd7d6dbc3514351ab8f16790b
|
|
Change-Id: I4a135a9f9ac2f16f9dab096f5c234ff1d6e5e853
|
|
Change-Id: Ic8dd72da175fee656889910b55d31ea161b944cc
|
|
Change-Id: If3148cb6e16cff4aad28c4f86467c66ed04bcd05
|
|
Change-Id: I84bf3788ac092c491d7c5a9f86421f1cf9f3e814
|
|
Change-Id: Icdd71733c4e9f4b36e6e957e4dea772087890faa
|
|
rather than spend the rest of my life protecting each one
Change-Id: I181df33b052a0303f072ce0252d98562231569e2
|
|
Change-Id: I05dfffced9a8677650a46b43f65a29e9b21c5524
|
|
Change-Id: Ia7f7ace8130d5dfe290207e0cd3d2e6a43b8ab46
|
|
Change-Id: I16db4e16e5c2fa3aa3bfb22f83d2c36695499b5c
|
|
(as some tests derive from the latter only for the Directories part, not for the
setUp/tearDown overrides: those tests will be cleaned up next)
Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f
Reviewed-on: https://gerrit.libreoffice.org/23078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia62de30ae94bdae87cd5109c44eab40af4d020e5
Reviewed-on: https://gerrit.libreoffice.org/22985
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to catch calling params with defaults like "= OUSString()"
Change-Id: Iad060e318ed492c22f8be44e326174fe6d28fff9
Reviewed-on: https://gerrit.libreoffice.org/22932
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia08c184b792ff73d3ed49d6a5d54dec1a35943e9
Reviewed-on: https://gerrit.libreoffice.org/21955
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idb0865f4d0db6c4eda33810ab2ef4cff49bc85d1
|
|
Experimenting with different non-alpha characters in front of
field, most of them aren't allowed and result in field not
recognized by MS Word: #$%&'()*+,-./:;<>?@[]^_`{|}~
Besides, if backslash "\" is followed by another backslash or
space, it is illegal, too. This patch takes care of it.
On the other side, not closing quotes is allowed by MS Word.
This patch allows this, too.
The patch does not handle another allowed field code "=2+2".
This should be done in another commit.
Change-Id: I842fe59c026b68977e61a7ae0b5495c02803ad83
Reviewed-on: https://gerrit.libreoffice.org/20435
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I31a69a997098eb1807361b8049c3312a4f287d75
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I92de8fa6a48dac9a0a09e6ebda4af9b8e4c3a1d7
|
|
Especially the 'using namespace std' is scary, now that we have
std::shared_ptr and boost::shared_ptr, too.
Change-Id: Ibb584281f1b9d56103ab5984473eb484157c12d5
|