Subject: Re: Calculating Cursor Size ar Run boundaries.
From: Jesper Skov (jskov@redhat.com)
Date: Tue May 30 2000 - 15:46:13 CDT
>>>>> "Martin" == Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au> writes:
Martin> Hi Jesper, You've done a great job in sorting out the
Martin> findpointcoords code. However I think there are cases where
Martin> we will want to go beyond what is inherent in the assumptions
Martin> in this code. The best example is inserting a superscript
Martin> chaarcter into the first poistion of a pre-existing
Martin> superscript run. Right now this is impossible. If you position
Martin> the cursor before the superscript run the text will be entered
Martin> as normal. If we change abi behaviour so that text is inserted
Martin> as superscript text cannot be directly entered as normal. The
Martin> only way to solve this is to have the capability to move the
Martin> insertion point in the piece table, without moving the cursor
Martin> in x on the screen BUT updating the cursor size and position
Martin> to reflect the insertion point in the document. So I move the
Martin> cursor to the end of a string of normal text. The cursor shows
Martin> normal size and location. I press ``forward arrow''. The
Martin> cursor stays fixed in x but jumps up on the line and changes
Martin> size to reflect insertion as superscript. This cannot be done
Martin> with the current findpointcoords code.
I agree with how it should behave - I don't know what Joe User would
think of having to make an extra cursor move when passing a font
size/type barrier. I guess it could be made a config option if it
would be against anybody's religion.
Martin> My suggestion is to calculate the cursor size and height for
Martin> ambiguous cases using the Piece Table information
Martin> directly. The code below shows how this information is
Martin> currently accessed (horrible isn't it?).
[snip]
Calculating the size/pos isn't the problematic part per se. In order
to get this work, there would have to be added extra Runs so it's
possible to describe the location of the IP:
smalltextBIGTEXT
0123456789abcdef
If the code is asked to find the IP for offset 9, it cannot - even by
looking at the Piece Table - figure out which side of the position
between 8&9 it should take the sizing information from. There's simply
not enough state (unless you tried to tell me how to get that state -
I didn't understand it if so, sorry).
From what little understanding I have of how stuff happens at this
level, on changing format (font size, super/sub script, etc) a FMT
marker is inserted:
smalltext<FMT:BIG>
0123456789
This marker is deleted as soon as some text is added since the
formatting information can then live in the Run (type 'B'):
smalltextB
0123456789
Now, there's probably a gazillion places that are designed and
implemented to handle things that way. But I'm wondering if a fairly
simple way to achieve the goal wouldn't be to leave that marker in the
text:
<FMT:small>smalltext<FMT:BIG>BIGTEXT
0 123456789a bcdef01
The visual presentation would look like it does now, but putting the
IP on offset 0xa would result in a cursor matching the smalltext size
and position 0xb would result in a cursor matching the BIGTEXT size.
I don't know how much of an impact this would have on the existing
code. It may be minimal, it may cause major problems.
Comments?
Ta,
Jesper
This archive was generated by hypermail 2b25 : Tue May 30 2000 - 15:46:24 CDT