[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSL-FO result tree structure design

Subject: Re: XSL-FO result tree structure design
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 24 May 2012 13:05:34 -0400
Re:  XSL-FO result tree structure design
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>

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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.