Issue 115003 - Cursor behaviour with Graphite fonts
Summary: Cursor behaviour with Graphite fonts
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOO330m9
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: 78749
  Show dependency tree
Reported: 2010-10-09 15:35 UTC by rgb
Modified: 2017-05-20 11:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

reviving the nice tradition of providing a bugdoc (9.38 KB, application/vnd.oasis.opendocument.text)
2010-11-04 08:37 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description rgb 2010-10-09 15:35:54 UTC
Steps to reproduce the problem:
1- Install Linux Libertine G font from here:
2- Open a Writer document and type the following text

Some text \prime Some text fi more text

3- Modify the paragraph style to use the Linux Libertine G font with "tex mode"
enabled (on the font name box type: Linux Libertine G:texm=1)
"\prime" will change into ' and fi will be replaced with proper typographical
4- Put the cursor on the end of the paragraph and use the cursor arrows to go to
the left one character at a time.

Actual result:
While the cursor behaviour is OK on the fi ligature (and this is an improvement
respect OOo 3.2.x), when you arrive to the "prime" the cursor will jump to the
right, possible going to the position where the text \prime should be if "tex
mode" were not enabled.

This behaviour is confusing because the cursor jump to a text position, but if
you press "back space" the text deleted is the one "hidden" by the Graphite
replacement, not the one where cursor is shown.

Problem is also present on DEV300m89
Comment 1 eric.savary 2010-11-04 05:36:21 UTC
@HDU: reproduced in m8 (I guess no regression since m5 and the integration of
graphite04). Missing or half supported feature?
Comment 2 2010-11-04 08:37:58 UTC
Created attachment 72844 [details]
reviving the nice tradition of providing a bugdoc
Comment 3 2010-11-04 08:54:05 UTC
The problem is that for text in non-CTL scripts WriterEngine and EditEngine do not use enough context. 
Their assumptions about latin text became obsolete with advanced typography.

@od: I suggest to get the cursor positions of the whole line (or same-font portions) at once by using 
OutputDevice::GetCaretPositions(). Trying to calculate these positions by using obsolete assumptions about 
cursor movements in latin text is bound to fail when any advanced typographic features come into play.
Comment 4 Marcus 2017-05-20 11:17:56 UTC
Reset assigne to the default "".