path: root/writerfilter/
AgeCommit message (Collapse)AuthorFilesLines
2020-05-13DOCX import: fix interaction between the crop and the wrap polygon of imagesMiklos Vajna1-0/+1
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: Reviewed-by: Miklos Vajna <> Tested-by: Jenkins
2020-02-06DOCX import: don't give up on floating tables in headers completelyMiklos Vajna1-0/+1
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: Tested-by: Jenkins Reviewed-by: Miklos Vajna <>
2020-01-28tdf#103964 DOCX import: ignore rotation when setting position of group shapesMiklos Vajna1-0/+1
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: Tested-by: Jenkins Reviewed-by: Miklos Vajna <>
2020-01-16sw: add DOCX import for semi-transparent textMiklos Vajna1-0/+1
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: Tested-by: Jenkins Reviewed-by: Miklos Vajna <>
2020-01-08DOCX import: fix lost page break when footer ends with a tableMiklos Vajna1-0/+1
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: Reviewed-by: Miklos Vajna <> Tested-by: Jenkins
2020-01-02tdf#129205 DOCX import: handle the <w:shd w:val="nil" ...> paragraph propertyMiklos Vajna1-0/+1
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: Reviewed-by: Miklos Vajna <> Tested-by: Jenkins
2019-12-20DOCX table import: fix interaction of 1-cell rows and "inside" vertical bordersMiklos Vajna1-0/+48
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: Reviewed-by: Miklos Vajna <> Tested-by: Jenkins