[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev 2.8.2dev.21 page count broken?
From: |
Bela Lubkin |
Subject: |
Re: lynx-dev 2.8.2dev.21 page count broken? |
Date: |
Mon, 3 May 1999 19:07:11 -0700 |
Johnny Tevessen wrote:
> Bela Lubkin (address@hidden) schrieb:
>
> > The full document has four pages on your display size.
>
> I think I do understand now how Lynx generated this counter.
> Many thanks!
> Still I think the counter in the upper right corner
> is confusing in such situations and should refer to the
> full page, ignoring any fragment pointer ("..#foo").
It is doing that!
> "Page A of B" just looks like: "This is page numero A.
> There are B pages in this document.", and "A" being
> an index of all accessible pages inside of the
> range 1..B.
There *are* B (4) pages in the document. But the fragment points to a
position inside one of those pages, so, although Lynx claims this is
"page A", it's actually some place inside page A (and covers part of
page A+1). This happens because Lynx doesn't force 1:1 alignment
between document pages and screen pages.
Go to the URL, then hit ^A or HOME or whatever your keymap uses for the
Lynx "HOME" action. Now you are on the true page 1, and can page
through all 4 pages.
When you go to a fragment, you don't get a restricted view of the
document; you get the whole document, with the specified starting
position (which, in this case, isn't exactly on the start of a page).
So it wouldn't make sense to give "fragment-relative" page numbers.
It *might* make sense to give more precise information than now, e.g.:
inside p1 of 4 [i.e. end of 1 + beginning of 2]
inside p2 of 4
last page of 4
Would that have made more sense?
>Bela<