Quantcast

Tagging fo:blocks as artifacts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tagging fo:blocks as artifacts

Holger Bast
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tagging fo:blocks as artifacts

Chris Bowditch
Hi Holger,

I agree the easiest solution would be to mark the unwanted blocks as
artifacts. Its a shame that FOP only supports role="artifact" on
fo:table-header and fo:table-footer :( If you were to submit a patch on
an enhancement it would be welcomed. I think this would be a good
improvement to FOP's accessibility support.

Thanks,

Chris

On 05/04/2017 21:41, Holger Bast wrote:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Aw: Re: Tagging fo:blocks as artifacts

Chris Bowditch
Hi Holger,

I'm happy to advise you, but please lets keep FOP related stuff on list.

The basic info you need for setting up a FOP Dev environment is here:
https://xmlgraphics.apache.org/fop/dev/

The latest FOP versions are developed using Maven, which makes importing
the source code into your favorite IDE a one click process. I personally
use IntelliJ, but others use Eclipse or Netbeans

Thanks,

Chris

On 12/04/2017 09:04, Holger Bast wrote:

> Hey Chris,
> thx for your mail.
> The last time I programmed in Java was more then 10 years ago. But I would try implementing this feature.
> What do I need for that? Toolchain? Repository?
>
> Bye, Holger
>
>
>> Gesendet: Montag, 10. April 2017 um 10:14 Uhr
>> Von: Chris <[hidden email]>
>> An: "[hidden email]" <[hidden email]>
>> Betreff: Re: Tagging fo:blocks as artifacts
>>
>> Hi Holger,
>>
>> I agree the easiest solution would be to mark the unwanted blocks as
>> artifacts. Its a shame that FOP only supports role="artifact" on
>> fo:table-header and fo:table-footer :( If you were to submit a patch on
>> an enhancement it would be welcomed. I think this would be a good
>> improvement to FOP's accessibility support.
>>
>> Thanks,
>>
>> Chris
>>
>> On 05/04/2017 21:41, Holger Bast wrote:
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>> .
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Loading...