Tumble feedback

[Paul Williams]

Eric,

In a previous message (2003-09-17) I explained that I was having 
problems with a complicated set of bookmarks and that I had resolved the 
problem of moving up the tree without outputting a page with a construct 
like this:

bookmark "2.2" {
    bookmark "2.2.1" { label ; };
};
bookmark "2.3" { page 9; }

in order to put all three bookmarks on one page.

I've since realised that I fooled the parser, but that the output wasn't 
correct.

I've made a small test case that shows two problems with bookmarks and
placed the files here: http://vt100.net/tumble/

When I tumble this and view the PDF in Acrobat 5.0.8 for Linux, I can
see two problems.

Firstly, the bookmarks for 5.5.4 to 5.5.7 don't appear at all, so
putting "label ;" in the .tum file didn't solve my nesting problem.

Secondly, going backwards and forwards through the document with the
bookmarks fully expanded shows the highlighted current page skipping
about erratically. On page 1, it correctly highlights 5.5.1. On page 2,
the highlight skips back up to 5.5, and on page 3 it recovers and goes
to 5.6.1.

I've had a look at the outline objects in the PDF and there don't appear
to be any problems with the links between them. I've had a look at a
much larger PDF with a nested ToC (Adobe's PDF Reference) and it works
correctly, but I couldn't see any difference in the object structure.

Incidentally, this second problem is unrelated to the absence of some of 
the bookmarks: it still goes wrong when I deleted them from the .tum file.

 From a cursory look at the code, it appears that the data for the 
missing bookmarks is forgotten about when the closing brace for bookmark 
"2.2" is reached. The bookmark information should have been written out 
to the file when a page was generated, but I haven't output a page at 
that point because I put the label in instead.

I wonder if the simplest way of solving this problem is to completely 
separate the generation of pages from the making of the bookmark tree.
If the pages were output first, we would know all their PDF object 
numbers, and then the bookmark generation would appear in the .tum file 
almost exactly as it is now (perhaps using the word "target" or "dest" 
instead of "page"), and the PDF object numbers for pages would be looked 
up at that point.

I think that building the outline in this fashion might also solve the 
second problem of misplaced highlighting. In the section of the PDF 
Specification on linearized PDFs, there is a hint that the best order 
for the objects of an outline tree is to skip any subtree that is closed 
(as tumble's subtrees always are), and then go back and fill in the 
subtrees after the top level objects have been made. I wonder whether 
Acrobat relies on this ordering to get highlighting right.

I was going to test the theory by running pdfopt (part of GhostScript) 
on miniman.pdf, but it crashes!

If I get time at the weekend, I'm going to have a go at hacking a 
"correctly" ordered outline tree into miniman.pdf to see if it corrects 
the highlighting. If it does, I think that separating outline (bookmark) 
generation from page output is necessary, because it is the only way to 
output all the subtrees after the top level.

Sorry for the length of message again! If my explanation is unclear, I'd 
be happy to have another go at it, because I really would like outlines 
to work in tumble.

Regards,
Paul