[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: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 24 May 2012 13:05:34 -0400

The transformed FO output reflects containers within containers within
the body flow (I use the id for reading ease, not in actual output):
<block id="chapter">
      <block id="sect1">
         <block id="sect2">
             <block id="para">A lonely para in a cruel sect2.</block>
         </block>
     </block>
</block>

The above approach might be important for constructs that need to know the extent of objects under influence, for example, indexing.


The second way is to create loose blocks, outside of other containing
blocks, where possible.
Example 2: Loose Blocks (I don't mean blocks that are immoral) - result FO:

<block id="chapter"/>
<block id="sect1"/>
<block id="sect2"/>
<block id="para">A lonely para in a cruel sect2.</block>

For the above you will likely need something like:


<block id="chapter" keep-with-next="always"/>
<block id="sect1" keep-with-next="always"/>
<block id="sect2" keep-with-next="always"/>
<block id="para">A lonely para in a cruel sect2.</block>

... so that if the paragraph is dragged to the next page due to widows and orphans, all of the blocks are dragged along with it. This would be important for, say, jumping to the first page of the chapter and ending up on the same page as the first paragraph.

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?

I'm not an implementer, so I can't comment on that.


2) Are there specific risks or benefits to using one of these two methods?

Not that I can think of. A block produces an area. You might use <wrapper> if the reason you are using blocks is only to add formatting properties to the tree. That way the object tree is annotated as you need, but you aren't asking the processor to create any areas, per se, for the chapters and sections.


3) Are there other methods I am missing? Hybrid, etc.

I've not encountered processing problems on my customers' projects when I've used other processors. I've not used the Arbortext engine so I cannot say if it would have had problems in those cases.


But I do try to think "do I need an area for this construct?" when I write XSL-FO ... if not, I'll use a wrapper in order to specify inherited properties. Of course using wrapper for non-inherited properties is useless, so you'll need <block> or <inline> instead of <wrapper> for non-inherited properties like baseline-shift=.

I hope this helps.

. . . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


Current Thread
Keywords