> I'd prefer for it to precede the DoNamedAnchor function because if it isn't > there I won't have to waste time looking for it.
I like that myself. V.3 of patch enclosed. Again, compiles but not tested. So, a new specification is this: 0x00 0x9A byte1 byte2 (DoSetTargetByteOffset) If it is invoked, this function must come right before a DoNamedAnchor function. DoSetTargetByteOffset sets the byte offset of the target of the following DoNamedAnchor function to 256*byte1 + byte2. The byte offset is measured from the beginning of the paragraph. A DoNamedAnchor function without a preceding DoSetTargetByteOffset function acts as if the byte offset were zero. Undefined behavior results if DoSetTargetByteOffset is issued but not immediately followed by DoSetTargetByteOffset. [[ I could weaken this last statement and allow DoSetTargetByteOffset to be issued anywhere between the last DoTable, Do*Image, and DoAnchorEnd and the DoNamedAnchor. In fact, that is how the enclosed patch works. But keeping this more rigid might make it easier to make viewers for some other platforms. ]] Backwards compatibility: Older viewers should ignore any instances of a DoSetTargetByteOffset and go to the beginning of the target paragraph, just as before. Therefore, texts in the new format will be backwards compatible, except that the new viewer feature of seeking to a precise position from link will not be available. Expectation from viewer: Conforming viewers will align the link's target with the top of the display unless display options make this impossible (e.g., text on last screenful), or else will try to make the link's target conspicuous in some other consistent way. It is to be guaranteed, in any case, that any text right after the target byte be displayed on the screen. Alex
exactAnchor3.diff
Description: Binary data
