But I have a suggestion that might make it even more manageable, at least for the reader.
Is it possible to build in some 'binary chop'-type mechanism which would speed paging through it?

There are currently 291 pages of entries. (Call it 292 to make it easier to divide by 2 !)

But actually call it 300, or better 320.

So when it comes up give the option to spring to half-way, to spring to page 146, being half-way between the beginning and the end.

(But if using the rounded figures, then half-way would be either 150 or 160. But calculating a mid-point is easy to do and wouldn't really need pre-set figures)

Then from there have a half-way point to both the beginning and end.

So springs to pages 73 and 219 would be provided from page 146, being the mid-points between the mid-point and the beginning or end.

Then from page 73, springs to 36 and 109 (which is easily calculated by working out the jump distance from 73 to the beginning and halving it, giving 36. 73 plus 36 = 109,( round it up to 110 ???)

Then from 36 to 18 and 54, and so on.

Obviously the page numbers would differ for each level that you're at, so the 219 would then provide 183 and 255.

And they would provide further jumps of 18 page distances..

Another level would then provide jumps of 9 page distances.

I think once down to that level, then the existing ability to jump 4 pages at a time would be sufficient.

It would be simple to code.

Just take the existing step value, halve it, then add or subtract that new step value from the current location.

Anyhoo, just a thought.

I am fully aware you have many other demands upon your time.

And, again, thank you for working so hard.

Julia.