| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
(cherry picked from commit 2abe9837deee3823c7928a76b5b2f94f1464f1a3)
Conflicts:
writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
|
|
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.
(cherry picked from commit 3a749d7278bbe65cfc063e64460df8af6bc2af47)
Conflicts:
writerfilter/CppunitTest_writerfilter_dmapper.mk
Change-Id: Id74a3eb0abddf745a9e4e59625bf9345f7df9dfe
|
|
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>
|
|
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
|
|
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
|
|
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>
|
