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 16:45:43 -0700
Message-ID: <E583503B7F57D41196A600D0B76FDDD54B29B5@cpex2.channelpoint.com>
To: "'Nikolai Grigoriev '" <grig@renderx.com>, "'www-xsl-fo@w3.org '" <www-xsl-fo@w3.org>
 
How about this as a compromise:

Add a custom attribute to fo:wrapper to denote an outline entry. e.g.

<fo:wrapper pdf:outline-label="Section 1">
  <fo:block>Section 1</fo:block>
  <fo:wrapper pdf:outline-label="Subsection 1.1">
     <fo:block>Subsection 1.1</fo:block>
  </fo:wrapper>
</fo:wrapper>

Then we get a spec-compliant solution with no loose interpretation of the
xslt tree bit, and we don't overload the fo:marker with an additional use. 

Comments?

-Kelly

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

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 18:47:17 GMT

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