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

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

From: Kelly Campbell <camk@channelpoint.com>
Date: Sat, 3 Feb 2001 12:30:27 -0700
Message-ID: <E583503B7F57D41196A600D0B76FDDD54B29B3@cpex2.channelpoint.com>
To: "'Nikolai Grigoriev '" <grig@renderx.com>, "'www-xsl-fo@w3.org '" <www-xsl-fo@w3.org>
  I tend to disagree with the use of fo:marker for this. First, markers
are meant to be retrieved in static-content. A bookmark marker would
have an implicit retrieval by the rendering agent which is not
specified anywhere except in our use of it. Second, I don't see how it
allows us to keep the hierarchy of the bookmarks from the parent
formatting objects.

In the typical use I've seen from many stylesheets, you have
<fo:blocks> which are siblings in the FO tree, but whose content might
be semantically hierarchical:

<fo:block>Section Heading 1</fo:block>
<fo:block>Section Subheading 1.1</fo:block>

I think a solution for the bookmarks should not impose hierarchy
requirements on the formatting objects themselves, e.g. you shouldn't
have to have:

<fo:block>Section Heading 1
<fo:block>Section Subheading 1.1</fo:block>

Thirdly, using fo:marker with a special role isn't as transparent as
we might think because FO processors understand and handle fo:marker,
where they can completely ignore elements in a different
namespace. FOP currently does this correctly. I was able to place
several levels of fop:outline elements in an FO file and FOP ignored
the elements it didn't know. I think this is a valid tree according to
my (loose) interpretation of Section 2.1 of the FO spec.

I implemented bookmark support in FOP yesterday and it works well with
the structure I gave as an example on this list. I did have some minor
issues implementing the tree building in FOP such that elements from
the extension namespace don't impose on the tree built from elements
in the FO namespace, but I have implemented it and bookmarks now work
somewhat well in FOP. I am still working on making sure it doesn't
affect processing of other FO files, and there are some issues of
where within a page the bookmark should point to that I need to
solve. I will discuss the specifics of my implementation on the
FOP-dev list so that people there can comment on whether or not we
want it committed to the repository.

I am interested to know how such a tree with unknown elements will
affect other implementations.


-----Original Message-----
From: Nikolai Grigoriev
To: www-xsl-fo@w3.org
Sent: 2/3/01 9:00 AM
Subject: PDF bookmarks (was: Re: extensions to FO)

Kelly, David,

> The problem I have with this syntax is it's depending on the
> attribute to determine where it is in the hierarchy rather than just
using a
> hierarchy via XML. I'm assuming that a bookmark with level 2 is just
> to the previous bookmark with a level="1". I think using the inherent
> hierarchy structures available with XML would be a nicer solution.

I concur. Moreover, I think it the particular case of PDF bookmarks, we
implement them within the XSL CR. I have already proposed this idea to
Sebastian some months ago; it seemed to me that he wasn't really
so I retry  :-).

My proposal is to use fo:markers  with a special role - like this:

<fo:marker role="bookmark">1 Introduction</fo:marker>

The hierarchy of bookmarks will be established by the hierarchy of
objects of the respective markers - in exactly the same way as it occurs
"normal" markers. This is restrictive with respect to what can be
expressed by
bookmarks in PDF (there, bookmark sequence and hierarchy can be
unrelated to the arrangement of the document locations pointed to by the
bookmarks). My opinion is that this is not very critical - all "normal"
usages are like table-of-contents to outline the physical structure of
document, and this is captured (and enforced) perfectly with this
At worst, one can add a couple of extension attributes to specify the
and the preceding entry in the outline tree, or introduce a more complex
syntax inside the "role" attribute".

A further (small) advantage of such a solution is that you will be able
to use one and the same element for bookmarks and running headers
(if you like; if you don't, you are free not to do it). A typical
would begin like this:

  <fo:marker marker-class-name="chapter"
      role="bookmark">1 Introduction</fo:marker>
  <fo:block font-weight="bold">1 Introduction</fo:block>

Another advantage: an application that does not support bookmarking will
need no extra effort to ignore it - fo:markers are invisible :-).

Comments are appreciated.

Received on Saturday, 3 February 2001 14:31:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:06:08 GMT