[pdftex] \escapes and /Limits

[Karl Berry]

(I apologize in advance for not knowing enough to be sure if I really
understand what's happening, not to mention the complexity of the
question.)

At the moment, I'm having texinfo.tex create destinations for outline
entries whose names contain PostScript string escape sequences.  (\no),
for example, that is, when interpreted, the two characters "newline" and
"o".  (Ultimately, it calls (line 1253)
  \pdfoutline goto name{\no}count-0{foo}
where the \ is catcode 12.
)

The problem is that the resulting outline entry in the PDF file cannot
be followed, i.e., clicking on it does nothing.  (Both xpdf and acrobat.)
(In the attached pdf, go to page 2, then click on the `foo' outline
link, and observe that nothing happens.)

It appears to me that the generated PDF file may be incorrect.  With the
attached test file, run through the attached (unreleased) texinfo.tex,
the resulting (also attached) PDF contains:

    /Names [(-1) 13 0 R (1) 4 0 R (\no) 5 0 R]
    /Limits [(-1) (\no)]

The /Limits should be, I believe, [(\no) (1)], where (\no) is the
lexicographically least (since the \n is interpreted as a newline) and
(1) is the lexicographically highest.  (I tried editing the PDF file by
hand, but it had no effect.  Don't know if that means my whole analysis
is wrong!)

If I change the Texinfo @node (= PDF destination) to, say, foo\no, the
outline entry works.  This is because, I hypothesize, that /Limits is
then correct (it is [(-1) (foo\no)]), since there's no problem sorting
on `f'.  It's sorting on the ASCII `\' (instead of the newline character
resulting from the string interpretation) that causes the problem.

This has nothing to do with Texinfo in particular.  I could construct an
example just using primitives and writing a catcode-12 \, then n, then o
destination.  It would be quite a bit of work, though, so I hope the
Texinfo example will suffice.

(Aside: the (-1) and (1) Names are simply destinations for the pages of
the documents, using the page numbers.  And the actual text `foo' of the
outline entry comes from the @chapter text, which can be anything and is
irrelevant to the problem.)

I looked at pdftex.ch, but I could not understand it well enough.

Can anyone here confirm or deny my hypothesis?

Thanks,
karl

P.S. I'm not looking for a workaround.  It took me hours to get to this
point, and I know I could change texinfo.tex to write \\no, and then it
works (/Limits is then, not surprisingly, (-1) (\\no).)  I'm just
wondering if this is a bug in pdftex -- if this analysis is correct, I
don't think the TeX document should have to be aware of PDF string
escapes!

(If all this is correct, the best fix might be for pdftex to make the
/Names entry be \\no, to avoid the string interpretation.)