Hi there,
I'm trying to use fop (2.1) to generate accessible pdf files. My document 
source is docbook5 that is transformed to
xsl-fo and then processed with fop to pdf.
The official docbook5-xsl files often generate deep nested fo:block structures 
like the following example:

<fo:block>
   <fo:block>
      <fo:block ...>
         <fo:block keep-with-next.within-column="always">
            <fo:block ...>
               <fo:marker marker-class-name="section.head.marker">Level 
1</fo:marker>
               <fo:block font-size="20.735999999999997pt">1.1. Level 
1</fo:block>
            </fo:block>
         </fo:block>
      </fo:block>
   </fo:block>
   <fo:block/>
</fo:block>

This code also generates a deep nested p(aragraph) structure in the pdf file, 
because every fo:block automatically is
tagged as paragraph. I'm trying to evaluate different approaches to get rid of 
this nested structure:

1) better code generation
That's the most obvious point but the docbook-xsl files are quite complex and I 
think this goal is hard to achieve.

2) tagging the unwanted block as 'artifacts'
Is there a way to tag fo:blocks as kind of artifact, so that they are not 
recognized being part of the document
structure? The role="artifact" can only be applied to 'wrapper' and 
'static-content' structures. An explicit way to
deactivate tagging for dedicated structure elements would be nice and the 
easiest way for me.

3) merging of the fo:blocks
Another way would be merging all nested fo:blocks that only contain another 
fo:block element as child together that only
one is left which can correctly be rendered. This goal is not easy to achieve, 
because you must have an eye on the
attributes; addition/subtraction of indents and so on.

4) ??

Did I forget something? Are there other ways to get rid of this nested 
structure?

Thanks, Holger







---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Reply via email to