Subject: [RFC] New fl_BlockLayout::findPointCoords implementation
From: Jesper Skov (jskov@redhat.com)
Date: Sat May 27 2000 - 16:13:59 CDT
Hi
I'd like people to look at this new implementation of the
findPointCoords method, and help me with suggestions for improvement.
I found the old implementation to crash for some types of input, and
tried to understand the code. Not much luck in that department, and
Mike Nordell has some issues with the implementation as well. So after
some lengthy (and mostly clueless) postings, I've gotten enough
feedback and suggestions to write a new implementation.
I don't quite understand all the elements of the old implementation,
so there may be some oversights still to be handled. But overall I
think it at least does away with the grievance Mike had with the old
code, and should also be more efficient.
I have commented the code to death, so it should be fairly
straightforward to point out places where the assumptions this is
built on are wrong.
Issues:
o I have added a method to the Run classes called
letPointPass(). It's a pretty bad name - and there may be other
means to achieve what it does: tells the block when to stop
scanning in certain EOL situations - see comments for full details
(and ask if it isn't made clear enough).
o fv_View has comments like this:
/*
Likewise, findPointCoords will return the run to the right
of the specified position, so we need to stop looking one
position to the left.
*/
It's unclear to me if I've broken some assumptions/semantics of the
old implementation. Everything I could think of testing seems to
work. I may just be missing something obvious (or the new semantics
match the old semantics in this regard). In any event, I'd like to
express the above assumption/requirement with comments (and/or
asserts) in the findPointCoords method.
o The old code has a check for pPrevLine==pLine@EOL - it's a situation
that does happen, it seems. I've seen a few asserts but couldn't
reproduce it when trying (so I replaced the assertion with some
code like in the old implementation). Basically, if anyone sees why
this can happen, I'd like to know.
o The old implementation would call lookupProperties() on a Run
before calling findPointCoords - this only in the second loop
though. It's unclear to me why this was done - it may have to be
done in the new code as well.
o I've introduced a FIXME at the only code which relies on
FP_RUN_JUSTAFTER outside of the findPointCoords function. It's
unclear to me what (if anything) should be done there. Any pointers
appreciated.
As you see, mostly stupid questions :)
Testing:
I've tested the new implementation with the below input. Some of
these cause asserts with the old implementation.
'text': means just type some text
'\[linebreak]': new paragraph (return) - or the linebreak Run (even
though I've never seen that)
'\[pagebreak]': new page (ctrl+return)
'\[EOD]' : end-of-document (i.e., don't have anything after the break)
text
text\[linebreak]\[EOD]
text\[linebreak]text\[EOD]
text\[pagebreak]\[EOD]
text\[pagebreak]text\[EOD]
text\[columnbreak]\[EOD]
text\[columnbreak]text\[EOD]
Hope this makes at least some sense :) Looking forward for some
feedback, and desperately hoping that this is useful (or it'll only
have been a learning experience - would like it to be productive as
well ;)
Thanks,
Jesper
This archive was generated by hypermail 2b25 : Sat May 27 2000 - 16:14:07 CDT