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: Sat, 3 Feb 2001 23:55:44 +0300
Message-ID: <023d01c08e24$40fe7a40$0a01a8c0@grig>
To: <www-xsl-fo@w3.org>
Kelly,

> First, markers are meant to be retrieved in static-content.

I cannot grasp why this hinders us. Markers are pieces of contents associated
with areas in the area tree. That's how they are going to be used in my
proposal, the semantics didn't change. If you use a marker with a
marker-class-name that has no correspondent retrieve-class-name, it would be
lost; but placing it into the document file is not prohibited by the spec. To
retrieve or not to retrieve is at your option. (If I had proposed to redefine
the semantics of fo:retrieve-marker, this would be a real crime - but I didn't
:-)).

> A bookmark marker would have an implicit retrieval by
> the rendering agent which is not specified anywhere except
> in our use of it.

The same is true for any extension. As far as the spec cannot deal with outlines
(it specifies only what happens on a page), every attempt to create bookmarks
will result in introduction of entities not specified anywhere. (By "entity" I
mean "ens  entis", not "&entity;" :-)).

By the definition of @role property, it can bear semantics specific to a
rendering agent. In my proposal, I use this property to instruct the renderer to
pick up a piece of contents that would otherwise be dropped, and use it for
purposes that don't interfere with the formatting. I don't feel I am abusing it.

> Second, I don't see how it
> allows us to keep the hierarchy of the bookmarks from
> the parent formatting objects.

Markers are ascribed to areas, and areas are intrinsically ordered in a tree.
This is true for normal markers, too.

> 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>

Then you will be required to insert an extra empty fo:wrapper (of an fo:block -
it does not make difference in this case) around each of the structural units,
like this:

<fo:wrapper>
  <fo:marker role="bookmark">Section Heading 1</fo:marker>
  <fo:block>Section Heading 1</fo:block>
    ... text of Section 1 ...
   <fo:wrapper>
      <fo:marker role="bookmark">Section Subheading 1.1</fo:marker>
      <fo:block>Section Subheading 1.1</fo:block>
    ... text of Subsection 1.1 ...
   </fo:wrapper>
</fo:wrapper>

This cannot be avoided in your solution, too; you wrap sections/subsections into
fop:toc, don't you?

BTW: have you noticed the similarity between this structure and your nested
fop:toc elements? In fact, the two patterns are isomorphic: I use fo:wrapper
instead of your fop:toc, and put your @label into #PCDATA inside an fo:marker.
So the difference in only in the choice of elements to convey this information,
the overhead for a stylesheet writer will be essentially the same.

> 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>
> </fo:block>

In my proposal, you are not expected to create structures like this (see above).
However, once you want to use XSLFO natural arborescence to set a bookmark
hierarchy, you cannot help designating some elements to delimit logical
divisions (fop:toc in your case, any FO that is a parent of an
fo:marker[@role='bookmark'] in mine).

> Thirdly, using fo:marker with a special role isn't as transparent as
> we might think because FO processors understand and handle fo:marker,

They are still free to handle these bookmarking fo:markers for their main
purpose. If you remember, this was one of the presumed strengths of my proposal.

> where they can completely ignore elements in a different
> namespace.

??? Sounds new to me. I have read in the spec that "an element from the XSL
namespace may have any attribute not from the XSL namespace" [XSL CR 2.2]. But
this applies to elements only; there is nothing about the possibility to have
elements outside the XSLFO namespace scattered throughout the document.

Moreover: ignoring an element normally means dropping it completely. You will
then lose everything inside your fop:toc elements. Pasting element's children
instead of it in a formatting tree is not an evident operation.

> FOP currently does this correctly.

I am not sure if this is really correct.

> 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.

Section 2.1. of the FO spec is empty - it contains nothing but a reference to
the XSLT spec. To which part of it are you referring?

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

XEP has a bad habit to validate its input; using unknown elements knocks it down
with a validation error message. If you are concerned about portability, yours
does not seem a happy solution to me.

Regards,
Nikolai
Received on Saturday, 3 February 2001 16:01:55 GMT

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