On Wed, Dec 21, 2005 at 10:24:33PM +0200, Martin Vermeer wrote: > On Wed, Dec 21, 2005 at 01:46:53PM -0500, Bennett Helm wrote: > > On Dec 21, 2005, at 9:01 AM, Bennett Helm wrote: > > > > >I haven't noticed any strange drawing issues. > > > > I take that back. On occasion, when typing text into the middle of a > > paragraph should result in the last word of that line being bumped to > > the next line, it doesn't happen on screen, even though the next line > > and subsequent lines are properly redrawn. A similar problem happens > > (and not always in the same cases) with deleting: when deleting text > > in a line should result in a word from the next line being brought > > up, that word does appear in the current line, though the next line > > still contains that word. > > > > I hope that's clear. I haven't been able to see a pattern as to when > > the problem occurs and when not. But it's frequent enough that you > > should be able to reproduce it without much effort. > > Clear enough. Jean-Marc has been expecting that the 'row signature' we > are using isn't discriminating enough, and now you seem to have run into > that. > > Our row signature is > > rit->endpos() - rit->pos() + 1000 * y > > which means: end-of-row - beginning-of-row + 1000 * vertical position of > row. The row beginning and end positions in characters from > start-of-paragraph, y in pixels from top of screen. > > I expect that the pattern you see is: the word that gets pushed to the > next line is the same length as the word getting pushed to the 'next > next' line. I can reproduce that. (endpos - pos) remains unchanged. > > A good signature has the following properties: > > 1) it _never_ changes when the row does not change. (e.g., not when you > add characters above it in the paragraph.) > 2) it _always_ changes when the row changes. On this, the current > signature is weak.
2) is mathematically impossible in theory, there being many more possible different rows than there are possible different checksums. In practice, a good checksum only have a 1 to 2^32 (or 2^64) chance of not changing when it should though. :-) > > The best signature would be a checksum computed over the row content, > but designed such that, e.g., changing the order of the characters will > produce a different checksum. Such a checksum would be rather expensive > to compute. I don't think such a checksum is that expensive. Consider byte[0]*1 + byte[1]*2 + byte[3]*3 + ... + byte[n-1]*n for the n byte values (or unicode values) in a row of text. This sum changes when text is added, deleted or rearranged. Computing this for all the visible rows won't take long. Maybe not something you want to do for the entire document on each keypress, but that should hardly be necessary? Helge Hafting
