Asger Alstrup wrote: > I believe that a fixed sized scroll bar is a significant regression in > terms of usability.
I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. > Also, I think that a very unreliable scroll bar is a problem. The scroll > bar can change a few pixels, but if it jumps much more than that, it is > confusing. It shouldn't jump at all (otherwise is just a bug). > I did not test the new scrollbar, but if you use a uniform estimated size > on all paragraphs, I think the obvious thing is to improve this by > estimating the height as a function of the number of characters in the > paragraph and the width available for the paragraph. You can define a > function for this which calculates in constant time by using mean values > for the character width and word length. Constant time per paragraph, O(number of paragraphs) total time > To improve further, consider the insets in the paragraph by having a > default size for each type and take that into account. Now, we are linear > time in the number of insets, but no loading or rendering of insets are > necessary to get the estimate, so it is still very fast. The biggest problem seems to be very high insets, like long tabulars > If this is still not accurate enough, then I'd go for better handling of > the biggest elements that can appear in a document: images, tables and > such. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. > Ultimately, if such patching up does not fix the problem, we have to admit > that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. > The scrollbar is one of the single most important features in a word > processor. You use it all the time. You want that to be reliable and not > seem strange. Sure, it is important. The problem is if what we have is good enough or not. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). Alfredo
