Bug Hunting Session
Bug 54494 - improve cursor traversal of combined characters
Summary: improve cursor traversal of combined characters
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
: 42324 (view as bug list)
Depends on: 100854
Blocks: RTL-CTL Font-Rendering a11y
  Show dependency treegraph
 
Reported: 2012-09-04 12:18 UTC by Caolán McNamara
Modified: 2019-01-18 15:05 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caolán McNamara 2012-09-04 12:18:42 UTC
A single glyph on screen can consist of multiple code points.

What LibreOffice basically does, or tries to do at least, is follow
http://unicode.org/reports/tr29/ and it should work like so...

a) The cursor keys skip over a full grapheme
b) A "delete" deletes a full grapheme
c) A backspace however, chips away a single codepoint at a time
d) A alt+cursor key moves a single code-point at a time

Which is all very well and good, but when we move a single code-point into a glyph our cursor positioning is fairly rubbish and not very helpful. 

The bengali KA+HALANT+TTA+HALANT+RA, i.e. 5 codepoints gives "ক্ট্র" which is a good example of this. 

I've no idea if there's any handy foo in opentype for determining the correct cursor position inside a gsub'ed glyph. Even if there is/isn't. It'd be nice to come up with...
a) a better calculation for the cursor position in these gsub'ed cases
b) a better cursor itself for helping out when trying to dig into a combining sequence.

I saw a lovely demo of something like this from SIL, perhaps it was a WorldPad demo or something of that nature (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=WorldPadDownload)
Comment 1 Caolán McNamara 2012-09-04 12:22:27 UTC
*** Bug 42324 has been marked as a duplicate of this bug. ***
Comment 2 Lior Kaplan 2012-10-18 21:57:19 UTC Comment hidden (obsolete)
Comment 3 Khaled Hosny 2014-01-11 09:45:29 UTC
OpenType’s GDEF table can have so ligature carets values that specify the horizontal cursor positions inside a ligatures (so not as sophisticated as the Graphite one, though I think Graphite2 dropped support for that), but very few fonts include this. What applications like Firefox do is to simply divide the width the ligature on the number of its characters.
Comment 4 QA Administrators 2016-02-21 08:36:43 UTC Comment hidden (obsolete)
Comment 5 Yousuf Philips (jay) (retired) 2017-10-13 20:18:23 UTC
So though we are using single glyphs in the document area, the input fields in the find toolbar and find & replace dialog are using single codepoints.
Comment 6 Yousuf Philips (jay) (retired) 2017-10-15 20:39:13 UTC
So alt+cursor key moves by single code-points, but alt+shift+cursor key doesnt allow you to select single code-points.
Comment 7 Eyal Rozenberg 2018-09-17 17:08:15 UTC
Reporter/others: Please try specifying conditions under which you would consider this bug resolved, and/or reproducible behavior which is not good enough (including how the cursor looks, hopefully with screenshots or photoshopped screenshots).