> How should the viewer render the segments? Should it show the text as
> "one" document (i.e. merge the current and next/previous segment)?

Yes, that was my thinking.

> That would require two simultaneously opened records and also *MAJOR*
> changes to several parts of the viewer (like the scrolling, session
> handling, etc.)

Hmmm.  Not good.  Would that be the code in session.c?  Are you
thinking of the History and HistoryData data structures?

> Possible solution: include the total number of paragraphs in every
> segment.

Yes, I was thinking last night that at the top of each non-first
chunk, we'd need the previous chunk ID, the total # of paragraphs in
the page, and the # of paragraphs in the chunks preceding this chunk.

OK, today's proposal:

We use three function codes.  Function code 1,
START-OF-MULTICHUNK-DOC, provides two 16-bit parameters: the total #
of paragraphs, and the record ID of the last chunk (for jump-to-end).
Function code 2, CHUNK-BEGINNING, provides 3 16-bit parameters: the
total # of paragraphs, the # of paragraphs preceding this chunk, and
the record ID of the previous chunk.  Function code 3, CHUNK-NEXT,
provides a single 16-bit parameter, the record ID of the next chunk in
the series.

The first chunk of the page contains at the start
START-OF-MULTICHUNK-DOC and CHUNK-NEXT, and at the end another
CHUNK-NEXT.  The start of each of the other chunks of the page has
CHUNK-BEGINNING and CHUNK-NEXT, and CHUNK-NEXT again at the bottom to
mark the end, except for the last chunk, which has no ending
CHUNK-NEXT.

> A scrollbar/jump location relative to the number of paragraphs could
> be a problem. In a document that is one huge paragraph the scrollbar
> would not be of any help to the user. Neither will the scrollbar/jump
> location be updated while you scroll *within* a paragraph. Could be
> confusing.

We currently have a max-paragraph-size of 1000 characters for plain
text, and 3000 for HTML.  Anything larger gets broken up into multiple
paragraphs.  So for example the AFS FAQ that I use as a plain-text
document has 73K of text, but gets broken up into 273 paragraphs.
That page gets split into 3 chunks.  The first has 125 paragraphs, the
second 104, the third 44.

I was also thinking, I suppose, that we could have a sort of hybrid
approach to the scrollbar.  The paragraph count would be the rough
guide, with actual lines on screen providing some fine detail within
that.

Bill

Reply via email to