The viewer scans backwards from the <a name=> tag to
the first <p> tag PRIOR to it.
    

The *viewer* isn't really that intelligent; it just 
jumps to the position the parser tells it to jump to...
My explanation was meant to show the practical result, but I guess I should have been more careful.  Here is an explanation from one of the bugs filed on this:
This is a known shortcoming of the DB. A named anchor is represented internally by the record ID and the paragraph # inside that record. So multiple anchors in the same paragraph (as per the example above) will practically speaking conflate into the same anchor. To fix this, we'd need to change the way in which text is represented, either trivially by adding a new function code to the existing text record type, or as part of a more radical restructuring of the text record type.
This still appears to be a viewer problem, rather than parser.  The bug I reported was in an HTML file that had many long lists separated by <br><a> pairs.  In this case, the viewer cannot jump to the right place .  There are no requirements in the W3C HTML standards that require an anchor tag to be in close proximity to a paragraph tag, yet the viewer will not do the right thing if this is not the case.

However, someone has to volunteer to do it...
I'm a Java programmer these days.  Don't think you'd want _me_ messing with the parser or viewer code ;-)

Ed




Reply via email to