This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This question applies at least to fo:folio-prefix, fo:folio-suffix, but also seems to apply to fo:index-page-number-prefix, fo:index-page-number-suffix, fo:index-page-citation-list-separator, and fo:index-page-citation-range-separator. Each of these objects has the following content model: (#PCDATA | %inline;)*. The question: From whom do the child objects inherit properties? The use of the term "static" for some of these seems to imply that they inherit normally, that is, by reference to their ancestors in the tree. However, that seems unlikely. It is easy, for example, to imagine an fo:page-number-citation with a 12-point "Glossary-" prefix surrounded by 10-point text in a footnote. Am I correct to assume that instead this content should be "grafted" in a manner similar to the way that fo:marker content inherits from the fo:retrieve-marker that it replaces? Or would the fo:page-number-citation need to explicitly set the font-size to the correct value?
From http://lists.w3.org/Archives/Public/xsl-editors/2007JulSep/0010.html: I have an additional question pertinent to this thread. The content models for fo:folio-prefix and fo:folio-suffix seem to be inconsistent with the "Areas" description for fo:page-number, fo:page-number-citation, and fo:page-number-citation-last. (A similar issue may exist for the index-related formatting objects as well, but I can't yet see for sure). Each of these "Areas" descriptions indicates that the object "generates and returns a single normal inline-area". If this is true, then it seems that no block-level objects should be allowed as descendants of fo:folio-prefix and fo:folio-suffix. Although block-level objects are currently prohibited as immediate descendants (children), they would currently be permitted in succeeding generations as children of fo:basic-link, fo:inline-container, etc. On the other hand, if block-level descendants are permitted, then I think those objects needs to be have an "Areas" description similar to that for fo:inline, that is: "... generates one or more normal inline-areas. The [object] returns these areas together with any normal block-areas ... returned by the children of the [object]."
Proposal for clarification: -------------------------------------------------- 1) Add to the end of the last sentence The fo:folio-prefix formatting object does not directly produce any areas. Its children will be retrieved and used when formatting page numbers. in the areas section of 6.6.13, 6.6.14 (fo:folio-prefix and -suffix) the text: ", as described in 6.6.10 and 6.10.7." 2) Add to the end of the last sentence The fo:index-page-number-prefix formatting object does not directly produce any areas. Its children will be retrieved and used by fo:index-page-citation-list when formatting cited page items and cited page item ranges. in the areas section of 6.10.2, 6.10.3, 6.10.8, and 6.10.9 fo:index-page-number-prefix, fo:index-page-number-suffix, fo:index-page-citation-list-separator, and fo:index-page-citation-range-separator the text: ", as described in 6.10.7." ------------------------------------------------ In accordance with the instructions at http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html#verify, please review the proposed resolution carefully and let the Working Group know whether it's acceptable or not.
I don't see that the proposed clarification answers either of the two questions posed: 1. From whom do the child objects inherit properties? Absent any clarification here, I understand the answer to be that they inherit from ancestors in the FO tree instead (as I thought more reasonable) from the page-number or page-number-citation objects that they are grafted into. This answer would seem to make these constructs useless, or at least very awkward to use. However, it is certainly possible to implement it this way, so I consider this part of the question to be closed. 2. How do you get block content to fit into a "single normal inline-area"? As far as I can tell, this requirement is NOT possible to implement, with or without the clarification offered, so I would ask the WG to please further clarify what is supposed to happen here. For example, admittedly contrived, assuming that the fo:folio-prefix shown belongs to the reference-page-sequence of the fo:page-number-citation shown: ... <fo:folio-prefix> Volume <fo:inline> <fo:block>The Rise and Fall of the Roman Empire</fo:block> <fo:inline> </fo:folio-prefix> ... <fo:block>... on page <fo:page-number-citation>.</fo:block> The fo:inline shown returns "one or more normal inline-areas ... together with any normal block-areas, page-level-out-of-line areas, and reference-level-out-of-line areas returned by the children of the fo:inline". How does an implementation go about making all of this fit into the "single normal inline-area" that the fo:page-number-citation generates and returns?