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

Thanks Steve for your thorough response--my comments
below:

--- Steve Zilles wrote:
> 
> should be removed and the following "constraint"
> should be
> added to 
> fo:basic-link and fo: bookmark:
> 
>    One of the external-destination and
> internal-destination
>    properties should be specified. If both are
> specified,
>    the system may either report it as an error, or
> use the
>    internal-destination property.
> 

I don't think that will work for bookmarks, because 
bookmarks activating another document may need both
properties to be set.[1]  I would recommend rephrasing
the above for bookmarks to something similar to:

If both external-destination and internal-destination
are specified, the external-destination refers to the
file to activate, while the internal-destination
refers to the destination within that file to
activate.  If external-destination is not specified,
then internal-destination is a destination within the
same document that the bookmark is in.

[1] PDF 1.5 Reference, Section 8.5.3 Action Types -
Remote Go-To Actions, Table 8.44, Keys "F"--file and
"D"--destination.


> 	34.)  Section 6.11.3 fo:bookmark-title [7]:  You
> may wish to
> consider removing the value space limitations placed
> on the font-style
> and font-weight properties, leaving it up to the XSL
> implementations of
> how they wish to handle unsupported or unavailable
> fonts-styles and/or
> font-weights, as they have to do already for fonts
> within regular text.
> 	
<snip/>

> The reason for putting the value space limitations
> on bookmark-title was
> to encourage interoperabilty of implementations.
> Informal surveys showed
> that implementations only supported the limited
> value space, so that
> restricting the value space would more likely insure
> interoperability.

OK.


> 
> 	49.)  Section 6.11.3,
> 	fo:bookmark-title, the two
> 	statements listed in the Constraints section appear
> to
> 	be duplicated from fo:bookmark, and are not
> relevant
> 	for this FO.
> 	
> 
> It is indeed likely that these constraints were
> duplicated from
> bookmark, but they are relevant to the
> fo:bookmark-title and the fix is
> to change "bookmark" to "bookmark-title" in the two
> constraints. 
> 

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.  But again I am unsure.

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


> 	51.)  Section 7.22.10 Property starting-state [2],
> The initial
> value of "show" for this property should be switched
> to "hide" instead,
> for reasons relating to the two FO's--fo:bookmark
> and
> fo:multi-case--that this property applies to: a.) 

> 
> While the Working Group notes that the value "hide"
> might be
> useful to users of bookmarks, the property

*might* is the key word here.  Since writing this
suggestion, I have researched that Arbortext (via its
reliance on the present starting-state value) and the
AntennaHouse PDF extension both have "show" by
default, which I think makes sense for smaller
documents with only a few bookmarks.  (e.g., Shrinking
a small set of five or six bookmarks into just two
top-level bookmarks doesn't look very good.)

I am still inclined to think, however, that "hide" is
preferable as the document size and number of
bookmarks increase.  But if this ever becomes a
problem, I suspect that the various XSL
implementations will just come up with a simple
starting-state-override="hide" extension property on
fo:bookmark-tree, allowing (say) a 200-bookmark
document to show only top-level bookmarks by default
without needing to manually specify this on every
bookmark that has child bookmarks.  So I am not much
concerned about this issue anymore.

> "starting-state"
> already has an initial value of "show" and this
> value is 
> the only reasonable initial value for fo:multi-case.

I guess the issue boils down to: if the user does not
explicitly specify a starting-state="show" on any
fo:multi-case, should the first option show by default
(initial-value="show") or no option at all
(initial-value="hide").  My inclination is still the
latter, but I certainly understand the SG's concern
about backwards compatibility.


> (Unless
> a multi-switch shows some case, there will often be
> no way
> to toggle to some other case.)
> 

Well, a UA still has to take that into account should
the user explicitly select "hide" for all options, as
the spec allows him/her to do should he/she want no
option viewed.


> The Working Group tries to avoid having properties
> where the
> initial value depends on the context of use. This
> makes parsing
> more difficult and creates very large problems when
> an initial
> value is inherited.
> 

Of course.


> Another important factor here is backwards
> compatabiltiy with
> previous versions. 
> Therefore, to preserve
> compatibility with
> the existing usage of "starting-state" the XSL 1.1
> specification
> will retain the original initial value specified in
> XSL 1.0.
> 
> 

OK.  I'm not that much concerned about it
anymore--again, if FOP gets many complaints I presume
we'll just place an extension property on
fo:bookmark-tree to allow showing only the top-level
bookmarks by default. 

Thanks!
Glen