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 <ja...@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@lists.runrev.com <javascript:;> > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
