Re: FW: Action: Replies to Glen Mazza's comments on Bookmarks

Hello Steve,

--- Steve Zilles <szilles@adobe.com> wrote:
> Sorry for the long delay in answering your comment,
> I was on vacation for 
> the month of February and came back to series of
> meetings.
> 

Thanks for your response, and sorry for my own delay
here.


> >
> >I am unsure here -- please check this one again. 
> Note
> >that the content model for fo:bookmark-tree is only
> >(#PCDATA) (no %inline; or %block;), so at least the
> >second constraint (about child inline areas)
> appears
> >not to be relevant.
> 
> #PCDATA is converted to a sequence of fo:characters
> which
> generate glyph-areas which are child inline-areas,
> see
> 
>    4.2.1 Area Types
>    There are two types of areas: block-areas and
> inline-areas.
>    [...]
>    A glyph-area is a special kind of inline-area
> which has
>    no child areas, and has a single glyph image as
> its content.
> 
> Therefore, it is appropriate that the second
> constraint apply.
> 

Yes, of course, thanks for clarifying this for me.  (I
was unsure of the PCDATA -> Area creation.)


> >[Another issue:  I can't seem to find the email
> now,
> >but someone in the Working Group about a year or so
> >ago mentioned that the usual descriptions of FO's
> >generating and returning areas are not really
> relevant
> >for the bookmark FO's because they are off-document
> >items.  I'm inclined to agree with that
> idea--having
> >an Areas returned description and Constraints
> related
> >to areas for the bookmark FO's are somewhat
> confusing,
> >because these FO's don't appear to be really part
> of
> >the Area Model--but rather external pointers to
> it.]
> 
> The point is not whether something is "off document"
> or not, 

Actually it may have some relevance, because the area
model seems to be not just about the formatting of
individual items, but how they interact with each
other in order to form a hierarchical arrangement of
areas--i.e. the area tree.  Bookmarks are not part of
the area tree--the sample tree given[1] for example
has no "bookmark-viewport-area" descending from
fo:root (nor is any such area defined), just
page-viewport-areas.   

My concern is that having FO's that create
off-document items--fo:bookmarks, (PDF) document
properties (name, author, version, etc.), possibly
fo:title--be considered as FO's creating/returning
areas may end up corrupting the area model
definition--see for example the page geometry
described in the rendering model (Section 4.9 [2]).

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#area-tree-sample

[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#rendmodel


> but whether a 
> formatted displayable result is produced. 
> The
> bookmark-title is intended to 
> be formatted into displayable form and, therefore,
> the normal area model 
> rules are applicable to it.

OK, but even with this official interpretation, a
reasonable argument could be made that bookmarks
should still be treated as auxiliary objects rather
than objects creating/returning areas, given:

1.)  We are not (manually) formatting bookmarks,
rather, bookmarks are function calls to the user
agent--with limited parameters for desired font and
style--for the UA to display them in a UA-determined
manner.  Too much of the physical appearance of
bookmarks--e.g., the graphics and dotted lines between
them, etc.--is out of control of both the stylesheet
writer and the XSL implementation.

2.)  Unlike areas in the area tree, there is no
"future-proofing" for the formatting occurring--newer
versions of the UA can take the same fo:bookmark
information and display them differently (e.g., use
different icons for the open/close graphics, etc.)

3.)  Too many of the area model rules (borders,
padding, stacking) for bookmarks would be handled by
the UA--but it is not the responsibility of the UA to
be conformant with the XSL recommendation, nor can the
XSL implementation have control over this.

This issue has little practical significance for 
implementors, however, so the SG's current
interpretation is acceptable for me.

Thanks,
Glen

Received on Sunday, 20 March 2005 21:05:38 UTC