[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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> </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: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|