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