Re: Info reader fails to find cross-references to anchors

[Gavin Smith]

On 18 July 2015 at 20:44, Eli Zaretskii <address@hidden> wrote:
> The slack could help with nodes, where you have the name of the node
> to search for, but it cannot help with anchors, where all you have is
> the position, which therefore needs to be accurate.
>
> So why not strip the CRs to begin with, and not rely on any slack?

We adopted this method to cope with files whether the CRs were counted
or not, because there were some files out there in the wild where they
were counted.

I thought that this method was satisfactory, but I admit that I hadn't
realised that anchors positions present a problem. The problem is
reduced because we deliberately start with a small slack (4, not 1000)
before running the end-of-line conversion, to encourage the conversion
to happen early. There will only be a problem if a node containing an
anchor is found before the conversion happens, which is possible for
the first node in a file, which is likely the Top node which is
unlikely to contain an anchor. The other time when I imagine things
could go wrong would be for an anchor in the first node in a subfile
of a split file. Have you had either of those problems or other
problems happen when testing?

Possibly the case of CRs not being counted can be detected by looking
at the offsets in the indirect table for subfiles and seeing if they
match the sizes of subfiles as read.

>
> (Btw, that small slack will fail if the preamble uses non-ASCII
> characters, no?)