Tumble feedback

[Eric Smith]

> Question 1. It wasn't obvious how to add a bookmark without having some
> other effect on the document, such as outputting the next page. I had a
> situation where I wanted to represent this fragment of TOC:
>
>     2.2 two point two ................ 9
>       2.2.1 two point two point one .. 9
>     2.3 two point three .............. 9
>
> and I though at first I could do this:
>
> bookmark "two point two" {
>    bookmark "two point two point one" { page 9; };
> };
> bookmark "two point three" { page 9; };
>
> but that's no good because I've someone incremented the pointer past
> page 9 by referring to it the first time.
>
> I eventually found that I could satisfy the parser by putting in a
> "label ;", like this:
>
> bookmark "two point two" {
>    bookmark "two point two point one" { label ; };
> };
> bookmark "two point three" { page 9; };
>
> and that works (and the label doesn't appear to do anything), but I
> thought it would be neater if I could just remove the "{ label ; }"
> section altogether.

Interesting, I hadn't realized that there was a problem, or that putting
in a dummy label would fix it.  The control file syntax is not very
good, which is why it isn't yet documented.  I'm trying to figure out
what it should be, so any suggestions are welcome.

The main thing I need to fix is the assumption of one-to-one correspondence
between the input and output pages, but other problems such as bookmark
nesting need to be fixed as well.

> Question 2. I know that a bookmark is just a point in the document, but
> sometimes a section goes on for several pages. It seems to me that there
> are two ways of describing this in the control file.
>
> With the first way, the section appears to "own" all the intermediate
> pages:
>
> bookmark "section 2" { pages 1 .. 10; };
> bookmark "section 3" { page 11; };
>
> The other way is:
>
> bookmark "section 2" { page 1; };
> pages 2 .. 10;
> bookmark "section 3" { page 11; };
>
> Is there any difference in the way that these two are represented in the
> PDF? I don't want Acrobat to get confused when I'm going backwards or
> forwards through the pages. (I could experiment more, but I only get
> limited opportunities to use a Windows box and Acrobat -- and xpdf on my
> machine doesn't show me the ToC anyway!)

Those should produce identical output.  The only reason that a bookmark
is treated as a container is to provide a way of specifying nested
bookmarks.

> I'm quite prepared to do the positioning of the JPEG myself, if the page
> dimensions can be taken from the first image that forms it (ie. the
> TIFF). I would probably erase the TIFF version of the photo to give
> myself some leeway, and then I'd would just composite with something like:
>
> page { image "main.tiff"; image "pic1.jpeg" { at 3in, 5.5in }; };
>
> I haven't been through the parser to see whether the skeleton of this is
> already there, but I hope the requirement is clear enough.

That's sort of what I had in mind, except that I was going to require
that the images come from an input section.

Though now that I think about it, requiring an input section is clunky,
and so it should be possible anywhere an image is needed to *either*
reference an input section, or have the file/page information inline.

Best regards,
Eric