RFE for khtml--where to file? (Vertical alignment of last page when paging with pageup/pagedown)

[Randy Kramer]

I want to submit an RFE for khtml (at least, I think that's what it should be 
applied to--I'll describe the request below)--it seems that there is no 
"major category" for khtml in kde's bugzilla (or did I miss something?), but 
instead there are khtml sub-categories under things like konqueror, quanta 
(iirc), kfm(??), kmail, and probably others.

The RFE is (for me) most directly applicable to konqueror and for an 
application I'd like to build which I think (based on my limited knowledge at 
this point) will use the khtml part without konqueror--should I file it under 
the khtml sub-category for konqueror or is there some better place?  (Aside: 
I also want the same behavior in kmail.)

One reason I ask is that bug 93196 
(http://bugs.kde.org/show_bug.cgi?id=93196), which *could* be an alternate 
solution to my problem, was closed as invalid, presumably because it was 
filed against the wrong component (kdelib instead of khtml).  I'd like to 
make sure I get the request in the right place.  (Over on bug 76082 there is 
some speculation about other reasons bug 93196 might have been closed.)

The request is this (I want to make this as concise and clear as 
possible--suggestions welcome):

Title: Make khtml pageup/pagedown vertical alignment the same for the last 
page as all other pages of a long web page.  <Using "page" with two slightly 
different meanings in the same sentence makes the writeup confusing--need to 
improve the choice of terminology somehow.>

Description: In most cases, when you use pageup/pagedown to "scroll" through a 
long web page, after each pagedown (except the last) the text is vertically 
aligned so that the last line or two from the previous page are repeated as  
the 1st line or two of the next page (and the next line to read is the 2nd or 
third line), in other words there is some overlap.  This makes it easy for 
your eyes to find where you left off and resume reading.  (And, if you had a 
lapse of attention while paging, there is some context on the page to help 
you remember what you were reading.)  (I'm guessing that the overlap is a 
certain number of pixels, and thus the number of lines of text repeated 
depends on the size of the font?)  

<digression>
I may file other RFEs related to this one:
   * I'd prefer that the overlap be a certain number of lines rather than a 
certain number of pixels (I'd vote for two).  Because the overlap appears to 
be expressed in pixels, sometimes the overlap includes partial lines of text, 
in other words, you don't see the full height of the characters/glyphs(??).
   * at least one webpage/URL that I've seen recently didn't work as 
described, instead a line of text was missed--it wasn't visible at the bottom 
of one page nor at the top of the next--I had to scroll up "manually" to find 
the missing line--I'll include that URL when I submit the RFE or a separate 
bug
</digression>

<resuming the "Description">
On the last page, this does not happen, the page is aligned so that the end of 
the "text" is at the bottom of the screen, and the last line from the 
previous page is somewhere on the page, but not at a consistent location.  My 
request is that the behavior on the last page be changed so that the next 
line to read is 2nd or 3rd from the top, just like all the other pages.

Of course, in that case the last page will not fill the entire frame, and a 
decision would have to be made about how to render the bottom of that last 
page.  I can imagine a number of alternatives, but I'm not sure that I know 
enough at this point to say that any of them would be unacceptable--maybe the 
developer that works on this wants to propose what is the best and/or easiest 
solution to see if there are any immediate or obvious objections.  

Some of the approaches I can think of:
   * just fill out the remainder of the page with white space
   * like above, but add a horizontal rule to mark the actual end of the page
   * vertically shrink the frame to enclose just the remaining text on the 
page (this does not sound so good to me, but I wouldn't think it's the 
easiest, either, so hopefully it won't be considered)
   * ???

There are other things I might mention in the RFE, but they may confuse the 
issue:

   * I note that the two different methods of paging through a long document 
(pageup/pagedown vs. clicking above or below the elevator on the vertical 
scrollbar) behave slightly differently--the pageup/pagedown approach repeats 
(as described) the last line (or two) of the previous page at the top of the 
next page, while the click above or below the elevator bar seems to move 
precisely a page, with no repeat of lines of text from the previous page.  
I'm not sure there is a reason for this difference in behavior, but nor do I 
have any problem with it--I prefer to use the pageup/pagedown method of 
scrolling (in most cases), and will be happy if this RFE is applied to the 
pageup/pagedown method of scrolling.

   * I've mentioned pageup but have been focusing on pagedown--without getting 
into detail, pageup should move back in a manner similar to the way pagedown 
moves forward (i.e., leaving a line or two of overlap on each pageup).  But, 
for the first page, I don't know if there is any need to align the text so 
precisely as I'd like when downloading to the last page--at first thought it 
seems that:
   * when you are paging backward (towards the top of the document) you are 
not serially reading, but instead skimming backward to find something
   * that it makes little or no sense to page so that the beginning of the web 
page starts partway down the page with leading whitespace

I'll experiment with that some more before filing the RFE.

Thanks,
Randy Kramer