diff options
author | Khaled Hosny <khaled@aliftype.com> | 2022-08-26 22:20:55 +0200 |
---|---|---|
committer | Miklos Vajna <vmiklos@collabora.com> | 2022-08-31 08:29:49 +0200 |
commit | 8cb4db941f91cc234dd18c61f8b1e51f65360d1f (patch) | |
tree | 4637ae5e0d509302f7b7a1b12f580a1749e4e36e /editeng | |
parent | d325edf88c8dbcdaf324b8e3585a314c9351cf60 (diff) |
tdf#30731: Improve caret travelling in Writer
Previously, when measuring caret position, Writer would measure the
width of the substring before the caret (i.e. layout it independent of
the text after the caret and measure its width).
This is incorrect, though. It assumes cutting the string laying it out
would result in the same width as when laid out as part of a bigger
string, which is invalid assumption when e.g. cutting inside a ligature
or between letters that have different shapes when next to each other,
etc.
This appears to work when the width of the substring laid out alone is
close enough to its width when laid out with the full text. But in cases
where is widths are largely different, like the extreme case in the bug
report, the caret will be jumping around as it is positioned based on
the unligated glyphs not the ligated, rendered glyphs.
This change introduces a special mode of measuring text width for caret
positioning, that will layout the whole string that return the width of
the requested substring.
Fields and small caps text are trickier to handle, so old behaviour is
retained for them. Now one will probably notice but if they do, it can
be dealt with then.
This also tries to be conservative and keep other pleases using the
existing behaviour which might be desirable (e.g. when measuring text
width for line breaking, we want the unligated width), but there might
be other places that should use the new behaviour.
To handle caret inside ligatures, the grapheme clusters in the ligature
are counted and the width of the whole ligature is distributed on them
evenly. A further improvement would be using HarfBuzz API to get
ligature caret positions for fonts that provide them, which helps when
the ligature components have different widths.
Change-Id: I02062e2e2e1b1a35c8f84307c0a8f5d743059ab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138889
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Diffstat (limited to 'editeng')
-rw-r--r-- | editeng/source/items/svxfont.cxx | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/editeng/source/items/svxfont.cxx b/editeng/source/items/svxfont.cxx index 868b830c63cc..65191cab8ed7 100644 --- a/editeng/source/items/svxfont.cxx +++ b/editeng/source/items/svxfont.cxx @@ -37,7 +37,7 @@ static tools::Long GetTextArray( const OutputDevice* pOut, const OUString& rStr, { const SalLayoutGlyphs* layoutGlyphs = SalLayoutGlyphsCache::self()->GetLayoutGlyphs(pOut, rStr, nIndex, nLen); - return pOut->GetTextArray( rStr, pDXAry, nIndex, nLen, nullptr, layoutGlyphs); + return pOut->GetTextArray( rStr, pDXAry, nIndex, nLen, false, nullptr, layoutGlyphs); } SvxFont::SvxFont() |