vcl/source/gdi/impglyphitem.cxx |   10 ++++++++++
 1 file changed, 10 insertions(+)

New commits:
commit 467f2c50a935efff6ff8911e7282ecea535665a3
Author:     Luboš Luňák <l.lu...@collabora.com>
AuthorDate: Thu Apr 28 20:04:52 2022 +0200
Commit:     Luboš Luňák <l.lu...@collabora.com>
CommitDate: Fri Apr 29 06:57:42 2022 +0200

    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.lu...@collabora.com>

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();
 }
 

Reply via email to