[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSL-FO result tree structure design

Subject: Re: [xsl] XSL-FO result tree structure design
From: "Tony Graham" <tgraham@xxxxxxxxxx>
Date: Thu, 24 May 2012 18:20:49 +0100 (IST)

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.


Tony Graham                                   tgraham@xxxxxxxxxx
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

Current Thread