Subject: Re: patch -- fix for Bug 760
From: Jesper Skov (jskov@redhat.com)
Date: Thu Jun 01 2000 - 10:58:32 CDT
>>>>> "Jesper" == Jesper Skov <jskov@redhat.com> writes:
Jesper> Basically, using checkForBeginOnForcedBreak() and
Jesper> checkForEndOnForcedBreak() was wrong. These assume the
Jesper> LayoutBlock to be in some special state to work - and as they
Jesper> always add empty Runs to either the first or the last line of
Jesper> a LayoutBlock, I'm not convinced that they would always work -
Jesper> but I don't want to stick my nose in it.
I tried commenting out the calls to these functions when using the
below patch, and it didn't seem to make a difference. It may be
possible to remove them entirely, but I'd like the new code in place
first and have it tested by others than myself.
Jesper> 1234 + 2xleft + ctrlxReturn => same assertion as I had tried
Jesper> to work around
^^^^^^^^^^^ should be 2xCtrl+Return
Jesper> I'll write a function that will validate and fix a LayoutBlock
Jesper> if it contains *any* lines which cannot contain the
Jesper> point. Initially, we can call that where I put in the Bug 760
Jesper> hack - and thus get rid of the assertions.
Yes, well. That was the plan anyway. Turned out I could not get the
validator to work since a line does not get split until later.
So I also wrote a new function which is used by the functions which
insert anything that should break a line (in the sense of formatting,
not contents). As far as I can tell, it works fine, and fixes Bug 760
for sure.
Jesper> When someone with a clue fixes the bug where it should be
Jesper> fixed, we can use the function solely for assertion.
I'm not implying, btw, that I have a clue. But I think the problem
gets fixed in the right place now.
My only concern is that I may be duplicating code living somewhere
else: assuming it's in the fb_LineBreaker, I think the duplication is
necessary since the line breaker (as far as I can tell) requires
size/position information to do its job - and size/position
information cannot be updated without causing assertions. Classic
catch 22... May be worth sharing some of the code though, if possible.
Anyhu, looking forward to getting some feedback.
I have noticed three things while working on this:
1) typing stuff, mixing in some page breaks, and then deleting it all
again leaves a lot of zero-length Runs in the document. Some of
these due to checkForBeginOnForcedBreak, but it happens even when
it's commented out. What part of the code is responsible for
merging/deleting such Runs? Or is it intentional (surely not).
2) I cannot insert a field without getting assertions. I suspect it's
partly due to the findPointCoord changes I have in my tree. Sure
hope it's not due to the field coord changes.
3) When using columns, inserting a page break only seems to have the
effect of a column break. Is this a known problem? (or intentional
behavior).
Thanks,
Jesper
This archive was generated by hypermail 2b25 : Thu Jun 01 2000 - 10:58:43 CDT