hack for glyph subset being different because of space being RTL

This is a rather weird corner case than I can see only with
JunitTest_svx_unoapi failing without this, when asking to lay out
characters 7-9 from "paragraph 1" with layout mode set to RTL.

Change-Id: Ic55e571a5934ea2b9de2f09b7c066abf014ac212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133578
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

1 files changed, 10 insertions, 0 deletions

diff --git a/vcl/source/gdi/impglyphitem.cxx b/vcl/source/gdi/impglyphitem.cxx
index b313cf8967e2..e66a5bad1a2d 100644
--- a/vcl/source/gdi/impglyphitem.cxx
+++ b/vcl/source/gdi/impglyphitem.cxx
@@ -165,6 +165,16 @@ SalLayoutGlyphsImpl* SalLayoutGlyphsImpl::cloneCharRange(sal_Int32 index, sal_In
         if (pos->IsUnsafeToBreak() || (pos->IsInCluster() && !pos->IsClusterStart()))
             return nullptr;
     }
+    // HACK: If mode is se to be RTL, but the last glyph is a non-RTL space,
+    // then making a subset would give a different result than the actual layout,
+    // because the weak BiDi mode code in ImplLayoutArgs ctor would interpret
+    // the string subset ending with space as the space being RTL, but it would
+    // treat it as non-RTL for the whole string if there would be more non-RTL
+    // characters after the space. So bail out.
+    if (GetFlags() & SalLayoutFlags::BiDiRtl && !rtl && !copy->empty() && copy->back().IsSpacing())
+    {
+        return nullptr;
+    }
     return copy.release();
 }