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 - 10:22:48 CDT


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

Martin> On Mon, 29 May 2000, Jesper Skov wrote:
>> 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).

On second thought - this can be recognized since selecting font
size/whatever introduces a FMT marker. All I have to do is stop
scanning when seeing one of these. I will try that.

Martin> OK here is what I think should be done. You are the third
Martin> person that I know of who has tried to fix this code via the
Martin> method of locating the run on the line. I was another. I think
Martin> that boundaries between different runs should be put in a too
Martin> hard basket and delt with via a seperate piece of code.

Martin> This code would calculate the cursor size and location
Martin> directly from the font and super/sub scriptness of the current
Martin> entry point. The x coordinate is just what is already
Martin> calculated. This code basically duplicates the line height
Martin> calculation code. You could just copy the revelent bits fron
Martin> fp_Line and put it into a new function within
Martin> fl_Blocklayout. Initially just use the string passing code to
Martin> get the character properties. Later the new function could use
Martin> Sam's new piece table accessor functions he proposed a few
Martin> days ago.

Martin> What do you think?

I don't quite grok all that. What function/method are you thinking of?

Anyhu, if Sam is going to make some changes that might invalidate that
(or even the work I've already made), I'd rather wait and see.

Jesper



This archive was generated by hypermail 2b25 : Mon May 29 2000 - 10:22:54 CDT