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

At first glance I like this a lot. "role" is intended for rendering hints,
as I understand it, which is precisely what we are using it for here (if one
extends "rendering" to mean not only page markup but also anything that
might go into the final document).

The only question I would have is, I don't think the spec as it is currently
set up, allows for a "role" property to be placed on fo:marker. The prose
accompanying this property states that "role" can be applied to any FO
contained within fo:flow or fo:static-content; I'm uncertain as to what they
mean by "contain", but it looks more like any FO that could be a child of
fo:flow or fo:static-content, as opposed to any FO that could be a
descendant. Common Accessibility properties are certainly explicitly
specified on many FO's, so unless the spec is completely random I would have
to assume that the absence of Common Accessibility properties on an FO means
that you don't use them.

I tend to argue for strict interpretation of the spec, but I hope you
understand that in this case I'm just pointing out a possible issue.
Personally I think fo:marker should have this property, because its use in
this situation makes sense. I'd be willing to add my support to a
representation to the XSL WG about this one, if you choose to make such a
representation. We could of course just go with what we are allowed to do by
Section 2.2, and use a property (attribute from other namespace on an XSL
element) of our own devising in exactly the fashion you describe.

Regards,
Arved

----- Original Message -----
From: Nikolai Grigoriev <grig@renderx.com>
To: <www-xsl-fo@w3.org>
Sent: Saturday, February 03, 2001 12:00 PM
Subject: PDF bookmarks (was: Re: extensions to FO)


> Kelly, David,
>
> > The problem I have with this syntax is it's depending on the
bookmark-level
> > 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
added
> > 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
can
> 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 contrary,
> 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 parent
> objects of the respective markers - in exactly the same way as it occurs
for
> "normal" markers. This is restrictive with respect to what can be
expressed by
> bookmarks in PDF (there, bookmark sequence and hierarchy can be completely
> unrelated to the arrangement of the document locations pointed to by the
> bookmarks). My opinion is that this is not very critical - all "normal"
bookmark
> usages are like table-of-contents to outline the physical structure of the
> document, and this is captured (and enforced) perfectly with this
proposal.
> At worst, one can add a couple of extension attributes to specify the
parent
> 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 chapter
> would begin like this:
>
> <fo:block>
>   <fo:marker marker-class-name="chapter"
>       role="bookmark">1 Introduction</fo:marker>
>   <fo:block font-weight="bold">1 Introduction</fo:block>
> ...
> </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.
>
> Regards,
> Nikolai
>
>
>
>
>
>
>
>
>

Received on Saturday, 3 February 2001 12:14:51 UTC