summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2015-08-02 20:57:41 +0200
committerChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2015-08-02 20:57:41 +0200
commit437e4abdf9e72fd0a6e6f8697a0e659bc77f9b10 (patch)
tree5772aa43a1f6782bceabd4efe3bd327b22599e29
parenta2b5363e81075a12190c7887d6ce844460ae6926 (diff)
Version 5.0.0.5, tag libreoffice-5.0.0.5-hotfix1 libreoffice-5.0.0.5-hotfix1
Change-Id: I901d2cd67fce1f94ad3a4889a4a88ee26fa4d877
m---------dictionaries0
m---------helpcontent20
m---------translations0
3 files changed, 0 insertions, 0 deletions
diff --git a/dictionaries b/dictionaries
-Subproject 1831888c727b76e155b5e3d8be38f16dd02d022
+Subproject 91a8c814ad24744a7462386612ad0752bb7b0cf
diff --git a/helpcontent2 b/helpcontent2
-Subproject d573f6806b0b73f142d87458bd3fd7a1dd552d9
+Subproject e6eb108cc2509849b02ad7e04d3388ac01279f2
diff --git a/translations b/translations
-Subproject 63369b53e7ed1e27d82e88e7b8787e7fa2d8db2
+Subproject 7131ab77373ba6cd9ca14dd8bfad58dd230d484
ating 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> 2020-01-28tdf#103964 DOCX import: ignore rotation when setting position of group shapesMiklos Vajna 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> 2020-01-16sw: add DOCX import for semi-transparent textMiklos Vajna 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> 2020-01-08DOCX import: fix lost page break when footer ends with a tableMiklos Vajna 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 2020-01-02tdf#129205 DOCX import: handle the <w:shd w:val="nil" ...> paragraph propertyMiklos Vajna 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 2019-12-20DOCX table import: fix interaction of 1-cell rows and "inside" vertical bordersMiklos Vajna 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