Re: [RFC] New fl_BlockLayout::findPointCoords implementation


Subject: Re: [RFC] New fl_BlockLayout::findPointCoords implementation
From: Jesper Skov (jskov@redhat.com)
Date: Mon May 29 2000 - 04:25:21 CDT


>>>>> "Martin" == Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au> writes:

Martin> On Sat, 27 May 2000, Jesper Skov wrote:

>> Hi
>>
>> I'd like people to look at this new implementation of the
>> findPointCoords method, and help me with suggestions for
>> improvement.
>>

Martin> Hi Jesper, I haven't taken the time read through your code in
Martin> depth but I have submitted it to some tests which show up
Martin> shortcommings in the cursor sizing and positioning

Thanks for trying it out. There are clearly some issues I hadn't
considered at all.

Martin> calculations. Basically the problem arises at the boundaries
Martin> of subscript and superscript text. When positioning the cursor
Martin> at the start of superscript run, the cursor shows superscript
Martin> size and position but the text is actually entered as
Martin> normal. At the end of a superscript run the cursor shows
Martin> normal size and position but the text is actually entered as
Martin> superscript. A very similar problem exists on the boundaries
Martin> of different size fonts. The code chooses exactly the wrong
Martin> size for the cursor at both the beginning and end. This used
Martin> to work with the old code.

This is explained by a subtlety in the old code; after finding the
requested offset, it would return the Run at that offset, but
calculate position/size from the previous Run. I simply overlooked
this when starting over - and didn't try different font sizes, so
using the returned Run for cursor calculations was fine.

Anyway, it's is linked to this:

Martin> ... and if you press "superscript" or "subscript" the cursor
Martin> immediately changes size and location correctly. This didn't
Martin> used to work. Also changing font size immediately changes the
Martin> size of the cursor. This also didn't use to work on new lines
Martin> after hitting return.

It's impossible for the code to distinguish between these two
cases. In the first it should return the size of the previous Run, in
the second it should return the size of the current Run (being the
first and only Run having the new font properties).

I can only guess at how to fix this, but it probably introduces other
problems: have all font style/size changes be marked by an empty Run
which cannot contain the point. Then the "return-size-of-previous-Run"
semantics of the old code would work in both situations.

Implementing this would be beyond my knowledge of AbiWord
though. Alternative implementation suggestions and/or actual
implemetations of this appreciated :)

Martin> In addition inserting Fields leads to the following assertion:

Martin> **** (23) FP_RUN_NOT != containsOffset(iOffset) at
Martin> fp_Run.cpp:1022 **** **** (23) Continue ? (y/n) [y] : y

Martin> and the cursor is positioned before the field instead of after
Martin> the field.

I can reproduce this (well, not the assertion, but the cursor
stuff). FWIW the old code also fails at this. I think I know how to
deal with this.

Cheers,
Jesper



This archive was generated by hypermail 2b25 : Mon May 29 2000 - 04:25:41 CDT