Presently, we sometimes get gaps between our lines. Gaps that are not owned by anything - and is there because of rounding errors. As far as I can tell, anyway. This causes two kind of problems: o In the maxXYToPosition code since it has to make guesses about ownership. It selects the closets miss - which is probably fine in most cases, but doesn't jive well. o Cursor line motion code works by computing a point based on present position and height of present line. And then moves the point a bit farther away for good measure. In most cases, this is fine. But the lack of precision sometimes causes the cursor to get stuck, because the position guessed to belong to next/prev line, actually gets attributed to the same line - mostly because of the guesstimate code above. I'm not entirely sure if this is the cause of the cursor motion problems in http://www.abisource.com/bugzilla/show_bug.cgi?id=307 , but it definitely has some rather large gaps between the lines. And the +2 magic constant in the code below just doesn't cut it. We need precision. I'm not sure how to achieve it. Possibly by also updating line heights in the fp_Column.cpp::layout loop when their Y positions are assigned? That's what I would suggest, but I'm not sure of all the implications - would anyone care to comment? Thanks, Jesper Index: fv_View.cpp =================================================================== RCS file: /cvsroot/abi/src/text/fmt/xp/fv_View.cpp,v retrieving revision 1.429 diff -u -5 -r1.429 fv_View.cpp --- fv_View.cpp 2001/04/15 23:25:40 1.429 +++ fv_View.cpp 2001/04/16 11:51:15 @@ -3578,28 +3578,32 @@ // Signal PieceTable Changes have finished m_pDoc->notifyPieceTableChangeEnd(); } +/*! + Move insertion point to previous or next line + \param bNext True if moving to next line + + This function moves the IP up or down one line, attempting to get as + close as possible to the prior "sticky" x position. The notion of + "next" is strictly physical, not logical. + + For example, instead of always moving from the last line of one + block to the first line of the next, you might wind up skipping over + a bunch of blocks to wind up in the first line of the second column. +*/ void FV_View::_moveInsPtNextPrevLine(bool bNext) { UT_sint32 xPoint; UT_sint32 yPoint; UT_sint32 iPointHeight; UT_sint32 iLineHeight; UT_sint32 xPoint2; UT_sint32 yPoint2; bool bDirection; - /* - This function moves the IP up or down one line, attempting to get - as close as possible to the prior "sticky" x position. The notion - of "next" is strictly physical, not logical. - - For example, instead of always moving from the last line of one block - to the first line of the next, you might wind up skipping over a - bunch of blocks to wind up in the first line of the second column. - */ + UT_sint32 xOldSticky = m_xPointSticky; // first, find the line we are on now UT_uint32 iOldPoint = getPoint(); @@ -3669,11 +3673,21 @@ else { if (pOldLine != pOldContainer->getFirstLine()) { // just move off this line - // Sevior TODO the +2 is a work around. The problem is somewhere else + // Sevior TODO the +2 is a work around. The problem is +somewhere else. + + // Martin: I think it's due to fp_Column::layout which + // computes screen Y pos from height in layout units, but + // does so with greater accuracy than the conversion + // between a single line's height in screen and layout + // units can be done (i.e., in fp_Column::layout you get + // accumulated fractions included which eventually makes + // the line Y positions differ from the sum of their + // heights). jskov 2001.04.16 + yPoint -= (pOldLine->getMarginBefore() + 2); } else if (bDocSection && (pOldSL->getFirstContainer() == pOldLeader)) { // move to prev section
