xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris <bowditch_ch...@hotmail.com>
Subject Re: Aw: Re: Tagging fo:blocks as artifacts
Date Wed, 12 Apr 2017 08:31:00 GMT
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 <bowditch_chris@hotmail.com>
>> An: "fop-users@xmlgraphics.apache.org" <fop-users@xmlgraphics.apache.org>
>> 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: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>
>>> .
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>>
> .
>

Mime
View raw message