To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=74188
------- Additional comments from c...@openoffice.org Mon Apr 26 10:52:47 +0000 2010 ------- I originally wrote this some time ago and didn't have the full story, but I've a better grasp of it now, and my old patch is totally bogus. So, first is attached a sample font for reference and second is attached a sample document for reference, and third is a sample picture for reference, and fourth is a new sample illustrative patch. There are two different issues going one here and they've gotten mixed up. The first one is the issue about where does the cluster begin or end, i.e. the break iterator rules and khongs comments. I'd like to spin that off as a separate issue. So see issue 111152 for that. (Note I've learned how to write breakiterator rules in the meantime :-)). Lets assume for demonstration purposes that the patch at issue 111152 is applied for the rest of this comment, but the remaining problem is independent of the specific break rules, and doesn't depend on 111152. The sample document has the string... 0995 09CD 099F 09B0 09BF Now (with the break iterator rules of 111152 in place) the break iterator gives 0, 3, 5 as the character break positions. In both the writer and draw engine, cursoring forwards and backwards through the sample text follows these rules correctly. i.e. first chunk is "0995 09CD 099F" second chunk is "09B0 09BF" Now in both the writer text and in the edit-engine text window, go to the end of the text, press left arrow, cursor is now like so... 0995 09CD 099F [LOGICAL CURSOR] 09B0 09BF press backspace (we currently use a model of "delete" removes the entire graphic cluster, while "backspace" chips away one character at a time). That leaves... 0995 09CD [LOGICAL CURSOR] 09B0 09BF What *writer* does to determine where to draw the visual cursor is to take all the text before the logical cursor i.e. "0995 09CD" and call GetDXArray on that sequence, and draws the cursor after where 09CD would appear in that string. What the "editengine" does is to take the full new string of "0995 09CD 09B0 09BF" and call GetDXArray on it, and then find the position of 09CD in those results and draws the cursor after that. "0995 09CD 09B0 09BF" is a single cluster (by issue 111152 rules). In either case the Lohit Bengali font attached assigns this sequence to one glyph. So there is a big difference between the position of the "09CD" glyph in "0995 09CD" vs where it appears in "0995 09CD 09B0 09BF". The output is that in writer the cursor is drawn basically in the middle of the glyph, and in the edit-engine it is drawn at the start of the glyph as seen in the screenshot. So that's the problem I'd like to address in this issue, the inconsistently between how the editengine and writer calculates the visual cursor when the logical cursor is between two characters that form a single glyph. I think we should prefer the writer mode here of calculating it based on taking the string before the logical cursor in isolation of the text following the cursor. The sample crude patch attached here illustrates what I'm trying to get at. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
