sw btlr writing mode layout: fix baseline offset

The problem was that the x position of the btlr text had a 159 twips
difference (it was too close to the cell border), since the text portion
height -> baseline offset calculation worked with the descent, not with
the ascent.

The position of the text now matches exactly what Word does.

As a side-effect this means that multiple portions in a line and also
multiple lines in a text frame now work correctly.

Change-Id: Ic139db328e2a913e5cae4026886c3410cdab357d
Reviewed-on: https://gerrit.libreoffice.org/67823
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

1 files changed, 8 insertions, 0 deletions

diff --git a/sw/qa/extras/layout/layout.cxx b/sw/qa/extras/layout/layout.cxx
index 77c826dba30d..1c8ca7aa6385 100644
--- a/sw/qa/extras/layout/layout.cxx
+++ b/sw/qa/extras/layout/layout.cxx
@@ -2804,6 +2804,14 @@ void SwLayoutWriter::testBtlrCell()
     // the orientation was 0 (layout did not take btlr direction request from
     // doc model).
     assertXPath(pXmlDoc, "//font[1]", "orientation", "900");
+
+#ifndef MACOSX // macOS fails with actual == 2662 for some reason.
+    // Without the accompanying fix in place, this test would have failed with 'Expected: 1915;
+    // Actual  : 1756', i.e. the AAA text was too close to the left cell border due to an ascent vs
+    // descent mismatch when calculating the baseline offset of the text portion.
+    assertXPath(pXmlDoc, "//textarray[1]", "x", "1915");
+    assertXPath(pXmlDoc, "//textarray[1]", "y", "2707");
+#endif
 }
 
 CPPUNIT_TEST_SUITE_REGISTRATION(SwLayoutWriter);