W3C home > Mailing lists > Public > www-xsl-fo@w3.org > February 2001

Re: PDF bookmarks (was: Re: extensions to FO)

From: Nikolai Grigoriev <grig@renderx.com>
Date: Sun, 4 Feb 2001 20:56:06 +0300
Message-ID: <016601c08ed4$12ee4530$0a01a8c0@grig>
To: <www-xsl-fo@w3.org>

Here's yet another essay about representing bookmarks :-).

I see the following problems with various ways proposed to encode PDF bookmarks:

1) The semantics of existing formatting objects should not
   be redefined nor extended. This is a drawback of my
   proposal (using fo:markers);

2) The bookmark hierarchy tree need not be isomorphic
   to the document structure. This is a limitation of Kelly's
   proposal (using pdf:outline-label attribute) and mine;

3) The contents of the bookmark label should not be
   restricted to plain text (even though it can only be
   plain text in PDF right now) - for extensibility's sake.
   This is a weak point of Kelly's proposal;

4) Using explicit, LISP-like data structures to
   encode tree hierarchy is unnatural in XML.
   This is a problem with Sebastian's current implementation
   of fotex:bookmark.

Thinking it over a while, I am inclined to support David Carlisle proposal:

> Actually I'd rather have specific bookmark constructors that
> are placed at the beginning of the file, not tied to section
> fo:blocks.

What if we create a separate bookmark tree as a top-level element outside
fo:page-sequences (e.g. immediately after fo:declarations), like a table of

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"

  <fox:bookmark internal-destination="whole-document">
     <fox:label>My Document</fox:label>
     <fox:bookmark internal-destination="intro">
     <fox:bookmark internal-destination="sect-1">
        <fox:label>Section 1 Title</fox:label>
        <fox:bookmark internal-destination="subsect-1-1">
           <fox:label>Subsection 1.1 Title</fox:label>

  <fo:page-sequence .....>
  ... ... ... ...

The "fox:" prefix stands for "FO eXtensions" :-).
The features are:

1) No standard elements are redefined - only extension
   elements are used.
2) The whole thing is atomic - dropping it as a whole
   makes no damage.
3) The tree ordering of bookmarks is imposed by the syntax.
4) The bookmark tree is arbitrary, and not constrained by
   the logical structure of divisions in the document.
5) (implementation-specific) The implementation is similar
   to fo:basic-link[@internal-destination] - activation
   behaviour is essentially the same.

What do you think of it?

Received on Sunday, 4 February 2001 13:00:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:52 UTC