Re: Calculating Cursor Size ar Run boundaries.


Subject: Re: Calculating Cursor Size ar Run boundaries.
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Tue May 30 2000 - 17:44:01 CDT


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30 May 2000, Jesper Skov wrote:

> 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.
>

Well, currently this is how the cursor moves if you are in WP reveal codes
mode (probably the greatest word processor feature ever). However, I
don't think any WP normally moves like this. It might become a problem if
you had to move individually over lots of different formatting
instructions.

>
> 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
>

The fragments look like this:
        FmtMrkFragment 0x832f750 api[80000001]
(from a ptbl dump).
        Run: 0x82c3b68 T=FmtMark Off=14 Len=0 D=n Line=0x832c1d8 [x 72 y 0
w 0 h 19
(from a formatter dump).

> 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

You can see this from the debug messages:

DEBUG: Edit:InsertFmtMark [blockOffset 14]

and

DEBUG: Edit:DeleteFmtMark: [blockOffset 14]

>
> 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.

If you want to generate the cursor motion you describe, this sounds like a
good idea. Keeping all that info in the ptbl would make it more
comprhenisble, but I don't know if it would destroy the whole structre.
           
                                     sam th
                                     sam@uchicago.edu
                                http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5NEQ0t+kM0Mq9M/wRAlECAJ9NwhG6w7Yvid+G6lGmplZXAFiKkACgkeQF
u1z4cujp3+/eLIOabKIrkhI=
=Ttqx
-----END PGP SIGNATURE-----



This archive was generated by hypermail 2b25 : Tue May 30 2000 - 17:44:25 CDT