On Thu, May 24, 2012 5:51 pm, Michael Friedman wrote:
...
<block id="chapter"/>
<block id="sect1"/>
<block id="sect2"/>
<block id="para">A lonely para in a cruel sect2.</block>
Moving to this approach would require redesigning the stylesheets to
recognize key elements, I think - I haven't thought down this road too
far yet, and it may be moot to do so.
Finally, my questions, based on the above, and my limited knowledge on
how the Arbortext PE (and FO processors) work:
1) Is there a preferred method in result tree design that FO
processors prefer, especially related to memory allocation or
chunking?
There are no hard and fast rules about how a XSL-FO processor manages
memory: a processor might keep the whole document in memory, discard each
fo:page-sequence and its associated area tree at the end of processing the
page sequence, or it might write out an intermediate file for two-pass
processing of long documents, and a processor might support multiple modes
depending its command line (or other) parameters.
2) Are there specific risks or benefits to using one of these two methods?
3) Are there other methods I am missing? Hybrid, etc.
If you only want the chapter and sections for their IDs, you could put a
fo:wrapper for each in the first FO containing text:
<block id="para"><wrapper id="chapter"/><wrapper id="sect1"/><wrapper
id="sect2"/>A lonely para in a cruel sect2.</block>
Putting <wrapper id="chapter"/>, etc., before the fo:block might seem like
a good idea, but if the fo:wrapper is in a context where only block-areas
are allowed, each empty fo:wrapper with an "id" property will generate a
block area [1] so you'll see your text slipping down the page with each
added <fo:wrapper id="..."/> [2].
If the fo:block for chapters and sections have properties that you've
elided for brevity, then you probably do need each of the fo:block unless
you're up for a bit of do-it-yourself resolving of property values on the
first and last visible block in the XSLT that creates the XSL-FO markup.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL-FO and XSLT consulting, training and programming
[1] http://www.w3.org/TR/xsl11/#fo_wrapper
[2] Though you could play tricks like putting each in a fo:block-container
with a different z-index
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--