I plucked a long Web page the other day, and it came down to the Palm split into 4 records. I hate that. The scrollbar doesn't work -- it only shows you the relative location in the segment of the page you are in, not in the real page. There are these clunky "Click here to get to the next part of the page" links at the top and bottom. All in all, a really lousy experience.
So I started thinking about how to fix it, at least in the database format. It would have to be backwards compatible, so that you could use an older viewer with DBs plucked in the newer format. Here's what I came up with. Change the parser to put some additional codes in the text records. We use up another of the remaining function codes, and call it SPLIT-TEXT-GLUE. It takes three bytes as arguments. The first byte is split into two fields, a two bit and a 6 bit field. The two bit field has these four values: 0 - RESERVED 1 - whole-page paragraph count 2 - previous chunk record ID 3 - next chunk record ID If the two-bit field is "whole-page paragraph count", the 6-bit field contains the number of chunks the page is split into (is 64 enough? And do we need this info at all?), and the remaining two bytes contain the total number of paragraphs in the page. If the two-bit field is "previous chunk record ID", the next two bytes contain the record ID of the immediately preceeding chunk of the page. If the two-bit field is "next chunk record ID", the next two bytes contain the record ID of the immediately following chunk of the page. When a page is split into chunks, a function code with the "whole-page paragraph count" is inserted at the very beginning of the text of the first chunk. A function code with "next chunk record ID" is inserted at the end of the text of every chunk except the last one, just before the inserted link that says "Click here to go to the next section". A function code with "previous chunk record ID" is inserted at the front of the text of every chunk except the first one, just after the inserted link that says "Click here to go to the preceeding section". In the viewer, the "percentage shown", and the scrollbar display, are changed to key off the total number of paragraphs in the page, using the standard paragraph count in the text record if no "whole-page paragraph count" function code appears at the beginning of the text. To glue together text segments, the viewer uses the "previous chunk record ID" function code as the *real* start of the text, thereby skipping over the inserted links and not displaying them, and the "next chunk record ID" function code as the *real* end of the document, again skipping over the inserted links. Older viewers will simply ignore the extra function code and display the chunks as they presently do. Comments? It's easy to hack into the parser. How about the viewer? Does this provide enough information to actually implement the necessary viewer changes? Bill
