Doesn't the compressed data contain a compressed-length field somewhere that the zlib library uses? If so, the viewer can use that to find the end of the compressed data.
If not, then only a touch more work is needed. We have seven flag bits available in each record. Make bit 1 signal whether we have additional data at the end of the record. (The format specs require bits 1-7 to be set to zero in 1.6+ documents. Bit 0 was introduced in 1.6 to signal continuations.) Then, if bit 1 is set, the last two bytes of the record contain the byte offset to navigation data from start of record. Finding the last two bytes of the record is easy: MemHandleSize(recordHandle)-2. Actually, even if the compressed data contains a length field, this is a more elegant solution, since this way we do not have to know anything about the compression, and can get the data in exactly the same way whether or not the record is uncompressed, doc compressed, zlib compressed, or compressed in some way we don/t yet support.
Then we should make sure that the navigation data structures (I haven't paid attention to all the iterations of the discussion, having been busy with a closed source project, my shareware Clie Skinner vg/sb skin loader--www.prussfamily.us/skinner.html) are extensible so we can add more.
This will break some old versions of the Zaurus (I think) viewer which used the whole byte instead of bit 0 to mark continuation, but this was before the official format for continuation markers was set, and it was a long time ago, so I don't think we should worry about it.
Alex
p.s. If Robert O'Connor is reading this, please contact me. Email from me doesn't seem to be getting through to you...
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133 U.S.A.
e-mail: [EMAIL PROTECTED]
online papers and home page: www.georgetown.edu/faculty/ap85
--------------------------------------------------------------------------
"Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
- Paul of Worczyn (1424)
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
