On Mon, Nov 05, 2001, Bill Janssen wrote: > How about the viewer? Does this provide enough information to > actually implement the necessary viewer changes?
How should the viewer render the segments? Should it show the text as "one" document (i.e. merge the current and next/previous segment)? That would require two simultaneously opened records and also *MAJOR* changes to several parts of the viewer (like the scrolling, session handling, etc.) How do you jump to another segment? E.g. if you are in the first segment and select "Jump to bottom" the viewer would have to parse *all* segments between the first and the last to know what segment it should jump to. That would be slow... Possible solution: include info about the next/previous record at the top of each record segment. That way the viewer can find the record reference without parsing the whole record. 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. When a named anchor points to a different segment than the first one you would have to traverse back to the first segment to know the total amount of paragraphs or you can't set the scrollbar/jump location. Possible solution: include the total number of paragraphs in every segment. That would leave us with a function code that requires twice as much data (6 bytes). Anyway, I doubt 6 extra bytes per segment will be a problem... /Mike
