Line numbers for soft-wrapped styled text?

[hh]

I see, you are optimizing this. Will become perfect.

The current search is part of a script that has to work also for
non-wrapped text (with possibly horizontal scrollbar) and is a first
step for calculating the visible "chars" (incl. whitespace).

In sum: you are right, the search for the lines can/should be
optimised (you already show a way to go).

From my point of view it has to be a rough estimate only, can be a
full line off, could stop after finding this 'top line' L1, using
then, say, L1-2 to be on the safe side.

*** My approach would then be to start calculating (or collecting, by
using the selectedLoc):
Walk through the string from there, line by line, as one needs the top
of each single 'visible' lines at any rate for the numbers display.
Then compare these found tops with the top and the bottom of the field
and decide when to start and when to stop. *** 

Of course, if one would like to know only the line numbers, then a 
binary search (optimised in your sense) for the bottomLine could/should
also be done.

This is essentially the same problem starting with a downward shifted
text. This again shows immediately that all your considerations are true
and will lead to an improvement.

So this could then use the same algorithm and adaptive guessing, returning
this time L2+2, to be on the safe side.

By the way:
The problem 'space-below' is probably a general problem of the current
text measurement, because for some fonts with extreme metrics ('Zapfino')
or others with wrong/incomplete metrics we have wrong measurement values.
This leads to the bug which I have seen (and seen reported as bug) that
the insertion cursor is up to a full line "off" (in direction top) and of
wrong height.

I'm looking forward to your complete solution. Perhaps one could even try
to draw a ruler with ticks at the exact line borders for styled text.

> Alex T. wrote:
> 

> 1. this uses a linear-interpolation for its initial guess for the 
> topline (i.e. the percentage, set to  vs / formattedheight). This is good.
> But it then uses that same value of percentage for the initial guess of 
> the bottomline - which seems totally wrong. Should it not use a 
> different percentage
> (specifically, the height of the field / (formattedheight - vs) with 
> maybe a minor tweak for margins) for starting on the bottomline calculation?
> 
> 2. After the initial percentage calculation, all the recursive calls 
> just revert to simple binary search (i.e. percentage = 0.5).
> Since the initial one is just an estimate, and can be thrown off by 
> variable line heights, this initial guess could be on the "wrong" side 
> of the actual answer - and hence all the rest of the recursive 
> iterations are done this "slow" way.
> Why not recalculate the percentage for each recursive call ?
> 
> 3. not so much a question as a bit of philosophical question ....
>        is a line "visible" if it occupies screen real-estate but has no 
> visible pixels on the screen ?
> i.e. the formattedRect has the same problem (if it is a problem) with 
> spacebelow as I mentioned earlier for formattedheight, so if the top 
> line within the visible field consists solely of the spacebelow a line, 
> then that line will not be included in the visibleTextLines().
> 
> Like I said, that's probably a philosophical question - but it does have 
> implications for how one could then set up the lineNumbers field; I 
> think you have to start it on the line before the "topline" form this 
> calculation, and then set the vscroll of the linenumbers field to match 
> the formattedrect of the next line of the original field (because you 
> can't set a negative vscroll value, so this is needed to push the first 
> visible line number downwards).