Subject: Screen coordinates vs layout units (also comment commit)
jskov@zoftcorp.adsl.dk
Date: Mon Apr 16 2001 - 07:00:37 CDT
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
This archive was generated by hypermail 2b25 : Mon Apr 16 2001 - 07:01:54 CDT