Find the scroll location in wrapped field

[Mike Doub]

I was hoping that the page ranges bug would get fixed.  I am trying to do
this myself but not being able to tell where soft  line breaks occur has me
blocked.

Some one posted a summary sizing of all of the different parts of a
character.  Unfortunately I can't find it.   Now that I know about
formattedrect I will give that a try for each char in a line and see if I
can simulate the word wrapping of a line to get the info I need about how
the line was split.

The original requirement was to keep a user selectable location in the same
position vertically as the text is resized.  But I am still trying to get
past the page ranges bug for basic page turning functionality.

 Anyway, I am learning a lot and plan to keep adding to my MasterLibrary
and will keep sharing info.

-= Mike

On Wednesday, November 19, 2014, James Hale <james at thehales.id.au> wrote:

> >
> > I am trying to build a special purpose e-Book where the user can shrink
> and
> > expand the text as needed with everything scaling, looking really nice
> > with fluid page turning.
> >
> And this is why you want to locate the line. If I understand, you want the
> line that is positioned at the top of the field before a size change to be
> still at the top of the field after. This is not easy. Even Apple don't do
> it in iBooks.
> I chose to break my text up into pages and on a text size change simply
> recalculate the paging. It would not be any significant extra to identify
> say the line at the top before the size change and then locate that line
> after and load it's possibly new page into the same window after. It
> wouldn't be at the top, but it would still be on the page they were looking
> at. Not as smooth as you describe but it might be the best you can do at
> this time.
> BTW the time to break up a long piece of text into pages is really pretty
> small. I haven't checked with v7 but with a lot of text it might be quicker
> than loading all the text in a single field given filling a field (which
> has taken a significant hit in moving through 6 to 7 from 5.5) now takes
> longer.
>
> Whatever workaround you come up with would be worth sharing.
>
> James
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com <javascript:;>
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>